Dies ist die Fortsetzung von Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Autor: Hayo W. (blueflash) Datum: 10.09.2011 00:56 eProfi schrieb: >> ...wenn man die Helligkeit genug aufdrehte, sah man auch bei >> nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der >> aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob >> man den Tastkopf gut kontaktiert hat. >> Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der >> immer bei x=0 den aktuellen DAC-Wert anzeigt. >Sorry, das hab ich irgendwie nicht so ganz verstanden. Die Höhe der >aktuellen Eingangsspannung in negativer oder positiver Richtung oder wie >ist das gemeint. Ich kann mir da nichts drunter vorstellen. Du hast >nicht zufällig ein Bild davon? Ein Beispiel: Du misst im Normal-Trigger einen Signal, das zwischen 2 und 3V schwankt und ab und zu Spikes bis 5V hat, auf die Du triggern willst. Nun siehst Du wg. fehlendem Trigger nicht, ob der Tastkopf richtig sitzt. Deshalb wäre es praktisch, wenn auch ohne Trigger bei x=0 (am linken Grid-Rand) die Eingangsspannung immer als Punkt dargestellt würde, sozusagen als senkrecht stehendes Multimeter. Dann siehst Du sofort an diesem Punkt, ob der Tastkopf richtig Kontakt macht und wie hoch die Spannung ist. >> Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit >> viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall >> ist mir der Unterschied AUTO und COMBI nicht klar. > >Was Michael erklärt ist schon ganz richtig, aber Auto und Combi arbeiten >im Prinzip gleich. Wenn nach einer bestimmten Zeit kein Triggerereignis >eintritt wird das Signal trotzdem ausgegeben. Der Unterschied liegt im >Timeout. Der Combitrigger hat einen wesentlich längeren Timeout so daß >auch langsamere Signal zuverlässig getriggert werden. Der Autotrigger >arbeitet leider nur bei schnellen Signalen ganz brauchbar. Ist diese Timeout-Zeit einstellbar? Das würde ich zusammen mit der Holdoff-Time so auswählbar machen, ob man eine feste konstante Zeit oder eine bestimmte Anzahl von Kästchen eingeben will. Nochmal: AutoTrigTime: Zeit, nach der der Strahl wieder startet, auch wenn kein Trigger kam. HoldOffTime: Zeit, wie lange nach dem aktuellen Strahlende auf jeden Fall nicht getriggert wird, auch wenn ein Trigger kam. Sitzt der Auto-Trigger im FPGA? Zu den Geschichten mit der Drehrichtung von Knöpfen: einfach alles einstellbar machen. Zu den Drehgebern, die bisher keine Taster hatten: seht Ihr da eine Möglichkeit, nachträglich welche mit Taster einzubauen, oder ist die Auswertung der 4 noch freien Eingänge 10-12,14 (die noch keine Pullups haben) am U9 im FPGA nicht unterstützt? Autor: branadic (Gast) Datum: 02.10.2011 12:33 Ich denke auch, dass zwischen den Samples und den Pixeln einfach eine Formel y=offset + sample * scalefactor (z.B. 8x16-->24Bit-FixedPoint-Mul, nur die oberen 8 Bit des Ergebnisses nutzen) stehen sollte. Damit kann man auch das Invertieren frei wählen, indem man scalefactor negativ macht. Beide Variablen stufenlos frei eingebbar machen, aus scalefactor den Wert V/div berechnen und fertig ist der y-Zoom. Ich finde es einfach praktisch, wenn man z.B. ein Rechtecksignal mit genau einem Kästchen Höhe darstellen kann (das selbe gilt auch für x-Zoom). Da der Gain des LHM scheinbar fein eingestellt werden kann, bietet es sich an, den ADC möglichst FullScale zu nutzen.
Hallo Hayo, Erst mal Herzlichen Dank fur was Sie alles fur die Wittig W20xx gemacht haben. Dadurch wird dieses gerat bestimmt viel besser. Habe mit Jörg schon gemaild, und werde einige Teile von Ihn kaufen. Gruß Gertjan.
eProfi schrieb: > Da der Gain des LHM scheinbar fein eingestellt werden kann, bietet es > sich an, den ADC möglichst FullScale zu nutzen. Den ADCc Fullscale zu betreiben klingt zunächst zwar verlockend, macht aber bei genauer Betrachtung wenig Sinn, man sollte immer etwas Reserve haben, um nicht in der Sättigung des Eingangsverstärkers zu liegen. Das wird übrigens auch bei professionellen Geräten so gehandhabt. Als Beispiel, das Tektronix TDS5104B zeigt auf dem sichtbaren Bereich sogar nur 200 Samples an, der Rest ist Reserve außerhalb des Bildschirmes. Angenommen du möchtest dir von einer Flanke die Basis anschauen, dann wirst du dazu verleitet sein das Signal nach oben zu kurbeln. Geht der Eingangsverstärker nun in die Sättigung wird sich auch die Basis deines Signales, dass du ja betrachten möchtest, stark verändern und nicht mehr der Realität entsprechen. Darüber hinaus ist es mit der Huckepackplatine auch gar nicht möglich den ADC im Fullscale zu betreiben. Das Excelsheet zeigt was maximal möglich ist. Der max. Gain des LMH6518 beträgt 38.8dB, es kommen weitere 6.02dB durch den darauf folgenden AD8131 hinzu. Zusammen mit der Widerstandskombination an dessen Ausgang 2x 24.9R plus den 150R vor den ADC verlieren wir noch mal 2.49dB, landen damit also bei einer Gesamtverstärkung von 42.33dB. Damit ist der ADC in allen drei Ablenkbereichen (1, 2, 5) zu etwa 225LSB ausgesteuert und wir haben ca. 30 LSB Reserve. Ich denke das ist ein überaus gutes Ergebnis und der Software-Scalefactor ist mit ca 1,78 in allen drei Bereichen auch konstant. Der Rauschteppich wird damit in den 5er-Bereichen noch mal etwas verbessert und ist, was ja noch viel wichtiger ist, in den 1er und 2er Bereichen nun genauso groß wie im 5er Bereich. 240 LSB, wie ursprünglich von Walter vorgeschlagen, erreichen wir durch die Widerstandskombi nicht. Diese erachte ich jedoch als durchaus sinnvoll, um definierte Verhältnisse zu schaffen. branadic
eProfi schrieb: >>> immer bei x=0 den aktuellen DAC-Wert anzeigt. Bist Du sicher, dass Du den DAC-Wert meinst und nicht ADC? > Nun siehst Du wg. fehlendem Trigger nicht, ob der Tastkopf richtig > sitzt. Deshalb wäre es praktisch, wenn auch ohne Trigger bei x=0 (am > linken Grid-Rand) die Eingangsspannung immer als Punkt dargestellt > würde, sozusagen als senkrecht stehendes Multimeter. Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich schnell hoch und runter flitzen, Es sei denn man berechnet den Mittelwert, der aber bei einem symmetrischen Signal Null ist. > Ist diese Timeout-Zeit einstellbar? Das wäre noch eine Idee. > Sitzt der Auto-Trigger im FPGA? Ja, deswegen habe ich da auch keinen Einfluß drauf. > > Zu den Geschichten mit der Drehrichtung von Knöpfen: einfach alles > einstellbar machen. Das wird vielleicht etwas sehr aufwändig. > Zu den Drehgebern, die bisher keine Taster hatten: seht Ihr da eine > Möglichkeit, nachträglich welche mit Taster einzubauen, oder ist die > Auswertung der 4 noch freien Eingänge 10-12,14 (die noch keine Pullups > haben) am U9 im FPGA nicht unterstützt? Da kann ich momentan leider nichts zu sagen. > > Autor: branadic (Gast) Datum: 02.10.2011 12:33 > Ich denke auch, dass zwischen den Samples und den Pixeln einfach eine > Formel y=offset + sample * scalefactor (z.B. > 8x16-->24Bit-FixedPoint-Mul, nur die oberen 8 Bit des Ergebnisses > nutzen) stehen sollte. > Damit kann man auch das Invertieren frei wählen, indem man scalefactor > negativ macht. Dann steht aber das invertierte Signal nicht für weitere Berechnungen wie QM oder Math zur Verfügung. Ein stufenloser Scalefaktor wäre machbar, aber die genaue Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über die Cursor) denn die Angabe 3,76V/div hat ja nicht allzu viel praktischen Wert beim Ablesen. Gruß Hayo
branadic: Ich meine ja nicht ganz FullScale, sondern nahe an FullScale, 200-230 ist ein guter Wert. Hayo: >> immer bei x=0 den aktuellen DAC-Wert anzeigt. > Bist Du sicher, dass Du den DAC-Wert meinst und nicht ADC? Hast Recht, ADC meine ich. > Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich > schnell hoch und runter flitzen, Es sei denn man berechnet den > Mittelwert, der aber bei einem symmetrischen Signal Null ist. Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet werden. > Dann steht aber das invertierte Signal nicht für weitere > Berechnungen wie QM oder Math zur Verfügung. Wieso? Du kannst dort doch auch nochmal skalieren. > Ein stufenloser Scalefaktor wäre machbar, aber die genaue > Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über > die Cursor) denn die Angabe 3,76V/div hat ja nicht > allzu viel praktischen Wert beim Ablesen. Finde ich schon, wenn man z.B. Verhältnisse messen will.
Es gibt eine neue Version der USB-Host Firmware: http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum Die Firmware ist etwas schlanker geworden und die Stabilität wurde drastisch erhöht! Als nächstes wird die Platine weiter optimiert und die Dokumentation vervollständigt. @Hayo: bitte die UC_rle_enc ersetzten. Danke!
eProfi schrieb: > Ich meine ja nicht ganz FullScale, sondern nahe an FullScale, 200-230 > ist ein guter Wert. Das ist doch mit der Huckepackplatine gegeben! Nach dem ursprünglichem Vorschlag von Walter den ADC mit 240 LSB auszusteuern müssten die Terminierungswiderstände am Ausgang des AD8131 weggelassen werden. Dafür ergäben sich Vertikalablenkungen von: 1 mV/div - 5 V/div, entsprechend einem ADC-Aussteuerbereich von 237 - 238 LSB. Folgt man jedoch dem Vorschlag von mir mit 220 LSB, was eine Bestückung der 2x 24.9 R + 15 0R zwingend notwendig macht, ergibt sich ein Vertikalablenkungsbereich von 1 mV/div - 10 V/div, mit einem ADC-Aussteuerbereich von 224 - max. 226 LSB. Die Reserve an den ADC halte ich durchaus für zweckmäßig und sinnvoll. Der Eingangsspannungsteiler sollte, das wäre aber noch mal zu prüfen, die notwendige Spannungsfestigkeit für 10 V/div aufweisen und es wäre sicher zu stellen, dass die Eingangsspannungsteiler in diesem Fall auch wirklich beide aktiv sind. Du hast dir das Excelsheet angeschaut? Das habe ich extra erstellt, damit man die zu Grunde liegende Rechnung nachvollziehen kann. http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls branadic
eProfi schrieb: >> Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich >> schnell hoch und runter flitzen, Es sei denn man berechnet den >> Mittelwert, der aber bei einem symmetrischen Signal Null ist. > Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes > auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet > werden. Leider stehen die ADC-Werte auch nicht die ganze Zeit zur Verfügung, sondern nur nach einem Triggerereignis. Für Deinen Punkt müßte man versuchen den Pretriggerspeicher auszulesen, die ganze Aktion würde aber unter Umständen das Timing des normalen Triggerbetriebs durcheinanderbringen. > >> Dann steht aber das invertierte Signal nicht für weitere >> Berechnungen wie QM oder Math zur Verfügung. > Wieso? Du kannst dort doch auch nochmal skalieren. Das ist leider nicht so ganz einfach. Die Grafikausgabe funktioniert aus Performancegründen nicht ganz so einfach, dass jeder Punkt nach einer Formel berechnet wird, sondern es wird anhand der Skalierungsfaktoren für jeden Spannungsbereich eine Wertetabelle aufgebaut die dann für jeden ADC-Wert einen Wert enthält der die Y-Ablenkung repräsentiert. >> Ein stufenloser Scalefaktor wäre machbar, aber die genaue >> Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über >> die Cursor) denn die Angabe 3,76V/div hat ja nicht >> allzu viel praktischen Wert beim Ablesen. > Finde ich schon, wenn man z.B. Verhältnisse messen will. Der Wert wäre außerdem vom Platz her in der Statuszeile nicht unterzubringen. Man müßte sich also überlegen wie man den Wert anzeigt. Gibt es da evtl. schon etablierte Lösungen an denen man sich orientieren kann? Gruß Hayo
Kurt Bohnen schrieb: > @Hayo: > bitte die UC_rle_enc ersetzten. Danke! Ok, geht klar. Mach ich wenn ich wieder zurück bin. Gruß Hayo
Hallo Leute! Um bei der Sammelbestellung etwas Zeit zu sparen möchte ich schon jetzt die Preise festlegen. Wer also noch teilnehmen möchte und sich nicht bei mir gemeldet hat, sollte dies jetzt nachholen. Je mehr Leute sich melden desto günstiger kann der Preis werden! Wichtig: Das ist noch keine Deadline! Das Ende der Bestellannahme wird rechtzeitig und deutlich bekannt gegeben. Wer Fragen hat kann sich hier im Forum oder per mail bei mir melden. Mfg, Kurt http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder
Angehängte Dateien:
-
LeCroy800x600.png
11 KB
Hayo W. schrieb: > eProfi schrieb: > >>> Tja, aber bei einem 5 Mhz Signal würde der Punkt dann ziemlich >>> schnell hoch und runter flitzen, Es sei denn man berechnet den >>> Mittelwert, der aber bei einem symmetrischen Signal Null ist. >> Ich dachte eher an ein Gleichspannungssignal, bei dem ganz selten Spikes >> auftreten. Oder ein RS232-Signal, bei dem ab und zu Bytes gesendet >> werden. > Leider stehen die ADC-Werte auch nicht die ganze Zeit zur Verfügung, > sondern nur nach einem Triggerereignis. Für Deinen Punkt müßte man > versuchen den Pretriggerspeicher auszulesen, die ganze Aktion würde aber > unter Umständen das Timing des normalen Triggerbetriebs > durcheinanderbringen. Das darf natürlich nicht passieren. Es genügt, wenn z.B. mit 10 Hz die Spannung / der Punkt aktualisiert wird. >>> Dann steht aber das invertierte Signal nicht für weitere >>> Berechnungen wie QM oder Math zur Verfügung. >> Wieso? Du kannst dort doch auch nochmal skalieren. > Das ist leider nicht so ganz einfach. Die Grafikausgabe funktioniert aus > Performancegründen nicht ganz so einfach, dass jeder Punkt nach einer > Formel berechnet wird, sondern es wird anhand der Skalierungsfaktoren > für jeden Spannungsbereich eine Wertetabelle aufgebaut die dann für > jeden ADC-Wert einen Wert enthält der die Y-Ablenkung repräsentiert. Steht diese Wertetabelle im RAM? Dann kannst Du sie bei jeder Änderung von y-Offset oder V/div einmalig neu berechnen. Wenn ich mich recht erinnere, gibt es eine weitere Tabelle, die bei PutPixel(x,y) den y-Wert in eine Display-Adresse "umrechnet". Diese beiden Tabellen würde ich gleich in eine einzige zusammenfassen: ADC nach Adresse, das bringt Performance (ich habe jetzt nicht nachgeschaut, ob es bereits so gemacht wird). > >>> Ein stufenloser Scalefaktor wäre machbar, aber die genaue >>> Amplitudenmessung müßte man sinnvoll umsetzen (evtl. über >>> die Cursor) denn die Angabe 3,76V/div hat ja nicht >>> allzu viel praktischen Wert beim Ablesen. >> Finde ich schon, wenn man z.B. Verhältnisse messen will. > Der Wert wäre außerdem vom Platz her in der Statuszeile nicht > unterzubringen. Man müßte sich also überlegen wie man den Wert anzeigt. > Gibt es da evtl. schon etablierte Lösungen an denen man sich orientieren > kann? > Im Anhang ein 800x600-Screenshot unseres LeCroy WaveRunner. Im oberen Pane (Teilfenster) ein Signal mit 50,0µs/div, abgetastet mit 5.0 Gs/s sind das 2,5 MSamples (bei diesem Modell max. 4x 12,5MSamples)), Timebase 0µs bedeutet, dass der Triggerzeitpunkt (hellgrüner Pfeil nach oben unter dem Pane) in der x-Mitte der Anzeige ist. Das hellbraune C1 mit dem "Haken" und das hellgrüne C4 zeigen die Gnd-Level von C1 und C4 an, im Klartext auch -22.00 V ofst bzw. -193.0 mV. (0 V ist wiederum die y-Mitte des Y-Bereiches). Der hellgrüne links-Pfeil rechts vom oberen Pane ist der Triggerlevel (hier 100.0mV über C4-Gnd). Der hellgetastete Bereich der oberen Darstellung wird im unteren gezoomt (50.0mV/div 1.00 µs/div) dargestellt (die Aufteilung in Panes (wieviele Grids dargestellt werden) und die Zuordnung, welches Signal wo dargestellt wird, ist frei wählbar). Folgende Werte sind 1-2-5-stufig einstellbar: - V/div für C1-C4 - s/div für C1-C4 Folgende Werte sind stufenlos einstellbar: - Triggerlevel oben und unten (auch über die Displaygrenzen hinaus) - x-Offset C1-C4 (Triggerzeitpunkt) - x-Offset Z1-Z4 (unabhängig von C1-C4) - V/div und s/div für Z1-Z4 (unabhängig von C1-C4) - Zoombereich (y-offset) Keine Frage, dass eine solche Anzeige auf 640x480 fast unmöglich ist. (800x600 ist einer der kleinen Minuspukte des LeCroys, unser "Platz 2" (Yokogawa) hatte nämlich 1024x768).
Kurt Bohnen schrieb: > Wichtig: Das ist noch keine Deadline! Das Ende der Bestellannahme wird > rechtzeitig und deutlich bekannt gegeben. Jetzt kommt aber die Deadline: Bestellungen für Huckepack Platinen und USB-Host werden noch bis zum 16.10.2011 24:00 Uhr angenommen.
Angehängte Dateien:
-
screen-04.jpg
61 KB -
screen-03.jpg
61 KB
Hallo Hayo und alle anderen: Zwei Macken stören beim Umgang mit dem Scope: Firmware 4.5-C2 1) Lege ich ein logisches Signal (Rechteckspannung 0,5V bis 5V) an, reagiert der Trigger (Flankentrigger, egal welche Flanke) erst ab einer bestimmten Mindestsignalhöhe. So z.B. im 5V-Bereich erst ab ca. 2 Volt, im 1V-Bereich erst ab ca. 0,9 Volt. Die Höhe ist nicht reproduzierbar jedesmal gleich. So hatte ich im 1V-Bereich auch schon einmal 0,5 Volt als untere Grenze. 2) Symmetrische Dreieckspannung: 3,5Vss; 100Hz a) Trigger auf pos.Flanke (screen-04). Sobald der Triggerpegel in den negativen Bereich geht, stimmt der Triggerpunkt nicht mehr (250mV zu hoch). b) Trigger auf negative Flanke (screen-03). Wird hier der Triggerpegel in den positiven Bereich bewegt, ist der Triggerpunkt um ca. 250mV zu niederig. Ist das bei euch auch so oder gibt es das Problem nur bei mir? Gruß Manfred
Hallo Manfred, ich kann das im Moment leider nicht testen. Aber inzwischen gibt es ja die Version 1.2.BF.4.9-C2, evtl. hat sich das damit ja bereits errledigt? Gruß Robert
Hallo Manfred, wie Robert schon andeutet bitte möglichst die aktuellste Version verwenden. Allerdings sollte sich in den Zwischenversionen am Trigger nichts geändert haben. Ich werde mir das mal ansehen. Gruß Hayo
Hallo Hayo, the function 'Undo autoscale' with last FW 1.2.BF.4.9-C2 seems not working, didn't recall the previous setting.I tested with CH1,any signal.May be you are already informed? Regards, Sandro
Hi Sandro, thanks for reporting, I will check it. Regards Hayo
Hallo, liebe Welec-Kolleg(innen) Info: Habe die neueste Firmware aufgespielt. An den Triggerproblemen hat sich nichts geändert. Gruß Manfred
Angehängte Dateien:
-
Muster.jpg
120 KB
Hallo nochmal, würde obige Probleme gerne in Kauf nehmen, wenn mein DSO noch funktionieren würde. Ich will aber nicht zu früh aufgeben! Deswegen suche ich eure Hilfe. Was ist passiert: Während eines Messvorganges (kann nicht an zu hoher Eingangsspannung liegen!) zeigte das Display ein Muster wie eine senkrecht angeordnete Jalousie zweier verschiedener Anordnungen, jeweils mindestens 20 Pixel breit. Das beigefügte Bild ist nur aus dem Gedächtnis gemacht, also symbolhaft: einerseits zufällig leuchtende Pixel, dazwischen die Anzeige des gemessenen Signals - allerdings eingefroren. Ich schlatete das Gerät aus und dann wieder ein. Dabei scheint das DSO in den Germs-Monitormode zu gehen, keine Initialisierung. Es leuchtet nur die Run/Stop-Taste grün. Das Drücken der linken zwei Tasten aktiviert den Germs-Monitor erneut mit wechselnd leuchtenden Tasten. Ich kann auch ein Firmwareupdate aufspielen, allerdings kommt das Oszi danach nicht mehr zur normalen Arbeitsansicht. Ich bin ratlos, hab schon alles (Un)mögliche versucht - Gerät ausschalten, auskühlen lassen, neue Firmware flashen, Ram neu bespielen, usw... Seht ihr eine Möglichkeit, die ich noch ausprobieren könnte? Manfred
Es könnte sein dass du den RAM nachlöten musst. Mfg, Kurt
Es gab da mal Probleme mit unsauber verlöteten Speicherbausteinen. Anhand deines Musters müßte sich das eigentlich eingrenzen lassen.
Hallo Manfred, bei mir saß der Stecker vom Display nicht richtig. Das könnte vom Fehlerbild schon passen. Gruß, Jörg
Hallo zusammen, Das Display zeigt im Germsloaderbetrieb keine Streifen. Stecker muss also passen. Ich hab in der Speicheraufteilung nachgeschaut. Da wird beim Einschalten das Flash in den Ram-Bereich kopiert, was bei mir wohl nicht der Fall ist. Welcher Speicherbereich wird beim Start des Germsloaders angesprungen? In welcher Reihenfolge passiert der Bootvorgang? Wo steckt der Speicher, der die Daten für das Display enthält? Ist dieser Speicher linear aufgebaut? Weiß da jemand Bescheid? Manfred
Nabend Leute, ich habe jetzt auf mein W2014A die neueste FW aufgespielt. Ich habe mal das 1kHz Testsignal vom Oszi auf den ersten Kanal gelegt und ein wenig mit den Einstellungen gespielt. Mir ist aufgefallen dass wenn ich die Zeitauflösung nach oben verstelle vom msec in den sec Bereich dass das Oszilloskop zwar anfangs alle Flanken erkennt und quasi einen befüllten gelben Streifen anzeigt. Ab einer bestimmten Einstellung werden nur vereinzelte Flanken erkannt und somit statt 1kHz ein Signal mit ca. 3Hz angezeigt. Lässt sich hier noch was einstellen damit man bei einer solch falschen Einstellung merkt dass die Messpunkte nicht mehr ausreichen und der angezeigte Messwert falsch ist. ODER immer erst Auto-Scale und dann in die gewünschte Einstellung wechseln? Danke und Gruss, Georg.
Georg X. schrieb: > Ab einer bestimmten Einstellung werden nur vereinzelte Flanken > erkannt und somit statt 1kHz ein Signal mit ca. 3Hz angezeigt. Das hat schon seine Richtigkeit. In der Grundvorlesung über digitale Systeme taucht relativ bald das Nyquist-Shannon-Abtasttheorem auf. Wenn du dagegen verstößt, passiert genau das, was du da beobachtet hast: Aliasing. Das aus den abgetasteten Daten rekonstruierte Signal sieht wie ein Signal anderer Frequenz aus. Das ist eine grundlegende Eigenschaft eines DSO. Gruß Rainer
Hallo Georg, Rainer hat völlig Recht: das Phänomen tritt grundsätzlich bei Abtastung eines Signales mit zu geringer Abtastrate auf und man hat auf der Softwareseite keinerlei Möglichkeit, zu erkennen, ob die Abtastrate ausreichend hoch ist oder nicht. Sobald du mit zu geringer Samplerate arbeitest, ist die Information über das tatsächliche Signal dahin und kann nicht softwareseitig zurückgewonnen werden (von Spezialfällen mal abgesehen). Falls du nicht weißt, in welchem Frequenzbereich dein Signal liegt, dann schalte vorsichtshalber immer probeweise in kleinere Zeitbasen. Auf die Weise bist du dann sicher, dass das was du siehst auch deinem tatsächlichen Signal entspricht. Es schadet auch nicht, immer mal einen Blick auf die Samplerate zu werfen und zu checken, ob man ausreichend weit oberhalb der Signalfrequenz liegt. Gruß Michael
Nabend, woher dass kommt und wie es funktioniert ist mir schon klar. Ich bin nur etwas andere Messmittel gewohnt. Da sind die Grenzen deutlich höher und die Darstellung ist anders, so dass man daran schon erkennt dass das Signal verfälscht wurde. Allerdings kosten die Geräte auch um das 100fache mehr. Danke euch für die Erleuterungen. Außerdem Danke an die fleißigen Entwicker unter euch. Richtig gute Arbeit. Gruß, Georg.
Professionelle Geräte können durch ihre meist sehr hohe Speichertiefe (bei uns z.B. 4MSa/Kanal) auch bei langsamen Zeitbasen noch relativ schnell abtasten, dadurch stößt man natürlich entsprechend seltener auf das Problem des Aliasings. Auch mein altes Zweitoszi hier zu Hause mit seinen 125kSa/Kanal schiebt die Abtastrate bei langsamen Signalen gegenüber dem Welec deutlich nach oben, obwohl es nur 100MSa/s maximale Samplerate hat. Aber auch bei professionellen Geräten gibt es bei Unterabtastung keinerlei Möglichkeit, zu erkennen, dass das angezeigte Signal nicht dem realen entspricht - das ist ja gerade das gemeine am Aliasing. Gruß, Michael
Für den SD-USB-Host habe ich noch eine kleine Anleitung geschrieben: http://welecw2000a.sourceforge.net/docs/Miscellaneous/SD-USB-Host/SD-USB-Host.pdf Weitere Infos werden später ergänzt.
Jürgen schrieb: > Rainer W. schrieb: >> Korrektur: >> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits. >> Solange die Summe der beiden Werte für die Länge des >> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von >> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen >> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder >> gar (>187, <100) einstellt. >> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der >> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und >> dann > > Hallo Rainer, > > ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen. > Das schau ich mir nochmal an! Da läßt sich sicher etwas machen. > > Gruß Jürgen @Rainer Ich hab mal wieder einen Blick zurück getan und die Lösung gefunden :-) Als Anhang mal eine Probe für die Pulse Width Problematik. Du kannst ja mal den Anhang ausprobieren, ob es so passt. Es fehlen allerdings noch die gesamten Prüfungen zu den Eingabebereichen in der Firmware. Gruß Jürgen Sorry, das sollte hier her in Teil 5!
Hallo Jürgen, Super! Bei der in meinem alten Beitrag gezeigten Pulstrigger-ärger-Pulsfolge Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" kriegt der Pulstrigger im "><"-Mode jetzt alle Pulse sauber zu fassen. Der ">"-Mode benimmt sich anscheinend auch vernünftig, obwohl der natürlich bei der Pulsfolge etwas überfordert ist. Getestet habe ich unverändert mit Pulslängen 100..400 µs. Bei der Bedienung für den "><"-Modus müßte man natürlich sicherstellen, das der ">"-Wert größer als der "<"-Wert ist. Da hätte ich aber noch einen Alternativvorschlag. Wie wäre es, wenn man den Reglern im "><"-Mode, anders als bisher, die Parameter 1. Triggerpulslänge 2. Toleranz zuordnet, also statt bisher z.B. für 100 µs Pulse die Regler auf "< 90µs" bzw. "> 110µs" zu stellen, würde man dann als Parameter einstellen "L 100µs" und "+/- 10µs". Vorteil wäre, das man in der Bedienung die beiden Parameter Länge und Toleranz sauber getrennt hat, so dass man nicht immer an beiden Regler drehen muß, um die Triggerpulslänge zu ändern. Hast du für die Lösung des Problems jetzt ein Work-arround um die FPGA Logik gebaut oder wie hast du dem Scope seine Triggerunarten abgewöhnt? Gruß Rainer
Hallo Rainer, Rainer W. schrieb: > Hast du für die Lösung des Problems jetzt ein Work-arround um die FPGA > Logik gebaut oder wie hast du dem Scope seine Triggerunarten abgewöhnt? Nö, wie oben angedeutet, hab ich mal wieder zur Welec 1.4 Software geschaut :-) Dort ist die zweite Taste im "><"-Modus mit "delta t" beschriftet, was genau der Funktion entspricht. > Bei der Bedienung für den "><"-Modus müßte man natürlich sicherstellen, > das der ">"-Wert größer als der "<"-Wert ist. Dies muß eben noch als "Eingabeprüfung" ausprogrammiert werden. > Da hätte ich aber noch einen Alternativvorschlag. Wie wäre es, wenn man > den Reglern im "><"-Mode, anders als bisher, die Parameter > > 1. Triggerpulslänge > 2. Toleranz > > zuordnet, also statt bisher z.B. für 100 µs Pulse die Regler auf > "< 90µs" bzw. "> 110µs" zu stellen, würde man dann als Parameter > einstellen "L 100µs" und "+/- 10µs". Vorteil wäre, das man in der > Bedienung die beiden Parameter Länge und Toleranz sauber getrennt hat, > so dass man nicht immer an beiden Regler drehen muß, um die > Triggerpulslänge zu ändern. Die Funktion ist jetzt: Die positive Impulsdauer muß größer als ">" sein und die negative Flanke dann innerhalb des Zeitfensters "dt", gerechnet ab ">" sein. D.h. das entsprechende Register "<" muss einfach mit der Differenz zwischen ">" und "<" geladen werden. Die jetzige Funktion scheint mir in der Bedienung logischer zu sein. In einer "Luxusversion" kann man ja mit der Drehung des ">"-Reglers auch den anderen Regler "<" entsprechend verstellen. Ist allerdings nicht ganz so einfach. Für die nicht funktionierenden "<"-Modus sollten wir eventuell intern auch einen "><"-Modus mit einem Festwert für ">" von z.B.16ns hinterlegen, da in der Betriebsanleitung von Welec sowieso eine Untergrenze von 16ns als Beschränkung angegeben ist. Der Regler verstellt dann nur noch die Obergrenze. Die Untergrenze muß erprobt werden. Gruß Jürgen
Hallo Jürgen, wer kommt schon drauf, dass die Regler falsch beschriftet sind. Prima . Jürgen schrieb: > Die Funktion ist jetzt: Die positive Impulsdauer muß größer als ">" sein > und die negative Flanke dann innerhalb des Zeitfensters "dt", gerechnet > ab ">" sein. D.h. das entsprechende Register "<" muss einfach mit der > Differenz zwischen ">" und "<" geladen werden. > > Die jetzige Funktion scheint mir in der Bedienung logischer zu sein. Logisch finde ich beide Einstellmethoden, je nach Weltanschauung. Klar, die Eingabe von ">" und "<" ist dichter am Signalverlauf dran, aber auf der anderen Seite kommt es oft genug vor, dass man nur die Impulsdauer verändern möchte und sich eigentlich gerne das Fummeln am zweiten Regler sparen würde. Die Idee den "<"-Mode durch einen "><" mit festem unteren Wert zu realisieren ist sicher eine gute Möglichkeit. Wie wäre es denn, wenn man die Modusauswahl ganz umschmeißt und einen Button mit Auswahllist für folgende vier Triggerarten einbaut: 1. "<" mit Regler "<" (intern als "><" mit unterem Limit 16ns) 2. ">" mit Regler ">" 3. "><" mit Reglern ">" und "<" 4. "t, dt" mit Reglern für Länge und Delta, die dann intern auf unteres Limit = Länge - Delta und oberes Limit = Länge + Delta (i.e. Register "<" = 2 * Delta) umgesetzt sind. Die jetzige Art des Softbuttons bringt nicht so die riesigen Vorteile und eine Auswahlliste wäre konform zur sonstigen Bedienphilosophie. Mit den vorgeschlagenen vier Einstellmodi würde es dann für alle Anwendungsfälle passen. Gruß Rainer
Rainer W. schrieb: > Hallo Jürgen, > > wer kommt schon drauf, dass die Regler falsch beschriftet sind. Prima . Hallo Jungs, das war ich. In der Annahme, dass WELEC die Funktionen und das Menü der Agilent Scopes abgekupfert hat (was ja auch größtenteils stimmt) habe ich die Beschriftung von Agilent übernommen. Das scheint aber ja nicht zu stimmen. Werde ich dann entweder wieder rückgängig machen, oder die Funktion anpassen so dass es stimmt. Wie seht Ihr das? Den Vorschlag von Rainer könnte man dann als Fernziel später mal umsetzen. Momentan bin ich an einer anderen Sache dran. Gruß Hayo p.s. Noch nie war Messtechnik so günstig. Hab gestern ein W2022A geschossen für ruinöse 153,- + Versand. Davon wagte ich als Studi nicht mal zu träumen...
Ich wurde kürzlich gefragt (in SFN) wie man am besten Netzspannungen mit unserem Oszi mißt, da die Spannungsbereiche dafür nicht so optimal ausgelegt seien (mit Tastkopf 10:1). Folgender kurzer Hinweis: Für solche Messungen lieber einen 100:1 Tastkopf verwenden. Es werden gerade welche in der E-Bucht angeboten, habe mir auch gleich einen besorgt. 100:1 Hochspannungs- Tastkopf 2kV, 100MHz -> 30,- Flocken Einer ist da noch zu haben. Gruß Hayo
Hallo Hayo, Hauptsache, Jürgen hat den Pulstrigger erstmal als funktionierend erkannt und die Reglerfunktion ist klar. Ich habe gerade noch mal mit deiner letzten 4.9 C2 probiert und eigentlich muß man nur wissen, dass im "><"-Mode auf dem "<"-Regler die Intervallbreite liegt. Vielleicht läßt sich als Sofortlösung mit der nächsten Release erstmal die Regler-Beschriftung korrigieren. Hayo W. schrieb: > Den Vorschlag von Rainer könnte man dann als Fernziel später mal > umsetzen. Momentan bin ich an einer anderen Sache dran. Wäre prima, dann hätte man beide Einstellvarianten zur Verfügung, eilt aber ja nicht. Gruß Rainer
Beschriftung ist schon wieder geändert auf Delta t. Alles wird gut...
Hallo Leute, da die Bestellannahme vorbei ist werde ich ich nun anfangen die Preise endgültig festzulegen. Sobald ich dann auch den Preis für die Platinen habe, werde ich euch den Gesammtbetrag und die Zahlungsmöglichkeiten mitteilen. Die gute Nachricht ist, die LMH6518 konnte ich wieder von eBay beziehen. Deshalb beträgt der Stückpreis nur ca. 5,51€! 4 Stück sind noch zu haben: http://stores.ebay.de/audiosector?_trksid=p4340.l2563 Alle weiteren News setzte ich ab jetz in den Hardware Thread. Mfg, Kurt
Hallo Leute, es geht mittlerweile wieder dem Jahresende entgegen. Dank der Arbeit von Jörg findet die Huckepackplatine ja bereits erste Unterstützung (ich hänge gerade am Einbau), auch wenn noch nicht alle Funktionalitäten umgesetzt sind (20MHz-Bandbreitenbegrenzung erfolgt am LMH und nicht mehr extern. Nun ist es aber so, wie wir alle sicherlich wissen, dass dieses ominöse ADC-Register dafür sorgt, dass der Frequenzgang alles andere als flach verläuft und das Welec bei derlei Messungen macht was es will. Wäre es nicht daher langsam an der Zeit sich dem Leon zu widmen, da damit auch Messungen im HF-Bereich möglich werden? Mal ganz zu schweigen von den zusätzlichen Möglichkeiten, die sich damit bieten würden. Es ist bedauerlich, dass sich noch niemand auf Alex's Terrain gewagt hat. branadic
Hayo W. schrieb: > Beschriftung ist schon wieder geändert auf Delta t. > > Alles wird gut... Nö! Die paar Änderungen kannst Du doch wieder übernehmen..
Hallo zusammen, möchte mich noch für die Bemühungen (speziell bei dir, Hayo) bedanken, das Oszi schrittweise brauchbar gemacht zu haben. Hatte viel Freude beim Einspielen einer neuen Firmware und mit den stetigen Verbesserungen. Leider muss ich mich von der Welec-Gemeinde verabschieden, da mein Oszi 2024A offensichtlich unrettbar defekt ist. Leider. Wünsche euch allen noch gute Fortschritte und viel Spaß bei der weiteren Entwicklung. Manfred
Manfred, wenn dein Gerät wirklich nicht mehr reparabel ist, würdest du es zum reverse-engeneering und für die Ersatzteile spenden? Es soll noch geklärt werden, welche Verbindungen zwischen den 2 FPGAs vorhanden sind. Dazu müssten die FPGAs abgelötet werden, was nur bei einem defekten Gerät Sinn macht. Außerdem bräuchte Bernhard (er besorgt die neuen Huckepackplatinen) einen Drehencoder. Mfg, Kurt
Gab es denn wenigstens ein würdiges Begräbnis? Schade, Hayo
Kurt Bohnen schrieb: > Außerdem bräuchte Bernhard (er besorgt die neuen Huckepackplatinen) > einen Drehencoder. Einen Drehencoder könnte ich noch spendieren. Ich hatte mir mal von den ALPS von Pollin (vor ca. 2 Jahren) ein paar zugelegt, weil bei meinenm Welec auch einer kaputtging. Passt ziemlich genau rein. Gruß, Bernhard P.S.: gerade gefunden Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" und es sind diese http://www.pollin.de/shop/dt/MDY2OTU3OTk-/Bauelemente_Bauteile/Passive_Bauelemente/Potis_Trimmer_Encoder/Encoder_ALPS_EC11E15244BY.html
Wie ich sehe habe die Drehencoder auch noch einen Druckschalter. Es kam ja mal die Frage ob die Signale des Druckschalters auswertbar seien. Hat da mal jemand recherchiert? Ich bin leider gerade in der Firma und komme nicht an meine Unterlagen heran. Wäre natürlich echt cool wenn man zusätzliche Schalterfunktionalität implementieren könnte. Gruß Hayo
na toll! Ich glaube kaum, das (geschätzte) 20-30 Welec-Besitzer jetzt noch den Drehencoder gegen einen mit Druckknopp tauschen... Was machen dann User, die nix zum drücken haben? Gruß Michael
Hey Leute/Programmierer, wurde meine Frage nach dem Leon wieder geschickt ignoriert!? Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Wäre gut, wenn ihr dazu mal ein Statement abgeben würdet. branadic
Hallo Branadic, nein nicht ignoriert, sondern zur Kenntnis genommen. Hab vorhin nicht darauf geantwortet, weil ich keine Zeit mehr hatte vor meinem Projektmeeting. Ich würde mich ja gerne der Portierung auf das LEON-Design widmen, aber meines Wissens ist dieses noch nicht so weit, dass alle Hardwarefunktionen unterstützt werden. Das wäre aber für mich die Voraussetzung für eine Portierung. Falls ich da falsch liege bitte korrigieren. Gruß Hayo
Michael D. schrieb: > na toll! > Ich glaube kaum, das (geschätzte) 20-30 Welec-Besitzer jetzt noch den > Drehencoder gegen einen mit Druckknopp tauschen... > Was machen dann User, die nix zum drücken haben? Also erstens denke ich dass es deutlich mehr WELEC-Besitzer sind (auch international), außerdem wären diese Funktionen dann (wie auch die LED-Funktionen) optional. Das heißt sie wären dann auch über die Funktionstasten verfügbar für alle die nicht löten wollen. Der Austausch der Drehencoder scheint mir aber recht simpel und daher vermutlich auch für etliche Bastelwütige (wie mich) interessant zu sein. Gruß Hayo
Hayo W. schrieb: > Ich würde mich ja gerne der Portierung auf das LEON-Design widmen, aber > meines Wissens ist dieses noch nicht so weit, dass alle > Hardwarefunktionen unterstützt werden. Das wäre aber für mich die > Voraussetzung für eine Portierung. > > Falls ich da falsch liege bitte korrigieren. Nach aktuellem Stand wird die gesamte Hardware unterstützt, mit einer Ausnahme, derzeit ist das Design auf die Funktion von zwei Kanälen beschränkt, weil Alex kein Vierkanalgerät besitzt und noch immer unbekannt zu sein scheint, wie die beiden FPGAs miteinander kommunizieren. branadic
der Andre...du hast ja Recht! Das Thema Leon3-Design, hatte ich auch schon mal versucht neu anzuregen. Obwohl das Aufspielen der Leon3-Software garnicht so schwer ist, kommen warscheinlich nicht alle damit zurecht. Zugegeben, die Anleitung dafür und die dafür benötigten Tools, sind etwas verstreut. Benötigt wird der Quartus-Programmer von Altera, USB-Blaster und der Waverecorder. Was ist eigendlich der letzte Stand des Leon3 bzw. wo liegen die "W2000A.sof" und die dazugehörige "sram" Dateien? Vielleicht würde noch mal eine "All-in-one" Anleitung zur Animation beitragen?!? Ich selbst habe schon verschiedene Versionen getestet und war von der Geschwindigkeit sehr beeindruckt! Gruß Michael
Soweit ich weiß, ist der Leon VHDL mäßig fertig. Nur die Firmware fehlt noch. Ich habe Alex schon eine mail geschrieben und gefragt, wie weit er mit der Doku gekommen ist und wo sie zu finden ist.
Michael D. schrieb: > der Andre...du hast ja Recht! > Das Thema Leon3-Design, hatte ich auch schon mal versucht neu anzuregen. Naja, wollte ja nur mal hören wie die Allgemeinheit dazu steht, schließlich sind die Grenzen des originalen Designs mehr als bekannt, spätestens bei Messungen von höherfrequenten Signalen ist Schluss und ein gutes Workaround gibt es ja offenbar dafür auch nicht. Zumindest mir missfällt diese "HF-Umschaltung", denn das auf dem Bildschirm präsentierte Ergebnis ist frei interpretierbar und nicht als Messergebnis zu bezeichnen. Die Störungen, die wie kippende Bits ausschauen, sind ebenfalls zweifelhaft und im Leon-Design in der Form noch nicht aufgetreten. Die Dezimationsfilter sollten ebenfalls nicht unterschlagen werden. Alex hat ja nun gut Zeit und Arbeit investiert, da sollte sie doch auch mal Früchte tragen. Bis zur vollständigen Unterstützung für die 4-Kanäler ist man ja nicht gezwungen das Design fest einzuspielen, sondern kann das auch nur temporär vornehmen und gerade das muss man ja nicht unbedingt als Nachteil sehen. Das Alex sich in letzter Zeit nicht mehr intensiv darum kümmert liegt nicht zuletzt auch am fehlenden Feedback und an fehlender Unterstützung, durchaus nachvollziehbar. Meiner ganz persönlichen Meinung nach hätte man dem Leon schon viel früher die notwendige Aufmerksamkeit widmen müssen. branadic
Hi Branadic, leider dringt zum Stand der Dinge in Sachen LEON nicht allzu viel an die "Öffentlichkeit". Ich wußte bislang nicht, dass die Entwicklung schon so weit fortgeschritten ist, dass die gesamte Hardware bis auf die Kanäle 3+4 unterstützt wird. Wenn jetzt noch die Ansteuerung der Hardware brauchbar dokumentiert wäre, sähe ich eigentlich (fast) keinen Hindernisgrund mit der Portierung anzufangen. Zum (fast): Leider hatte ich massive Schwierigkeiten das LEON-Design bei mir zum Laufen zu bringen. Als alter EDVler und Computerfreak der ersten Stunde traue ich mir schon zu das alles richtig hinzukriegen. Dennoch habe ich 2 Tage lang vergeblich versucht das Ganze bei mir zum Laufen zu bringen. Offensichtlich gab es Probleme bei der richtigen Registrierung des USB-Device. Hatte das auch schon mal jemand? Ich bin aber grundsätzlich kein Aufgeber und werde das gerne nochmal versuchen. Die Aussicht auf mehr Performance ist schon sehr verlockend! Weiterhin kommt jetzt ein alter Studienkollege von mir mit an Bord, der unter Umständen diese Plattform für seine (leicht verspätete) Diplomarbeit nutzen wird. Es könnte noch sehr interessant werden... Gruß Hayo
@Hayo > Also erstens denke ich dass es deutlich mehr WELEC-Besitzer sind (auch > international), außerdem wären diese Funktionen dann (wie auch die > LED-Funktionen) optional. Das heißt sie wären dann auch über die > Funktionstasten verfügbar für alle die nicht löten wollen. Okay, dann nehme ich natürlich alles zurück und behaupte das Gegenteil! ;-) > Der Austausch der Drehencoder scheint mir aber recht simpel und daher > vermutlich auch für etliche Bastelwütige (wie mich) interessant zu sein. Ich bin da ja genauso, wie du weißt und habe da auch keine Berührungsängste mit dem Lötkolben! @Kurt > Soweit ich weiß, ist der Leon VHDL mäßig fertig. Ach? Jetzt wird's spannend! > Nur die Firmware fehlt > noch. Ich habe Alex schon eine mail geschrieben und gefragt, wie weit er > mit der Doku gekommen ist und wo sie zu finden ist. ...das wäre chic!!! Btw. war da nicht schon mal eine vorab Testversion für das Ram, dieses Jahr, oder war das schon länger her? Vielleicht mache ich mich mal auf die Suche, wenn Zeit is'. @branadic > Das Alex sich in letzter Zeit nicht mehr intensiv darum kümmert liegt > nicht zuletzt auch am fehlenden Feedback und an fehlender Unterstützung, > durchaus nachvollziehbar. vielleicht auch u.a. an den von mir angegebenen Gründen der Installation?!? Hayo hat mit dem Aufspielen der FW(LEON3) auch Probleme gehabt, sonst hätte er bestimmt schon dazu etwas beitragen können, denke ich. Ich hatte mal eine bebilderte Installation(Altera)mit aufspielen der FW für das Ram gepostet, soweit ich mich erinnern kann. Wenn Bedarf besteht, könnte ich das mal heraus suchen, oder liegt das irgendwo im Gethub oder SF? Gruß Michael EDIT: Hayo, warst mal wieder schneller... :-(
Alexander schrieb (per mail): > Eine richtige Doku habe ich dafür noch nicht gemacht. > Stattdessen sind im Prinzip alle SFR-Zugriffe implementiert und zu 98% > mit Erfolg getestet. > > Ich glaube schon, dass die Funktionsaufrufe ziemlich selbsterklärend > sein sollten. > Die GUI ist nicht von mir! @Michael, am besten suchst du die Anleitung mal raus, dann kann man sie gut sichtbar verlinken.
Angehängte Dateien:
-
LOGA_OFF.jpeg
53 KB -
LOGA_TTL.jpeg
39 KB -
LOGA_CMOS.jpeg
45 KB
So, nachdem einige Zeit nichts über das nächste Release zu hören war hier eine Vorschau auf die 5er Version. Was neu ist und warum es so lange gedauert hat muß ich wohl nicht erklären, da die Screenshots für sich sprechen. Screenshot 1 -> Normaler Analogmodus Screenshot 2 -> Digitalmodus TTL Screenshot 3 -> Digitalmodus CMOS Zur Zeit alles noch beta. Bis zur Fertigstellung muß noch einiges an Feinarbeit gemacht werden. Damit dürfte die Messlatte für vergleichbare Oszis wieder etwas höher liegen... Gruß Hayo
Hayo, kannst du was mit der leon.zip anfangen? Es ist schade dass es keine Dokumentation gibt, aber die Leon Firmware hat noch einen so kleinen Funktionsumfang, dass das reverse engeneeren deutlich einfacher sein sollte als bei der Nios Firmware. Wie siehst du das, als W2000A erfahrener Programmierer, oder auch alle anderen die sich an der leon Firmware beteilige möchten? Mfg, Kurt
Hayo W. schrieb: > Was neu ist und warum es so lange gedauert hat muß ich wohl nicht > erklären, > da die Screenshots für sich sprechen. > > Screenshot 1 -> Normaler Analogmodus > Screenshot 2 -> Digitalmodus TTL > Screenshot 3 -> Digitalmodus CMOS Der Vollständigkeit halber müssten ECL bzw. PECL (min. 150mVpp, typ. 800mVpp, max. 1Vpp) und RSPECL (min. 320mVpp, typ. 400mVpp, max. 420mVpp) auch Erwähnung finden. branadic
branadic schrieb: > Der Vollständigkeit halber müssten ECL bzw. PECL (min. 150mVpp, typ. > 800mVpp, max. 1Vpp) und RSPECL (min. 320mVpp, typ. 400mVpp, max. > 420mVpp) auch Erwähnung finden. Oder gleich eine Option "User"-defined mit Level-Definition über's Setup. Gruß Rainer
@Kurt Hatte noch keine Zeit mir die Datei anzusehen. @Branadic Du hast recht, die Liste ist noch nicht komplett. Ich wollt nur erstmal eine Grundliste zur Verfügung stellen. @Rainer Auch das wäre denkbar. Die Auswahl von bestimmten Logiktypen mit festen Einstellungen finde aber schon recht komfortabel. Dem weiteren (späteren) Ausbau steht natürlich nichts entgegen. Gruß Hayo
@Kurt Habs jetzt mal auf die Schnelle überflogen. Leider ist die Source nur sehr spärlich kommentiert, das erinnert mich an die alte WELEC-FW. Es war auf den ersten Blick nicht erkennbar ob alle Hardwarefunktionen unterstützt werden. Funktionen um den DAC anzusprechen und den Trigger zu setzen habe ich wohl gefunden. Einen UI-Interrupthandler habe ich aber zum Beispiel nicht finden können, auch den Zugriff auf das Flash konnte ich noch nicht lokalisieren. Auch waren die Hardwareansteuerungen nicht auf den ersten Blick selbsterklärend. Da müßte man also erstmal forschen, was eigentlich vermeidbar wäre wenn es eine Doku zu den Hardwareschnittstellen gäbe. Gruß Hayo
Rainer W. schrieb: > branadic schrieb: >> Der Vollständigkeit halber müssten ECL bzw. PECL .. auch Erwähnung finden. Ich habe erstmal nur Single Ended Logiktypen berücksichtigt, da die Messung von differenziellen Pegeln (ECL, PECL, LVDS, RS422 etc.) mit unserem Gerät wegen des gemeinsamen Grounds so nicht ohne Weiteres möglich ist. Gruß Hayo
Hallo Hayo, ECL-Pegel implizieren nicht, dass der Ausgang differentiell sein muss, sie können genauso gut single-ended Verwendung finden. Ungeachtet der Tatsache, dass ich diese Funktionen selbst nicht benötige, wollte ich nur darauf aufmerksam machen. branadic
moin, > @Michael, > am besten suchst du die Anleitung mal raus, dann kann man sie gut > sichtbar verlinken. hier schon mal der Link für die Installation der benötigten Programme(Englisch): Installation-LEON3 im Detail: Quartus-II-Programmer, USB-Blaster, Waverecorder http://sourceforge.net/apps/trac/welecw2000a/wiki/leon3design LEON3 FPGA-Design-Firmware latest Preview1.1 http://sourceforge.net/projects/welecw2000a/files/LEON3%20FPGA%20Design/Previews/ ------------------------------------------------------------------------ --- Vorab eine Kurzanleitung: Am DSO werden "no Buttons" gedrückt!!! Nach dem das DSO im Quartus-II-Programmer als "Nios Evulation Board"(HID-HumanInterface) erkannt wird (Hardware Setup), kann das LEON3-Design über "USB" eingespielt werden---(w2000a.sof)---. Wichtig! Im Quartus-II Prog.-Fenster darf nur "1 Device"(z.B.)"EPC35F484" stehen! Danach wird die Software---(w2000a.bin)--- am "DSO-COMPORT" mit dem Waverecorder über eine Batchdatei mit den erforderlichen Parametern aufgesetzt. Es wird nur das "RAM" beschrieben. Nach dem Aus- und wieder Einschalten ist alles wie voher! ------------------------------------------------------------------------ --- Ich will mal schauen, ob ich das mit einer bebilderten Doku hinbekomme. Die Bilder habe ich schon, fehlt nur noch der Text... (by Alex) LEON3-welec2000a https://github.com/alexvie/welecw2000a/tree/11357b1c5d2999d0a0b1dd7238f0cdff550bb8dd/fpga/leon3/ Ich hatte mal auf GITHUB das komplette Projekt herunter geladen mit dem Filnamen: alexvie-welecw2000a-bcc9464(entpackt 36MB), leider finde ich die Quelle nicht mehr, hab's aber auf der Platte. Ob es das Aktuellste ist, kann nur Alex beantworten Ansonsten bin ich hier noch fündig geworden: https://github.com/alexvie/welecw2000a/tree/11357b1c5d2999d0a0b1dd7238f0cdff550bb8dd/fpga/leon3/grlib-W2000A/designs/leon3-w2000a Wenn man auf dieser Seite ist, kann man das Qellcode-Projekt als ZIP-File 9MB(oben links) herunterladen, vielleicht kann Hayo damit was anfangen?!? Gruß Michael
Danke Hayo, super das habe ich mir schon immer gewünscht unverrauschte Digitalsignale wie bei einem LA, für Dinge bei den man die Signalqualität schon für ok befunden hat und dann auch kein Rauschen mehr braucht. Anscheinend funktioniert der Trigger inzwischen besser ich hatte früher immer Probleme wenn die Triggerschwelle sehr niedrig eingestellt war erst ab ca. 0,5-1V funktionierte das ganze zuverlässig. Hayo W. schrieb: > da die Messung von differenziellen Pegeln (ECL, PECL, LVDS, RS422 etc.) mit > unserem Gerät wegen des gemeinsamen Grounds so nicht ohne Weiteres möglich ist. differentiell muss aber nicht bedeuten dass die beiden Pegel unterschiedliche Potentiale haben. siehe CAN http://www.kfztech.de/kfztechnik/elo/can/bmw2.JPG Ich fände es super wenn man das integrieren könnte, dann würde man nicht mal mehr einen CAN-Treiber brauchen sondern könnte direkt mit 2 Kanälen auf den CAN Bus und aufzeichnen.
@Branadic Meines Wissens werden die ECL-Logiktypen konstruktionsbedingt immer differenziell verwendet, aber vielleicht gibt es auch Ausnahmen. ECl hat ja einen sehr kleinen Spannungshub, der eigentlich nur möglich ist wenn durch den differenziellen Betrieb das Rauschen bzw. die Störeinflüsse kompensiert werden. @Michael An der Anleitung lag es bei mir nicht. Ich hatte alles nach der Anleitung durchgeführt. Bei der USB-Erkennung ist irgendwas schiefgelaufen, so dass das Device nicht in Quartus erschien. Gruß Hayo
Angehängte Dateien:
-
Altera-USB-Treiber.gif
20 KB
> @Michael > An der Anleitung lag es bei mir nicht. Ich hatte alles nach der > Anleitung durchgeführt. Bei der USB-Erkennung ist irgendwas > schiefgelaufen, so dass das Device nicht in Quartus erschien. > Gruß Hayo Ok, ich habe jetzt mal ein komplettes Treiberpaket aller benötigten Treiber gepackt, da im Download nicht wirklich alle enthalten sind. Den Ordner "CyUsb" inkl. "CyUsb.spt" in die c:\Windows\Sytem32 kopieren. CyUSB.sys und CyUSB.inf nach c:\Windows\System32\Drivers. Die restlichen 3 dll's plus die usbblstr.sys nach c:\Windows\System32 jetzt muß das aber hinhauen! Gruß Michael
Ich werd's noch mal versuchen. Mal sehen ob ich es dieses Wochenende schaffe. Gruß Hayo
Hallo, gerade habe ich ein wenig mit dem Welec gearbeitet und möchte eine kleine Erweiterung anregen, die ich sehr vermisse: Könnte man an geeigneter Stelle die Bandbreite einblenden? Das ist bei Verwendung der verschiedenen Filter eine sehr wichtige Information. Gruß Michael
Wenn das LEON3 Design jetzt auf einem 2-Kanaler funktioniert und eventuell die Software einfach darauf anzupassen ist. Dann ist ja die komplette Software des Oszis Open Source. Könnte man hier nicht ansetzen und auch einen Schaltplan und eine Leiterplatte entwerfen die zu dem FPGA Desgin kompatibel ist? Das Oszi besteht aus: Eingangsstufe: Es existiert schon ein alternativer Schaltplan ADC FPGA Displayschnittstelle Tasten Stromversorgung DC/DC aus 12 - 24V Mfg Michael
Zwar eine sehr schöne und reizvolle Idee aber für die paar Euro die die Welecs kosten wird man da keinen Selbstbau hinbekommen. Dazu ein Gehäuse, Display... Obwohl sich wahrscheinlich schon Anhänger finden würden, wenn die Selbstbauplattform erstmal voll funktionsfähig steht. Michael
Das Display alleine bestellt kostet schon mehr als ein in der E-Bucht geschossenes gebrauchtes DSO von WELEC... Eine andere Idee, die ich mit meinem ehemaligen Studienkollegen diskutiert habe, ist eine Koprozessorplatine mit einem DSP drauf an den Datenbus anzukoppeln und da die rechenaufwändigen Sachen drauf berechnen zu lassen. Das dürfte bei FFT und Filterberechnungen einen echten Geschwindigkeitsschub geben, da der DSP solche Sachen quasi in Echtzeit berechnet. Entsprechende Boards gibt es z.B. von Motorola oder Texas Instruments als Evaluation Kits. Gruß Hayo
Hat etwas gedauert, aber dafür läuft es jetzt stabil. Die Logikpegel des Logic Processors sind zur Zeit nur für nicht modifizierte Geräte eingestellt. Eine Anpassung für andere Hardware (24/33 Ohm bzw Addon) ist in Vorbereitung. Funktionieren sollte es aber trotzdem, wenn auch die Schaltschwellen dann nicht ganz genau sind. Gruß Hayo
Hallo Hayo, W2022A 1.2.BF.5.0 da scheint's ein Problem zu geben: Aquire -> Button Logic(Off)-> TTL 5V -> Menu beendet nicht. Weitere Betätigungen dieser Taste scrollen zwar durch die Auswahl, der Menupkt. endet aber nicht. Nur z.B. Druck Average(Off) beendet den Pkt. Die Anzeige steht weiterhin auf: Logic (Off). Betätigt man wieder Logic(Off) sieht man das die TTL 5V aber angehakt sind. Dann z.B. wieder Average(Off) und es 'hakt' nun auch dieser Menu-Pkt. Mit dem Drehgeber ausgewählt funktioniert es. Gruß Robert
Hallo Hayo, Robert schrieb: > W2022A 1.2.BF.5.0 > > da scheint's ein Problem zu geben: > > Aquire -> Button Logic(Off)-> TTL 5V -> Menu beendet nicht. > Weitere Betätigungen dieser Taste scrollen zwar durch die Auswahl, der > Menupkt. endet aber nicht. Nur z.B. Druck Average(Off) beendet den Pkt. > Die Anzeige steht weiterhin auf: Logic (Off). Betätigt man wieder > Logic(Off) sieht man das die TTL 5V aber angehakt sind. > > Dann z.B. wieder Average(Off) und es 'hakt' nun auch dieser Menu-Pkt. ACK Schönen Sonntag! Gruß Jürgen
Hi, das isr der Menü-Timer, ich dachte das hätte ich gefixt. Korrigiere ich und gebe das nachher raus. Gruß Hayo
Hayo W. schrieb: > Korrigiere ich und gebe das nachher raus. > > Gruß Hayo Ich sortiere eben die Pulse Width -Geschichte in die Version 5.0. Dauert noch ein paar Minuten. Ich stelle die geänderten Dateien dann hierher und Du kannst das übernehmen. Und natürlich die Button Beschriftung wieder zurück ändern :-) Gruß Jürgen
Hallo Hayo, hier sind die 4 geaenderten Dateien. Gruß Jürgen
Liebe Gemeinde! Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit interessiert. Zum "aktuellen" Stand meiner Entwicklung: "Fehlerfrei" und kaum verbesserbar: FPGA: LEON3 + Debug Support Unit im FPGA Signalerfassung, inklusive der digitalen Dezimationsfilter! SRAM-Anbindung (bei den scheinbaren EMV-Problemen hat das eine abnormal lange Zeit gebraucht, ging erst gut und schnell, nachdem ich den SRAM-Controller selbst geschrieben habe) 9 Bit Farben VGA: Bitte nur darauf schreiben, nie davon lesen -> (Cache-Verhalten)! DAC + restliche analoge Einstellungen über GPOs. Trigger: Auto, Normal + Glitch (1 Sample!) über Hysterese Firmware: Treiberfunktionen für den Trigger, Abtastgeschwindigkeit, DAC Offset (ohne Kalibrierung per Software), Auslesen des Triggerspeichers (Samplebuffers) im Normal Mode. Teilen der seriellen Schnittstelle mit dem integrierten Programmer (Debug Uart). Screenshot Waverecoder: Upload, Backtrace, saubere Schnittstellentrennung (UART, Debug UART, nicht implementiert Ethernet) Setzen von Befehlen SetTrigger, ReadData, WriteData über den Debug UART. Linux, MAC, Windows Unterstützung. Nachteile: Debuggen geht nur eingschränkt mit dem grmon und einem 6.? GDB. Noch kein Betriebssystem in der Firmware, Slogs Treiber zum Programmieren des FPGAs funktioniert zwar unter Windows, aber das installieren kann sich als schwierig erweisen. Unterschiede bei der Linux-Treiberinstallation für den FPGA-Programmer je nach Kernelversion. Die Software steckt noch ziemlich in den Kinderschuhen. @Kurt: Die fehlenden Pin-Zuweisungen der Adress-Datenbussanbindung zwischen den FPGAs kann man mit zwei VHDL Designs ohne Demolierung des Boards feststellen. Bei einem schickt man bspw. Rechtecksignale rein, beim anderen ließt man auf den Kanäle das Signal, speichert es und ließt es mit Quartus aus. So hat das warscheinlich auch Slog gemacht. @Michael Das FPGA Design ist auf eine möglichst gute Portierbarkeit ausgelegt. Wenn hier jemand beabsichtigt, ein eigenes Oszi damit zu bauen, bitte unbedignt einen Ethernet PHY mit Isolator zum Debuggen und so verwenden draufpacken! Der LEON3 hat leider keine freie USB-Schnittstelle intern, die man nur Einbinden muss. MfG Alexander
Hi, leider war diese Page nicht erreichbar in den letzten Stunden, daher von mir keine Rückmeldung. Das Problem ist erkannt. Es ist der Timer 3, der beim Button drücken ausgelöst wird. Das tritt nur im Standardlayout auf, deshalb war mir das nicht aufgefallen. Workaround ist also erstmal das Layout auf eines der "Mono" Layouts zu ändern, dann ist alles gut. Gruß Hayo p.s. Korrektur gibts morgen
Hallo Alex, > Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit > interessiert. na, auf jeden Fall! Ich bin ja nur User... > Zum "aktuellen" Stand meiner Entwicklung: > "Fehlerfrei" und kaum verbesserbar: ...... hast du für uns was Kompiliertes (w2000.sof u. bin) zum testen da? Jetzt werde ich neugierig! :-) @Hayo > Das tritt nur im Standardlayout auf, deshalb war mir das nicht > aufgefallen. stimmt, kann ich bestätigen. Ich hatte das mehrmals getestet, allerdings nicht mit dem Standart-Layout und konnte da keine Unstimmigkeiten feststellen...deswegen hatte ich erstmal die Klappe gehalten ;-) Hast mal wieder eine tolle Arbeit gemacht! Gruß Michael
alex008 schrieb: > Liebe Gemeinde! > > Freut mich, dass ihr euch jetzt wieder für meine Diplomarbeit > interessiert. Hi Alex, das Interesse war immer da, nur habe ich auf einen Stand der Entwicklung gewartet der für eine Portierung geeignet ist. Wenn das Ganze eine Diplomarbeit ist, dann müßte das doch recht gut dokumentiert sein. Stellst Du uns die Doku zur Verfügung? Eine detailierte Beschreibung der Register bzw. der Ansteuerung ist natürlich mit das Wichtigste (UARTs, Timer, ADCs, DACs, Display, Drehencoder, Buttons etc). Wie sieht es denn mit den Kanälen 3 + 4 aus. Wenn ich das richtig herausgehört habe gehört der zweite FPGA nicht zu Deiner Diplomarbeit. Wird hier noch eine Umsetzung erfolgen, oder bleibt es bei zwei Kanälen? Ist das von Kurt gepostete Coding zur Ansteuerung des LEON das Aktuellste, oder gibt es schon aktuellere Routinen? Gruß Hayo
So hier die Korrektur. Hab auch noch die Änderung beim Pulstrigger eingebaut - allerdings in einer etwas von Jürgens Version abweichender Implementierung. Das Ergebnis ist aber das Gleiche. Es wird nur an einer anderen Stelle subtrahiert. An den Registern habe ich auch noch etwas rumgespielt. Gruß Hayo
Hallo! Der LEON3 hat einen AHB-Bus und einen APB-Bus (Adress-Datenbus). Davon habe ich einen AHB-Teilnehmer für die SRAM/Flash-Anbindung geschrieben, ein AHB-Teilnehmer ist der Triggerspeicher (32KB) und ein APB-Teilnehmer ist das SFR mit 32 Register. Alle anderen Geräte sind die originalen Teile vom LEON3. Das beinhaltet den konfigurierbaren Framebuffer-SVGA mit 16 Bit Farbe, welcher sich die Daten aus dem SRAM selbst holt. Dabei ist auch ein UART, der dem 16550 ähnlich und einfachst zu bedienen ist. Was auch beim LEON3 niemals fehlt ist die DSU (Debug Support Unit) und eine seiner Schnittstellen, hier ist es der Debug UART. Für alle Komponenten, welche ich nicht geschrieben habe, gibt es 3 Dokumente bei www.gaisler.com oder im Repository: sparcv8.pdf, grlib.pdf und grip.pdf. Die Startadressen von allen Busteilnehmern stehen in der Source-Datei DSO_Main.h. @Hayo Es gibt für alle Hardware-Ansteuerungen, die du wissen möchtest, einfache LOW-Level Routinen, die sicher zu 95 % fehlerfrei sind (externer Trigger ungetestet!, der Rest sollte passen). Schwieriger wird es bei der hochperformanten GUI, die noch nicht ausgereift ist. Auch hier ist das hinzufügen von Menüeinträgen relativ leicht, bei der Darstellung (GUI-Core) gibt es aber noch ein paar Probleme zu lösen. Wenn du es geschafft hast, mit dem originalen Quellcode zurechtzukommen, sollte ein Umstieg für dich recht leicht sein. Robert, unser GUI Entwickler, benötigte von mir zum Einarbeiten so gut wie keine Hilfe. Falk schrieb mir auch einmal, dass ihm meine Routinen für die Signalerfassung wesentlich besser sein sollen, als die von der NIOS-Seite. Beispiel Debug Uart Protokoll: Erstes Byte: Ein Bit für Schreiben oder Lesen, rest für die Datenmenge in DWORDs (Bytes *4). Danach folgen 4 Byte für die Adresse, und am Schluss schickt man, oder man bekommt die Daten. @Michael Beim LEON3-Zeug funktionieren leider nur die LOW-Level Treiberroutinen gut, mehr als beim Preview 1.1 ist da vom Benutzer nicht zu sehen. Mir fehlt leider die Zeit, um den Rest weiter zu entwickeln. MfG Alexander
alex008 schrieb: > Auch hier ist das hinzufügen von Menüeinträgen relativ leicht, bei der > Darstellung (GUI-Core) gibt es aber noch ein paar Probleme zu lösen. Wie äußern sich diese Probleme? MfG Ingo
Hi Alex, bei dem Coding welches Kurt hier gepostet hat fehlen noch Headerdateien und von GUI hab ich da auch nichts drin gefunden. Gibt es andere Sourcen? Gruß Hayo
Nein, bis eben nicht. Sonst hätte ich wohl auch die Frage nicht gestellt ;-) Aber dann hat sich ja alles geklärt. Soweit ich das auf die Schnelle gesehen habe ist ja alles vorhanden um sich da weiter schlau zu machen. Danke Hayo
Jetzt frage ich mich, wozu ich mir die Mühe gemacht habe??? Siehe: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
Nicht böse sein, ich hatte einfach noch keine Zeit mir alles durchzulesen. Ich schaffe es zwischendurch manchmal nur kurz einen Blick auf die Postings zu werfen und habe dann auch keine Zeit den Links nachzugehen. Ich arbeite mich aber voran... Gruß Hayo
Dennoch bleibt die Frage ob die fehlenden zwei Kanäle noch implementiert werden oder ob das Projekt jetzt abgeschlossen ist. Gruß Hayo
Es ist einfach so, dass dem Alex nur ein 2-Kanal-Gerät zur Verfügung steht und stand und er deswegen die anderen beiden Kanäle nicht implementieren konnte. branadic
Moin moin, ich könnte z.B. Alex ein 4 Kanal Gerät zur Verfügung stellen. Wäre es dann in absehbarer Zeit möglich das Leon Design auf auf die 4 Kanäler zu erweitern ? Hat Alex dazu lust und Zeit ? Gruß Dirk
Da ich momentan keine Zeit für das Projekt habe und trotzdem indirekt hilfreich am Projekt mitwirken will, kann auch ich meinen 4-kanaler dem Alex leihen, und würde noch einen LA1034 LogicAnalyzer dazupacken. Weiß jemand, was aus manfred.h s (Gast) Datum: 17.10.2011 21:18 Gerät wurde? Ich würde es ihm gerne abkaufen (und evtl.Alex zur Verfügung stellen). Tipp: ibäh:audiosector hat neben den LMHs ca. 2250 sehr interessante Teile im Angebot, u.a. Panasonic Rotary Encoder cgi.ebay.de/170645192579 (zu testen, ob sie ins Oszi passen), evtl. bietet sich eine Sammelbestellung (im Forum Markt) an. Hat schonmal jemand bei Welec angefragt, was die mit defekten Geräten machen? Vielleicht können sie welche zum Debuggen zur Verfügung stellen. Immerhin profitieren sie von unserer Arbeit ziemlich.
eProfi schrieb: > > Hat schonmal jemand bei Welec angefragt, was die mit defekten Geräten > machen? Vielleicht können sie welche zum Debuggen zur Verfügung stellen. > Immerhin profitieren sie von unserer Arbeit ziemlich. Das ist keine schlechte Idee. Ich hatte mir auch schon überlegt ob man nicht mal fragen könnte ob WELEC Dukumentation zu einigen der Register raustut, wenn sie das VHDL schon nicht zur Verfügung stellen wollen/können. Das könnte uns u.U. etwas weiter bringen. Bin übrigens nicht untätig, sondern bin ziemlich intensiv am experimentieren mit FIR-Filtern und der sin(x)/x Interpolation. Ist ziemlich viel Recherche- und Testaufwand, aber ich arbeite mich voran. Meine Vorlesungen in Digitale Systeme sind halt schon etwas länger her. Da muß man sich erstmal wieder reinarbeiten. Gruß Hayo
Hallo Hayo,
ich muß nochmal auf den Pulstrigger zurückkommen. Entweder habe ich da
die neue Bedienung nicht verstanden oder es hat sich im "><"-Mode mit
der BF 5.0 C2 ein Bug eingeschlichen:
Mit den Zeitgrenzen "> 40µs", "< 60µs" gelingt es mir nicht, z.B. auf
einen 50µs Digitalpuls zu triggern (Signal 5V, Normal Trigger 3V).
Mit der BF 5.0 und entsprechenden Einstellungen ("> 40µs", "dt 20µs")
funktioniert es einwandfrei.
In beiden Versionen gibt es nach Aufruf von Default Setup noch ein
Problem mit den Einstellung vom Pulstrigger: Die im Puls-Width Trigger
Menü angezeigten Werte entsprechen danach nicht den Geräteeinstellungen,
m.a.W. erst wenn man z.B. den Kanal neu wählt und die Zeitgrenzen
ändert, stimmen die angezeigten Werte. Ohne explizite Kanalwahl erfolgt
kein Trigger.
Wenn du mal eine Ablenkung von FIR, IIR und Co. brauchst, kannst du
vielleicht da noch einmal gucken.
Schönes Wochenende
Gruß
Rainer
p.s. zum Pulstrigger: Für die Einstellung der Zeitlimits ist die Bereichsumschaltung noch sehr "praxisfern", insbesondere im "><"-Mode. Durch die momentan feste Schrittweite (8ns, 1µs, 1ms) lassen sich kurz über den Umschaltpunkten (1µ bzw, 1ms) die Zeiten nur sehr grob einstellen und kurz unterhalb von 1ms dreht man sich einen Wolf. Das führt auch dazu, dass es z.B. nicht möglich auf Pulse von z.B. 1.9 ms zu triggern, falls gleichzeitig solche von 1.1 ms vorhanden sind, weil in solch einem Fall das dt Fenster relativ sehr groß sein muß. IMHO sind im "><"-Mode als Einstellparameter ">" und "dt" wesentlich besser geeignet, weil man bei ">" und "<" für Pulslängenänderung immer zwei Regler bedienen muß. Gruß Rainer
> Mit den Zeitgrenzen "> 40µs", "< 60µs" gelingt es mir nicht, z.B. auf > einen 50µs Digitalpuls zu triggern (Signal 5V, Normal Trigger 3V). Bei mir hat es manchmal funktioniert und manchmal bicht. Mir ist aber nicht ganz klar woran es liegt. > In beiden Versionen gibt es nach Aufruf von Default Setup noch ein > Problem mit den Einstellung vom Pulstrigger: Die im Puls-Width Trigger > Menü angezeigten Werte entsprechen danach nicht den Geräteeinstellungen, > m.a.W. erst wenn man z.B. den Kanal neu wählt und die Zeitgrenzen > ändert, stimmen die angezeigten Werte. Ohne explizite Kanalwahl erfolgt > kein Trigger. Hmm, das muß ich mal prüfen. Vielleicht fehlt nach dem Default Setup die Triggerinitialisierung -> danke für den Hinweis > IMHO sind im "><"-Mode als Einstellparameter ">" und "dt" wesentlich > besser geeignet, weil man bei ">" und "<" für Pulslängenänderung immer > zwei Regler bedienen muß. Da hast Du eigentlich Recht. Wie sehen das dei Anderen? Sollen wir das wieder zurückändern? Die Abstufung der Einstellwerte war mir auch schon mehrfach negativ aufgefallen - ist noch alter Sourcecode. Da werde ich mal versuchen was dran zu ändern. Gruß Hayo
bei > < kann man aber direkt 180-200µSek einstellen, bei der anderen Variante müsste man 190 +- 10 einstellen. Vielleicht kann man es ja wählbar machen ob > < oder > dt
Hayo W. schrieb: > Die Abstufung der Einstellwerte war mir auch schon mehrfach negativ > aufgefallen - ist noch alter Sourcecode. Bei der Zeiteinstellung ist IMHO eine Auflösung im Bereich 1..5% ganz praktisch. Wie wäre ist mit der üblichen 1-2-5 Log-Approximation, also z.B.
1 | Bereich Schrittweite |
2 | 1.00 .. 2.00 ms 0.02 ms |
3 | 2.00 .. 5.00 ms 0.05 ms |
4 | 5.00 .. 10.0 ms 0.10 ms |
5 | 10.0 .. 20.0 ms 0.20 ms |
6 | u.s.w. |
Das sollte fein genug sein und man kurbelt sich nicht tot ;-) Gruß Rainer
Ich sehe mir das mal an wenn ich hier mit den Filtern durch bin. Zur Zeit läuft mein FIR mit Circular Buffer langsamer als der nicht optimierte FIR mit Shiftlogik. Nebenbei habe ich im direkten Vergleich festgestellt, dass die Filter die ich ohne fundierten Algorithmus nur nach logischen Überlegungen selbst entworfen habe (Smooth, Strong), deutlich schneller sind und trotzdem ein genauso gutes Ergebnis aufweisen - da bin ich doch schon etwas überrascht und es zeigt, dass die Überlegungen grundsätzlich richtig waren. Gruß Hayo
Hallo Dirk! Vielen Dank für dein Angebot, mir deinen 4 Kanäler zu borgen. Ich werde es aber nicht annehmen, da mich das zu sehr unter Zugzwang stellen würde. Die FPGAs der 4 Kanäler sind laut Crazor (lange nichts mehr von ihm gehört) über den Adress-Datenbuss verbunden. Beim einem schön hirarchischen Aufbau der Software sollte es nicht allzu schwer sein beide FPGA Designs zu verbinden. Man müsste unter Umständen nicht einmal den FPGA mit dem Softcore ändern, wenn man den zweiten FPGA dazu einfügt. Auch beim anderen FPGA (für Kanal 3 und 4) müsste man nur die Signalerfassungsteil herausnehmen und die Adress-Datenbuss-Schnittstelle adaptieren. Was ein wenig aufwendiger werden könnte, wäre das Auffinden der ADC Pins für Kanal 3/4. @Hayo Ich habe dir doch schon einmal einen hoch optimiertes Polyphasen-Interpolationsfilter geschickt (optimierter FIR-Filter für die Interpolation, der sich die Multiplikation mit den eingefügten 0ern spart). Probiers vielleicht mit Pointer-Zugriffen anstatt von Array-Zugriffe auf den Puffer, damit spart man sich im Schnitt 1/3 von der Zeit! MfG Alexander
Hi Alex, ja danke für den Hinweis. Mit dem Filter hatte ich es zuesrst probiert, aber es lief nicht - keine Ahnung warum. Mittlerweile bin ich auch schon weiter. Mein FIR mit Circular Buffer ist inzwischen pfeilschnell dank geänderter Pointerberechnung und Lookup Table. Ich bin gerade dabei die Koeffizienten für den sin(x)/x Filter zu berechnen. Mit einem Raised Cosinus Filter hate ich es schon probiert, das ergibt leider keine vernünftige Interpolation, da es kein idealer Tiefpass ist. Gruß Hayo
Hallo Hayo! Am besten wäre es meiner Meinung nach, wennst du dir einmal die sin(x)/x-Koeffizienten für 4 Bandbreiten mit gleicher Länge generierst. http://en.wikipedia.org/wiki/Sinc_filter Für B = 2 ist die Grenzfrequenz 1/4 von der Abtastfrequenz. Für B = 4 ist die Grenzfrequenz 1/8 von der Abtastfrequenz. Am besten ist es noch, wenn sin(0)/0 = 1 in der Mitte vorkommt (ungerade Anzahl an Koeffizienten)! Zusätzlich erzeugst du dir mit gleicher Länge ein Hamming (gut, einfach) ein Hann (gut, einfach, anders) und ein Dreieck-Filter (keine Überschwinger im Zeitsignal durch den Filter). http://de.wikipedia.org/wiki/Fensterfunktion Um nun die Filterkoeffizienten für einen fertig verwendbaren Filter zu generiern, musst du die Sinc-Koeffizienten nur mehr mit den Fenster-Koeffizienten einzeln multiplizieren. Damit erreicht man meiner Meinung nach ausreichende Flexibilität. Bspw. Filter auf fs/2, fs/4, fs/10, fs/16 kombiniert ohne (Rechteck-Fenster) und mit den Fenstern ergeben 16 verschiedene Filter! Und als Draufgabe wäre eine unabhängige Option von Zero-Padding (theoretisch richtig) und Wert halten (besser bei kleinen Werten) bei Interpolieren ein Hit! MfG Alexander
alex008 schrieb: > Hallo Hayo! > > Am besten wäre es meiner Meinung nach, wennst du dir einmal die > sin(x)/x-Koeffizienten für 4 Bandbreiten mit gleicher Länge generierst. Daran arbeite ich gerade... > http://en.wikipedia.org/wiki/Sinc_filter > > Für B = 2 ist die Grenzfrequenz 1/4 von der Abtastfrequenz. > Für B = 4 ist die Grenzfrequenz 1/8 von der Abtastfrequenz. > > Am besten ist es noch, wenn sin(0)/0 = 1 in der Mitte vorkommt (ungerade > Anzahl an Koeffizienten)! Ja, ich arbeite mit 11 Koeffizienten. > Um nun die Filterkoeffizienten für einen fertig verwendbaren Filter zu > generiern, musst du die Sinc-Koeffizienten nur mehr mit den > Fenster-Koeffizienten einzeln multiplizieren. Da gibt es fertige Formeln für bei denen die Fensterfunktion schon drin ist. Ist allerdings etwas viel getippe im Rechner... Ich bin am übverlegen ob ich das mal in eine kleine Funktion kippe die die Koeffs berechnet. > Damit erreicht man meiner Meinung nach ausreichende Flexibilität. > Bspw. Filter auf fs/2, fs/4, fs/10, fs/16 > kombiniert ohne (Rechteck-Fenster) und mit den Fenstern ergeben 16 > verschiedene Filter! Das ist wahr. > Und als Draufgabe wäre eine unabhängige Option von Zero-Padding > (theoretisch richtig) und Wert halten (besser bei kleinen Werten) bei > Interpolieren ein Hit! Ich wollte mal den klassischen Ansatz mit Zero-Padding machen, Mit meinen bisherigen Koeffizienten blieben da aber immer Zacken stehen. Ich wollte jetzt mal mit Koeffizienten aus dem Tietze Schenk (ja auch meine alte Ausgabe hat schon digitale Filter drin!) einen Test machen. Danke für die Tips Gruß Hayo
alex008 schrieb: > Hallo Dirk! > > Vielen Dank für dein Angebot, mir deinen 4 Kanäler zu borgen. > Ich werde es aber nicht annehmen, da mich das zu sehr unter Zugzwang > stellen würde. Hallo Alex, was heißt das konkret für das Welec-Projekt? Wirst du die Thematik angehen oder ist das Thema ganz und gar für dich gestorben? alex008 schrieb: > Die FPGAs der 4 Kanäler sind laut Crazor (lange nichts mehr von ihm > gehört) über den Adress-Datenbuss verbunden. > Beim einem schön hirarchischen Aufbau der Software sollte es nicht allzu > schwer sein beide FPGA Designs zu verbinden. > Man müsste unter Umständen nicht einmal den FPGA mit dem Softcore > ändern, wenn man den zweiten FPGA dazu einfügt. > Auch beim anderen FPGA (für Kanal 3 und 4) müsste man nur die > Signalerfassungsteil herausnehmen und die Adress-Datenbuss-Schnittstelle > adaptieren. > Was ein wenig aufwendiger werden könnte, wäre das Auffinden der ADC Pins > für Kanal 3/4. Gedankliche Ansätze hast du ja präsentiert, jetzt wäre es natürlich toll, wenn das nicht nur theoretischer Natur bleiben würde. branadic
Hallo Branadic! In meiner jetzigen beruflichen Situation würde mich die Entwicklung des Oszis zu stark belasten. Ich habe schon in der Firma wegen dem zu hohen Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald kündigen werde. Wenn ich eine Firma finde, bei der ich weniger unter Druck stehe, werde ich mich wieder dieser Open Source Entwicklung widmen. Der nächste Punkt ist, das diese Entwicklung meiner Meinung nach zuerst auch für einen Anwender brauchbar sein sollte, bevor man irgendeine Erweiterung macht. Die Hardwarefunktionalität ist jetzt schon so komplex, dass man zuerst die Software soweit bringt (großer Nachholbedarf), dass auch der Anwender die Vorteile der Neuentwicklung nutzen kann. Alexander
Hallo Hayo, siehst du eine Chance, wenn die Geschichte mit den Filtern erledigt ist, mit der Nios Firmware eine kleine Pause einzulegen und den Entwicklungsschwerpunkt Richtung Nios Firmware zu verlagern? Mfg, Kurt
alex008 schrieb: > In meiner jetzigen beruflichen Situation würde mich die Entwicklung des > Oszis zu stark belasten. Ich habe schon in der Firma wegen dem zu hohen > Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald > kündigen werde. Das ist natürlich bedauerlich zu hören. > Wenn ich eine Firma finde, bei der ich weniger unter Druck stehe, werde > ich mich wieder dieser Open Source Entwicklung widmen. Kann ja nicht so schwer sein einen entsprechenden Arbeitgeber zu finden. > Der nächste Punkt ist, das diese Entwicklung meiner Meinung nach zuerst > auch für einen Anwender brauchbar sein sollte, bevor man irgendeine > Erweiterung macht. > Die Hardwarefunktionalität ist jetzt schon so komplex, dass man zuerst > die Software soweit bringt (großer Nachholbedarf), dass auch der > Anwender die Vorteile der Neuentwicklung nutzen kann. Grundsätzlich funktioniert das Design ja erst einmal auf allen Welec-Geräten, wenn auch in eingeschränkter Form bei den 4-Kanälern, sodass nur zwei Kanäle funktionieren. Ob man das auch mit funktionierender Firmware als "für den Anwender brauchbar" bezeichnen kann lasse ich mal offen. Womöglich steigt die Motivation den zweiten FPGA auch noch zu implementieren, wenn erst einmal eine funktionstüchtige Firmware bereit steht? Was die ADCs angeht, so würde ich schwer vermuten, dass die bei Kanal 3 und 4 an den gleichen Pins hängen wie auch bei Kanal 1 und 2. Das würde zumindest logisch erscheinen. branadic
@alex > Ich habe schon in der Firma wegen dem zu hohen > Druck bekannt gegeben, dass ich mit sehr hoher Wahrscheinlichkeit bald > kündigen werde. Das kommt mir sehr bekannt vor. Junge engagierte Mitarbeiter, die noch nicht so lange dabei sind ordentlich ausquetschen, da diese sich ja noch nicht so wehren... Da hilft nur eins: Erst mal weitermachen und nebenbei nach was Besserem suchen. So hab ich das auch gemacht. Danach gings mir in jeder Hinsicht besser. Jetzt hab ich sogar Zeit nebenher dieses Open Source Projekt zu machen. Das wär vorher nie gegangen. @Kurt Du meintest sicherlich LEON und nicht NIOS. Also ich zögere da momentan noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe. Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle Besitzer eines 4 Kanalgerätes. Bei dem Aufwand den die Erstellung einer vollwertigen Firmware für den LEON erfordert möchte man da natürlich auch keine Kompromisse machen. Also ich wäre da deutlich motivierter wenn nicht der Vorteil des LEON Designs mit dem Nachteil der unvollständigen Hardwareunterstützung erkauft wäre. Grundsätzlich müßte ich auch mal drüber nachdenken ob ich die Firmwarestruktur der NIOS-Implementierung übernehme um beide Linien weiter unterstützen zu können oder ob ich da einen Schnitt mache und nur noch das LEON-Design unterstütze. Gruß Hayo
Angehängte Dateien:
-
Linear.jpeg
38 KB -
sinc.jpeg
43 KB
So, jetzt mal was Anderes Ich kämpfe immer noch mit der sin(x)/x Interpolation. Wie man auf dem Screenshot sieht bleiben trotz Interpolation immer noch Reste vom Zero Padding stehen. Cutoff Frequenz ist 0.1 normiert auf die Abtastfrequenz -> d.h. 0.1 * 2.5 GHz = 250 MHz. Bei 0.05 das Gleiche. Trotzdem habe ich irgendwie das Gefühl die Cutoff Frequenz ist noch zu hoch. Hat hier jemand gute Vorschläge? Ich habe mir übrigens jetzt ein Programm geschrieben welches mir den Filterkernel berechnet. Das liegt bei der nächsten Version mit dabei, falls jemand selbst FIR-Filter berechnen möchte. Hier die Bildschirmausgabe: * Windowed sinc FIR filter * * Type : low pass 10th order * Filter length (order + 1) : 11 * Cutoff frequency (normed) : 0.100000 * Window : Blackman * Gain : 2.500000 * Fixed point width : 15 * Integer factor (fixed point) : 32768 * * * floating point fixed point * --------------------------------------------- * h[0] = -0.000000 h[0] = 0 * h[1] = 0.006564 h[1] = 215 * h[2] = 0.070701 h[2] = 2316 * h[3] = 0.269282 h[3] = 8823 * h[4] = 0.554480 h[4] = 18169 * h[5] = 0.697946 h[5] = 22870 * h[6] = 0.554480 h[6] = 18169 * h[7] = 0.269282 h[7] = 8823 * h[8] = 0.070701 h[8] = 2316 * h[9] = 0.006564 h[9] = 215 * h[10] = -0.000000 h[10] = 0 Gruß Hayo
Hayo W. schrieb: > Also ich zögere da momentan > noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe. > Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle > Besitzer eines 4 Kanalgerätes. Bei dem Aufwand den die Erstellung einer > vollwertigen Firmware für den LEON erfordert möchte man da natürlich > auch keine Kompromisse machen. Das du diese Bedenken äußern würdest haben wir erst gestern Abend im SkypeChat vorher gesagt. Dennoch hoffen wir, Kurt und ich, dass du dich davon nicht abschrecken lassen wirst und es Alex die notwendige Motivation verschafft die Implementierung zu vervollständigen. branadic
@branadic Ich werd mir das noch mal durch den Kopf gehen lassen. @all Wegen der Filter bin ich etwas weiter gekommen. Das hängt wohl mit der Cutoff Frequenz in Verbindung mit der Filterlänge zusammen. Bei niedrigen Cutoff Frequenzen muß die Filterlänge größer sein, damit die Rechteck-Characteristik im Frequenzbereich annähernd erhalten bleibt. Heißt übersetzt: Ich habe mal einen Filterkernel mit 17 Koeffizienten berechent (statt 11) und schon waren bei 10ns/div die Zacken weg. Für 5 und 2ns muß ich den Filter vermutlich ziemlich lang machen, was die Berechnung natürlich verlangsamt - mal sehen. Gruß Hayo
Hayo W. schrieb: > @Kurt > > Du meintest sicherlich LEON und nicht NIOS. Also ich zögere da momentan > noch da ich die Unterstützung der Kanäle 3 + 4 erstmal noch nicht sehe. > Das schränkt natürlich die Brauchbarkeit ein. Zumindest für alle > Besitzer eines 4 Kanalgerätes. Sicher, der Leon ist gemeint. Da die Brauchbarkeit mit dem Nios und den dämlichen Filtern gegen Null tendiert, zumindest für sinnvolle Messungen, würde ich das fehlen von 3 Kanälen nicht als große Beeinträchtigung sehen. Die Leute, die mit dem Welec nur an irgendwelchen µCs rummessen, sind wohl mit dem Nios eher zufrieden. Das Oszi soll aber nicht als Ersatz für einen 50€ Logicanalyzer dienen, sondern Messungen bis mindestens 100Mhz ermöglichen, was zurzeit definitiv nicht gegeben ist und sich dank Nios auch mit der Huckepackplatinen nicht ändern wird. Hayo W. schrieb: > @branadic > > Ich werd mir das noch mal durch den Kopf gehen lassen. Sehr gut, danke.
Der Ton hier gefällt mir im Moment überhaupt nicht - sowohl in Alex' als auch in Hayos Richtung werden Forderungen statt Bitten gestellt und es ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern" zu sprechen. Beide haben schon sehr viel geleistet und beide tun das ausschließlich in ihrer Freizeit - glaubt ihr da ist dieser Ton angemessen? Stattdessen sollte man versuchen, eine Lösung für das Henne-Ei Problem des Leon zu finden: solange nur zwei Kanäle ansprechbar sind, ist die Motivation gering, mit der Firmwareentwicklung zu beginnen und solange es keine Firmware gibt, möchte niemand die fehlenden zwei Kanäle angehen. Das Samplen der Kanäle 3 und 4 dürfte kein Problem sein - wenn man bei Welec mitgedacht hat dann sind die ADCS am zweiten FPGA identisch angebunden wie am ersten. Als Hürde sehe ich hier nur die Kommunikation zwischen den FPGAs - wenn man Informationen hätte, wie die beiden im NIOS Design verbunden sind dann könnte man das sicher relativ zügig implementieren. Die Programmiermaschine Hayo wird sich bestimmt nicht zweimal bitten lassen, die Firmware auf viel leistungsfähigerer Basis umzusetzen, wenn erst einmal die Grundlage(inklusive Doku aller Schnittstellen / Register) vorhanden ist. Die Frage ist also: wie bekommt man heraus, wie die FPGAs verbunden sind? Wenn diese Info vorhanden wäre könnte eventuell sogar ich die Zeit finden, mich um die Schnittstelle zu kümmern - versprechen kann ich da aber leider nichts, da ich beruflich auch recht eingespannt bin. Michael
Michael H. schrieb: > und es > ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern" > zu sprechen. Ok, meine Formulierung war etwas undeutlich. Mit "dämlichen Filtern" sind natürlich nicht die gemeint, die Hayo programmiert hat, sondern die zur Zeit im FPGA implementierten. Die sorgen nämlich dafür, dass die Signale bei höheren Frequenzen und Amplituden gnadenlos verstümmelt verden. Michael H. schrieb: > Beide haben schon sehr viel geleistet und beide tun das ausschließlich > in ihrer Freizeit Das bestreitet niemand! Aber auch andere Leute, wie branadic, Walter und ich haben viel geleistet, und die wollen langsam Ergebnisse sehen, die nun mal in erster Linie vom Leon abhängen. Um es nochmal deutlich zu sagen, es ist wirklich großartig, was Hayo und die anderen Programmierer schon geschafft haben, und in welchem Tempo. Aber von den vielen Entwicklern (früher bestimmt 15 Leute) ist nur noch ein Drittel übrig geblieben: Hayo, Jörg, Walter, branadic Alexander vieleicht und ich. Damit das Projekt nicht vollständig entschläft, ist es sicher erlaubt fordernde als auch motivierende Worte zu sprechen. Mfg, Kurt PS: Kurt Bohnen schrieb: > würde ich das fehlen von 3 Kanälen nicht als große > Beeinträchtigung sehen. Natürlich fehlen nur 2 Kanäle ;-)
Michael H. schrieb: > Der Ton hier gefällt mir im Moment überhaupt nicht - sowohl in Alex' als > auch in Hayos Richtung werden Forderungen statt Bitten gestellt und es > ist wohl weder produktiv noch motivierend, hier von "dämlichen Filtern" > zu sprechen. Mir war nicht klar das Michael ein Moralapostel war/ist. Aber im ernst, mir ist primär egal was dir gefällt oder nicht, aber niemand hat gefordert, sondern lediglich nachgefragt und versucht zu motivieren. Das wir mit Alex's Haltung beim vorerst aktuellen Single-FPGA-Design zu bleiben und Hayo's Haltungen keinen Plattformwechsel durchzuführen solange nicht beide FPGAs implementiert sind war absehbar. Das ist ein Problem und muss irgendwo auch zur Sprache gebracht werden, wenn nicht hier, dann wo? Michael H. schrieb: > Beide haben schon sehr viel geleistet und beide tun das ausschließlich > in ihrer Freizeit - glaubt ihr da ist dieser Ton angemessen? Na ein Glück haben alle anderen Entwickler inkl. mir beruflich mitgewirkt und nicht ihre Freizeit geopfert und mit "glaubt ihr" fühle ich mich durchaus mit angesprochen. Mein Nachfragen um die Programmierer zu motivieren zieht sich durch alle Threads wie ein roter Faden, doch so langsam bin ich der A***leckerei schlichtweg überdrüssig, denn genauso kommt es mir langsam vor! Man ist ständig auf die Laune Einzelner angewiesen. Ich kann niemandem vorschreiben womit er sich beschäftigen sollen, allerdings bin ich und das habe ich mehrfach zum Ausdruck gebracht, der Meinung, dass viele der in letzter Zeit umgesetzten Spielereien die Funktion nicht wirklich verbessert und damit keinen wirklichen Fortschritt gebracht haben. Wir erinnern uns an die verschiedenen Farbpaletten, den Logikpegeln und ähnliche Dinge. Der wirklich größte Fortschritt dürfte mit Abstand die Implementierung der Huckepackplatine gewesen sein. Und hier möchte ich daran erinnern, dass das weit über ein Jahr mit viel Nachfragerei gebraucht hat. Wenn das so weitergehen soll, dann wird auch in den nächsten Jahren kein Paradigmenwechseln stattfinden und der Leon nie den Weg ins Welec schaffen, davon bin ich mehr als überzeugt. Darüber hinaus sind viele der anfänglichen Entwickler mittlerweile abgesprungen, das Projekt artet also immer mehr zu einer One Man-Show aus und die Arbeit der übrigen Entwickler geht in der Beweihräucherung einer einzelnen Person unter, das missfällt mir. branadic
Hey, nicht streiten! Ich habe durchaus Verständnis, dass jeder für seinen Standpunkt und seine favorisierten Projekte eintritt. Ich fühle mich jetzt auch nicht angegriffen, wenn kritische Anmerkungen gemacht werden. Ist ja klar, das jeder seine Anliegen etwas pushen möchte und daher hier zur Sprache bringt. Kein Problem. Dazu ist das Forum da. Ich möchte zum Stand der Dinge nochmal darauf hinweisen, dass das primäre Ziel meiner Entwicklungen bisher die Verbesserung der originalen Plattform war, so dass in überschaubarer Zeit ein benutzbares Oszi dabei herauskommt. Das ist, finde ich, auch schon recht weit gediehen. Kurts etwas pessimistische Einschätzung teile ich da nicht. Gut, das Teil ist nicht unbedingt die erste Wahl für ein HF-Labor, aber für den Hausgebrauch reicht das locker aus. Davor hatte ich nur ein 50MHz Analog-Oszi von Philips - Da kann unser DSO mehr als locker mithalten. Und auch für das Meiste was ich damals im Studium in den Laboren gemacht habe hätte das WELEC ausgereicht. Da hätte ich mich als Studi gefreut wie ein Schneekönig wenn ich sowas gehabt hätte (und das für den Preis!). Das jetzt die Möglichkeit besteht auf eine leistungsfähigere "Hardware" umzuschwenken übt natürlich einen gewissen Reiz aus. Aber es sollte Allen klar sein dass es einige Zeit dauern wird bis da was Brauchbares mit echtem Nutzwert herauskommt, da wie schon mehrfach erwähnt die Resourcen bei allen hier auf die Freizeit beschränkt sind. Ich denke auch die absoluten Befürworter einer Portierung auf das LEON Design werden Verständnis dafür haben, dass auch weiterhin erstmal die Verbesserung der aktuellen Firmware Priorität bei mir hat. Das soll nicht heißen, dass die Portierung nicht stattfindet, sondern dass das Ganze auch mit den richtigen Vorüberlegungen angegangen werden muß. Weiterhin macht das Ganze nur Sinn, wenn auch weiterhin Unterstützung seitens der FPGA-Entwickler kommt. Alex hatte ja angedeutet, dass er evtl. wieder zur Verfügung steht wenn sich seine berufliche Situation entspannt. Also gehen wir das Ganze mal mit etwas Gelassenheit an und sehen mal Schritt für Schritt was sich machen läßt. Gruß Hayo
Ach ja, zur One Man Show wollte ich noch was sagen. Ich beanspruche die Lorbeeren des bisher Geschafften keinesfalls für mich allein. Da sind zahlreiche Beiträge im Laufe der Zeit eingeflossen, ohne die wir nicht da wären wo wir jetzt sind. Im Changelog habe ich die Mitstreiter vermerkt (hoffe ich habe niemanden vergessen). Auch im Coding habe ich versucht die Stellen kenntlich zu machen. Es ist nurt einfach so, dass ich offensichtlich am konstantesten die Zeit für das Projekt aufbringen kann (und will). Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung. Gruß Hayo
Hallo Trage zwar nichts zur Entwicklung bei, als ab und zu mal die neue Version zu probieren und fleißig hier mitzulesen.. , aber ich möchte auch mal meine Meinung kundtun. Ich sehe die Zukunft auch im Leon Design, aber wenn es dann bei einem 4 Kanal DSO nur 2 Kanäle nutzbar sind, würde ich da nicht mitumsteigen. Ich weiß, branadic, da kommt schon wieder einer und machte deine Anststrengungen und A...l zunichte. >Und auch für das Meiste was ich damals im Studium in den Laboren gemacht >habe hätte das WELEC ausgereicht. Da hätte ich mich als Studi gefreut >wie ein Schneekönig wenn ich sowas gehabt hätte (und das für den >Preis!). Sehe ich auch so! Einige hier wollen halt ein HF DSO, aber viele hier sehen es wie Hayo, dass sie schon froh sind, dass sie ein günstiges 4 Kanal DSO haben das besser ist als das alte 50MHz Analog Osci. (bei mir 20MHz :-) ) >Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich >selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen >sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung. Sehe ich auch so! (Obwohl ich am wenigsten dazu beitrage ;-) ) l.G. Roberto
Roberto schrieb: > Ich sehe die Zukunft auch im Leon Design, aber wenn es dann bei einem 4 > Kanal DSO nur 2 Kanäle nutzbar sind, würde ich da nicht mitumsteigen. Das letzte Wort dazu hat Alex doch noch gar nicht gesprochen, aber momentan beißt sich die Katze selbst in der Schwanz: Der eine will nicht damit anfangen Firmware zu bauen wenn es nur zwei Kanäle sind, der andere will das Design nicht auf 4 Kanäle weiterentwickeln, wenn es keinen Fortschritt bei der Firmware gibt. Entweder überwindet sich einer von beiden oder aber die Sache ist gestorben. Hayo W. schrieb: > Das jetzt die Möglichkeit besteht auf eine leistungsfähigere "Hardware" > umzuschwenken übt natürlich einen gewissen Reiz aus. Aber es sollte > Allen klar sein dass es einige Zeit dauern wird bis da was Brauchbares > mit echtem Nutzwert herauskommt, da wie schon mehrfach erwähnt die > Resourcen bei allen hier auf die Freizeit beschränkt sind. Jedem dürfte klar sein, dass es einige Zeit brauchen wird, bis der Leon den aktuellen Stand vom NIOS-Design hat. Jörg hatte einmal vorgeschlagen, dass man vielleicht mit einen HAL arbeiten könnte, dann könnte die Entwicklung bilateral voranschreiten und alle wären glücklich. Roberto schrieb: > Einige hier wollen halt ein HF DSO, aber viele hier sehen es wie Hayo, > dass sie schon froh sind, dass sie ein günstiges 4 Kanal DSO haben das > besser ist als das alte 50MHz Analog Osci. (bei mir 20MHz :-) ) Es gibt kein HF DSO und 200MHz -3dB-Gerenze sind nun auch kein besonderes Alleinstellungsmerkmal. Die Huckepackplatine vermag ihr vollständiges Potential, messen bis 200MHz, nun mal erst richtig zu zeigen, wenn sicher gestellt ist das keine Filter die digitalisierten Signale wieder zunichte macht, aber das ist mit dem NIOS nun mal nicht der Fall. Das sollte langsam auch bei allen angekommen sein. Da hilft auch ein Umschalten des ominösen Registers herzlich wenig, denn ich will mit einem Gerät schließlich messen und nicht nur Zufallsbilder erzeugen, die frei interpretierbar sind. Das Filter, zumindest wird vermutet das es eines ist, beeinflusst in hohem Maße den Frequenzgang, sodass aus einer Eingangsstufe mit flachem Frequenzgang etwas völlig vermurkstes wird. Und bisher ist nicht klar, wie sich das Filter deaktivieren lässt. Schwer nachzuvollziehen, dass ihr euch damit zufrieden geben wollt, denn auch bei einem 20MHz Rechteck greift das Filter schon in vollem Maße und verformt die Flanken. Die Motivation die Huckepackplatine zu entwickeln war ja gerade das Welec zu verbessern. Die erste logische Konsequenz dazu war die Unterstützung der Huckepackplatine durch die Firmware. Es hat ewig gedauert, weit über ein Jahr, aber dank Jörg ist diese Unterstützung nun gegeben. Die nächste logische Konsequenz aus dem Welec ein Messgerät zu machen ist nun einmal der Plattformwechsel hin zum Leon-Design. Nicht zuletzt deswegen, weil es OpenSource ist und wir den Entwickler an der Strippe haben. Hayo W. schrieb: > Es ist nurt einfach so, dass ich offensichtlich am konstantesten die > Zeit für das Projekt aufbringen kann (und will). Ich will nicht sagen das du die anderen vergrauelt hast (ich erinnere an die OS-Version), aber die Zusammenarbeit mit dir schien ja nicht ganz einfach zu sein. Mich wundert es dann nicht das die Leute dann irgendwann die Nase voll hatten. Hayo W. schrieb: > Jeder hat die Möglichkeit selbst was beizutragen oder auch nur sich > selbst seine eigene angepasste Firmwareversion zu basteln. Alle Sourcen > sind frei verfügbar und ich gebe jederzeit gerne Hilfestellung. Das sagt sich immer wunderbar einfach "Bau dir deine eigene Version..." Programmierung ist nun mal nicht jedermanns Metier, so wie du vielleicht auch nur bedingt Ahnung von analoger Schaltungstechnik haben wirst. Das ist innerhalb des Projektes von Anfang an ein Problem gewesen, Hardwareentwickler und Softwarenentwickler haben einfach nicht Hand in Hand zusammengearbeitet, stattdessen musste gebettelt werden, dass wichtige Funktionen für die Hardwareentwicklung in Software umgesetzt werden. Das funktioniert natürlich eine gewisse Zeit lang, aber dann verlieren die Leute die Lust am Projekt weiterhin mitzuwirken. Wen wundert es, dass der ursprüngliche Entwicklerkern schon lange nicht mehr existent ist? Vielleicht lag das aber auch daran, dass dem Projekt eine RoadMap gefehlt hat, an der klar die Aufgaben und Ziele erkennbar gewesen wären. Ich mach dir das nicht mal zum Vorwurf Hayo, aber es muss auch mal klar gesagt werden, alles unterliegt deiner Laune. Und momentan liegt diese bei Spielereien, die die Funktionalität des Gerätes im Ursprung nicht verbessern. Hätte Jörg sich nicht daran gemacht die Arbeit der Hardwareentwickler durch Integration der Ansteuerung der Huckepackplatine zu unterstützen würden wir heute noch darauf warten. Du hast deine beiden Huckepackplatinen ja nun auch weit über ein Jahr, ich nehme an die liegen immer noch schön verpackt? Soviel zum Thema Hand in Hand arbeiten. Ich wundere mich nach wie vor, dass niemand der sich mit Huckepackplatinen eingedeckt hat das hier je moniert hat. Ob diese Leute mittlerweile auch resignieren? Auf jeden Fall ist seit einiger Zeit wieder erkennbar, dass sich der Kreis der Akteure reduziert hat. Hayo W. schrieb: > Ich möchte zum Stand der Dinge nochmal darauf hinweisen, dass das > primäre Ziel meiner Entwicklungen bisher die Verbesserung der originalen > Plattform war, so dass in überschaubarer Zeit ein benutzbares Oszi dabei > herauskommt. Das ist, finde ich, auch schon recht weit gediehen. > Ich denke auch die absoluten Befürworter einer Portierung auf das LEON > Design werden Verständnis dafür haben, dass auch weiterhin erstmal die > Verbesserung der aktuellen Firmware Priorität bei mir hat. Offenbar haben wir da ganz unterschiedliche Vorstellungen von dem Begriffen "benutzbar", "Oszi" und "Verbesserung". Unbestritten ist dass das Welec schneller geworden und die ein oder andere Funktion nun gegeben ist, aber wenn der Signalerfassungsteil schon fehlerhaft ist nützt der ganze Aufwand im Anschluss herzlich wenig, das Signal ist dann einfach unwiederbringlich hin. Irgendwie will das nur niemand einsehen. Warum dann noch darin Energie verschwenden? Warum so resistent? Ich kann das beim besten Willen nicht nachvollziehen und die Logik dahinter entzieht sich mir! Ich sehe in den jüngsten Aktivitäten nur Spielereien. Ziel sollte nach meiner Auffassung die Verbesserung der Basis sein und diese lässt sich mit dem NIOS nun einmal nicht bewerkstelligen. Ferrari-rot macht aus einem Käfer nun mal noch kein schnelles Auto! Da ich aber merke das man hier als Einzelperson gegen Windmühlen oder eingesessene Altkonservative ankämpft und ich es offen gestanden auch leid bin mich hier immer und immer zu wiederholen geb ich jetzt Ruhe. Macht doch was ihr wollt. Begnügt euch weiterhin mit "Blingbling" statt mal da anzugreifen wo wirkliches Verbesserungspotential steckt, um aus dem Welec ein DSO zu machen. branadic
Tja branadic, es ist aber kein böser Wille, dass dies der aktuelle Stand ist. Es liegt auch am riesigen Aufwand, den jeder scheut. Wenn ich mir auf SFN allein die Liste an Software anschaue, die nur zum Aufspielen des LEONs nötig ist und dann nicht erkennen kann, was jetzt auf welcher Plattform läuft. Und damit hat man noch nicht einmal eine laufende Toolchain zum Programmieren. Ich mache mal einen Vorschlag: Hayo erstellt ein C++-Framework. Ob vom NIOS übernommen oder neu, muss er selbst entscheiden. Dann kann mit laufender Toolchain im TopDown-Verfahren dieser Rahmen mit der NIOS-Menüstruktur ohne echte Funktion gefüllt werden. Das kann auch branadic, dazu muss man kein Meisterprogrammierer sein. Anschließend kann dann die Funktion vom NIOS portiert werden, Schritt für Schritt. Grüße, Guido
Es will doch niemand, dass jetzt alle Nutzer sofort auf den Leon umsteigen. Dessen Firmware hat doch erst Alpha Staus. Bis da eine Beta draus wird, die man dem Nutzer zum testen anbieten kann, dürfte es noch viel Arbeit sein. Und bis dahin läuft der Leon nur im RAM, sodass man jederzeit wieder mit dem Nios seine "Messungen" machen kann. So riesig kompliziert, die Leon Toolchain zu installieren ist es auch nicht. Das habe sogar ich geschafft. Es könnte allerdings sein, dass die Anleitung im Wiki noch etwas ergänzt werden müsste.
branadic schrieb: > Der eine will nicht damit anfangen Firmware zu bauen wenn es nur zwei Kanäle sind... Das habe ich nicht gesagt. Ich sagte ich zögere etwas weil da erstens (wie Guido ganz richtig schrieb) die Hürden für den Einstieg genommen werden müssen. Das betrifft in der Tat vor allem Toolchain, Anleitungen und technische Doku. Zweitens ist schon erstmal recht viel zeitlicher Aufwand damit verbunden bis man erste Ergebnisse erwarten kann, während in der NIOS-Umgebung dank vorhandener Basis schneller Resultate erzielt werden können. Das die technische Basis beim LEON deutlich besser ist, ist völlig klar. Jörg hatte einmal > vorgeschlagen, dass man vielleicht mit einen HAL arbeiten könnte, dann > könnte die Entwicklung bilateral voranschreiten und alle wären > glücklich. Das würde aber den Performancevorteil unter Umständen wieder auffressen, was ich eigentlich schade fände. > Die Huckepackplatine vermag ihr vollständiges Potential, messen bis > 200MHz, nun mal erst richtig zu zeigen, wenn sicher gestellt ist das > keine Filter die digitalisierten Signale wieder zunichte macht, .... > Die nächste logische Konsequenz aus dem Welec ein Messgerät zu > machen ist nun einmal der Plattformwechsel hin zum Leon-Design. Nicht > zuletzt deswegen, weil es OpenSource ist und wir den Entwickler an der > Strippe haben. Keine Frage, das ist ein echtes Argument. > Ich will nicht sagen das du die anderen vergrauelt hast (ich erinnere an > die OS-Version), aber die Zusammenarbeit mit dir schien ja nicht ganz > einfach zu sein. Mich wundert es dann nicht das die Leute dann > irgendwann die Nase voll hatten. Hmm, da fühle ich mich aber doch etwas mißverstanden muß ich sagen. Ich habe damals mehrfach erklärt warum ich gerne an einer eigenen Version der Firmware festhalten wollte. Ich habe alle Entwicklungen auch der OS-Version zur Verfügung gestellt und umgekehrt auch einige Sachen aus der OS-Version übernommen. > Das sagt sich immer wunderbar einfach "Bau dir deine eigene Version..." > Programmierung ist nun mal nicht jedermanns Metier, Das ist schon klar, aber wenn man nicht selber programmierren kann ist man halt auf Andere angewiesen. Ich wollte nur auf die grundsätzlichen Möglichkeiten hinweisen, die sicherlich auch der Eine oder Andere hier nutzt. Ich versuche weiterhin auch die Vorschläge hier aus dem Forum einzuarbeiten und dabei auf Vorlieben der Mehrheit einzugehen. > Wen wundert es, dass der ursprüngliche Entwicklerkern schon lange > nicht mehr existent ist? Das ist aber nichts Ungewöhnliches. Die Wenigsten widmen sich so langfristig einem Projekt, da irgendwann persönliche Umstände den Fokus auf andere Dinge lenken. > Vielleicht lag das aber auch daran, dass dem Projekt eine RoadMap > gefehlt hat, an der klar die Aufgaben und Ziele erkennbar gewesen wären. mag sein. > Ich mach dir das nicht mal zum Vorwurf Hayo, aber es muss auch mal klar > gesagt werden, alles unterliegt deiner Laune. Und momentan liegt diese > bei Spielereien, die die Funktionalität des Gerätes im Ursprung nicht > verbessern. Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich aber mächtig interessant finde. Das ich da zum Teil die Prioritäten bei der BF-Version vorgebe ist doch klar. Das würde jeder Andere auch machen, und das denke ich kann man mir doch nicht zum Vorwurf machen. Das war ja der Grund, warum ich neben der OS-Version meine eigene beibehalten hatte. Ich wollte für mich selbst die Prioritäten setzen können. > Hätte Jörg sich nicht daran gemacht die Arbeit der > Hardwareentwickler durch Integration der Ansteuerung der > Huckepackplatine zu unterstützen würden wir heute noch darauf warten. Da hast Du vermutlich Recht. Das lag aber leider auch daran, dass die Harwareentwickler die Sache nicht zuende gedacht hatten und mir die entsprechenden Informationen zur Ansteuerung fehlten. Wenn Jörg das nicht zuende gedacht und entwickelt hätte wäre es auch etwas schwierig geworden. > Du hast deine beiden Huckepackplatinen ja nun auch weit über ein Jahr, > ich nehme an die liegen immer noch schön verpackt? Ist richtig, erst wollte ich mal Jörgs Fortschritte abwarten. Ich glaube es funktioniert zwar soweit schon, aber eine endgültige Rückmeldung über den Stand der Dinge mit Probemessungen und Screenshots fehlt noch. Ich vermute mal, dass Jörg beruflich auch recht eingespannt ist. Das wäre doch was für Dich, die Firmware unterstützt die Platine ja schon. Außer Jörg (und Dir?) hat aber wohl noch keiner Selbige eingebaut oder? > Ich wundere mich nach wie vor, dass niemand der sich mit > Huckepackplatinen eingedeckt hat das hier je moniert hat. Ob diese Leute > mittlerweile auch resignieren? Das glaube ich eher nicht. Ich denke es wird einfach nur in Ruhe abgewartet wie sich das entwickelt. > ...aber wenn der Signalerfassungsteil schon fehlerhaft ist > nützt der ganze Aufwand im Anschluss herzlich wenig, das Signal ist dann > einfach unwiederbringlich hin. Irgendwie will das nur niemand einsehen. Ganz so schlimm ist es auch wieder nicht, Die Signale werden in einem gewissen Frequenzband schon ganz anständig dargestellt. Ich habe da schon mehrfach den Vergleich mit dem Tektronix 2465A gemacht und fand das nicht so schlecht. > Da ich aber merke das man hier als Einzelperson gegen Windmühlen oder > eingesessene Altkonservative ankämpft... Oha, wer soll sich denn den Schuh anziehen ein Alkonservativer zu sein? Ich bin ja selbst auch nicht mehr taufrisch, aber das wäre wohl etwas zu viel des Guten. > und ich es offen gestanden auch > leid bin mich hier immer und immer zu wiederholen geb ich jetzt Ruhe. Das ist aber nicht der Sinn der Diskussionen hier. Es soll ja keiner Mundtot gemacht werden. Also laß Dich nicht davon abhalten Deine Meinung zu äußern. > Ich sehe in den jüngsten Aktivitäten nur Spielereien. Ja aber auch die erfreuen das Herz... > Ziel sollte nach > meiner Auffassung die Verbesserung der Basis sein Ja da hast Du natürlich auch recht. Ich bin ja auch nicht abgeneigt, sondern stürze mich jetzt nur nicht gleich mit lautem Hurra in die Sache. Ich habe aber die Absicht mein 2-Kanal Oszi als LEON Plattform umzufunktionieren und mal zu prüfen wie ich da weiter vorgehen kann. Hinweise und Tips zur LEON Entwicklungs-Toolchain sind willkommen. Gruß Hayo
Sollten wir für das Leon-Design nicht ev. einen neuen Thread öffnen? Es wird schon über lange Zeit parallel zum bisherigen Stand verlaufen.
Hayo W. schrieb: > Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner > Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund > meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich > aber mächtig interessant finde. Die selben Themen könntest du auch auf dem Leon bearbeiten... Auch müsste während der Arbeit am Leon die Nios Entwicklung nicht vollständig ruhen, obwohl meiner Meinugn nach deine Firmware sehr nahe an der Perfektion ist! Hast du konkrete Probleme/Fragen zur Installation der Toolchain? Fühlt sich jemand der stillen Mitleser die noch nichts zum Projekt beigetragen haben dazu berufen, die Anleitung zu erweitern?
Hayo W. schrieb: > Da hast Du vermutlich Recht. Das lag aber leider auch daran, dass die > Harwareentwickler die Sache nicht zuende gedacht hatten und mir die > entsprechenden Informationen zur Ansteuerung fehlten. Wenn Jörg das > nicht zuende gedacht und entwickelt hätte wäre es auch etwas schwierig > geworden. Das möchte ich doch mal richtig stellen, wie das Ganze umgesetzt und angebunden werden sollte wurde vorgegeben. Das sich das als unpraktisch erwiesen hat und Jörg eine schönere Lösung gefunden hat ist eine andere Geschichte. Hayo W. schrieb: > Ist richtig, erst wollte ich mal Jörgs Fortschritte abwarten. Ich glaube > es funktioniert zwar soweit schon, aber eine endgültige Rückmeldung über > den Stand der Dinge mit Probemessungen und Screenshots fehlt noch. Ich > vermute mal, dass Jörg beruflich auch recht eingespannt ist. Das wäre > doch was für Dich, die Firmware unterstützt die Platine ja schon. Außer > Jörg (und Dir?) hat aber wohl noch keiner Selbige eingebaut oder? Die Rückmeldung kam, auch wenn der Allgemeinheit nur bedingt bunte Bildchen gezeigt worden sind. Von Walter sind auch Probemessungen veröffentlicht, die die Schwächen durch das öminöse Register eindeutig verdeutlicht haben, zugleich aber den wirklich flachen Amplitudengang der neuen Eingangsstufe dokumentieren. Was erwartet man noch? Die Implementierung von Jörg funktioniert, auch das sollte mittlerweie bekannt sein. Hayo W. schrieb: > Ganz so schlimm ist es auch wieder nicht, Die Signale werden in einem > gewissen Frequenzband schon ganz anständig dargestellt. Ich habe da > schon mehrfach den Vergleich mit dem Tektronix 2465A gemacht und fand > das nicht so schlecht. Ich weiß nicht ob dein 2465A defekt ist oder du dir die Ergebnisse schön reden möchtest, mein 2465A und das menschliche Auge sagen etwas anderes. Bei 1GS und 10 Stützstellen bei einem 100MHz Sinussignal würde ich doch etwas anderes erwarten als das, was auf dem Welec zu sehen ist. branadic
branadic schrieb: > Ich weiß nicht ob dein 2465A defekt ist oder du dir die Ergebnisse schön > reden möchtest, mein 2465A und das menschliche Auge sagen etwas anderes. > Bei 1GS und 10 Stützstellen bei einem 100MHz Sinussignal würde ich doch > etwas anderes erwarten als das, was auf dem Welec zu sehen ist. Mach das mal konkret und verweise nicht auf riesige pdf-Dateien, die sich naturgemäß kein Schwein anschaut. Mein W2012A ist bis 100 MHz spezifiziert, üblicherweise -3 dB, und kann viel mehr in diesem Rahmen. Hast du vielleicht etwas falsch verstanden?
Ach Guido, nur weil du noch mit 14k-Modem unterwegs bist und dir vielleicht zu fein bist dir die Arbeit anderer anzuschauen heißt das nicht, dass die Messungen nicht dokumentiert worden sind. Um es dir mundgerecht zu kredenzen hier noch mal der direkte Link: http://welecw2000a.sourceforge.net/docs/Hardware/PCB_messung_2.pdf und nach wie vor findet man alles zum Thema Hardwareverbesserung hier: http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement branadic
Nix Modem, DSL, aber nach 20 Sekunden habe ich den Downloadvorgang mal wieder abgebrochen. Ich erwarte mir auch nichts neues davon. Bilder mit der Huckepackplatine auf dem Welec, die einen Vorteil belegen, gibt es wohl noch nicht. Auch Jörg wollte keine publizieren. Sorry, deinen Messprotkollen traue ich soviel wie denen von jedem anderen. Ist wahrscheinlich eine Berufskrankheit, hat sich bisher aber immer bewährt. Gruß, Guido
Okay Guido, ich lasse es jetzt einfach dabei, bevor ich dir gegenüber ausfallend werde. Denk was du willst, ich lege keinen Wert auf deine Meinung! branadic
Guido schrieb: > Bilder mit der Huckepackplatine auf dem Welec, die einen Vorteil > belegen, gibt es wohl noch nicht. Doch. Sind in den PDFs. Aber wenn du nichtmal die Zeit hast, den Download abzuwarten, wird es dir auch zu viel Arbeit sein die Platinen ins Oszi einzubauen, oder?
Naja Kurt, bestellt sind sie ja. Aber vllt. werde ich sie vor dem Einbau noch durchmesen müssen? Gruß, Guido
Guido schrieb: > Aber vllt. werde ich sie vor > dem Einbau noch durchmesen müssen? Ganz ehrlich Guido, das ist mehr als daneben und auch dir sollte langsam klar werden, dass du dich gerade lächerlich machst! branadic
Ah, ok. Du bist DER Guido, ich dachte schon wir hätten 2. ;-) Extern durchmessen dürfte Aufwändig werden. Besser mit Lupe/Mikroskop kontrollieren und alle Ein- und Ausgänge gegen Masse auf Kurzschluss prüfen.
branadic schrieb: > Ganz ehrlich Guido, das ist mehr als daneben und auch dir sollte langsam > klar werden, dass du dich gerade lächerlich machst! Immer langsam branadic. Auch andere Forumsteilnehmer sind berufstätig und haben in diesem Zusammenhang Messmöglichkeiten, die über den Hobbybereich hinausgehen. Aber auch hier zu Hause bin ich nicht so karg ausgestattet, bis 500 MHz reicht es. Jo Kurt, ich bins, im anderen Forum ja auch. Grüße, Guido
Guido schrieb: > Immer langsam branadic. Auch andere Forumsteilnehmer sind > berufstätig und haben in diesem Zusammenhang Messmöglichkeiten, die > über den Hobbybereich hinausgehen. Aber auch hier zu Hause bin ich > nicht so karg ausgestattet, bis 500 MHz reicht es. Es hat auch niemand bestritten das auch du Messmöglichkeiten hast, aber jetzt daher zu kommen und zu meinen, nur wenn du die Messungen durchgeführt hast sind sie auch glaubwürdig ist armseelig und lächerlich hoch drei. Mit solchen Aussagen sorgst du selbst dafür, dass man die Achtung und den Respekt vor dir verliert, weil du ihn selbst für andere nicht aufbringst. Im Gegenteil, du strafst die Arbeit anderer damit ab. Schäm dich Guido und das meine ich ganz genau so wie ich es schreibe! branadic
Hi branadic, ich meinte auch nicht eine Rückmeldung über die grundsätzliche Funktion der Platine, die ich nicht in Zweifel ziehe, sondern vielleicht einige Screenshots mit Testsignalen die die korrekte Ansteuerung zeigen. Weiterhin bietet ja die Platine die Möglichkeit den Meßbereich nach unten bis 1mV/div aufzubohren. Das habe ich aber bislang in der Firmware noch nicht berücksichtigt, weil ich nicht weiß ob das sinnvolle Ergebnisse liefert, oder das Ganze dann im Rauschen untergeht. Auch die Skalierungsfaktoren sind wohl noch nicht auf dem letzten Stand. Also salopp ausgedrückt ein paar Actionbilder der eingebauten Platine wären ganz nett. Jetzt wo die kalte Jahreszeit anfängt habe ich wohl auch eher die Zeit mal die Platine einzubauen die Du mir freundlicherweise schon bestückt hattest. Dann kann ich da vielleicht auch was zu beitragen. Gruß Hayo
Hayo W. schrieb: > ich meinte auch nicht eine Rückmeldung über die grundsätzliche Funktion > der Platine, die ich nicht in Zweifel ziehe, sondern vielleicht einige > Screenshots mit Testsignalen die die korrekte Ansteuerung zeigen. Soweit ich das weiß hat Jörg keinen Signalgenerator oder ähnliches. Zudem haben seine Messungen bisher am offenen Gerät stattgefunden und sind daher nicht 100% repräsentativ. Hayo W. schrieb: > Auch die Skalierungsfaktoren sind wohl noch nicht auf dem letzten Stand. Theoretisch sollten sie das sein. Ich hatte ja das folgende ExcelSheet zur Verfüfung gestellt, mit dem sich die Skalierungsfaktoren für alle Einstellungen ermitteln lassen und anhand dessen man auch die notwendigen Einstellungen am PGA/VGA nachvollziehen kann: http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls Hayo W. schrieb: > Also salopp ausgedrückt ein paar Actionbilder der eingebauten Platine > wären ganz nett Ich muss gestehen, dass ich von solchen bunten Bildern nicht sonderlich viel halte, da deren Aussagekraft zweifelhaft ist. Aber offenbar lässt man sich hier nur damit überzeuge, Diagramme und Grafiken scheinen eher zweitrangig zu sein. Zudem hat Walter ja Bilder in seinen letzten Dokumentationen, auf die ich schon mehrfach verwiesen habe. Dazu muss man aber auch bereit sein sich die Zeit zu nehmen einen Blick auf die Dokumentation zu werfen. Die Prosa darin hält sich stark in Grenzen und nur die notwendigen Hinweise sind niedergeschrieben worden. Ansonsten sind Bilder und Grafiken zu sehen. Wenn ich die Zeit finde werde ich bunte Bilder machen. branadic
Kurt Bohnen schrieb: > Hayo W. schrieb: >> Unbedingtes Ja. Das ganze ist für mich eine Spielwiese die ich in meiner >> Freizeit nutze um mich an Themen auszutoben mit denen ich aufgrund >> meiner beruflichen Tätigkeit leider nichts mehr zu tun habe, die ich >> aber mächtig interessant finde. > > Die selben Themen könntest du auch auf dem Leon bearbeiten... Ja schon richtig, ich wollte auch nur grundsätzlich darauf hinweisen, dass das Ganze Projekt eigentlich nur Spielerei ist. Allerdings eine sehr interessante mit viel Lerneffekt. > Auch müsste während der Arbeit am Leon die Nios Entwicklung nicht > vollständig ruhen, Das Problem ist da die verfügbare Zeit. > Hast du konkrete Probleme/Fragen zur Installation der Toolchain? Noch nicht. Ich muß mich erstmal durch die vorhandenen Informationen arbeiten, bevor ich da präzise Fragen stellen kann. Grundsätzlich sieht meine Arbeitsliste so aus: 1. LEON Demo zum Laufen kriegen. Diesen Schritt hatte ich ja schon mal in Angriff genommen, war aber leider gescheitert. Bevor das nicht klappt brauche ich wohl gar nicht erst weiter zu machen. 2. C/C++ Entwicklungsumgebung (SDK) installieren und ein eigenes Testkompilat erstellen um die grundsätzliche Funktionalität zu überprüfen. 3. Grundsätzliche Gedanken machen zur zukünftigen Programmstruktur. 4. Die NIOS-Firmware evtl. an diese Struktur anpassen um Plattformübergreifend entwickeln zu können. 5. Die vorhandenen LEON Hardwaretreiberroutinen für die neue Programmstruktur portieren/anpassen 6. Schritt für Schritt die neue Firmware implementieren. Gibt es für das SDK auch schon Anleitungen? Für welche Betriebssysteme gibt es die Entwicklungsumgebung? (Windows?, Linux?) Wo kriege ich das SDK her? Dazu gibt es vermutlich auch schon Anleitungen, aber ich bin da noch nicht so weit vorgedrungen. Es gibt da also noch einiges zu tun. Übrigens sind die fehlenden zwei Kanäle nicht die einzige Einschränkung. Das LEON-Design unterstützt nur einen UART. D.h. es gibt nur entweder eine RS232 oder eine USB-Unterstützung. Welches von beiden Alex da jetzt vorgesehen hat muß ich noch prüfen. Gruß Hayo
Hi branadic, darf ich wieder aufhören mich zu schämen? ;-) Gruß, Guido
Jetzt muß ich mal lachen, denn manchmal kann es schon lustig mit euch sein!!! Gruß Michael
Hier ist ja was los! Wollte auch schon länger mal was schreiben, zum Thema Leon, Software-Migration, Zeitpläne. Zeitpläne und Hobbyprojekte passen schon mal gar nicht zusammen. Erwartungshaltungen auch nicht, denn wir reden hier von Dingen die Leute in ihrer Freizeit tun. Wieviel sie davon aufbringen und woran sie Spaß haben ist ihnen schwer vorzuschreiben. Ich habe selbst das Leon-Design noch nicht ausprobiert. Eine geschlossene und aktuelle Anleitung wie dafür vorzugehen ist wäre natürlich eine prima Hilfe. Nur falls das noch nicht zusammengetragen ist. Das kann auch jemand tun der nicht entwickelt. Ich will da "irgendwann" aber mit Sicherheit ran. Vorher gibt es dummerweise noch 2 andere große Hobbyprojekte abzuschließen, und meine Ehe gilt es auch zu erhalten. Deshalb bin ich nur so sporadisch dabei. Die Voraussetzungen sind eigentlich prima: Ich bin hauptberuflich langjähriger Softwareentwickler im Embedded-Bereich, unsere Firma macht anspruchsvolle ASIC- und FPGA-Designs. Ich kann selbst leider kein HDL, aber könnte Alex' Design zu gegebener Zeit mal mit den Profis im Kollegenkreis durchgehen. Davon verspreche ich mir noch was, denn mit Verlaub und allem Respekt, Alex hat(te) da noch nicht so viel Erfahrung. Spatzen auf dem Dach, zugegeben. Branadic hat meinen Vorschlag einer Hardware-Abstraktionsschicht zitiert, und Hayo ihn als möglicherweise performancefressend kritisiert. Das sehe ich nicht so, dann wären die Schnittstellen falsch gewählt bzw implementiert. Im Gegenteil, ich denke ordentliche Interfaces wären sogar ein Gewinn. In der Nios-Software fallen mir ständig (naja, wenn ich denn mal da reingucken muß) ungeschickte Dinge auf. Wenn der Autor Datenstrukturen , Arrays, und das Schlüsselwort "const" gekannt hätte wäre auch schon viel gewonnen. Das "Schlimmste" was passieren könnte wäre wenn Hayo sich abguckt wie die Leon-Hardware bedient wird und das dann alternativ in die Nios-Software reinzwingt. Dann hätten wir ein noch unwartbareres Monster als jetzt schon. Eine ordentliche Struktur sollte vorher schon her. Meine vielleicht etwas zu naive Vorstellung der Vorgehensweise wäre: - Zusammentragen der Hardwareansteuerung in beiden Designs - Definition der Schnittstellen, z.B. mit Doxygen - gemeinsamen Build-Flow für beide Platformen aufsetzen - Implementation dieser unteren Schichten - Portierung von Codeteilen aus dem Nios-Design, bzw. ordentliche Neuimplementation nach schlechter Vorlage - Weiterentwicklung Natürlich ist das erstmal eine Konsolidierungsphase oder gar ein Schritt zurück, bevor es dann viel besser weitergehen kann. Und macht wohlmöglich keinen Spaß, siehe oben. Aber wird früher oder später kommen, daran glaube ich schon. Ich habe mal etliche Jahre in einem recht großen Open-Source Projekt mitgearbeitet (www.rockbox.org), war zeitweilig einer der Hauptentwickler. Aus deren FAQ, ich könnte es nicht besser ausdrücken: Why are you developing X when you should be doing Y? You make the common mistake of confusing Rockbox development with that of commercial projects. There is not much of an agenda for the development of Rockbox. Anyone who wants to write new features can do that. If there is a current "huge emphasis" on the X functionality, it is because one or more developers, decided he/they wanted to write it. It's not because "Rockbox project management" decided function X is a more important feature than anything else. That is the nature of free software: people write code that scratches their own itches, or that simply is fun to write. Everybody working with Rockbox is doing it for fun. A wide or narrow audience actually has only little bearing on the choice of features to implement. The moment someone with a bit of time to spare and the necessary programming skills (or a will to learn them) feels function Y is a sufficiently useful feature, it will be written. (That could be you.) @Hayo: habe ich mal irgendwo gelesen, daß du in oder bei Hamburg wohnst? Demnächst könnte ich da in der Nähe sein, vielleicht können wir uns mal zusammenhocken. Jörg
Hallo Jörg, habe Deine Email heute morgen erhalten und kurz beantwortet. Leider komme ich hier in der Firma über den Proxy nicht an meine Emails, daher hier meine Gedanken zu dem LEON-Projekt. Mein anfängliches Zögern beruht unter anderem darauf, dass ich eigentlich ungern halbe Sachen machen möchte wenn sich hier die Möglichkeit bietet die Firmware neu aufzusetzen. Das wiederum bedeutet aber (hatte ich ja schon angedeutet), dass die NIOS-Firmware auf die neue Struktur angepasst werden müßte um beide Plattformen weiterhin parallel supporten zu können. Und genau dieser zeitliche Aufwand hat mich etwas abgeschreckt. Aber ich bin eigentlich Deiner Meinung, dass man nicht die LEON-Plattform nach den alten NIOS-Strukturen ausrichten sollte sondern umgekehrt. Ehrlicherweise muß ich zugeben das mir hier etwas die Erfahrung fehlt, da ich bislang nur sehr hardwarenah (Studium) und danach nur noch im SAP-Umfeld Software entwickelt habe. Du erwähnst z.b. ein Tool wie Doxygen, da bräuchte ich dann etwas Nachhilfe. Bin aber auf jeden Fall interessiert etwas dazuzulernen. Ich denke es gibt da einige Ideen auszutauschen und es kommt auch dem NIOS-Projekt zu Gute wenn die Softwarebasis mal geradegerückt wird. Gruß Hayo
Hatte gerade etwas Zeit und habe mal Doxygen runtergeladen und ausprobiert. Nicht übel! Das macht ja eine ganz nette Übersicht und ist einfacher zu bedienen als ich dachte. Was dabei besonders auffällt ist ein Punkt der mir auch schon länger am Herzen liegt - die Namenskonvention. Es gibt da ein ziemliches Durcheinander bei der Namensgebung, das auf jeden Fall beseitigt werden muß um eine vernünftige Basis zu schaffen. Gruß Hayo
Hayo W. schrieb: > Was dabei besonders auffällt ist ein Punkt der mir auch schon länger am > Herzen liegt - die Namenskonvention. Crazor hat sich schon vor zeiten dazu mal Gedacnken gemacht und einen Coding Standard am Wiki verfasst: http://sourceforge.net/apps/trac/welecw2000a/wiki/CodingStyle Vielleicht lässt sich auf den aufsetzten oder er sich anpassen.
Hallo Robert, das ist ein guter Hinweis. Den Beitrag kannte ich noch nicht. Zu 95% stimme ich den Vorschlägen zu und setze das bei meinem Coding auch schon so um. Nur beim Identifier Naming benutze ich entgegen Crazors Vorschlag eigentlich ganz gern den CamelCaseStyle und nicht so gerne den c_style, da dieser die Bezeichner oft ziemlich in die Länge zieht. Manchmal benutze ich auch Kombinationen davon (ist natürlich nicht ganz konsistent dann). Aber da müßte man sich dann eben festlegen, da das die Lesbarkeit des Codes wesentlich beeinflussen kann. Leider hat sich der WELEC-Programmierer einen Dreck um irgendwelche Namenskonventionen geschert und so fliegen da Unmengen von unterschiedlichen Bezeichnern durch die Firmware. Da eine Linie reinzubringen ist schon etlicher Aufwand. Dazu kommt, dass sämtlich Variable global deklariert sind. Ich würde da eigentlich etliche Variablen lieber je nach Kontext in die entsprechenden Klassen verlegen. All das ist ne Menge Arbeit, die nach außen keinerlei sichtbare Auswirkungen hat, aber zukünftige Entwicklungen begünstigt. Gruß Hayo
Hallo Kollegen, habe aus alter Gewohnheit wieder einmal ins Forum reingeschaut. Dabei habe ich bemerkt, dass ihr gute Fortschritte macht. Gratulation. Ich selber habe meinem defekten Oszi noch eine Chance gegeben und es meinem Sohn nach Wien zur Reparatur geschickt. Sollte der nichts ausrichten, was zu befürchten ist, kann ich das Oszi oder einzelne Teile davon eventuell Interessenten von euch zuschicken. Aber bitte noch etwas Geduld. Ihr lest dann davon. Habe mich inzwischen mit einem OWON eingedeckt, da es von WELEC ja keine Geräte mehr gibt. Bin damit im Moment sehr zufrieden und kann so weiter meinem Hobby frönen :-) Manfred
Hallo Manfred, schreib doch mal ein paar Details zu Deinem neuen Spielzeug. Mich würde mal interessieren mit welchen Eckdaten das Gerät aufwartet und ob die Spezifikationen auch wirklich so zutreffen. Ist die Firmware einigermaßen Bugfrei? Welches Gerät (Typenbezeichnung) ist es denn? Gruß Hayo
Angehängte Dateien:
-
Example.jpg
90 KB
Hallo Hayo, wollte nicht allzuviel für ein neues DSO ausgeben. Es gibt bei EBAY den 100MHz-2Kanaler OWON SDS7102 um 337 Euro, dazu kommen 17Euro Zoll, Versand ist gratis. Ich habe eine LiPo-Batterie und den VGA-Ausgang dazugekauft (+72Euro), also alles in allem 426,-. Mangels Testequipment kann ich nicht sagen, wie genau die Spezifikationen eingehalten werden. Auffallend: sehr schnelle Lieferung aus Hongkong in 3 Tagen, handlich, leicht, 4 Stundenbetrieb mit Batterie, beeindruckender 800x600-SVGA-Bildschim, gute Triggerung (Combitrigger geht ab) auf jeden Kanal alternierend möglich, 2mV bis 50V, wenig Rauschen, 10M Speichertiefe (tolle Sache), Timebase 2ns/div bis 100s/div, 1GS/s, wobei gestoppt und dann weit in die Tiefe gezoomt werden kann, 2 verschiedene Automatikmessungen, diverse Speichermöglichkeiten, auch von ganzen Serien bis zu 1000 Bilder, usw... Die Firmware ist an etlichen Punkten verbesserungsfähig, das hättest du besser hingekriegt. Die Hardware scheint ok zu sein. Für meine Bedürfnisse wirklich ein beeindruckendes Gerät. Anbei noch ein Bild Einer Messung von heute. Manfred
manfred.h schrieb: > Anbei noch ein Bild Einer Messung von heute. Da sind sie wieder - die Zeitangaben der Cursor bezogen auf den Triggerzeitpunkt ;-) Gruß Rainer
@Manfred SDS7102 compared to W2022A is more expensive and buggy,see on youtube.And with Welec we have electrical diagrams and a continuos improvement.. Regards Sandro
You are right Sandro, but I have to admit that features like VGA-Output, big 800x600 TFT, deep memory and LiIo- Accu are nice to have. Another interesting thing I found about it is the (perhaps) possibility to hack the DSO to the next higher bandwidth level. The bandwidth is limited by the LMH6518 amplifier which bandwidth can be set up to 900 MHz by SPI programming - fascinating. On the other side the chinese developers made some bad (HF) mistakes on the PCB-design and finishing. Some of them can (perhaps) be corrected by Yourself (like floating grounds or unshielded cables). I'm flirting with the idea to get one (SDS8102 / 2GHz) as template for some new ideas and reference for our WELEC. Maybe we need a new OWON thread... ;-) Regards Hayo
Ok ich hab es gemacht! Das SDS8102 ist bestellt. Sollte bis zum Wochenende da sein. Habe es allerdings beim deutschen Importeur bestellt da mir Garantie und Rückgabemöglichkeit den Aufpreis wert sind. Das dürfte ein interessanter Vergleich werden. Mal sehen was man für unser WELEC so abkupfern kann :-). Gruß Hayo
Ich gehe schwer davon aus, dass du dir das fünfteilige Video auf "duröhre" angeschaut hast? So viel mehr als den alternierenden Trigger wirst du auch nicht finden. Und soweit ich die Kritik vernommen habe scheint auch das Owon erhebliche Schwächen in Hard- und Software aufzuweisen. Als Beispiel sei nur mal der Triggerausgang genannt. Ist dagegen bekannt, dass Rigol in die 600MHz (DS6062 und DS6064) und 1GHz-Klasse (DS6102 und DS6104) vorgedrungen ist? Damit hebt sich Rigol von den anderen Geräten wieder etwas ab. branadic
Ja die Videos kenne ich. Zur Firmware: Der Händler in Chemniz sagte mir, dass die neueste Firmwareversion drauf ist (von letzter Woche). Alle bislang bekannten Fehler sollen wohl behoben sein, mal sehen... Zur Hardware: Ja, ich weiß von einigen Fehlern im Design. Nachdem was ich gesehen habe kann man aber einige selbst beheben bzw. zumindest verbessern. Wenn das Ding sich als überbezahlte Brotdose entpuppt schicke ich es einfach zurück. Das ist eben der Vorteil beim einheimischen Händler, auch wenn er etwas teurer ist als die Direktimporte. Über ein RIGOL hatte ich auch schon nachgedacht, auch über ein Hantek. Bei letzterem finde ich es sehr charmant, dass da Linux drauf läuft. Letztlich fand ich aber das OWON am interessantesten. Bei meiner Auswahl war mir die Bandbreite nicht ganz so wichtig, da mein Bedarf deutlich unter 100MHz liegt, und das SDS8102 bis ca. 150MHz sinusförmige Signale noch ganz akkurat darstellt (es gibt da irgendwo einen deutschen Test). Wichtiger war mir die höhere Abtastrate von 2GHz, weil man dann mehr echte Meßpunkte hat und das dargestellte Signal dann auch mehr der Wirklichkeit entspricht. Btw, was ich interessant finde ist die theoretische Möglichkeit die Bandbreite aufzubohren in dem man den Eingangsverstärker umprogrammiert (wie auch immer). Gruß Hayo
Der Eingangsverstärker hat den gleichen VGA an Board wie auch die Huckepackplatine, den LMH6518 und der wird via SPI konfiguriert. Allerdings macht das "Aufbohren" nur begrenzt Sinn, da zum Einen Nyquist die Finger mit im Spiel hat, zum Anderen sind bei denen weitere Bauteile im Signalpfad, die die Bandbreite bereits vorher begrenzen. http://www.mikrocontroller.net/attachment/122374/Owon_input.pdf aus dem Thread: Beitrag "Neue OWON-Oszilloskope? Owon SDS6062 60MHz" branadic
Hayo W. schrieb: > Das SDS8102 ist bestellt. Gibt es da einen Ansatz, eigene Software reinzukriegen? Sprich, ist das Ding offen? Jörg
Ok, genug gemutmaßt! Das Teil ist um 14:00 angekommen (hitverdächtig schnell - gestern bestellt!) und ich bin seitdem am Testen. Erster Eindruck: Keine überberbezahlte Brotdose sondern für den Hausgebrauch eine feine Sache. Das Menü empfinde ich als etwas umständlich im Vergleich zu unserem Baby, aber man kommt recht schnell damit klar. Wie schon öfters in einigen Foren angemerkt ist die Haptik der Menüknöpfe mit dem "Klick" nicht so schön wie unsere Softbuttons, aber es funktiomniert. Die Drehknöpfe sind leider nicht wie unsere gummiert, sondern nur aus Plastik. Das hört sich aber schlimmer an als es ist. Es läßt sich trotzdem recht gut bedienen. Was mir etwas besser gefällt als beim WELEC, das ist der Umstand, dass die Drehencoder für die Funktionen die häufiges Drehen erfordern (Zerolevel-Verstellung, Pretrigger-Scrolling etc.) keine Rastung haben. Sie fühlen sich also an wie Analogdrehknöpfe und "rattern" daher auch nicht. Auch der Trigger macht einen sehr stabilen Eindruck. Die einzelnen Triggeroptionen werde ich noch testen. Ich werde also wohl das Teil nicht wieder zurückschicken sondern für weitere Vergleiche behalten. Ich habe ja auch noch etwas Zeit mir das zu überlegen. Grundsätzlich macht die Firmware erstmal einen stabilen Eindruck - Fehler konnte ich auf die Schnelle noch keine finden. @Branadic > Der Eingangsverstärker hat den gleichen VGA an Board wie auch die > Huckepackplatine, den LMH6518 und der wird via SPI konfiguriert. Das ist ja Witz an der Sache! Die Hinweise kannte ich schon, danke. Grundsätzlich gehe ich aber schon davon aus, dass eine Umprogrammierung die Bandbreite auf 200 oder 300MHz erhöt. @Jörg Soweit ich weiß gibt es da momentan noch nichts Aktuelles. Dafür ist die Büchse wohl noch zu neu. Aber so wie die sich verkauft wird das wohl nicht ausbleiben. Die original Firmware ist wohl, wie ich irgendwo gelesen habe, verschlüsselt. Ich dachte beim Bandbreitenhack auch an die Möglichkeit da an den SPI einfach andere Hardware dranzuhängen, die die Initialisierung macht. Wenn Du am 3.12. vorbeikommsz kannst Du Dir ja ein eigenes Bild von dem Gerät machen. So, werd jetzt noch ein wenig rumspielen, wär ja gelacht wenn ich nicht doch noch ein paar Fehler finde. Ein genauerer Vergleich mit unserem Schätzchen folgt natürlich auch noch. Gruß Hayo
Rainer W. schrieb: > Da sind sie wieder - die Zeitangaben der Cursor bezogen auf den > Triggerzeitpunkt ;-) Du hast recht, beim Owon sind alle Horizontalangaben auf den Triggerzeitpunkt bezogen. Ich stelle aber beim Testen an einigen Stellen fest, dass das nicht immer so praktisch ist. Am Besten man kann es sich so einstellen wie man es braucht... Gruß Hayo
So, da das Thema etwas umfangreicher werden könnte, hab ich mal einen Parallel-Thread aufgemacht. Beitrag "WELEC W2000A vs. OWON SDS8102" Da werde ich dann den Vergleich fortführen. Hab auch schon die erste Macke gefunden :-). Gruß Hayo
Falls mir jemand eine defekte Mainboardplatine zukommen lassen möchte könnte ich ein deteiliertes Röntgenbild anfertigen. Dann könnte man vieleicht die Verbindungen der Adcs sehen. Ansonzten muss ich meine ausbauen was etwas dauern kann. Gruß Torsten
Cool, wie kommst Du denn zu sowas? Ein Röntgengerät hat man ja eigentlich nicht so im heimischen Bastelzubehör oder? Und wie verkraften die Bauteile die Strahlung? Ist das unkritisch? Gruß Hayo
Hayo W. schrieb: > Was mir etwas besser gefällt als beim WELEC, das ist der Umstand, dass > die Drehencoder für die Funktionen die häufiges Drehen erfordern > (Zerolevel-Verstellung, Pretrigger-Scrolling etc.) keine Rastung haben. > Sie fühlen sich also an wie Analogdrehknöpfe und "rattern" daher auch > nicht. Da wurde ja auch schon einiges versucht andere Encoder aufzutreiben, was aber immer auch recht teuer wäre. Hat sich die eingebauten Encoder im Welec mal jemand genau angeschaut? Ich hab mir überlegt ob man da nicht irgendwo mit dem Seitenscheider ansetzen könnte und einfach den Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran?
Hi, den Versuch das PCB zu röntgen hab ich auch schon gemacht. Auf einem medizinischem Röntgengerät. Den Bauteilen hat es auf jeden Fall nicht geschadet. Das Ergebnis war aber nicht sehr aufschlussreich. Man erkannte zwar die einzelnen Bauteile und auch die Die-Träger und Pins, Details wie die Leitungen auf und im PCB waren aber leider nicht zu erkennen. Auch mit einem höher auflösendem Gerät wird es wohl schwierig da das massive Innenleben der IC's die "Sicht" auf die darunter liegenden feinen Strukturen versperrt. Gruß Sunny
Stephan S. schrieb: > Ich hab mir überlegt ob man da nicht > irgendwo mit dem Seitenscheider ansetzen könnte und einfach den > Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran? Hab ich noch nicht gesehen. Wenn man die Feder von außen einfach beseitigen könnte wäre das natürlich nicht schlecht. Dann würde ich bei mir sofort einige Encoder davon befreien. Hayo
Hayo W. schrieb: >> Ich hab mir überlegt ob man da nicht >> irgendwo mit dem Seitenscheider ansetzen könnte und einfach den >> Rastmechanismus rauszwickt oder blockiert. Käme man da irgendwie ran? > > Hab ich noch nicht gesehen. Wenn man die Feder von außen einfach > beseitigen könnte wäre das natürlich nicht schlecht. Dann würde ich bei > mir sofort einige Encoder davon befreien. Ich kann euch verraten dass das nicht geht, die Encoder sind wie sie sind. Die einzige Möglichkeit die ihr habt, kauft euch die Alps-Encoder bspw. von Reichelt STEC11B04. Vielleicht gibt es die anderswo noch günstiger. Die sind kompatibel, lediglich die Welle ist als geschlitzen Welle ausgeführt und haben Impulse: 15 / Rastungen: 30. Man müsste also die Welle passend auf die Encoderknöpfe zurechtfeilen/fräsenDie Rastung ist um Welten weicher und nicht so hart wie bei den Welec-Encodern. Selbst die Variante mit Taster STEC11B03 fühlt sich gut an. Warum ist eigentlich noch niemand das Front-Panel angegangen? Das ist ja nur eine 2-lagige Platine. Man könnte die überarbeiten und gleich ein paar Encoder mit Taster an den richtigen Stellen vorsehen. Außer den Softbuttons ist das ja keine große Sache. Sonderlich teuer dürfte eine solche Leiterplatte auch nicht werden, selbst mit Gold-Finish. branadic
Die ALPS-Encoder gibt es auch "voll kompatibel", mit abgeflachter Welle. Ich hatte mir damals Darisus als möglichen Lieferanten rausgesucht. Das Frontpanel überarbeiten habe ich auch mal kurz erwogen, wenn auch aus anderem Grund: um das LCD weiter nach vorne zu setzen. Derzeit würde es mit dem Platinenfortsatz der die Softbuttons trägt kollidieren. So eine Platine wäre recht groß und daher nicht ganz billig. Ein paar Encoder mit Taster bekäme man bestimmt leicht fliegend verdrahtet. Es sind eh nur 4 Eingänge frei. Jörg
Ich habe mich bei Alps mal etwas umgeschaut und folgende Encoder herausgesucht: Kanal-Offset: ohne Rastung, ohne Schalter --> EC11E1530401 Vertikalablenkung: mit Rastung, ohne Schalter --> EC11E15204A3 Horizontalablenkung: mit Rastung, ohne Schalter --> EC11E15204A3 Triggerzeitpunkt: ohne Rastung, mit Schalter --> EC11E153440D Triggerlevel: ohne Rastung, mit Schalter --> EC11E153440D Multifunktionsencoder: ohne Rastung, mit Schalter --> EC11E153440D Alle Encoder haben 15 Impulse pro Umdrehung. Zu den Schalterfunktionen: Multifunktionsencoder: frei konfigurierbar für Menufunktionen Triggerzeitpunkt: ein Druck stellt zurück auf 50% Triggerlevel: ein Druck stellt auf 50% Triggerlevel oder auf Null Damit wären 3 von 4 freien Eingängen belegt. branadic
ich denke das mehr Impulse besser wären um feinfühliger scrollen zu können, die kann man bei der Auswertung immer noch runterrechnen, wenn aber Impulse fehlen kann man keinen mehr dazuzaubern. Nach einigen Impulsen kann man das Scrollen dann softwaretechnisch immer noch beschleunigen.
Also ich glaub ich will nicht so viel Geld für ein neues Frontpanel und ne Menge neuer Encoder ausgeben. Das läppert sich bei so vielen Encodern ganz schön. Ich dachte halt einfach nur dass es vielleicht eine Einfachstlösung gibt um die Rastung los zu kriegen. Vielleicht kann man das Gehäuse ja irgendwo anbohren oder aufbiegen um an den Mechanismus ranzukommen. Vielleicht müsste man mal einen opfern und zerlegen. Oder röntgen. Ich bin jetzt noch eine Woche in China, aber dann könnte ich mich der Sache mal annehmen.
branadic schrieb: > Alle Encoder haben 15 Impulse pro Umdrehung. Aber 30 (zarte) Rastungen, hier gab es nachfolgend wohl Mißverständnisse. Die Kurbelei bliebe also unverändert, aber fühlt sich besser an und es gibt optional eine Taste. Wir müßten noch klären, ob das FPGA die letzten 4 Bits auch der Software zur Verfügung stellt. Jörg
Stephan S. schrieb: > Also ich glaub ich will nicht so viel Geld für ein neues Frontpanel und > ne Menge neuer Encoder ausgeben. Angenommen man nimmt alle mit zarter Rastung, wie Jörg das so schön formuliert hat, dann käme der Preis für ein 4-Kanalgerät gerade mal auf 27,-€ zzgl. Versand, dafür hätte man dann drei zusätzliche Taster. 9x EC11E15204A3 + 3x EC11E15244G1 Ein 2-Kanalgerät käme auf 18,-€. 5x EC11E15204A3 + 3x EC11E15244G1 Ich finde das jetzt nicht so viel wie du das erscheinen lassen wolltest. branadic
Das ist tatsächlichnicht so viel wie ich dachte. Wo gibts die denn zu dem Preis? Ich hatte die teurer in Erinnerung. Wenn wir ein paar Leute mehr zusammen kriegen würden, dann sind auch die Leiterplatten nicht so teuer. Leiterplattenfläche ist garnicht so teuer wenn die Stückzahlen höher werden. Nur bei einstelligen Stückzahlen ists immer unangenehm teuer.
Es kommt ganz darauf an, wo man die bestellt, Darisus wurde ja als mögliche Quelle genannt. Es gibt aber auch noch andere Distributoren wie RS etc. Ich habe noch mal drüber geschlafen und finde, dass es eine gute Idee ist alle bis auf die Encoder für die Ablenkungen zu tauschen. Diese gehen recht schwer und fühlen sich daher wie Schalter an. Das würde ich so auch lassen wollen. Alle anderen Encoder werden gegen solche mit zarter Rastung getauscht. Die Encoder für Triggerlevel, Triggerposition und der Multifunktionsencoder gegen solche mit Taster. Ich für meinen Teil denke, dass das die beste Kombination ist, mit einem guten Spektrum an Haptik. Das käme dann 24,50€ zzgl. Mwst. für ein 4-Kanäler gleich. branadic
Da währe ich auch mit dabei! Ich hatte sowas schon länger vor, allerdings bin ich wie so oft einfach nicht dazu gekommen. Um ehrlich zu sein sind die Taster einer der Punkte die mich am meissten stören am Welec. Hier schonmal vielen Dank an branadic für die Recherchearbeit und die ganzen Hardwareverbesserungen :)
Wie wäre das dann mit den Tastern? Würden die original Drehknöpfe noch passen? Was ich nicht wollte, wäre ein Oszi was dann auf den ersten Blick verbastelt aussieht weil die Knöpfe zu weit raus stehen müssen um noch weg zum Drücken zu haben, oder abgesägte oder abgefeilte Knöpfe um den Weg zu ermöglichen. Und wenn schon eine neue Leiterplatte gemacht wird: gibts sonst noch was anderes was da mit drauf könnte? Könnte ja auch was sein, was jetzt garnicht mal unbedingt was mit der Bedienung zu tun hat.
An alle Sammelbesteller: Bitte beachtet meine Infos und Updates im Hardware Thread! [Alle Bestellungen die keinen USB-Host enthalten sind fertig verpackt und werden morgen abgeschickt.]
Ich wäre bei einer Sammelbestellung bzgl. Drehencoder und Platine mit einem Statz für das 4-Kanal und einem Satz für das Zweikanalgerät dabei. Unter Umständen hätte mein Kumpel auch noch Interesse für sein W2022A. Übrigens ist das mit den Drucktasten im Encoder wirklich sehr praktzisch wie ich beim OWON feststelle. Allerdings finde ich den Kraftaufwand für das Auslösen etwas zu hoch. Man schiebt das Gerät wenn es frei steht dann über den Tisch. Gruß Hayo
Die Sammelbestellung werde ich dann auch noch übernehmen. Alle Interessenten melden sich bitte an meine sourceforge Adresse (zu finden auf http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder) Die USB-Host Sammelbesteller würden keinen Versand zahlen. Alle anderen 2,50€. Preis für 2 Kanäle: 21,07€ inkl. Steuer (+ Versand) Preis für 4 Kanäle: 29,21€ inkl. Steuer (+ Versand) Wenn es genug Mengenrabatt gibt, wird es auch noch etwas günstiger.
Sind die Drehencoder dann auf der Originalplatine?
nochmal langsam, was sind das für andere Drehencoder? Mehr Impulse/Umdrehungen oder nur ein weicheres rasten + Kontakt zum drücken?
Hallo Kurt, ich wäre auch dabei beim Austausch der Encoder in meinem W2022A. Du hast PN. Vielen Dank nochmals. Gruß Marc
Hallo, ich würde vorschlagen, die Diskussion zu den Dreh-Encodern im Hardware-Thread weiter zu führen (Beitrag "Wittig(welec) DSO W20xxA Hardware") - genügt ja wenn hier ein Hinweis dazu steht und dann im anderen Thread die Details geklärt werden. Gruß Sebastian
Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler braucht nun nur noch 9 Sekunden vom Einschalten bis zum Wellenzappeln, vorher waren es 18 Sekunden. Also doppelt so schnell. :-) Und das mit 2 ganz einfachen Maßnamen, da waren immense Warteschleifen: 1.) beim LED-Selbsttest schalte ich die LEDs nur noch ein, kein Geblinke mehr, das abgewartet wurde bevor es weitergeht 2.) der Splash-Screen macht keine künstliche Verzögerung des Bootvorgangs mehr. Er ist trotzdem knapp 2 Sekunden zu sehen währen das Oszi zuende initialisiert. Wer sich sehr dafür interessiert kann ja später mit Utility->About in Ruhe nachschauen. Anbei die Firmware und auch der Quellcode, zur besseren Auffindbarkeit haben meine bescheidenen Änderungen einen Kompilerschalter "QUICKSTART" drumrum. Ich hoffe Hayo mag das einpflegen, auch wenn er kürzer gewürdigt wird. Wenn man das ganze mal richtig angeht läßt sich da bestimmt noch einiges mehr rausholen. In der Software wird viel blockierend gewartet (und Multitasking kann sie nicht), m.E. oft unnötig lang, so langsam ist die Hardware nicht. Eine Irrtumsquelle dürfte die Funktion nr_delay() aus der Nios-Lib sein. Deren Argument sind nicht Millisekunden, sie wartet deutlich länger. Ich hatte es mal gemessen, aber wieder vergessen... Jörg
Jörg H. schrieb: > Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler > braucht nun nur noch 9 Sekunden vom Einschalten Endlich mal wieder ein praktischer Beitrag im Firmware Thread.... Danke Jörg! Jürgen
Jörg H. schrieb: > Ich habe mal das Startverhalten der Software beschleunigt. Mein 4Kanäler > braucht nun nur noch 9 Sekunden vom Einschalten bis zum Wellenzappeln, > vorher waren es 18 Sekunden. Also doppelt so schnell. :-) Ich fand das an sich nicht weiter störend, deshalb habe da an der Bootsequenz auch nichts verkürzt. Ist aber natürlich kein Problem das Ganze grundsätzlich zu verkürzen. > Und das mit 2 ganz einfachen Maßnamen, da waren immense Warteschleifen: > 1.) beim LED-Selbsttest schalte ich die LEDs nur noch ein, kein Geblinke > mehr, das abgewartet wurde bevor es weitergeht Hatte ich als LED-Test so konzipiert da man die Funktion ganz gut erkennen kann. Läßt sich bei Bedarf natürlich auch verkürzen oder weglassen. > 2.) der Splash-Screen macht keine künstliche Verzögerung des > Bootvorgangs mehr. Er ist trotzdem knapp 2 Sekunden zu sehen währen das > Oszi zuende initialisiert. Wer sich sehr dafür interessiert kann ja > später mit Utility->About in Ruhe nachschauen. Kann man machen. Das geht aber auch erst seit den letzten Firmwareversionen. Vorher war immer noch ein DeleteSplash() nötig. > Anbei die Firmware und auch der Quellcode, zur besseren Auffindbarkeit > haben meine bescheidenen Änderungen einen Kompilerschalter "QUICKSTART" > drumrum. Ich hoffe Hayo mag das einpflegen, auch wenn er kürzer > gewürdigt wird. Auf die Würdigung kann ich auch verzichten :-) - es geht ja im Wesentlichen um die Identifizierung der Firmwareversion. > Wenn man das ganze mal richtig angeht läßt sich da bestimmt noch einiges > mehr rausholen. In der Software wird viel blockierend gewartet Das ist richtig, aber eigentlich meistens mit Grund. > (und Multitasking kann sie nicht) Jein, wenn man das Warten über einen Timer löst ist es quasi wie Multitasking. Wird auch an einigen Stellen gemacht. > Eine Irrtumsquelle dürfte die Funktion nr_delay() aus > der Nios-Lib sein. Deren Argument sind nicht Millisekunden, sie wartet > deutlich länger. Stimmt, das Delay ist nur grob geschätzt, aber an einigen Stellen ganz nützlich Ich baue die Änderungen gerne ein wenn es glückliche DSO-Besitzer erzeugt :-) Gruß Hayo
Hallo Hayo, ja - bitte so schnell wie möglich booten. Sollte wirklich mal jemand Probleme mit einer LED haben, dann wäre ein Testmodus im Utility-Menü nützlicher als jedesmal beim Einschalten zu warten. Die Wahrscheinlichkeit, dass 1. tatsächlich mal eine LED ausfällt und dass man 2. beim Einschalten auch tatsächlich "inventur macht" und alle LEDs checkt ist so gering, dass man einen Ausfall in der Regel ohnehin erst im Betrieb bemerkt und dann beim Einschalten genau aufpasst - und hier wäre man mit einem Eintrag im Utility-Menü genauso gut bedient.
Da ist was dran - und Du hast mich auf die Idee gebracht dass man einen LED-Test im Hardwaremenü einführen könnte. Besten Dank Hayo
Habt ihr die Firmware ausprobiert, bzw. habe ich mich undeutlich ausgedrückt? Beim Booten werden nach wie vor alle LEDs eingeschaltet, solange bis das UI richtig loslegt leuchten sie. Ihr habt also immer noch die Möglichkeit, diese ach so unzuverlässigen LEDs bei jedem Booten zu überprüfen. ;-) Ich finde, Geräteentwickler sollten sich durchaus Mühe geben, dem instant-on so nah wie möglich zu kommen. Steve Jobs hat einem Mac-OS Entwickler zur Motivation seinerzeit vorgerechnet, das er mit ein paar Sekunden extra ganze Menschenleben an Zeit vernichtet. Hayo: Der Compilerschalter kann dann natürlich raus, das war nur zum Testen und Finden. Jörg
Doch doch, das hatte ich schon richtig verstanden, aber die Idee einen LED-Test im Hardwaremenü unterzubringen fand ich trotzdem gut. Zur Not kann man den auf einer Party dann als Lichtorgel benutzen ;-) Zur Zuverlässigkeit: Ich bin halt in einer Zeit aufgewachsen als es noch keine LED gab und alle Geräte noch Kontroll-Lämpchen hatten. Da war war es schon nicht unwichtig einen Test zu machen. Bei den LED heutzutage hat das wohl eher Unterhaltungswert. Gruß Hayo
>kann man den auf einer Party dann als Lichtorgel benutzen Dann aber bitte den LED-Test auch an die FFT anbinden! ;-) Viele Grüße, egberto
In Verbindung mit den Huckepackplatinen ist mir ein scheinbarer Fehler in der Firmware aufgefallen, nämlich eine Querbeinflussung des DAC bei Kanal 3 und 4, was offenbar auf einen Überlauf zurückzuführen ist. Dreht man den Offset auf Kanal 3 über die Grenzen hinaus wird Kanal 4 beeinflusst und anders herum. Weiterhin passt die Kalibrierung derzeit noch nicht. Kanal 2 wird zwar für die 5er Bereiche abgeglichen, aber bei den restlichen Ablenkungen passt der Offset nicht, Kanal 3 und 4 bekomme ich gar nicht kalibriert. Da läuft irgendwo etwas erheblich schief. Mit der Huckepackplatine ist es notwendig den DC-Offset für jeden Kanal in allen Vertikalablenkungen zu Kalibrieren. Die ADC-Kalibrierung kann bspw. in der höchsten Vertikalablenkung vorgenommen werden, da die GND-Kopplung in der originalen Bestückung an der falschen Stelle sitzt und mit Huckepackplatine verschwindet. branadic
branadic schrieb: > Dreht man den Offset auf Kanal 3 über die Grenzen hinaus wird Kanal 4 > beeinflusst und anders herum. Wie ist das gemeint mit beeinflussen? Ich kann das leider bei mir ohne die Platinen nicht nachvollziehen. Kannst Du das noch etwas genauer beschreiben? Gruß Hayo
Hayo W. schrieb: > Wie ist das gemeint mit beeinflussen? In dem ich Kanal 4 verschiebe, obwohl ich an Kanal 3 den Offset verstelle. branadic
Ich habe das auch, und mir ist seit der Bestätigung durch branadic klar daß ich da wohl noch mal ran muß. Vorher dachte ich da wäre irgendwas marginal oder ein Hardwareproblem bei mir, und zwischenzeitlich hatte ich schon wieder vergessen daß das Problem noch ungelöst ist... Merkwürdig ist das ich am DAC-Handling gar nichts gemacht habe und das es ohne neue Eingangsstufe nicht auftritt. Jörg
Hallo Jungs! Ich habe ein 2 Kanal Welec - ohne irgendwelche Hardware-Modifikationen. Kann ich die aktuelle Firmware auch ohne irgendwelche Huckepackplatinen benutzen? Hab das mal ein wenig überflogen - ihr macht ja spitzen Arbeit! Bin eher etwas "Einsteigermäßiger" unterwegs und würde es mich nicht trauen in dem Oszi herumzulöten. Bietet jemand von euch profis auch - natürlich bezahlte - umbauten an? Allerbeste Grüße Christopher
@ Christopher, ja, du kannst die neuste Firmware auch mit einem unmodifizierten Welec nutzen. Ein Umbau wird erwartungsgemäß wohl niemand für dich durchführen, nicht weil alle egoistisch sind, sondern vielmehr weil du die notwendige Zeit dafür nicht bezahlen könntest. Die Bestückung der Huckepackplatine, der Ausbau der obsoleten Bauteile und die Umrüstung samt Einbau der Huckepackplatine kosten wirklich gut Zeit. Am Feedback allein siehst du ja, wie wenig Leute sich die Umrüstung schon angetan haben obwohl sie sich mit Material eingedeckt haben. Entsprechend wenig Erfahrung liegt hier in Verbreitung vor. Leider, muss ich zum Bedauern feststellen. Umgerüstete Geräte wirst du zur Zeit nur in der Entwicklergruppe (Skype) finden. branadic
@ Hayo What compiler do you use for Welec firmware update? I have only an editor and looking for a free compiler to do small FW mods Regards, Sandro
Ganz vergessen zu erwähnen, Offset-Verschiebung und der dazugehörige Marker passen jetzt natürlich auch nicht mehr zusammen. Vielleicht findest du ja die Zeit dein 2-Kanal-Welec mal umzurüsten Hayo? Wenn die Unterstützung mal bis zum Ende implementiert wäre würden sicherlich auch mehr Leute ihr Welec umrüsten. branadic
@Sandro How to get and how to use the SDK (devopment kit) is described in the documents which You will find in the "doc" directory of my "distrubution". @Branadic Ja die Umrüstung wollte ich demnächst mal in Angriff nehmen, aber die Probleme mit Kanal 3+4 kann ich dann trotzdem nicht sehen. Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige Ideen für die weitere Entwicklung ausgetauscht. Könnte noch ganz interessant werden, zumal Jörg über einige berufliche Erfahrung verfügt die uns da recht nützlich sein könnte. Gruß Hayo
Hayo W. schrieb: > Hatte übrigens vorhin ein nettes Treffen mit Jörg und wir haben einige > > Ideen für die weitere Entwicklung ausgetauscht. Ganz meinerseits! Wir haben Pläne geschmiedet für einen Software-Neuanfang, der auch andere Plattformen (Leon und ganz vage Owon) ermöglichen soll. Dafür zu gegebener Zeit ein neuer Tread, bzw. zum Mitmachen einen Architekturentwurf im Sourceforge-Wiki. Vielleicht gewinnen wir ja auch neue Entwickler damit, macht hoffentlich mehr Spaß als der alte Code. Jörg
Da das ein etwas langfristigeres Projekt ist, wird die bisherige Firmware natürlich solange parallel weiterentwickelt bis die Neue einsatzbereit ist, es wird also auch erst mal weiterhin Updates auf Basis der 1.2.BF.x.x geben. Erstes Ziel der neuen Entwicklungslinie ist erstmal der Hardwarelayer und als Grundlage dafür die genauere Untersuchung bzw. Dokumentation der NIOS-Hardwareansteuerung. Ich denke es wird interessant... Hayo
Nachdem ich die Opensource Firmware bisher nur genutzt habe, habe ich jetzt selbst etwas umgebaut bzw. hinzugefügt. Ich habe in meinem Oszi schon länger einen Li Akku eingebaut, allerdings ohne irgendwie die Spannung, Strom oder Kapazität zu überwachen. Diesen Umbau habe ich jetzt erweitert: Als Schutz- und Überwachungselektronik habe ich die Standardkombination aus Notebookakkus bestehend aus MM1414 (als Kurzschlussschutz, Über- und Unterspannungsüberwachung) und BQ2060, zum messen von Gesamtspannung, Lade-/Entladestrom, Berechnung von Kapazität etc. Abgerufen werden die interessanten Daten vom BQ2060 (momentan nur Ladezustand) über einen extra Mikrocontroller und per UART an das Oszi übertragen. Da zeige ich diesen Wert jetzt einfach nur noch an. Momentan auf UI_Plane3 am Rand des Gitternetzes. Am liebsten würde ich diesen Wert aber neben die aktuelle Abtastrate schreiben, aber auf welches Plane muss ich dann schreiben?
Du kannst Textausgaben in die - Text_Plane - schreiben. Die wird dann je nach eingestelltem Layout auf die richtige UI_Plane umgebogen. Das gilt für die üblichen Ausgabebereiche über und unter dem Grid bzw. bei FFT auch neben dem Grid. Allerdings ist da neben der Abtastrate eigentlich kein Platz mehr. Du kommst dann mit anderen Textausgaben ins Gehege. Gruß Hayo
Angehängte Dateien:
-
oszi.jpg
160 KB
Hallo, ich habe nur ein Zweikanal Gerät, also hab ich da etwas Platz. Danke für die Hilfe, ich hätte nie die richtige Plane gefunden! Im Foto liegen Kanal 1 und 2 genau übereinander, deshalb sieht man nur eine Linie.
Nett gemacht :-) helfe jederzeit gerne. Gruß Hayo
Hallo mal wieder, gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel. Kann man da irgendwas fehlbedienen oder klappt es bei schnellen Digitalsignalen nicht? Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen. Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten könnten. Viele Grüße Michael
Hi, ich muß zugeben, dass diese Funktionen bislang nur rudimentär getestet sind. Ich gelobe aber Besserung. Vor Weihnachten schaffe ich das nicht mehr, aber im neuen Jahr sollte das hinhauen. Gruß Hayo
Ich habe einen neuen Thread zu der werdenden neuen Firmware aufgemacht, hier der Link: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" (Bisher war ich damit noch sozusagen im "stealth mode", außer gegenüber Hayo und dem Skype-Chat.) Jörg
Angehängte Dateien:
-
TTL_logic_off.jpg
51 KB -
TTL_logic_on.jpg
36 KB -
LVTTL_logic_off.jpg
45 KB -
LVTTL_logic_on.jpg
35 KB
Michael H. schrieb: > Hallo mal wieder, > gerade habe ich etwas mit einem STM32F407 gespielt und dabei mal die > neue "Logic" Funktion des Welec ausprobiert. Leider wurde das 6MHz > Rechteck dabei zu einer Nulllinie, unabhängig vom gewählten Logikpegel. So ich hab doch noch mal zwischen Arbeit und Klamottenpacken getestet. Ich konnte da keine Auffälligkeiten feststellen. Als Beispiel mal Screenshots zur TTL und LVTTL-Familie. > Ich war auch etwas verwundert, kein 3.3V CMOS in der Liste zu sehen. Die Pegel sind kompatibel zu LVTTL, daher kein extra Eintrag. > Da ich die Funktion eine gute Idee für das Basteln an Digitalschaltungen > finde, würde es mich freuen, wenn andere ihre Erfahrungen damit posten > könnten. Ja, da stimme ich zu. Da ich auch nur begrenzt Zeit zum Testen habe würde ich mich über Rückmeldungen freuen. Am besten mit Screenshots im Logic und Normalbetrieb und kurzer Beschreibung (Logicfamilie, Frequenz). Gruß Hayo p.s. es gibt noch vor meinem Winterurlaub eine Xmas Edition - vermutlich morgen.
@Michael Mir ist gerade eine Idee gekommen woran es liegen könnte! Hast Du einen Tastkopf mit 10:1 Teiler verwendet? Das wird nämlich zur Zeit noch nicht unterstützt. Da geht bei der 5.0 leider nur 1:1. Bei der Xmas Edition versuche ich das mit einzubauen, mal sehen ob ich das noch schaffe. Gruß Hayo
Hi Hayo, danke für die Mühe - da ich einen 10:1 Tastkopf verwendet habe, hat sich das ganze damit wohl schon geklärt. Ich bin gespannt auf deine Xmas Edition, noch mehr bin ich aber gespannt was aus dem von Jörg angestoßenen Neubau der Software von Grundauf wird. Sehr vielversprechend und schon erstaunlich weit gediehen, wenn man bedenkt, dass der Thread erst ein paar Tage alt ist. Gruß Michael
In der Tat - und die Xmas Edition profitiert auch schon davon, denn ich
habe die schnelle MSTEP Multiplikation die Jörg entdeckt hat schon mit
eingebaut da Jörg so nett war mir die modifizierten Dateien für den
Compiler zur Verfügung zu stellen.
Der Geschwindigkeitszuwachs ist nicht von schlechten Eltern und läßt
schon ahnen was wir mit der neuen Firmware evtl, erreichen können.
Kleiner Performancevergleich vorher/nachher:
vorher mit MSTEP [frames/s]
-------------------------------------------------------
QM (3 Slots) 211 243
FFT 512 160 256
FFT 1024 65 146
Das betrifft natürlich auch alle anderen Funktionen bei denen ausgiebig
gerechnet wird.
Gruß Hayo
Frohe Weihnachten und viel Spaß beim Spielen. Die FIR und sin(x)/x Routinen sind zwar schon zum Teil implemetiert, laufen aber noch nicht so ganz rund, daher sind sie erstmal nicht aktiv. Mit dem LED test könnt Ihr ja unter dem Weihnachtsbaum für Stimmung sorgen... ;-) Bin dann ab morgen im Ski-Urlaub. Gruß Hayo
Na dann: Schönen Urlaub und vieeel Schnee! Gruß, Guido
Danke, ich muß mal sehen ob es bei uns im Hotel einen Internetzugang gibt, ansonsten frohe Weihnachten und guten Rutsch. Gruß Hayo
Thanks a lot, Hayo you are, as usua, very generous and kind... Have a nice christmas and a very happy new year!! Regards, Paolo
ich finde es ja sehr spannend was hier passiert und hab Interesse an dem DSO. Kann mir denn jemand mal sagen wo man das Ding kaufen kann? Gurgel und E... sind da nicht so auskunftsfreudig....
Hi Hayo, Jörg and guys all! Hayo, thanks You very, very much for the free time You provided generously to us and for this new firmware's version!!! I installed your latest great job, the new 1.2.BF.5.1XE and I tried it a bit. As always I am speechless, RESPECT!!! I believe also thanks to the integration of the Jörg's code (RESPECT also to Him and to all who are involved in the Welec Project) the new firmware is incredibly much fast and much more responsive now. The LED's test idea is brilliant as so its implementation and since the upcoming Christmas' holiday can be used as Christmas tree! ;-) I have seen that some item in some menu it was reduced and this streamlines the management. Some item are instead deactivated (grey) and they will available in the future, I hope soon. Reduced items in Hardware Menu works great for me (W2022A and W2012A) even if there are only two setting (Factory and High Frequency, all other are now grey deactivated), I used High Frequency setting without any spikes' problem. As always only for knowledge and no for criticism, follow the report about some issue I noted: 1) [W2022A & W2012A] The memory management seems to me do not works, when I save a waveform in memory 1 and after a new one in the memory 2 or other, then memory 1 is missed and there is only the last I saved. 2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized fail on channel 2, it seem to me to be calculated as half of the real value: channel 1 recognize right and very accurate values as compared to other master oscilloscopes I have and I used as champions instruments. (*) 3) [W2022A only] Sometime using the Cursors features get garbage on the screen, show corrupt labels and wrong values, but this issue was even in the former release. I take this opportunity to wish to You Hayo, Jörg and all guys a Merry Christmas! RESPECT! Danke und Frohe Weihnachten! Luc (*)W2022A is strikingly higher to the W2012A as response time, I believe because it is really about 200MHz bandwidth by selected inner componentistic circuitry or anyway its inner components are better than the same in the W2012A version.
Frohe Weihnachten! Ich habe die Xmas Edition in mein W2022A geflasht und kurz getestet (Testsignal). Recht schnell im Vergleich zum Original. Die Filterung und Combi-Triggerung sind supper, Displayeinstellungen (Status/Mono-Beige) ebenso, usw. Danke für die Arbeit! Ich fand auch ein Paar bugs mit dem Trigger welche ich berichten möchte: 1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach dem Mode-Wechsel. Ist dass gewünscht? 2)Pulse Width Mode funktioniert nicht richtig. Mal funktioniert der < wie es soll(reagiert auf die Zeit-Grenzen), mal der >. Der der jeweils andere triggert dann immer (unabhängig von der eingestelten Zeitlimits) oder nie. Der >< funktioniert nie. Meistens triggert er nicht. Es sieht so aus als würde die beim anderen eingestellte Zeit (die inaktive Zeit), oder dessen Logik, ins Triggern mitwirken. 3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder nicht sehe ich gerade(im Normal Mode). Wenn die Trigger-Logik wie PulseWidth bei dem Extern nicht geht, man sollte die Edge und PulseWidth Tasten sperren. 4)Nach dem wechseln des PulseWidth Modes < zum >, wird nicht getriggert bis man die Zeiteinstellungstaste druckt, egal wie die Zeit vorher war. Kleinigkeit für den Benutzer, wahrscheinlich schwer zu finden. 5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert. Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein paar dazu: -beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau), -der Oszi reagiert sehr träge auf die Drehschalter und bekommt den Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber stört auch am meisten. -bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei 500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den kleineren Zeiten nicht mehr? -wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....). Nochmals großen Dank an alle beteiligten und schönen Gruß aus Wien, Kruno
Interessierter schrieb: > ich finde es ja sehr spannend was hier passiert und hab Interesse an dem > DSO. > Kann mir denn jemand mal sagen wo man das Ding kaufen kann? > Gurgel und E... sind da nicht so auskunftsfreudig.... Such' mal bei Ebay nach den Verkäufer "welecgmbh". Zur Zeit tröpfeln die wieder Geräte dort ein, oder du fragst mal mit der Kontaktfunktion an. Mit einer normalen Artikelsuche ist das schwer zu finden, weil "Welec" dort nicht mit drin steht. Vielleicht dürfen die das aus irgendwelchen Gründen nicht. @All: auch frohe Weihnachten! Ich mache derweil weiter an der neuen Firmware, siehe dort: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Jörg
Angehängte Dateien:
-
Memory_1.jpg
43 KB -
Memory_2.jpg
42 KB -
Memory_3.jpg
43 KB -
Memory_4.jpg
52 KB -
Fall_Time.jpg
56 KB
Ein frohes neues Jahr, bin gerade wieder aus dem Urlaub zurück und noch dabei alles aufzuräumen - daher nur eine kurze Rückmeldung. Luc schrieb: > Some item are instead deactivated (grey) and they will available in the > future, I hope soon. I also hope... > Reduced items in Hardware Menu works great for me (W2022A and W2012A) > even if there are only two setting (Factory and High Frequency, all > other are now grey deactivated), I used High Frequency setting without > any spikes' problem. There is only one setting working better in the HF-Range (But also with a little spike problem). All others have more problems or don't work, so I decided to throw them out. Also I reduced the entries in the pre gain menu to the three important settings. - Standard for all unmodified scopes (using gain 1.25) - 24.9 Ohm for modified input stage equipped with two 24.9 Ohm resistors and one 150 Ohm resistors (replacing 0 Ohm and 150 KOhm resistors) - Add-On PCB for the new input stage on its own PCB > 1) [W2022A & W2012A] The memory management seems to me do not works, > when I save a waveform in memory 1 and after a new one in the memory 2 > or other, then memory 1 is missed and there is only the last I saved. I'm sorry but I can't reproduce the problem. On my scopes it is working without problems -> see screenshots. > 2) [W2022A & W2012A] In the Quick Measures, the Fall Time recognized > fail on channel 2, it seem to me to be calculated as half of the real > value: channel 1 recognize right and very accurate values I can't reproduce this also. See screenshot. > 3) [W2022A only] Sometime using the Cursors features get garbage on the > screen, show corrupt labels and wrong values, but this issue was even in > the former release. Yes I also had the problem, but couldn't reproduce it after restart. Do You know how to force it? Kind regards Hayo
Krunoslav O. schrieb: > 1) Beim wechseln zwischen Edge und Pulse Width wird der Trigger-Source > nicht mitgenommen. Z.B. Extern bei PulseWidth und Source1 bei Edge, nach > dem Mode-Wechsel. > Ist dass gewünscht? Nein, hatte ich noch nicht bemerkt, da der Pulsetrigger recht wenig in Gebrauch ist (wg. unten genannter Gründe) > 2)Pulse Width Mode funktioniert nicht richtig. Ja ist leider ein bekanntes Problem welches sich nicht so einfach beheben läßt da die Triggeransteuerung im FPGA eingebrannt ist. Ich hatte schon mal die Idee da einen Workaround in die Firmware einzuarbeiten. Evtl. läßt sich da mit der neuen Firmware und den von Jörg gewonnenen Erkenntnissen etwas machen. > 3)Der External Trigger triggert bei PulseWidth immer, unabhängig von den > Zeiteinstellungen, eigentlich unabhängig ob es einen Signal hat oder > nicht sehe ich gerade(im Normal Mode). Ist aus den gleichen Gründen etwas unausgegoren. Ich tendiere auch dazu den PW-Trigger bei externem Betrieb ganz raus zunehmen. > 5)AutoScale braucht manchmal seeehr laaaangee (>30"). Zweimal passiert. Das hängt von der Anzahl der aktiven Kanäle und dem Signal ab. Die Autoscalefunktion arbeitet sich Stück für Stück durch alle Zeitbereiche und Spannungsbereiche bis alles passt. Im ungünstigsten Fall müssen erst alle relevanten Zeitbereiche und dann alle Spannungsbereiche durchsucht werden -> läßt sich per Terminal schön nachvollziehen, da ich die Debuggausgabe dringelassen habe. > Verbesserungsvorschläge gibt es wahrscheinlich ein Haufen. Ich werfe ein > paar dazu: > -beige Funktionstasten sind nicht so mein Geschmack (Vorschlag grau), Ist von Agilent so kopiert. Wir haben leider auch nur eine sehr begrenzte Farbpalette. > -der Oszi reagiert sehr träge auf die Drehschalter und bekommt den > Winkel der Drehung nicht ganz mit. Ist sicher schwerer Brocken, aber > stört auch am meisten. Ja, das ist auch ein bekanntes Problem das zum Teil im FPGA verbockt wurde. In der neuen Firmware könnte das etwas besser werden, da Jörg für die Eventverarbeitung eine Eventqueue vorgesehen hat die das Ganze (hoffentlich) etwas flüssiger verarbeitet. > -bei der Zeitbasis 1" wird der Verlauf am Display live gezeichnet, bei > 500ms muss man warten bis alles aufgezeichnet ist. Geht das bei den > kleineren Zeiten nicht mehr? Mit der aktuellen Polling-Eventverarbeitung leider nicht. Da ist das Ende der Fahnenstange schon erreicht. Mit der neuen queuegesteuerten Verarbeitung könnte da noch was machbar sein, wir werden sehen. > -wenn der Verlauf gezeichnet wird, wird der noch ausstehende Teil als > Nulllinie gezeichnet. Leer wäre besser (ich weiß, Klugsch.....). Das Ganze ist ein Ringpuffer, dh. irgendwann fängt sowieso das alte Signal wieder an. Dann ist da auch keine Nulllinie mehr. Gruß und willkommen an Bord Hayo
Hallo Hayo Danke für die Antwort, macht einiges klar. Das letzte Punkt (Ringpuffer) auch, wobei ich es als störend empfinde und von anderen DSOs nicht kenne. Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und man muss u.U. genau schauen wo der neue endet und das alte beginnt. Ist aber nicht so wichtig. Gruß Kruno
Krunoslav O. schrieb: > Gerade beim zweiten Durchlauf kommt ein neues Signal über das alte und > man muss u.U. genau schauen wo der neue endet und das alte beginnt. Die Stelle ist einfach zu finden - genau beim roten Pretriggermarker am oberen Bildrand. Der markiert nämlich im USTB-Modus den aktuellen Zeitpunkt - so wie beim normalen Modus eigentlich auch. Der Grund warum der Puffer nach der Aufzeichnung nicht gelöscht wird ist der, dass man im Speicher scrollen kann und sich beliebige vergangene Zeitpunkte bis zum Ende des Puffers ansehen kann. Beim Shift-Modus ist der Puffer vor dem aktuellen Zeitpunkt ja leer, da kenne ich das so, dass das Signal als Nulllinie dargestellt wird (wie beim Herzschlagmonitor z.B.). Gruß Hayo
Bin nach einem Jahr endlich mal wieder mit festem Wohnsitz in Deutschland und hab mal die neue Weihnachtsedition aufgespielt um die Akkus zu testen die ich aus China mitgebracht habe. Dazu ne kleine Idee: wie wärs wenn man die Zeiten ab z.B. 100 s/DIV nicht mehr in s/DIV, sondern in min/DIV skaliert? Wer kann sich schon ohne laufend rum zu rechnen was vorstellen wenn der Entladevorgang eines Akkus 2600 s gedauert hat? Selbst wenn man das Oszi als Langzeitdatenlogger für beliebige andere Daten nimmt denke ich dass Minuten sinnvoller wären.
Luc schrieb: > Hi Hayo, Jörg and guys all! > As always only for knowledge and no for criticism, follow the report > about some issue I noted: > 1) [W2022A & W2012A] The memory management seems to me do not works, > when I save a waveform in memory 1 and after a new one in the memory 2 > or other, then memory 1 is missed and there is only the last I saved. Ok, I got it now! When I made some tests with TTL circuits I had the same effect as You. I will try to fix it soon. Thanks for reporting :-) > (*)W2022A is strikingly higher to the W2012A as response time, I believe > because it is really about 200MHz bandwidth by selected inner > componentistic circuitry or anyway its inner components are better than > the same in the W2012A version. I agree with You. While I made my tests with TTL circuits I could also see a difference between my 2022A and my 2014A. The Bandwidth of the 2022A seems to be really better. On the 2022A the overshots of the TTL-signal (20MHz) could be seen very good, while the 2014A did not display them. Hayo
Hallo zusammen, ich hab ein kleines Problem bei meinem W2022A mit dem Triggern auf einen Fankenwechsel. Ich verwende aktuell die Firmware 1.2.BF.5.1XE (per Ramloader hochgeladen) Ich will einfach nur auf eine steigende Flanke von 0V auf 3V triggern. Eingestellt habe ich bei Horizontal den Modus "Main" und eine 500ms Auflösung. Der Trigger ist bei Edge auf positive Flanke, Source 1, PreTrigger 200ms, eingestellt. Im Triggermenü Mode steht im Mode auf Normal, Coupling DC, Trigger Level 1.5V, Holdoff 100ms. Wenn ich jetzt ein 1Hz Signal am Eingang anlege, triggert das Oszi nicht. Die angezeigt Linie bleibt weiterhin auf 0V. Stell ich die Horizontale-Auflösung des Oszi auf 1s ein, wechselt es automatisch in den Roll-Modus und ich kann das Signal sehen. Hab ich irgend eine Einstellung vergessen oder kann es sein das mit meinem Oszi was nicht stimmt. (Das Oszi ist neu). Vielen Dank für eure Hilfe.
Angehängte Dateien:
-
1Hz-Rechteck-01.png
4,3 KB -
1Hz-Rechteck-USTB-02.png
2,7 KB
Hallo Warhawk, ich habe mich gerade dazu entschlossen die X-Mas Edition aufzuspielen und mal eben deine Einstellungen mit einem 1Hz Rechteck getestet. Schau mal oben im Screenshot, ob diese mit deinen identisch sind. Bei 200mS wird ca. alle 7Sec. getriggert, wie man an den LED's sehen kann. Ab 1S Timebase kommst du automatisch in den USTB-Modus (Ultra slow Timebase), deswegen der Rollmodus, sonst würde man warscheinlich sehr lange warten müssen, bis sich auf dem Bildschirm was tut. Im 2. Shot bin ich mal auf eine Sekunde gegangen. Hast vorher ein Default-Setup gemacht? Gruß Michael
Hallo Michael, vielen Dank. ich hab nochmal die Defaults geladen und dann ging es. Nach dem Aufspielen der Firmware hatte ich aber schonmal die Defaults geladen und die ADC Offset kalibiert. Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-)
dann ist ja alles gut. Es kann sein, wenn das DSO zickt, man mehrmals Default-Setup drücken muß. Vielleicht wird auch nicht immer alles zurück gesetzt, wie auch immer... Ich klatsch mir die Updates immer gleich ins Flash, denn wenn das Teil einfriert, komme ich um ein neues Einspielen eh nicht rum! Btw. Bis ich beim "Holdoff" auf 100mS angekommen bin, hab' ich mir einen Wolf gekurbelt! Könnte man beim schnelleren Drehen des Enkoders nicht grössere Zeitsprünge implementieren? Gruß Michael
Hallo zusammen, Warhawk schrieb: > Keine Ahnung warum es nicht ging, aber hauptsache es geht jetzt ;-) leider funktioniert es aber doch nicht. Warhawk hat da eine vollkommen richtige Beschreibung geliefert! Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da war oder ob nur das Oszi hing!! Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt daher, das die Triggereinstellungen teilweise nicht vollständig oder in der Firmware an verschiedenen Stellen gesetzt werden und so diverse Einstellungen unbeabsichtigt nicht durchgeschalten werden. Das beeinträchtigt leider den Spaß an der Freude sehr! Grüße Jürgen
Jürgen schrieb: > Ich habe in den letzten Wochen versucht mal ganz einfach mit meinem > W2024A zu arbeiten. Oft wusste man nicht, ob das Signal, welches gerade > mit einem simplen Flankentrigger untersucht wurde nun wirklich nicht da > war oder ob nur das Oszi hing!! > Diese Hänger treten auf, wenn mann z.B. den Trigger zwischen den > Eingängen umschaltet oder zwischen Normaltrigger und Combitrigger > wechselt oder z.B. mal einen Singleshot benötigt. Ich denke, das rührt > daher, das die Triggereinstellungen teilweise nicht vollständig oder in > der Firmware an verschiedenen Stellen gesetzt werden und so diverse > Einstellungen unbeabsichtigt nicht durchgeschalten werden. An dieser Stelle komme ich als nächstes mit der neuen Firmware an. Kanaleinstellungen und Offset kann ich mittlerweile, nun kommt Capturing und Trigger dran. Wird spannend, was ist wirklich in der Hardware kaputt, was in der alten Software, was läßt sich durch Workarounds noch hinbiegen, was nicht? Dieses Arbeitspaket stelle ich mir aufwändiger vor als die bisherigen. Wir werden sehen... Mit der kleinen schlanken Osoz-Firmware (Arbeitstitel) läßt sich jedenfalls schön schnell testen. Ein Download in das Gerät dauert derzeit 13 Sekunden, und selbst das liegt hauptsächlich an Zeichensätzen und Icons, die alle schon drin sind. Jörg
Hallo Jörg, das hört sich alles sehr interessant an, was du da baust! Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM zum testen? Ist schon spannend... Gruß Michael
Michael D. schrieb: > Vielleicht gibst du uns mal eine kleine, kompilierte Kostprobe für's RAM > zum testen? Gern aber was soll diese Kostprobe denn tun? Ich arbeite mich von unten hoch, baue einen Layer der die "Infrastruktur" des Gerätes in geordneter Weise zugänglich macht. Auf diesem Plattformlayer setzt die Applikation dann auf. Ist also maximal undankbar, bzw. understatement: nichts von dem wird nachher sichtbar sein, aber es macht die eigentliche Arbeit. Natürlich tun die Programme, die ich da so reinlade schon etwas: es ist jeweils spezieller Test-Code für den Plattformlayer, mit dem ich z.B. Wertebereiche durchfahre, Geschwindigkeiten messe, Randbedingungen teste usw. Man soll sich ja später auf den Unterbau verlassen können. Es gibt da halt nur recht wenig zu sehen. Grüße, Jörg
Hallo allerseits, bin momentan etwas busy und daher nicht so oft in unserer Sache aktiv. Hier eine Korrektur des Flashproblems das Luc entdeckt hatte. Das neue CPU Timing welches ich nach Jörgs Forschungsergebnissen eingebaut hatte brachte die Flash-Schreibroutinen etwas durcheinander. Das ist jetzt wieder korrigiert. Weiterhin habe ich das Timing des USB-Host Interface angepasst, da dieses ebenfalls dadurch beeinflusst wird. GRuß Hayo
Hab noch ein paar Fehler gefunden - die C3 gibt es morgen. Gruß Hayo
So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden konnte. Gruß Hayo
Hi Hayo and guys all! Hayo W. schrieb: >So hier die versprochene C3 in der ich keine Auffälligkeiten mehr finden >konnte. Hayo, as always you are right and all troubles are gone: RESPECT!!!!!!! Really impressive, no words, W2012A and W2022A both works like a charm, I have not noticed any problems! The oscilloscopes work fine, really fast and responsive. Now I am little hurry, however thank you very much Hayo, Jörgs and all who are involve in the Welec project. Last but no least, the logics trigger are awesome, really terrific! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hier die C4 mit dem angepassten Timing für das USB-Host Interface. Hayo
Hallo! Muss man etwas spezielles beachten, wenn man die aktuelle Firmware an "unmodifizierten" Geräten im originalzustand verwendet? Gruß Letschi
Hayo Sorry, but where I find the files Functions.txt Special? Thanks so much for your work.
@Letschi Nein, die Firmware unterstützt in erster Linie originale Geräte und zusätzlich auch noch einige Hardwaremodifikationen. Wenn Du ein normales W20xxA hast kannst Du das also problemlos draufspielen. Bitte beachten, dass das nicht mit dem originalen Firmwareloader von WELEC geht. Hierfür entweder den WELEC-Updater von Markus nehmen oder besser das Perl-Skript. Anleitung findet sich im "Docs" Verzeichnis. @wailer You will find it in the "Docs" directory! Hayo
Hayo Sorry I can not find the director: DOC Why not post the link?
wailer schrieb: > Hayo Sorry I can not find the director: DOC > Why not post the link? Download the 1.2.BF.xy...zip above and unzip it. Then you will find the doc-directory. Link: http://www.mikrocontroller.net/attachment/131946/1.2.BF.5.1C4.zip
Hallo, ich hatte ja heute im Osoz-Thread von meinen gestrigen Forschungsergebnissen zu Thema Startup berichtet: Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Anbei daher hier nun eine Firmwareversion mit dem schnellen Loader, zum Ausprobieren. Das ist exakt Hayos Version 5.1C4, siehe ein paar Postings weiter oben, aber mit dem "Turbolader". Ich habe nur das Flashfile eingepackt, den Rest habt ihr ja schon. Viel Spaß damit! Jörg
Toll was da alles ans Licht kommt und wenn das Oszi jetzt wirklich so schnell bootet - klasse! Werde ich am Wochenende gleich mal ausprobieren... Gruß Michael
Alter Schwede! Die Neugier hat mir keine Ruhe gelassen... Incl. reindrücken des Netzschalters braucht das Gerät 2 Sekunden zum Starten!!! Das nenn ich prompte Verfügbarkeit. Nicht übel, gefällt mir. Gruß Hayo
Hallo Hayo und interessierte, Hier ein paar Updates für die "alte" Software. Ich habe mich gestern an das Problem der Offset-Querbeeinflussung mit der neuen Eingangsstufe gesetzt. Ursache ist ein Überlauf der 4 Variablen CHx_DAC_Offset. Ich habe nun zur Sicherheit in Hardware::SetDacOffset() den Wert mit 0xFFFF maskiert, sonst kann der in den Kommandoteil überlaufen. Die Ursache warum das zu groß werden kann habe ich vermutlich noch nicht vollständig erfasst, verstehe die Software zu wenig. Vielleicht hast du da mehr Durchblick. Ich habe zumindest mal ein Clipping in den Drehregler-Code eingebaut, in die 4 Funktionen UserIF::ON_Zero_Channel_x() Anbei die relevanten Dateien, ausgehend von deiner C4-Version. Den Turbolader habe ich auch mit reingelegt, compiliert für die alte, willkürliche Kopierlänge. So hat das noch etwas Luft, kann den alten 1:1 ersetzen. Der gestrige Code war maßgeschneidert, startet natürlich am schnellsten. Dafür müßte man sich noch einen Flow überlegen. Ich habe den Code mit Absicht so geschrieben, daß die Länge am Anfang "im Klartext" drinsteht, 5.-8. Byte, byteweise rückwärts weil little endian. Da könnte man das zur Not reinpatchen, muß aber die Prüfsumme hinten in der Zeile auch korrigieren. Den Quellcode des Loaders habe ich bei Osoz eingecheckt, unter platform/nios/sdk/startup. Im Quellcode steht auch wie man ihn per Kommandozeile einzeln compiliert. Viele Grüße, Jörg
Gute Sonntag, Jörg H., Hayo und alle! @Jörg H. Jörg H. thanks You very much for the free time You provided generously to us and for this new great firmware's improvement!!! Very impressive work, no words, really much terrific's speed: R E S P E C T ! ! ! ! ! ! ! @Hayo and/or anyone else who has an answer: I was thinking on occasion could be useful inhibit quick measures' cursor marker leaving only the numerical values of labels so that can be observed waveforms without the marker lines dancing on the screen that sometimes can be annoying. On the other hand most of the DSO that I know do not show markers when performing automatic measurements unless this is not explicitly wanted by the user. Perhaps it would be not difficult to add this feature, I'm wrong? I hope I'm right, so the question is: Would not be it possible to add a button that allows to view or not the markers when performing automatic measurements? Ich danke Ihnen allen für Ihre Aufmerksamkeit. Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hi Luc, yes Your idea is not bad. I thought about it the last weeks since I got my new OWON DSO. It does not have this QM-Cursors too. I think I could realize this in the next release. Kind regards Hayo
Jörg H. schrieb: > Ich habe mich gestern an das Problem der Offset-Querbeeinflussung mit > der neuen Eingangsstufe gesetzt. Ursache ist ein Überlauf der 4 > Variablen CHx_DAC_Offset. Ich habe nun zur Sicherheit in > Hardware::SetDacOffset() den Wert mit 0xFFFF maskiert, sonst kann der in > den Kommandoteil überlaufen. Die Querbeeinflussung ist leider nach wie vor vorhanden, die Maskierung funktioniert also nicht wie gewünscht, zumindest auf meinem Welec. Darüber hinaus besteht nach wie vor das Problem, dass die Offset-Kalibrierung bei der Huckepackplatine nicht funktioniert. Dazu ist zunächst zu sagen, dass der Offset im Zusammenhang mit der Huckepackplatine für alle Vertikalablenkungen zu ermitteln ist, da jeweils andere Verstärkungsfaktoren (Dämpfungsfaktoren im LMH6518) eingestellt werden, d.h. die DAC-Werte für 5V/div können nicht für 500mV und 50mV usw. verwendet werden. Dazu möchte ich noch einmal auf die von mir erstellte Tabelle verweisen, die sämtliche Einstellungen enthält: http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls Daher wäre es gut, wenn das Ganze nicht mehr nur so kryptische Bezeichnungen wie "Voltage Range 9" besitzen würde, sondern der tatsächliche Spannungsbereich namentlich genannt würde, dann könnte man auch ohne im Sourcecode fit zu sein erkennen wo Probleme auftauchen. Vielleicht erkennt ja jemand von euch, warum die Offset-Routine nicht mit der Huckepackplatine harmonieren will? Anbei die Ausgabe. Kanal 1 ist derzeit bei mir nicht bestückt, da ja die Problematik mit der Spannungsversorgung bestand. Diese ist ja durch den anderen Spannungsregler behoben worden, daher sollte sie mal wieder eingebaut werden. Aber für den Moment bitte einfach Kanal 1 ignorieren.
1 | outbuf5: 70000f10<\r><\n><\r><\n> |
2 | outbuf5: 50000010<\r><\n><\r><\n> |
3 | outbuf5: 10000010<\r><\n><\r><\n> |
4 | outbuf5: 30000010<\r><\n><\r><\n><\r><\n> |
5 | Channel 1 start calibrating ADC offsets<\r><\n> |
6 | ADC 1 Offset = 3<\r><\n> |
7 | ADC 2 Offset = 0<\r><\n> |
8 | ADC 3 Offset = 2<\r><\n> |
9 | ADC 4 Offset = 0<\r><\n><\r><\n> |
10 | Channel 2 start calibrating ADC offsets<\r><\n>A |
11 | DC 1 Offset = 0<\r><\n> |
12 | ADC 2 Offset = 0<\r><\n> |
13 | ADC 3 Offset = 1<\r><\n> |
14 | ADC 4 Offset = 1<\r><\n><\r><\n> |
15 | Channel 3 start calibrating ADC offsets<\r><\n> |
16 | ADC 1 Offset = 2<\r><\n> |
17 | ADC 2 Offset = 2<\r><\n> |
18 | ADC 3 Offset = 0<\r><\n> |
19 | ADC 4 Offset = 3<\r><\n><\r><\n> |
20 | Channel 4 start calibrating ADC offsets<\r><\n> |
21 | ADC 1 Offset = 3<\r><\n> |
22 | ADC 2 Offset = 1<\r><\n> |
23 | ADC 3 Offset = 1<\r><\n> |
24 | ADC 4 Offset = 0<\r><\n><\n><\r> |
25 | **************** Voltage Range 9 ********************<\n><\r> |
26 | outbuf5: 70000f10<\r><\n><\r><\n> |
27 | outbuf5: 50000010<\r><\n><\r><\n> |
28 | outbuf5: 10000010<\r><\n><\r><\n> |
29 | outbuf5: 30000010<\r><\n><\r><\n> |
30 | Calibration run 1<\n><\r> |
31 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
32 | Channel 2: ADC average value = 34 Diff = -94<\r><\n> |
33 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
34 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
35 | Calibration run 2<\n><\r> |
36 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
37 | Channel 2: ADC average value = 42 Diff = -86<\r><\n> |
38 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
39 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
40 | Calibration run 3<\n><\r> |
41 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
42 | Channel 2: ADC average value = 51 Diff = -77<\r><\n> |
43 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
44 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
45 | Calibration run 4<\n><\r> |
46 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
47 | Channel 2: ADC average value = 65 Diff = -63<\r><\n> |
48 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
49 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
50 | Calibration run 5<\n><\r> |
51 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
52 | Channel 2: ADC average value = 72 Diff = -56<\r><\n> |
53 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
54 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
55 | Calibration run 6<\n><\r> |
56 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
57 | Channel 2: ADC average value = 71 Diff = -57<\r><\n> |
58 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
59 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
60 | Calibration run 7<\n><\r> |
61 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
62 | Channel 2: ADC average value = 79 Diff = -49<\r><\n> |
63 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
64 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
65 | Calibration run 8<\n><\r> |
66 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
67 | Channel 2: ADC average value = 83 Diff = -45<\r><\n> |
68 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
69 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
70 | Calibration run 9<\n><\r> |
71 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
72 | Channel 2: ADC average value = 86 Diff = -42<\r><\n> |
73 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
74 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
75 | Calibration run 10<\n><\r> |
76 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
77 | Channel 2: ADC average value = 87 Diff = -41<\r><\n> |
78 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
79 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
80 | <\n><\r>**************** Voltage Range 10 ********************<\n><\r> |
81 | outbuf5: 70000f10<\r><\n><\r><\n> |
82 | outbuf5: 50000010<\r><\n><\r><\n> |
83 | outbuf5: 10000010<\r><\n><\r><\n> |
84 | outbuf5: 30000010<\r><\n><\r><\n> |
85 | Calibration run 1<\n><\r> |
86 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
87 | Channel 2: ADC average value = 79 Diff = -49<\r><\n> |
88 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
89 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
90 | Calibration run 2<\n><\r> |
91 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
92 | Channel 2: ADC average value = 83 Diff = -45<\r><\n> |
93 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
94 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
95 | Calibration run 3<\n><\r> |
96 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
97 | Channel 2: ADC average value = 91 Diff = -37<\r><\n> |
98 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
99 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
100 | Calibration run 4<\n><\r> |
101 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
102 | Channel 2: ADC average value = 95 Diff = -33<\r><\n> |
103 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
104 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
105 | Calibration run 5<\n><\r> |
106 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
107 | Channel 2: ADC average value = 100 Diff = -28<\r><\n> |
108 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
109 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
110 | Calibration run 6<\n><\r> |
111 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
112 | Channel 2: ADC average value = 104 Diff = -24<\r><\n> |
113 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
114 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
115 | Calibration run 7<\n><\r> |
116 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
117 | Channel 2: ADC average value = 103 Diff = -25<\r><\n> |
118 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
119 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
120 | Calibration run 8<\n><\r> |
121 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
122 | Channel 2: ADC average value = 107 Diff = -21<\r><\n> |
123 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
124 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
125 | Calibration run 9<\n><\r> |
126 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
127 | Channel 2: ADC average value = 110 Diff = -18<\r><\n> |
128 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
129 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
130 | Calibration run 10<\n><\r> |
131 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
132 | Channel 2: ADC average value = 114 Diff = -14<\r><\n> |
133 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
134 | Channel 4: ADC average value = 0 Diff = -128<\r><\n><\n><\r> |
135 | **************** Voltage Range 11 ********************<\n><\r> |
136 | outbuf5: 70000f10<\r><\n><\r><\n> |
137 | outbuf5: 50000010<\r><\n><\r><\n> |
138 | outbuf5: 10000010<\r><\n><\r><\n> |
139 | outbuf5: 30000010<\r><\n><\r><\n> |
140 | Calibration run 1<\n><\r> |
141 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
142 | Channel 2: ADC average value = 106 Diff = -22<\r><\n> |
143 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
144 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
145 | Calibration run 2<\n><\r> |
146 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
147 | Channel 2: ADC average value = 107 Diff = -21<\r><\n> |
148 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
149 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
150 | Calibration run 3<\n><\r> |
151 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
152 | Channel 2: ADC average value = 110 Diff = -18<\r><\n> |
153 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
154 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
155 | Calibration run 4<\n><\r> |
156 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
157 | Channel 2: ADC average value = 113 Diff = -15<\r><\n> |
158 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
159 | Channel 4: ADC average value = 0 Diff = -128<\r><\n> |
160 | Calibration run 5<\n><\r> |
161 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
162 | Channel 2: ADC average value = 115 Diff = -13<\r><\n> |
163 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
164 | Channel 4: ADC average value = 6 Diff = -122<\r><\n> |
165 | Calibration run 6<\n><\r> |
166 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
167 | Channel 2: ADC average value = 114 Diff = -14<\r><\n> |
168 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
169 | Channel 4: ADC average value = 15 Diff = -113<\r><\n> |
170 | Calibration run 7<\n><\r> |
171 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
172 | Channel 2: ADC average value = 116 Diff = -12<\r><\n> |
173 | Channel 3: ADC average value = 0 Diff = -128<\r><\n> |
174 | Channel 4: ADC average value = 26 Diff = -102<\r><\n> |
175 | Calibration run 8<\n><\r> |
176 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
177 | Channel 2: ADC average value = 117 Diff = -11<\r><\n> |
178 | Channel 3: ADC average value = 4 Diff = -124<\r><\n> |
179 | Channel 4: ADC average value = 46 Diff = -82<\r><\n> |
180 | Calibration run 9<\n><\r> |
181 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
182 | Channel 2: ADC average value = 118 Diff = -10<\r><\n> |
183 | Channel 3: ADC average value = 98 Diff = -30<\r><\n> |
184 | Channel 4: ADC average value = 94 Diff = -34<\r><\n> |
185 | Calibration run 10<\n><\r> |
186 | Channel 1: ADC average value = 126 Diff = -2<\r><\n> |
187 | Channel 2: ADC average value = 119 Diff = -9<\r><\n> |
188 | Channel 3: ADC average value = 185 Diff = 57<\r><\n> |
189 | Channel 4: ADC average value = 118 Diff = -10<\r><\n> |
190 | outbuf5: 70000f10<\r><\n><\r><\n> |
191 | outbuf5: 50000010<\r><\n><\r><\n> |
192 | outbuf5: 10000010<\r><\n><\r><\n> |
193 | outbuf5: 30000010<\r><\n><\r><\n> |
194 | protected config written to flash<\r><\n> |
195 | protected config written to flash backup sector<\r><\n> |
Nachdem sich bisher noch immer niemand anderes zu den besagten Problemen geäußert hat gehe ich davon aus, dass nach wie vor niemand die Huckepackplatine ins Welec gebaut hat? Leute, wozu habt ihr euch die Hardware dann gekauft? branadic
Okay, Jörg hat mir soeben einen ersten Hinweis geliefert. Derzeit folgt die gesamte Firmware auch mit Huckepackplatine der 1-2-5 - Mimik, soll heißen, dass stillschweigend davon ausgegangen wird, dass sich die Eingangsbeschaltung in allen Dekaden gleich verhält. Das ist bei einem Messgerät natürlich absolut sinnbefreit, denn allein die Eingangsoffsets der Operationsverstärker werden sich bei unterschiedlichen Dekaden vollkommen unterschiedlich auswirken. Noch schlimmer wirkt sich dies jedoch bei der Huckepackplatine aus. Genau aus diesem Grund hatte ich genannte Tabelle für unsere Hardware erstellt. Um maximales SNR zu erzielen und das sollte ja das Ziel der Übung sein, sollten die Verstärkungsfaktoren der Huckepackplatine wie von mir erstellt umgesetzt werden. Das bedeutet gleichermaßen das eine ADC und DAC Kalibrierung in allen Vertikalablenkungen erforderlich ist. Jetzt erklärt sich auch, warum die "Kalibrationsroutine" so kurz ist. Zum Vergleich, bei dem Oszi bei mir auf Arbeit dauert die komplette Kalibration (Signalpfadkompensation) 10min. In welche Dekade wird derzeit eigentlich die Kalibration durchgeführt? Bei 50mV/20mV/10mV oder bei 5V/2V/1V? Im Hinblick auf Osoz sollten wir diesen Fehler nicht noch einmal so umsetzen. branadic
Ok hier die 5.2 mit dem neuen Turboloader von Jörg incl. angepasster Ladelänge. Weiterhin für Luc jetzt abschaltbare QM-Cursor (Display Setup) Die Badewanne ruft... Hayo
Hallo Hayo, habe gerade geflasht, dabei ist mir noch ein kleiner, nicht wirklich störender Fehler aufgefallen: Direkt nach Anschalten des Oszis wird der Drehregler (der mit dem Pfeil im Uhrzeigersinn) beleuchtet, obwohl man sich ja im Utility-Menü befindet, wo man nichts mit diesem Regler auswählen kann. Gruß ZwoCa
Hi all, hallo Branadic! ....Leute, wozu habt ihr euch die Hardware dann gekauft? Das habe ich mir auch gedacht u. bin angefangen zu löten! Zum warm werden Kurts USB-Host; das hat auch ganz gut geklappt u. ich bin mutig geworden. Die Huckepackplatinen sind danach ins Welec(2022A) gewandert, was ich als außerordentlich sportliche Übung empfand - allerdings erfolglos. Beide Kanäle haben in der Mitte des LCDs ihre 0-Linie abgebildet u. das wars auch schon, keine Messung möglich in keinem Bereich. Fehler konnte ich auch keine entdecken, also erfolgte der Rückbau, schade eigentlich. Erfahrungen anderer Huckepack-Besitzer würden mich an dieser Stelle aber auch interessieren - vielleicht bin ich ja nicht der einzige bei dem es nicht geklappt hat ;-) Jochen
Hayo W. schrieb: > Ok hier die 5.2 mit dem neuen Turboloader von Jörg incl. angepasster > Ladelänge. Ich bin schwer beeindruckt! Da hat man ja schon fast Mühe, die Versions-Nr. im Startbildschirm zu erfassen. Bei mir landet das Scope (W2024A) nach einem Reset nicht fest im Utility-Menü. Gruß Rainer
Hi Hayo, Branadic, Jörg H., Kurt Bohnen and guys all! Hayo W. schrieb: >Weiterhin für Luc jetzt abschaltbare QM-Cursor (Display Setup) Oh man, Hayo you are really too fast!: thank You so much Hayo! It is incredible, as always I am speechless: RESPECT!!!!!!! Hayo, as speed You can compete with "Turbolader" implementation designed by Jorg H., both are fast, really much fast! Congratulations to both: RESPECT!!!!!!! branadic schrieb: >Nachdem sich bisher noch immer niemand anderes zu den besagten Problemen >geäußert hat gehe ich davon aus, dass nach wie vor niemand die >Huckepackplatine ins Welec gebaut hat? Leute, wozu habt ihr euch die >Hardware dann gekauft? Really very sorry branadic, currently I can not help. I bought the material from Kurt Bohnen (both Huckepackplatine and Vinculum) but I have not had time to assemble it. I will do it as soon as possible. Anyway, congratulations and thanks for your valuable contribution branadic: RESPECT!!!!!!! Vielen Dank an alle!!!!!!! Mit freundlichen Grüßen, Luc
ZwoCa schrieb: > Hallo Hayo, > habe gerade geflasht, dabei ist mir noch ein kleiner, nicht wirklich > störender Fehler aufgefallen: > Direkt nach Anschalten des Oszis wird der Drehregler (der mit dem Pfeil > im Uhrzeigersinn) beleuchtet, obwohl man sich ja im Utility-Menü > befindet, wo man nichts mit diesem Regler auswählen kann. Den Fehler kann ich leider nicht reproduzieren. Hast Du es mal mit Default Setup probiert, so wie in der Anleitung empfohlen? Hayo
Wer an der Firmware selbst herumschrauben möchte sollte sich das aktualisierte SDK runterladen, in dem die Neuerungen von Jörg mit eingearbeitet sind (makefile, script etc.) und die neuen delay() Funktionen enthalten sind. http://heanet.dl.sourceforge.net/project/welecw2000a/Development/SDK_BlueFlash_Build.zip Gruß Hayo
Hallo Hayo, ja habe ich gemacht. Schalte ich das Gerät ein bin ich immer direkt im Utility-Menü. Der Pfeil leuchtet. Gehe ich in ein anderes Menü und wieder zurück zu Utility, dann ist er nicht beleuchtet, aber wenn ich dann nochmal das Default Setup lade oder das Gerät neu starte leuchtet er wieder. Gruß ZwoCa
Habs nochmal ausprobiert, Du hast recht, die LED wird nicht richtig gesetzt. Wird korrigiert, danke. Hayo
Ok hier ist auch schon die Korrektur! Bin dann mal weg zum Training und....Ihr wißt es natürlich....beim Griechen :-) Hayo
Guten Abend Jörg H., und alle!
Jörg H. schrieb:
>Anbei daher hier nun eine Firmwareversion mit dem schnellen Loader
For its DSO series WaveAce, LeCroy claim fast power up under 10 seconds.
Now Welec DSO series W20xx are rated to start up themselves under 5
seconds, half of WaveAce!
Thank You very much Jörg H., RESPECT!!!!!!!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Guten Abend Hayo, und alle! @Hayo. Thank You very much for the new 1.2.BF.5.2C2 firmware's release! I tried it and works like a charm. Really great job: RESPECT!!!!!!! I think now the DSO is very useful and fun to use! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
So nach einigen Schwierigkeiten habe ich die Cygwin Umgebung auch angepasst an das neue Build. Wer also unter Windows selbst basteln möchte sollte sich diese hier runterladen: http://sourceforge.net/projects/welecw2000a/files/Development/NIOS_Cygwin.zip/download Hayo
moin moin Hayo & Co. nach dem verstellen des Triggerlevel, kurz bevor die Hilfslinie verschwindet bleibt alles f. kurze Zeit stehen, koennt ihr das mal pruefen ?, oder ist das nur bei mir so ? vlG Charly
Moin, das ist korrekt, das liegt daran das der neue Triggerlevel ins Flash geschrieben wird. Der Flashschreibvorgang braucht immer einen kurzen Augenblick weil erst der ganze Sektor gelöscht und dann neu beschrieben werden muß. Ich arbeite gerade im Rahmen der neuen Hardwaretreiber an einer Optimierung der Schreibgeschwindigkeit. Gruß Hayo
Hayo W. schrieb: > das ist korrekt, das liegt daran das der neue Triggerlevel ins Flash > geschrieben wird. Der Flashschreibvorgang braucht immer einen kurzen wird eigentlich jede Bedienung des Geräts sofort ins Flash geschrieben? Wenn ja, ist das nicht der Lebenszeit des Flashs wenig zuträglich? Oder ist dort genug Platz, dass redundant gespeichert und fehlerhafte Zellen weggemittelt werden können?
Die Frage wird öfters mal gestellt, daher hier eine etwas ausführlichere Antwort. Johannes S. schrieb: > wird eigentlich jede Bedienung des Geräts sofort ins Flash geschrieben? Nicht alle aber die wichtigsten, damit nach einem Neustart alles so ist wie vorher. > Wenn ja, ist das nicht der Lebenszeit des Flashs wenig zuträglich? Oder > ist dort genug Platz, dass redundant gespeichert und fehlerhafte Zellen > weggemittelt werden können? Eine solch aufwändige Sektorverwaltung ist bei uns nicht notwendig, hier ein kleines Rechenbeispiel: Der Hersteller garantiert eine Million Löschzyclen pro Sektor. Wenn Du das ganze Jahr lang das Gerät jeden Tag benutzt und dabei jeden Tag 100 mal die Einstellungen änderst und ins Flash schreibst, bist Du nach 27 Jahren immer noch nicht am spezifzierten Limit. Erinnere mich in 27 Jahren daran, dass ich die Konfiguration in einen anderen Sektor schreibe... Hayo
Danke Hayo f. die Erklaerung, Termin zur errinerung alle 27 Jahre hab ich gestzt :) ( i hoffe i erreich dich dann direkt & muss dich nitt wieder beim Griechen suchen ) vlG Charly
Das kann ich natürlich auf keinen Fall ausschließen ;-) Was aber wahrscheinlicher ist, das ist das Deine Drehregler und Druckknöpfe bis dahin bei so häufiger Benutzung schon längst das Zeitliche gesegnet haben. Hayo
Angehängte Dateien:
-
screen-0000.png
5,4 KB
Hi dso team, also I checked last firmware and works very well.Enclosed a screenshot of a video signal,trigger is stable ,better in normal trigger than video itself,may be cause there isn't a hardware filter at the input. Only the sin interpolation like the other scope would be a 'cherry on the pie'. I confirm some features are available only on our DSO. Thanks Hayo,Jorg and Luc for fast response. regards, Sandro
Hallo! Ich bin ein ziemlicher Neuling was Oszis betrifft, habe aber ein Welec-Gerät mit eurer Firmware vor mir, wo ich meine ersten Erfahrungen sammeln darf. Ich hab nun etwas rumgespielt und dabei sind einige Fragen zur Bedienung, im speziellen zum Trigger aufgetaucht, die ihr mir vielleicht beantworten könnt. Mein "Testsignal" für meine Versuche ist die TX-Leitung einer RS232-Schnittstelle, über die im 1-Sekunden-Intervall ein Zeichen geschickt wird. Frage 1: Trigger im "Normal-Mode": Auf die steigende Flanke des Startbits wird immer zuverlässig getriggert, aber warum kann ich durch das aufgezeichnete Signal nicht scrollen? Frage 2: Trigger im "Auto" oder im "Kombi-Mode": Auf die steigende Flanke des Startbits wird nicht getriggert, nur wenn ich einen "Single-Shot" mache, bekomme ich auch ein stehendes Bild, durch das ich dann erfreulicherweise auch scrollen kann. Warum bekomme ich nur bei einem Single-Shot ein stehendes Bild? Vielen Dank für euere Antworten! Gruß Mike
Hallo Mike, willkommen in der Gemeinde. Was ist es denn geworden (12er, 14er, 22iger oder gar ein 24iger)? Bist Du ein Bastelwilliger oder eher ein normaler Benutzer der die Nase voll hatte von der originalen Firmware? Für den ersten Fall sei Dir noch der Hardwarethread empfohlen. http://www.mikrocontroller.net/topic/goto_post/2499418 Zu Deinen Fragen: Dein Signal hat mit einer Periode von 1 Sekunde den quasi Status eines einzelnen Ereignis. Dafür sind Auto-Trigger und Combi-Trigger nicht geeignet, da diese nach bestimmten Timeouts einen künstlichen Trigger erzwingen. Dadurch wird Dein "Einzelereignis" quasi verschluckt. Das einzige was da hilft wie Du schon gemerkt hast ist der Normaltrigger weil dieser bis in alle Ewigkeit wartet bis Dein Ereignis auftritt und danach auch wieder so lange stehen bleibt bis das nächste Ereignis kommt. Nachteil - Du kannst nicht scrollen, da er ja immer noch wartet und daher die weitere Bildschirmausgabe blockiert. Lösung: Du hast es ja schon rausgefunden - der Single Shot. Was macht der eigentlich? Nun der schaltet "zwangsweise" in den Normal-Triggermodus und wartet auf das Ereignis. Danach bricht er aber die weitere Acquisition ab und gibt die Bildschirmausgabe frei, weswegen Du dann auch scrollen kannst. Hoffe das war einigermaßen hilfreich und nicht zu umständlich erklärt. Gruß Hayo
Hallo Hayo! Vielen Dank für die ausführliche Antwort - jetzt ist mir einiges klarer! Ich nenne ein W2022A mein Eigen. Prinzipiell bin ich auch bastelfreudig, aber im Moment bin ich noch damit beschäftigt, mich mit der generellen Funktionsweise des Oszis vertraut zu machen - dann schauen wir mal weiter... :o) Danke und Gruß Mike
Ein Solches (2022A) besitze ich auch. Wie Du beim Testen feststellen wirst, ist der Trigger eines unserer Sorgenkinder. Leider funktioniert nur der Flankentrigger recht zuverlässig. Der Pulsweitentrigger ist hardwareseitig (FPGA) blöderweise schlecht implementiert und läßt sich nicht korrigieren, hier arbeite ich an einer Softwarelösung (so wie der Combi-Trigger ja auch). Der externe Trigger hat ebenfalls ein Hardwareproblem, welches sich aber durch Auswechseln einiger weniger Bauteile leicht beheben läßt. Beschreibung findet sich im Hardwarethread. Hayo
Hayo W. schrieb: >Der Pulsweitentrigger ist hardwareseitig (FPGA) blöderweise schlecht >implementiert und läßt sich nicht korrigieren, hier arbeite ich an einer >Softwarelösung (so wie der Combi-Trigger ja auch). Hayo, this is really a very good news, thank you! For me COMBI trigger works fine, however any improvement in our oscilloscope is always well come, so thank you again Hayo for the the effort also because it not be easy to implement, really a hard job! Hayo W. schrieb: >Der externe Trigger hat ebenfalls ein Hardwareproblem, welches sich aber >durch Auswechseln einiger weniger Bauteile leicht beheben läßt. >Beschreibung findet sich im Hardwarethread. Hayo, you have done well to remember it! I implemented the modify and I am very pleased, so many thanks to Jürgen who had the intuition and Jörg H. who improved it adding also a fix for the LINE trigger and course to you Hayo who instrumentally tested the changes and provided some screen shots: Jürgen, Jörg H., Hayo and all who are involved in the Welec project, RESPECT!!! The modify is easy, simply change few components, swap two resistor and enjoy with a better DSO! Follow the Hayo's advice and take a look at the Hardwarethread, you will not regret! ;-) And while you're at Hardwarethread, my advice is least to implement changes in the two front end preamp input's line resistors from 0ohm 1% x 2 pieces case 0402 to 24,9ohm 1% x 2 pieces case 0402 and replace the MAXIM 1121 termination's impedance between ADC's pin 8 and 9 from original 150Kohm value case 0402 to the new 150ohm value case 0402, for each channel. This modify improve both the linearity bandwidth and the noise and it is branadic's work who with collaboration of WMarton, Jörg H., Jürgen, Kurt Bohnen, Bruno We, alex008, Michael D., Guido and Michael H. studied the matter and finally provided a simple, easy and powerfull solution! (please, apologize me if I am forget somebody related to this matter). Also this modify is not so much difficult to implement and it is highly recommended expecially if you do not have Pickaback New Input Stage's board. Pickaback is a new input stage's board for the Welec DSO's, it was designed by branadic and distributed by Kurt Bohnen and it is the state of the art for the Welec DSO's hardware improvement! So, branadic, WMarton, Jörg H., Jürgen, Kurt Bohnen, Bruno We, alex008, Michael D., Guido and Michael H: RESPECT!!! As always Hayo is right, so please go to take a look at the Hardwarethread, you will also find Vinculum by Kurt Bohnen! ;-) @Sandro My contribution to the welec project it is null, the real stars are the ones I listed, hoping not to have forgotten anyone, apologize me in the case. Thank you to all! Vielen Dank!!!!!!! Mit freundlichen Grüßen, Luc
Hallo Hayo, ich habe mir das wegschreiben der Config ins Flash mal angesehen. Das kurze "stottern" des Oszis beim Sichern der Config wird ja nicht vom Schreiben, sondern primär vom Löschen des Sektors im Flash verursacht. Die Config ist (aktuell) 1200byte groß, der Sektor ist 64K groß. Es ist doch also eigentlich nicht nötig, den Sektor vor jedem Schreibvorgang zu löschen, sondern nur alle 50 Speichervorgänge. Ich habe das ganze mal auf meinen Scope eingebaut, Patch hänge ich hier mal an. Das Scope stottert damit nicht mehr nach jeder Änderung und fühlt sich so für mich etwas "runder" an. Und obwohl der Flash auch so fast ewig halten sollte, wird er mit dieser Methode noch ein wenig geschont. Was meinst Du dazu? Hab ich was übersehen? Gruß, Björn
Hi Björn, sorry - bin momentan etwas busy, daher die späte Antwort. Björn F. schrieb: > Das kurze "stottern" des Oszis beim Sichern der Config wird ja nicht vom > Schreiben, sondern primär vom Löschen des Sektors im Flash verursacht. Das ist richtig. > Die Config ist (aktuell) 1200byte groß, der Sektor ist 64K groß. Es ist > doch also eigentlich nicht nötig, den Sektor vor jedem Schreibvorgang zu > löschen, sondern nur alle 50 Speichervorgänge. Wenn ich Dein Coding richtig interpretiere (hab nur mal kurz drübergeschaut) dann springst Du in 1200byte Schritten durch den Sektor und löschst den Sektor erst wenn Du wieder von vorn anfängst. > Und obwohl der Flash auch so fast ewig halten sollte, wird > er mit dieser Methode noch ein wenig geschont. Ja, geschätzte Lebensdauer 50 x 27 = 1350 Jahre -> erinnere mich also im Jahr 3362 daran, dass ich einen anderen Sektor verwende... > Was meinst Du dazu? Hab ich was übersehen? Das scheint mir eine gute Idee zu sein. Ich werde mir das mal ansehen und etwas testen. Wenn es da keine Probleme gibt werde ich das auf jeden Fall übernehmen. Allerdings werde ich wohl den Speicherbereich nach etwas vergrößern, damit wir noch Reserve für weitere Variablen haben. Auch für die neue OSOZ-Version dürfte das ein interessanter Ansatz sein. Gruß Hayo
Zum Thema Flash kann ich auch noch was sagen, bin mit meinem Bootloader gerade dran und finde so zwei-drei Sachen raus: In zumindest meinem Gerät ist kein Flash-Chip von AMD (=Spansion), wie's im Wiki steht, sondern von Macronix. Das ist ein Unterschied, ich bin ja halb wahnsinnig geworden: Beim AMD-Chip ist es möglich, während des Löschens eines Sektors von anderen Teilen des Chips zu lesen, steht explizit im Datenblatt. Das wollte ich ausnutzen, um in der "Zwangspause" schon mal eine Prüfsumme mit den rückgelesenen Daten aus dem Vorgängersektor zu aktualisieren, um etwas Zeit zu sparen. Klappte nachhaltig nicht. Bis ich denn mal auf die Idee kam, meinen Chip in Augenschein zu nehmen... Also das Datenblatt von Macronix gesucht. Dort schreiben sie nichts, ob Lesen während des Sektorlöschens möglich ist. Was ferner im Datenblatt steht: Der Chip verkraftet deutlich weniger Schreibzugriffe als der von AMD, schon nach 100.000 Zyklen müssen wir Hayo beim Griechen rausziehen. Ich baue das bei meinen Gerätschaften "immer" so, daß ich persistente Einstellungen nicht sofort ins (in meinem Fall) EEPROM schreibe, sondern erst nach einem Timeout, was durch jede Einstellung wieder hochgesetzt wird. So vermeide ich, das laufend neue Zwischenwerte geschrieben werden, und verlege das Schreiben in Ruhepausen wenn der Benutzer gerade nicht wild dranrumdreht. Bei Osoz täte ich das auch wieder so machen. Dort haben wir Softwaretimer, die quasi nichts kosten. Noch eine Beobachtung: Der GERMSloader schreibt ein Byte zu wenig ins Flash, das letzte kommt nicht an. Ich habe noch nicht probiert, ob das beim RAM-Upload auch so ist. Kann durchaus zu unerklärlichen Phänomänen führen, der Linker hängt ja keine Füllbytes an, hinten stehen die konstanten Daten. (Mit meinem neuen Uploader hat sich das Problem aber demnächst erledigt.) FYI, ich bin derzeit bei 23 Sekunden für das Flashen der Hayo-Firmware. Details siehe Osoz-Thread: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Jörg
Hallo Jörg, richtig flashen oder doch eher "rammen"?? Viele Grüße, egberto
egberto schrieb: > richtig flashen oder doch eher "rammen"?? Schon richtig ins Flash, daran arbeite ich gerade. (In's RAM geht's ja in 16 Sekunden.) Jörg
o-ha tolle Sache.....für die Entwicklung bestimmt ein riesen Fortschritt (gerade zum testen). Wie lange dauerten das packen (auf einer normalen Maschine)? Die Zeit muss man ja eigentlich noch dazu rechnen. Viele Grüße, egberto
egberto schrieb: > Wie lange dauerten das packen (auf einer normalen Maschine)? Definiere "normalen Maschine"... Auf meinem gut 2 Jahre alten Arbeitspferd Core2 Duo 3GHz gerade gemessen 0,4 Sekunden. (Wobei ihm das "Duo" hierfür nichts nützt) Kannst du also gerne mit dazurechnen. ;-) Mit Abstrichen bei der Kompressionsrate geht's auch deutlich schneller (z.B. auf mittlere Einstellung nur 4% größer, aber 4* schneller), das war jetzt die Maximaleinstellung. Jörg
ok, das ist wirklich nichts (hätte ja sein können, das das eine halbe Stunde dauert ;-)) Ich freue mich schon auf die erste OSOZ Version für den Endnutzer (also solche wie mich) zum testen. Viel Erfolg und danke für die fleißige Arbeit. egberto
Guten Abend an alle. @Hayo Only for reference and example, because today I have played around with my logic analyzer. So here are measurements on 3,3V LVTTL outputs when they are displayed on a Logic Analyzer and on a W2022A with the LVTTL 3,3V filter switched on. As I already wrote time ago it's really very impressive, the W2022A works damn fine! So if I am not wrong ultimately the W20xxA DSO's are a bit MSO. Am I wrong? I believe that I am right or at least it is not so wrong. ;-) Thank You very much Hayo, You are great: RESPECT!!!!!!! Vielen Dank! Mit freundlichen Grüßen, Luc
Hi Luc, nice Screenshots. Unfortunately I had not the time to test the logic mode of our "MSO" very well. Due to this I'm glad to hear that it seems to work well. In the moment I'm a little bit spare of time - that is the reason why You don't hear so much from me. But don't worry, I'm still active on our project and I have some new Ideas which are growing in my head. Also there is the OSOZ project which I want to support further. Greetings to all Hayo
Hallo, habe vor kurzem ein W2024 ersteigert und die aktuelle Software eingespielt. Mit den vorhanden Dokus hat das prima funktioniert. Ich möchte mich bei allen Beteiligten herzlich bedanken, die das so ermöglicht haben. Gruß Ralf
Gerne doch. Und hier kommt auch schon Nachschlag. Die BF.5.3. Neben einigen Fixes bringt sie hauptsächlich das Config Slot Writing von Björn, das wirklich gut funktioniert. Ich habe das nochmal etwas überarbeitet aber im Prinzip ist es genau so wie Björn es vorgeschlagen hat. Ein wesentlicher Vorteil ist die viel flüssigere Bedienung der Timebase-Verstellung und auch einiger anderer Funktionen. Auch erhältlich hier: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.5.x/ Gruß Hayo
Hallo hayo, inzwischen sind wir in 2012 (Infoscreen). Michel
Ja aber das (non) copyright ist schon älter...
Hayo W. schrieb: > Gerne doch. Und hier kommt auch schon Nachschlag. Die BF.5.3. Hallo Hayo und Björn, ein dickes Lob an euch beide. Der neue Speicheralgorithmus ist ein klasse Fortschritt für die Performance bei der Bedienung. Die andere Idee zur Speicherung in Bedienpausen lohnt es aber vielleicht trotzdem noch im Auge zu behalten, d.h. bei Veränderung einer Einstellung ein nachtriggerbares (Software-)Monoflop mit einer Zeitkonstante von ruhig ein paar zehn Sekunden (nach-)zutriggern und erst wenn die Zeit abläuft, die Speicherung anzugestoßen. Einstellungen die nur kurz bestehen, sind es eigentlich sowieso nicht wert, im Flash abgelegt zu werden. Gruß und schönen Abend Rainer
Hier ist Hayos neuer Release mit meinem neuen Upload-Verfahren, dem Dekompressor. Ramload in 16 Sekunden, Flashen in 18 Sekunden. Bitte mal testen, unter Linux habe ich es noch nicht laufenlassen. Hayo, könntest du auch in dein Makefile einbauen. Siehe Osoz. Frohes Flashen, Jörg
Hmmm, bei mir gehts unter Linux (Debian) nicht, Ramloader:
1 | bernhard@cork:$ ./ramloader.sh |
2 | loading decompressor to RAM... |
3 | |
4 | GERMSloader.pl Ver 1.1.2 |
5 | |
6 | *** No Warranty |
7 | *** |
8 | *** This program is distributed in the hope that it will be useful, |
9 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
10 | *** The entire risk as to the quality and performance |
11 | *** of the program is with you. Should the program prove defective, |
12 | *** you assume the cost of all necessary servicing, repair or correction. |
13 | *** In no event will any of the developers, or any other party, |
14 | *** be liable to anyone for damages arising out of the use or inability |
15 | *** to use the program. |
16 | |
17 | Writing line 000032 of 000032: S8 detected, end of GERMS transmission. |
18 | Successfully wrote firmware in 1 seconds! |
19 | Please reboot DSO if not already done. |
20 | READY! |
21 | Thanks for all the fish. |
22 | upload finshed. |
23 | loading compressed application... |
24 | |
25 | GERMSloader.pl Ver 1.1.2 |
26 | |
27 | *** No Warranty |
28 | *** |
29 | *** This program is distributed in the hope that it will be useful, |
30 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
31 | *** The entire risk as to the quality and performance |
32 | *** of the program is with you. Should the program prove defective, |
33 | *** you assume the cost of all necessary servicing, repair or correction. |
34 | *** In no event will any of the developers, or any other party, |
35 | *** be liable to anyone for damages arising out of the use or inability |
36 | *** to use the program. |
37 | |
38 | Writing chunk 10 of 10 |
39 | Error: Timeout while reading response from DSO! |
40 | Firmware update was NOT successful! |
41 | Please fix the connection issue and retry! |
Flashloader genauso:
1 | bernhard@cork:$ ./flashloader.sh |
2 | loading decompressor to RAM... |
3 | |
4 | GERMSloader.pl Ver 1.1.2 |
5 | |
6 | *** No Warranty |
7 | *** |
8 | *** This program is distributed in the hope that it will be useful, |
9 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
10 | *** The entire risk as to the quality and performance |
11 | *** of the program is with you. Should the program prove defective, |
12 | *** you assume the cost of all necessary servicing, repair or correction. |
13 | *** In no event will any of the developers, or any other party, |
14 | *** be liable to anyone for damages arising out of the use or inability |
15 | *** to use the program. |
16 | |
17 | Writing line 000040 of 000040: S8 detected, end of GERMS transmission. |
18 | Successfully wrote firmware in 1 seconds! |
19 | Please reboot DSO if not already done. |
20 | READY! |
21 | Thanks for all the fish. |
22 | upload finished. |
23 | flashing compressed application... |
24 | |
25 | GERMSloader.pl Ver 1.1.2 |
26 | |
27 | *** No Warranty |
28 | *** |
29 | *** This program is distributed in the hope that it will be useful, |
30 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
31 | *** The entire risk as to the quality and performance |
32 | *** of the program is with you. Should the program prove defective, |
33 | *** you assume the cost of all necessary servicing, repair or correction. |
34 | *** In no event will any of the developers, or any other party, |
35 | *** be liable to anyone for damages arising out of the use or inability |
36 | *** to use the program. |
37 | |
38 | Writing chunk 10 of 10 |
39 | Error: Timeout while reading response from DSO! |
40 | Firmware update was NOT successful! |
41 | Please fix the connection issue and retry! |
Gruß, Bernhard
Hat es denn wirklich nicht geklappt, oder bringt dich nur die Fehlermeldung durcheinander? Jörg hat das Skript nur um das Pushen der komprimierten Daten erweitert, ich habe aber wegen akutem Zeitmangel noch nicht "aufgeräumt" darin, oder anders gesagt: es geht vermutlich trotzdem und sagt nur, dass es nicht klappt.
Hallo, es hat wirklich nicht geklappt. Nach dem Upload bleibt das Oszilloskop "hängen", nach einem Neustart läuft es auch nicht mehr (Bildschirm bleibt "schwarz" und Run/Stop leuchtet). Gruß, Bernhard
Es sollte keine Fehlermeldung kommen. Der Dekompressor sendet nach Abschluß seiner Tätigkeit ein einzelnes Zeichen, eine Ziffer. 0 für Erfolg, andere Fehlercodes für Mißerfolg. Das Perl-Script wartet darauf, bei Bernhard anscheinend vergeblich. Bei der Flash-Variante kann es worst-case ein bischen dauern, bis die Bestätigung kommt, je nachdem wie ausgelutscht das Flash schon ist. Eventuell muß das Timeout im Script verlängert werden. Bei Ramload kommt es aber sofort, da darf es kein Problem geben. Ich habe es (erfolgreich) mit Cygwin getestet, weil das Oszi an mein Windows-Notebook angeschlossen ist. Linux gibt's nur im Keller... ;-) Was man auch noch ausprobieren könnte: Vielleicht ist dein Rechner so viel schneller als meiner, und sendet die Binärdatei bevor der Loader bereit ist. Mal ein "sleep 1" zwischen die beiden Perl-Aufrufe probieren? Jörg
Jörg H. schrieb: > Ich habe es (erfolgreich) mit Cygwin getestet, Edit: Blödsinn, nicht Cygwin sondern ganz normal Windows, das Batchfile und Perl von ActiveState. Das kaum vorhandene Protokoll zwischen Dekompressor und Script ist zugegeben noch ausbaufähig. Im Moment krankt es daran, das ich nichts senden kann ohne meinen eigenen Datenempfang zu stören. Sprich, Vollduplex klappt nicht. Das muß noch untersucht werden. Sonst könnte ich z.B. nach erfolgreich empfangenem Header was sagen oder nach jedem geschriebenen Sektor einen Punkt senden. Jörg
Hallo Jörg, habe deinen Uploader gerade mal getestet. Funktioniert hier einwandfrei (sowohl die RAM- als auch die Flash-Variante), keine Fehlermeldungen und geht wirklich brutal schnell. (Windows 7 x64, FTDI USB-zu-seriell-Adapter) Gruß ZwoCa
Jörg H. schrieb: > Was man auch noch ausprobieren könnte: Vielleicht ist dein Rechner so > viel schneller als meiner, und sendet die Binärdatei bevor der Loader > bereit ist. Mal ein "sleep 1" zwischen die beiden Perl-Aufrufe > probieren? > > Jörg Hm, ein sleep 5 hilft auch nichts...
Dann ist unter Linux wohl noch was im Argen. Hab' ich ja auch nicht getestet, und laut Definition Softwareentwicklung ist alles was nicht getestet ist kaputt... ;-) Mit vereinten Kräften werden wir das aber rausfinden, denke ich. Derweil fröhliches Flashen an die Windows-User, Jörg
Hi, es liegt an der Gewschwindigkeit und vielleicht an der chunksize...entweder das Oszilloskop, oder die serielle (USB-V24) wird überfahren, vermutlich die serielle Schnittstelle (getestet mit 2 verschiedenen Adaptern, einen "Billigwandler" und einem FTDI). mit
1 | $count = 100; # how many fractions |
2 | my $filesize = -s $filename; |
3 | my $chunk = ($filesize / $count) + 1; |
4 | open($filehnd, $filename) or die "Error: File '$filename' not found.\n"; |
5 | binmode $filehnd; |
6 | my $buffer; |
7 | |
8 | printf "File %s is %u Bytes big, chunk-size is %u\n", $filename, $filesize, $chunk; |
9 | |
10 | while (read ($filehnd, $buffer, $chunk)) # exit if read fails |
11 | {
|
12 | $cur++; |
13 | printf "Writing chunk %u of %u\r", $cur, $count; |
14 | $serial->write($buffer); |
15 | select(undef, undef, undef, 0.6); |
16 | }
|
17 | close($filehnd); |
18 | |
19 | # waiting for response: a single character when done
|
20 | printf "Wrote everything, waiting for response\n"; |
geht es, ist aber wiedr langsam. Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in C wüsste das vorgehen, in Perl muß ich es mir ergooglen... Gruß, Bernhard
Interessant. Das Oszilloskop wird auf keinen Fall überfahren, empfängt im Interrupt, hat Puffer ohne Ende, das ist nicht das Problem. (Unter Windows messe ich auch einen lückenlosen Stream der Bytes.) Also die serielle unter Linux. Windows puffert da anscheinend mehr. Ich hätte erwartet, daß das "write" ggf. blockiert bis seine Daten raus oder zumindest in einem Puffer sind. Jörg
Bernhard M. schrieb: > Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in > C wüsste das vorgehen, in Perl muß ich es mir ergooglen... Ehe ich mir erst mühsam heraussuchen muss, was du da änderst: kannst du mir ein diff gegen das Skript von Jörg schicken, damit ich es in mein Repository reinbekomme? Ich bin nämlich gerade dabei, das grundlegend aufzuräumen (entweder so, dass die Binärdaten gleich mit dem Dekompressor zusammen im selben File stehen, aber auf jeden Fall so, das der Skript nur einmal aufgerufen werden muss, damit es auch ohne das umgebende Shellscript funktioniert) und würde dabei gleich deine Erkenntnisse einbauen wollen.
Johannes S. schrieb: > Bernhard M. schrieb: >> Leider ist mein Perl nicht so gut, deshalb geht das basteln langsam; in >> C wüsste das vorgehen, in Perl muß ich es mir ergooglen... > > Ehe ich mir erst mühsam heraussuchen muss, was du da änderst: kannst du > mir ein diff gegen das Skript von Jörg schicken, damit ich es in mein > Repository reinbekomme? Ich bin nämlich gerade dabei, das grundlegend > aufzuräumen (entweder so, dass die Binärdaten gleich mit dem > Dekompressor zusammen im selben File stehen, aber auf jeden Fall so, das > der Skript nur einmal aufgerufen werden muss, damit es auch ohne das > umgebende Shellscript funktioniert) und würde dabei gleich deine > Erkenntnisse einbauen wollen. Mach ich, wenn es geht. Ich habe den Verdacht, daß "non-blocking" gesendet wird... Gruß, Bernhard
Bernhard M. schrieb: > Mach ich, wenn es geht. > Ich habe den Verdacht, daß "non-blocking" gesendet wird... Ja, das tut es, allerdings war das nicht das Problem. Ich glaube, ich hab's ;-) Melde mich dann gleich, wenn es geht.
Also, es scheint eine Verbindung von zwei Problemen zu sein: - das serial->write blockt unter Linux nicht (stünde auch in der Doku, aber sowas lese ich ja nur, wenn's brennt :-D) - die Puffergröße ist unter POSIX fest auf 4096, das ist für Jörgs Chunks zu klein Ich berechne jetzt die Chunkgröße aus der Dateigröße und blocke unter Linux "zu Fuß", so geht es zumindestens bei mir, und das auch sehr akzeptabel schnell. Kann das bitte a) mal jemand unter Windows testen, ob ich das jetzt nicht kaputtgemacht habe, und b) unter Linux einer bestätigen, dass es da jetzt auch bei ihm geht? Wenn das so fluppt, werde ich mich ans Zusammenfassen der Schreibfunktion machen.
Bei mir jetzt damit:
1 | bernhard@cork:$ ./ramloader.sh |
2 | loading decompressor to RAM... |
3 | |
4 | GERMSloader.pl Ver 1.2.0 |
5 | |
6 | *** No Warranty |
7 | ***
|
8 | *** This program is distributed in the hope that it will be useful, |
9 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
10 | *** The entire risk as to the quality and performance |
11 | *** of the program is with you. Should the program prove defective, |
12 | *** you assume the cost of all necessary servicing, repair or correction. |
13 | *** In no event will any of the developers, or any other party, |
14 | *** be liable to anyone for damages arising out of the use or inability |
15 | *** to use the program. |
16 | |
17 | Writing line 000032 of 000032: S8 detected, end of GERMS transmission. |
18 | Successfully wrote firmware in 0.4 seconds! |
19 | Please reboot DSO if not already done. |
20 | READY! |
21 | Thanks for all the fish. |
22 | upload finshed. |
23 | loading compressed application... |
24 | |
25 | GERMSloader.pl Ver 1.2.0 |
26 | |
27 | *** No Warranty |
28 | ***
|
29 | *** This program is distributed in the hope that it will be useful, |
30 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
31 | *** The entire risk as to the quality and performance |
32 | *** of the program is with you. Should the program prove defective, |
33 | *** you assume the cost of all necessary servicing, repair or correction. |
34 | *** In no event will any of the developers, or any other party, |
35 | *** be liable to anyone for damages arising out of the use or inability |
36 | *** to use the program. |
37 | |
38 | Successfully wrote firmware in 14.8 seconds! |
39 | Please reboot DSO if not already done. |
40 | READY! |
41 | Thanks for all the fish. |
42 | binary upload done. |
also voller Erfolg unter Linux!! Glückwunsch!
Schön. :-) Dann brauche ich jetzt nur noch den Gegentest unter Windows.
Die:
1 | $serial->write_drain unless $ostype =~ /Win/; # waiting for buffer draining, as Linux serial->write doesn't block |
hatte ich nicht gefunden, unter C heisst das tcdrain()...
Sehr schön, vielen Dank Johannes! (Ist ja echt spannend hier) Ich habe es nicht ausprobiert, gucke nur interessiert auf den Code. Könnte da ein Rundungsproblem sein, oder rechnet Perl immer mit float?
1 | $count = $filesize / $buffersize |
Wenn es Integer ist wird count abgerundet, und die Chunks in Folge wieder leicht zu groß. Zwei Zeilen tiefer ist auch noch eine +1, die sorgte bei mir dafür daß es auch mindestens 10 Chunks werden, kann nun raus. Die Meldung "Please Restart..." könnten wir für meinen Loader rausnehmen, der macht das von sich aus (im Erfolgsfall). Von wegen fusionierte Lösung mit 1*Script: Finde ich wie gesagt gut. Ich würde es aber bei 2 Dateien belassen, das macht das Kompilieren einfacher und schneller. Das in eine Datei zu basteln wäre ein Extra-Schritt, den das Perl-Script dann wieder rückgängig machen muß. Ich weiß, ich war vor ein paar Tagen selbst noch anderer Meinung, wollte das Komprimat an's Loader-Hexfile hintendran"hexen". Jörg
Ja, das mit dem Runden ist mir schon aufgefallen, wollte nur sehen, ob es prinzipiell geht. Ich mach das dann gleich "heile"... Zum Thema "Trennen der Dateien": das Zusammenpappen erledigt ja das Makefile, da hat man (theoretisch) keinen Stress. Für mich ist es aber im Perlskript wiederum einfacher, wenn ich nicht erst mehrere Dateien mit einem normierten Endungs- bzw. Dateinamensschema öffnen muss, sondern statt dessen an einer festen Markierung den GERMS- vom Binärteil trenne. Dann muss sich auch niemand an Benennungsschemata halten, sondern der Dateiname kann weiter frei gewählt werden.
Johannes S. schrieb: > Kann das bitte a) mal jemand unter Windows testen, ob ich das jetzt > nicht kaputtgemacht habe, Funktioniert noch. Ich habe diese Version jetzt bei Osoz eingecheckt, nun ist dort alles funktionsfähig beisammen. Jörg
Guten Sonntag, Hayo, Jörg H., Björn F. und alle! @Hayo @Björn F. Right now I am testing the new 1.2.BF.5.3 release. Seems to me it works great even thanks to introduction of the Björn F.'s suggestions. So Hayo as usual I have to thanks You very much for the free time You provided generously to us and for this new great firmware's release, no words: RESPECT!!!!!!! Of course I have also to thanks very much Björn F. for his contribution in the firmware's improvement: RESPECT!!!!!!! In this occasion I have to thanks all people who are involved in the Welec Project, thank all You: RESPECT!!!!!! @Jörg H. Thank You very much for the FastFlash5.3 firmware version! It's very impressive and fast, really no words:RESPECT!!!!!! Jörg H., as usual You prove to be faster than the comic book's superhero Flash! Really You are the master of the Time, you command it and it obeys at you! I take this opportunity to show something about of X-Y rapresentation, so I added some pics of ASA (Analog Signature Analysis) or current/voltage electronic components' signature shown using vertical deflection for current and horizontal deflection for voltage. In the X-Y mode the Time Base is excluded, the pics show ASA signature of some electronics component when they are subjected to a 50Hz's sinusoidal voltage and then referred to a 680ohm sense resistor so that we have a circle on the screen for 4,7uF and 2,1H and a 45 degree line for 680ohm. ASA's signature shown in the pics are for a 10uF's electrolytic capacitor, for a 4,3V zener diode, for 10kohm and 90ohm resistors and for a 220Vac's transformer input, even combining components among their. So the Welec DSO are also a Huntron Tracker clone for sure! Vielen Dank! Mit freundlichen Grüßen, Luc
So, ich habe nun den Perl-Flasher mal zusammengefasst, (hoffentlich) verbessert und warte jetzt auf Kommentare. Änderungen: - man kann alle bisher verwendbaren Modi (Backup, GERMS-Flash, UCL-Flash) nunmehr auf einmal ausführen, also gern auch Backup, gleich darauf Flash und dann hinterher das komprimierte Binary. - daher musste leider das Parameterformat etwas geändert werden, das serielle Device ist jetzt mit -d anzugeben, eventuelle Start- und Endadresse beim Backup mit -s und -e - alle wichtigen Parameter können direkt im Skript vorverdrahtet und dann auf der Befehlszeile weggelassen werden, bisher ist das nur mit dem Device so (/dev/ttyUSB0 ist Standard), falls das Anklang findet, lagere ich das gern noch in eine Configdatei aus. Ein Aufruf könnte also z.B. so lauten: GERMSloader.pl -d COM1 -r Firmware_Backup.flash -s 0x40000 -e 0x7FFFF -w dekompressor_flash.germs -b TomCat_flash.ucl (verwendet COM1, liest erst ein Backup des Bereichs 0x40000-0x7FFFF in Firmware_Backup.flash, schreibt dann den Dekompressor und startet ihn, und schiebt anschliessend gleich das gepackte Binary hinterher) oder aber GERMSloader.pl -w TomCat.ram (verwendet /dev/ttyUSB0 und schreibt TomCat.ram ins Gerät) Hoffe, soweit alle Klarheiten beseitigt zu haben. ;-) /Hannes
Und auf nachdrücklichen Wunsch eines einzelnen Herrn hier noch zwei kleine Änderungen: - die Vorbelegung des seriellen Ports ist jetzt OS-abhängig, COM1 unter Win, /dev/ttyUSB0 unter allen anderen - die Chunksize des UCL-Writers ist jetzt 4096 statt eines etwas krummen Wertes, weil es "so schöner aussieht" ;-) Weitere Ideen sind erwünscht. Bisher steht noch das Auswerten eines Kommentars (#UCL"TomCat_flash.ucl") im Dekompressor-GERMS-File auf der Agenda, welcher dann ein automatisches "Chaining" des UCL-Files ermöglicht, man will ja schliesslich auf der Befehlszeile so tippfaul als möglich sein... ;-)
Johannes S. schrieb: > Bisher steht noch das Auswerten eines Kommentars > (#UCL"TomCat_flash.ucl") im Dekompressor-GERMS-File auf der Agenda, Und weil es gerade so schön war, habe ich das jetzt auch noch nachgerüstet. Wenn ein Kommentar der Form #UCL"TomCat_ram.ucl" bzw. # UCL"TomCat_ram.ucl" in der GERMS-Datei des Dekompressors gefunden wird, wird die zwischen den "" stehende Datei so behandelt, als wäre sie mittels des Parameters -b angegeben worden. /Hannes
Gut, danke, habe ich im SVN nachgezogen. Man könnte deine Ergänzung doch so verallgemeinern, daß generell die Parameter auch in der Datei angegeben werden können? Die Kommandozeile sollte aber Priorität haben, um das übersteuern zu können, sonst müßte man im Bedarfsfall ja die Datei ändern. Jörg
Welche weiteren Parameter stehen so in direktem Zusammenhang mit dem GERMS-File, dass sie ebenfalls darin Platz finden sollten, weil sie bereits im Buildprozess bekannt sind? Nein, ich denke, der Rest sollte in ein Configfile ausgelagert werden, welches die benutzerdefinierten Parameter wie den Port beherbergt, damit man das nur einmal anpassen und nicht jedesmal beim Herunterladen einer neuen Firmware in einer Datei rumeditiert werden muss (wie es jetzt mit den Shellskripten noch ist). Priorität wäre dann Befehlszeile > Configdatei > UCL-Kommentar. Und das muss ich allerdings jetzt noch anpassen, bisher übersteuert der UCL-Kommentar die Befehlszeile.
Hallo Hannes, die Germsloader1.2.0 vom 16.02.2012 funzt einwandfrei mit Profilic USB- Com-Adapter(COM4), WinXP-SP4 In ca. 16sek ist alles erledigt! Wahnsinn... Die Germsloader die du danach gepostet hast, laufen nicht. Habe jetzt alle getestet! Die DOS-Fenster bleiben gefühlte 500ms offen und gehen gleich wieder zu, also keine Chance zum lesen. Gruß Michael EDIT: Waren die letzten jetzt nur für die RAM gedacht? Hatte nur die Flash getestet.
Michael D. schrieb: > Die Germsloader die du danach gepostet hast, laufen nicht. Habe jetzt > alle getestet! Die DOS-Fenster bleiben gefühlte 500ms offen und gehen > gleich wieder zu, also keine Chance zum lesen. Klar, denn: Johannes S. schrieb: > - daher musste leider das Parameterformat etwas geändert werden, das > serielle Device ist jetzt mit -d anzugeben, eventuelle Start- und > Endadresse beim Backup mit -s und -e und die flashloader.bat bzw. ramloader.bat, welche du da doppelklickst, sind bisher noch nicht angepasst auf das geänderte Parameterformat. Das wird sicher in einem der nächsten Builds passieren. Deswegen ist das hehre Ziel, dass diese Shellscripte irgendwann gar nicht mehr benötigt werden, um solche Fehlerquellen zu beseitigen. > EDIT: Waren die letzten jetzt nur für die RAM gedacht? Hatte nur die > Flash getestet. Nö, da besteht kein Unterschied. /Hannes
Johannes! Deine Hilfe wird gebraucht - Linux ist in Not. Das Perlskript funktioniert leider nur unter Windows. Unter Linux wird die komprimierte Datei nicht eingelesen (siehe auch OSOZ-Thread -> Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA") Kannst Du da helfen? Gruß Hayo
Siehe den anderen Thread, das hab ich gleich... /Hannes
So, das hab ich jetzt mal geklärt. Normalerweise dürften die Shellskripte eigentlich gar nicht funktionieren, wenn da DOS line-endings dran sind, aber wie auch immer, ich werf die überschüssigen <#13>s jetzt weg. Ausprobieren, sollte klappen. /Hannes
Ok, der Hinweis mit den DOS Endings war richtig. Wenn ich die aus den Skripten entferne wird die Datei gefunden und gestartet. Hab auch das neue Perlskript ausprobiert, damit läuft es auch. Aber: Das Update ist nicht erfolgreich. Folgende Meldung: --- Writing compressed firmware (25457 bytes / 7 chunks of 4096 bytes)... Writing chunk 7 of 7 - 100.0% - 3.2 sec / 0 sec left Error: bad response from DSO! Error response was: '5' Firmware update was NOT successful! done. So ich teste nochmal unter Windows. Hayo
Fehlercode 5 heißt, die Dekompression hat nicht hingehauen. Die Anzahl der dekomprimierten Bytes stimmt nicht mit der Erwartung überein. Könnte ein Übertragungsfehler sein. Dabei fällt mir auf, daß die Ausgabe des Perl-Scripts differenzierter sein könnte, z.B.: "bad response" für eine nicht erwartete Antwort (Müll), "error response" für einen gültigen Fehlercode. Jörg
So hab noch mal den Gegentest gemacht unter Win XP (gleicher Rechner). Läuft ohne Probleme und startet die Firmware gleich nach dem Upload. Was läuft denn da unter Linux schief? Hayo
Hayo W. schrieb: > --- Writing compressed firmware (25457 bytes / 7 chunks of 4096 > bytes)... Hab ich da was nicht mitbekommen? Warum ist das so klein? Jörg H. schrieb: > Dabei fällt mir auf, daß die Ausgabe des Perl-Scripts differenzierter > sein könnte, z.B.: "bad response" für eine nicht erwartete Antwort > (Müll), "error response" für einen gültigen Fehlercode. Ja gern, dazu müsste mir der Autor des Dekompressors mal die Errorcodes verklickern... :-D
Hayo W. schrieb: > Läuft ohne Probleme und startet die Firmware gleich nach dem Upload. > Was läuft denn da unter Linux schief? Das lässt sich nur herausfinden, indem du mir das gesamte Verzeichnis mal herschickst, damit ich mir das anschauen kann. Bei mir klappt unter Linux jedenfalls alles bestens, also muss es etwas mit den bei dir vorhandenen Dateien zu tun haben.
Ok, ich hau das gleich mal als neues Release raus. Ich hatte ohnehin nur damit gewartet um den Turbo-Loader mit dazuzupacken. Gruß Hayo
Und hier ist sie die BF.5.4 Wieder etwas schneller und besser. Highlights sind die schnelle ADC-Routine und es wird jetzt ein neuer Config-Sektor verwendet. d.h. die Uhr tickt jetzt wieder von vorn, und dank Slot Writing halt das Flash ca. 50 Mal länger. Die Kompressor-Loader Dateien befinden sich im ucl-Verzeichnis. Im Root-Verzeichnis sind die normalen Flash und Ram-Dateien wie immer. Nicht erschrecken, der Ladevorgang dauert wirklich nur 15 Sekunden! Auch erhältlich hier: http://netcologne.dl.sourceforge.net/project/welecw2000a/Open%20Source%20Firmware/1.2.BF.5.x/1.2.BF.5.4.zip @Johannes Die Dateien sind 1:1 aus dem Entwicklungsverzeichnis kopiert. Gruß Hayo
Für alle die selbst entwickeln: Das angepasste SDK mit neuem Linkerskript und Makefile gibt es hier: http://sourceforge.net/projects/welecw2000a/files/Development/SDK_BlueFlash_Build.zip/download Hayo
Angehängte Dateien:
-
Erscheinung_inv.jpg
42 KB -
Erscheinung.jpg
44 KB
Hallo zusammen, erstmal möchte ich Euch Entwicklern für den langjährigen Einsatz für die Welecs danken. Und wenn schon alles schön werden soll und auf dem Prüfstand steht, möchte ich eine Beobachtung melden, die mglw. mit der ADC-Auslesung zu tun hat: Wenn man ein Rechteck einspeist (z.B. Probe Comp.) werden immer wieder einzelne falsche Abtastungen angezeigt. D.h. einzelne Low Abtastungen im High-Signal. Am besten sieht man den Effekt, wenn das Display auf "persist" steht. Aufgrund der Logik vermute ich eher ein SW- als einen HW-Defekt. Vielleicht ist das bei Euch ja auch nicht nachvollziehbar? Screeshots anbei. Viele Grüße, Rainer PS: Ich hatte das schonmal gemeldet, scheint untergegangen zu sein.
Angehängte Dateien:
-
No_Spikes_01.jpeg
44 KB -
No_Spikes_02.jpeg
45 KB
Hallo Rainer, untergegangen ist das nicht, sondern nur nicht nachvollziehbar. Ich habe mit genau Deinen Einstellungen 15 Min lang gewartet, da war kein einziger Spike (siehe Bilder). Auf beiden Geräten wohlgemerkt. FW ist die aktuelle BF.5.4. Ich habe sowohl Factory Hardwareeinstellung als auch Highspeed getestet. Diese Spikes weisen eigentlich auf falsch gesetzte Register hin. Die hatte ich wenn ich in den Hardwareeinstellungen auf die jetzt ausgeblendeten Testeinstellungen gegangen bin. Starte doch mal ein Terminal (mit den bekannten Einstellungen) und drück dann > , <. Du bekommst dann diverse Variablen aufgelistet. Unter Anderem folgende: * channel_Adr_add12 : 5f0a * channel_Adr_add34 : 5f5f * * adc_change12_reg : 2020f00 * adc_change34_reg : 200000a * Das entspricht bei mir der "Factory" Einstellung. Wie sieht das bei Dir aus? Gruß Hayo
Bin heute abend noch mal an die ADC-Routine rangegangen und - wer hätte es gedacht - ich hab da nochmal ordentlich was an Geschwindigkeit rausgequetscht. Aktuelle Framerate ist 1581/1613 FPM was 26,35/26,88 FPS entspricht. Falls Ihr Euch erinnert, mit den (WELEC) Assemblerroutinen lag das bei müden 969/583 FPM. Das ist jetzt mehr als ein Drittel schneller! Wie geht das? Ich habe den Umweg über den Zwischenpuffer weggelassen und schreibe jetzt in einem Arbeitsgang die korrigierten Werte direkt aus dem FPGA-Register in den Signalspeicher. Die nächste Version kommt also bald. Mir schwirrt da noch was im Kopf rum, aber dazu später... Das dürfte für die OSOZ Treiber auch ein interessanter Ansatz sein, denn schneller geht es wohl nimmer! Gruß Hayo
Hallo Hayo, mit loop unrolling geht vermutlich noch was. Damit habe ich aber auch bei Osoz absichtlich noch nicht angefangen. Ist nicht wirklich platformunabhängig, denn eine CPU mit Cache könnte je nach Umfeld besser ohne laufen. Was du völlig unabhängig davon noch "heben" könntest: Ich habe doch mal schnelle 16*16bit auf 32bit Multiplikationsroutinen gebaut, die kannst du vermutlich für deine FFT und vielleicht auch sonstige Signalverarbeitung benutzen? Heißen nr_smul16() und nr_umul16(), für signed und unsigned, ich würde zur Platformunabhängigkeit noch ein Makro drumherum bauen, das wahlweise auch eine normale Multiplikation verwenden könnte. Branadic brachte mich gestern drauf, welchen Stand hat eigentlich die neue Eingangsstufe bei dir? Die braucht in der alten Firmware ja noch etwas Debugging. Ich mag da ehrlich gesagt nicht gerne beigehen. Der gestrige Release war ja noch ohne Linux-UCL Support. Hast du da noch etwas weiter getestet, das Perl-Script mal per Hand aufgerufen? In den Shellscripten waren noch Fehler, du hattest wohl nicht die aktuellen von Osoz. (Ob die jetzt gehen weiß ich allerdings selbst nicht.) Jörg
Angehängte Dateien:
-
spikes1.png
3,3 KB -
spikes2.png
3,3 KB -
spikes3.png
3,4 KB -
spikes4.png
3,5 KB -
spikes5.png
3,5 KB -
spikes6.png
3,6 KB -
spikes7.png
3,7 KB -
spikes8.png
3,6 KB -
spikes9.png
3,7 KB
Hallo Hayo, bei meinem W2024 sieht es genauso wie bei Rainer H. auf. Die Spikes treten anscheinend nur bei 5 MSa/s auf und auch nur in einem gewissen Abstand hinter dem Triggerzeitpunkt. Wie der Abstand von Horizontalposition und Pretrigger abhängt, ist mir nicht klar. Ich hänge einfach mal ein bisschen Daumenkino ran. Vielleicht hat ja jemand eine Idee. Bei mir habe ich folgende Variablenwerte: * channel_Adr_add12 : 5f0a * channel_Adr_add34 : a0a * * adc_change12_reg : 1020000 * adc_change34_reg : 200000a * FW ist die 5.4 - der komprimierte Upload ist schwer beeindruckend!!! Gruß Rainer
Bei Dir werden werksseitig die Register aus dem Protected Flash nicht richtig gesetzt. Probiere doch bitte diese 5.5 Pre Version aus. Ich erzwinge da die richtigen Registerwerte. Würd mich mal interessieren ob es hilft. Nebenbei darfst Du auch noch als Erster die schnelle Datenerfassung "genießen". Gruß Hayo
@Jörg Ich sehe gerade, dass Dein Beitrag hier und meiner im OSOZ-Thread sich überschnitten haben. Ich vermute Du hast recht mit der Beschleunigung bei der FFT. Allerdings wollte ich da eigentlich nicht mehr allzu viel Schmalz in den Application Layer der BF-Version stecken. Die einzigen Sachen die ich hier noch machen wollte sind die Hardwarenahen Sachen die wir auch für OSOZ verwerten können. Quasi als Technologieträger und Testplattform. Wie siehst Du das? Eine Neuerung wollte ich der BF 5.5 noch angedeihen lassen im Bereich Trigger. Details später. Gruß Hayo
Hayo W. schrieb: > Ich vermute Du hast recht mit der Beschleunigung bei der FFT. Allerdings > wollte ich da eigentlich nicht mehr allzu viel Schmalz in den > Application Layer der BF-Version stecken. Die einzigen Sachen die ich > hier noch machen wollte sind die Hardwarenahen Sachen die wir auch für > OSOZ verwerten können. Quasi als Technologieträger und Testplattform. > > Wie siehst Du das? Ich weiß nicht wie du die FFT geschrieben hast. Als Rechenalgorithmus wäre sie je erstmal völlig unabhängig von der Umgebung, könnte man 1:1 rausnehmen. Na gut, vielleicht die Datentypen noch gemäß stdint.h umbenennen. Jörg
Hayo W. schrieb: > Probiere doch bitte diese 5.5 Pre Version aus. Leider sieht das Verhalten bezüglich Spikes mit der 5.5 unverändert aus, sowohl Bildschirm als auch angezeigt Variablenwerte - nur schnelle ;-( Gruß Rainer
@Hayo Stocken nach dem Triggerverstellen weg, und schoen schnell, Kompliment!, Danke! den Efekt von Rainer mit den falschen Abtastungen kann i nicht feststellen (getestet mit 5.5Pre) vlG Charly
Jörg H. schrieb: > Branadic brachte mich gestern drauf, welchen Stand hat eigentlich die > neue Eingangsstufe bei dir? Die braucht in der alten Firmware ja noch > etwas Debugging. Ich mag da ehrlich gesagt nicht gerne beigehen. Stimmt es Hayo, dass du mit der Umrüstung deines 2-Kanälers begonnen hattest? Wie weit ist das gediegen? Sind die Huckepackplatinen jetzt drin? branadic Das Thema scheint entweder unangenehm zu sein, sodass man nicht darauf reagiert oder es wird bewusst ignoriert um nicht reagieren zu müssen. Zumindest ist auffällig, dass bei Nachfragen entsprechende Post immer wieder übergangen werden.
@Charly Dann werden bei Dir von Werk aus die richtigen Registerwerte gesetzt. Anscheinend sind daovon nur Einige betroffen. @Rainer Hab gestern leider vergessen noch eine Anleitung beizufügen - Beipackzettel sozusagen. Also beim Start oder Reset werden weiterhin die Werkseinstellungen aus dem Protected Flash geladen. Um die korrekten Registerwerte zu erzwingen mußt Du ins Hardwaresetup wechseln, dort einmal kurz die High Speed Einstellung wählen und dann wieder zurück auf die Factory Einstellung. Danach sollten die Registerwerte stimmen - bis zum nächsten Neustart. Wenn es das wirklich ist kann ich in der Firmware dafür sorgen, dass die richtigen Werte voreingestellt sind. Gruß Hayo
branadic schrieb: > Sind die Huckepackplatinen jetzt drin? Nein, sind sie nicht, ich konnte mich noch nicht dazu durchringen. Andere Sachen schienen mir wichtiger oder interessanter zu sein. Aber das sollte doch kein Problem sein, da Jörg doch hier den Support leistet und die BF-FW dank Jörgs Zutun die Eingangssufe unterstützt. Dafür arbeite ich gerade an einer Triggererweiterung die sicher sehr nützlich sein wird. Gruß Hayo
Angehängte Dateien:
-
delayed.jpg
57 KB -
factory.jpg
54 KB
Hallo zusammen, nachdem Ihr das "Spike-Problem" nicht alle nachvollziehen könnt, noch einige weiter Infos: - Es ist ein 2-Kanal W2022, ohne HW-Mods (bisher noch nicht mal aufgeschraubt...) - Ich bekommt die Spikes nur im 1 Kanal erzeugt, Triggerkanal ist unabhängig - Nur bei 50 µs Zeitauflösung - In der "Delay"-Anzeige werden die Spikes mit angezeigt, sogar mehr als in der "Main"-Anzeige. Jetzt wirds spannend... Wenn ich im ADC-Setup die "High-Freq" Einstellung wähle, ändert sich an den Erscheinungen nichts. Gehe ich wieder zurück auf "Factory" sieht es aus wie auf dem 2. Bild. Viele Grüße, Rainer
welche Registerwerte werden über das Terminal angezeigt? Evtl. nach der Registerumstellung mal die Timebase hin und her ändern oder den Memoryausschnitt verändern. Hayo
Hayo W. schrieb: > Nein, sind sie nicht, ich konnte mich noch nicht dazu durchringen. Ganz realistisch wirst du dich auch in den nächsten Jahren nicht dazu durchringen können. Hayo W. schrieb: > Aber > das sollte doch kein Problem sein, da Jörg doch hier den Support leistet > und die BF-FW dank Jörgs Zutun die Eingangssufe unterstützt. Ein theoretisches "das sollte kein Problem sein" nützt aber leider herzlich wenig. Fakt ist, mit der derzeitigen Implementierung kann man nicht viel anfangen, weil sie noch zu viele Fehler enthält. Witzigerweise fühlt sich aber niemand mehr dazu berufen den Part anzugehen, zu vervollständigen und die Fehler zu beseitigen. Wenn ich überlege wie laut das Geschrei ganz am Anfang auf Seite der Softwarefraktion war, davon ist heute nichts mehr über. Aus heutiger Sicht wird das Welec wohl immer eine Baustelle oder Spielwiese für Programmierer bleiben. Als Mitentwickler der Huckepkackplatine muss man die Leute ausdrücklich davor warnen den Umbau auf die neue Eingangsstufe vorzunehmen, weil die Softwarefraktion sich nicht dazu hinreißen lässt die anfänglich zugesagte Implementierung umzusetzen. Unter Zusammenarbeit verstehe ich etwas anders! Ich bin mehr als enttäuscht! branadic
Hallo Hayo, die Registerwerte liegen bei. Komischerweise ändert jetzt auch ein Ändern der Timebase wenig, d.h. mind. bis 100µs tauchen die Spikes weiterhin auf. Viele Grüße, Rainer
Angehängte Dateien:
-
8C7_0G.jpeg
42 KB -
8C7_0L.jpeg
42 KB
So ich hab da mal was für Dich (Euch) vorbereitet. Die Factory-Einstellung ist wieder wie früher, aber ich habe im Menü diverse Testeinstellungen eingeblendet. Da könnt Ihr mal durchprobieren ob eine davon passt. Diese Registereinstellungen sind leider unterschiedlich von Hardwarerevision zu HW-Rev.. Meine Geräte sind einmal 8C7.0G und 8C7.0L - auf den Bildern kann man sehen was passiert wenn man die Factoryregisterwerte der beiden Geräte vertauscht. Welche HW-Rev. hast Du bzw. Ihr? Wenn die Testeinstellungen nicht funktionieren können wir nur eines machen: Jemanden suchen mit der gleichen HW-Rev. bei dem die Spikes nicht auftauchen und dann die Registerwerte übernehmen. Leider sind die Registerfunktionen völlig undokumentiert und scheinen sich auch noch je nach HW-Rev. zu unterscheiden. Gruß Hayo
Hallo, ich hab HW 1C9.C(.)9. Die Einstellungen Test 1..5 sind alle ähnlich schlecht (häufige Spikes). Am wenigsten Störungen gibt es "Factory" und "High Freq.". Jetzt komischerweise wieder nur auf Kanal 1... Viele Grüße, Rainer
Das ist eine neuere Version. Anscheinend haben die da noch Änderungen am FPGA vorgenommen und Einiges verschlimmbessert. Wer von den werten Mitlesern hier im Forum hat denn auch ein neueres Gerät mit HW-Rev. > 8C7 und hat keine Probleme mit Spikes? Wir brauchen die Registerwerte - wer hilft? Gruß Hayo
Nein viel einfacher. Utility -> About Oscilloscope Dort die zweite Zeile. Dann Terminal starten, die Einstellungen findet man in "How to use a Terminal" (siehe Anhang). Hayo
Hi Hayo, hab seit langem mal wieder mein Welec ausgepackt und wollt gerade die ADC-Testeinstellungen in der 1.2.BF.5.5Pre2 ausprobieren. Alle Einträge im ADC-Setup außer Factory und High FRQ sind grau und lassen sich nicht anwählen, mach ich da was falsch? HW-Version ist: 8C7.0G Gruß Stefan
Hi Stefan V. and guys all!
@Stefan V.
Maybe it is because You are using turbo version that You have in the
>ucl< folder.
Plesase, tray the classic version, it is much slowest but You will
solve.
I hope You can fix your problem.
Best regards,
Luc
Thanks Luc, you are right! @Hayo Ich hab Spikes nur auf Kanal 1 bei den Einstellungen: Factory, 1, 3, und 4 HW-Rev ist 8C7.0G Gruß Stefan
Angehängte Dateien:
-
Spikes_not_Trig1.png
5,5 KB -
Spikes_not_Trig2.png
5,5 KB -
Spikes_not_Trig3.png
5,4 KB -
Spikes_not_Trig4.png
5,5 KB
Hayo W. schrieb: > Hab gestern leider vergessen noch eine Anleitung beizufügen - > Beipackzettel sozusagen. Hallo Hayo, danke für den Beipackzettel. Danach (FW 5.5 Pre 1) treten die Spikes woanders auf und gefühlsmäßig sogar stärker. Dafür habe ich festgestellt, dass bei frei laufendem Bild (i.e. Signal wird nicht getriggert) nur ein einzelner Spike synchron auf Ch1 und 2 (2,5 und 5 MSa/s) 418 µs bzw. 209 µs nach der Triggermarke bzw. bei 10 MSa/s zwei gegensinnige Spikes nur auf Ch1 60µs vor bzw. 145µs nach der Triggermarke auftreten. W2024A Hardware Vers. ist 1C9.0L Gruß Rainer
Angehängte Dateien:
-
Spikes_not_Trig5.png
4,5 KB
P.S. Korrektur: Ch 3+4 sind genauso betroffen wie Ch 1+2 *** User error 0. Ordnung :-( Hayo, wie ist das mit den Test-Einstellungen gemeint? Ich habe jetzt die 5.5 Pre2 eingespielt (incl. Default Setup), aber über Utility Hardware ADC Setup wird das níchts. "Factory Setup" und "High Frequ" lassen sich anwählen, aber Test1 .. Test5 weigern sich und sind disabled (grau). Habe ich da was nicht mitbekommen? Bei freilaufendem Bild habe ich jetzt einen anderen Abstand zwischen Triggermarke und Spike. Gruß Rainer
Hi Hayo, Jörg H., Björn F., Branadic, Rainer H., Rainer W.,Charly B. and guys all! @Hayo I am testing the new 1.2.BF.5.5Pre2 firmware release. It is surprisingly fast, the waveforms shown on the screen seem to be drawn in real time, almost as on an analog oscilloscope! As usually I am speechless but in this occasion I even believe no to my eyes. It is as I am watching at another DSO, a really fast one, no to my Welecs! So Hayo thank You very much!: RESPECT!!!!!!! Talking of something else, I would not be rude and I do not know if I can interject, but not to do the evil advocate, I think Branadic is right. I mean that would be nice to be able to manage the Huckepackplatinen also for the hard work behind it who Branadic did. I know there are priorities, some things are easier and more immediate to do than other. Ok to the effort to further improve the trigger, it is certainly a great thing, but I hope one day or another we will manage to see the Huckepackplatinen at work in the Welec DSO. I understand that it is not so easy because Huckepackplatinen have to be installed also and that it is not simple to do, but I hope soon we can see something, I am sure! I also know that here all who are involved in the Welec Project use their free time and their resources for the comunity and they have already given so much, so I can not compel them to do more, I hope that the meaning of my words can be understood. I repeat, I would not be rude or polemic but this is my thoughts. Perhaps I have not used the right words but I do not know how else to express myself, so I am not sure to have expressed myself well but I hope I was understandable. Hayo and all apologize me for this digression. @Jörg H. Thank You very much for your turbo implementation, it is very fast and I believe the actual DSO's speed is also for your idea, intuition and work, so RESPECT!!!!!!! Returning to the new firmware release, here some consideration. It is really incredibly fast and quick either as commands response than as waveforms drawn, but spikes are unfortunately come back. As reported by Rainer H., Rainer W.,Charly B. and perhaps other, seems to me spikes appear mainly in the pretrigger area, the next it is devoid and the waveforms are clean. I have experienced spike either on CH1 than CH2 and on both the W2012A and the W2022A. My DSOs are modified, I have changed the front-end and terminations resistors in the input stage and now I have to set hardware for 24,9ohm. Hardware Version is 8C7.0B for the W2012A and 8C7.0C W2022A so I can not help exporting the configuration parameters from the terminal, I am sorry. Maybe there are spikes because of some conflict with the implementation of Jörg H. and Björn F. I wonder why they appear only in the pretrigger area but I have not the right answer, maybe it might just be a software incompatibility. We will see. Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Luc schrieb: > I wonder why they appear only in the pretrigger Hi Luc, nice observation. If the horizontal position is set to the right part of the trace, i.e. the end is completely visible, it is possible to follow the spike while turning the PreTrig time towards 0. The PreTrigger setting seems to be equivalent to the time between the spike and the right end of the trace. (trigger set to combi, not trigger due to level setting below signal) Rainer
Wie Ihr schon bemerkt habt sind die UCL-Dateien der 5.5Pre2 leider nicht aktuell. Das kommt daher, dass ich diese unter Linux leider noch nicht verwenden kann und daher auch nicht prüfen kann. Verwendet also bitte die normalen .flash und .ram Dateien -> sorry. Momemtan sieht es wohl so aus, dass alle mit den 8C7.xx Versionen Glück gehabt haben und die Kollegen mit den 1C9.xx Versionen gekniffen sind. Aber vielleicht findet sich ja doch jemand der eine 1C9.xx ohne Spikes hat. Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere Version ist. Die Nummerierung läßt zwar eine ältere Version vermuten, aber da diese Versionen erst in letzter Zeit aufgetaucht sind denke ich es sind neuere Versionen. Gruß Hayo
Hayo W. schrieb: > Wie Ihr schon bemerkt habt sind die UCL-Dateien der 5.5Pre2 leider nicht > aktuell. Das kommt daher, dass ich diese unter Linux leider noch nicht > verwenden kann und daher auch nicht prüfen kann. Magst du das nicht mal genauer untersuchen? Gerade für uns Entwickler ist das mit dem .ucl-Download doch sowas von dermaßen eine Arbeitserleichterung, daß es mich wundert das du noch nicht sabbernd davorliegst. ;-) Ich verwende das nur noch, ausschließlich, auch beim kleinen Osoz ist das eine prima Sache. Johannes und ich sind fast durchgängig im Skype-Gruppenchat zu erreichen, da kann man das auf kurzem Wege klären. Jörg
Hi Jörg, ich hab einen ganzen Tag lang dran rumgedoktort - ohne Erfolg. Ich stecke weder im UCL noch im Perlthema tief genug drin um da wirklich weiterzukommen. Daher hoffe ich hier auf Johannes und Dich. In der Tat wäre das extrem hilfreich. Gruß Hayo
Dazu müßten wir aber wissen, was bei dir nicht klappt, und natürlich sicherstellen daß du die aktuellen Versionen der Scripte verwendest. Im Passiv-Modus wird das nix... Siehe Osoz-Thread, was passiert bei dir wenn du das Perl-Script direkt aufrufst? Jörg
Sorry bin eben erst wieder zu hause. Also wenn ich das Shellskript abfahre kommt die schon bekannte Meldung Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Writing line 000025 of 000025: S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.3 seconds! --- Writing compressed firmware (168433 bytes / 42 chunks of 4096 bytes)... Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left Error: bad response from DSO! Error response was: '5' Firmware update was NOT successful! done. Wenn ich den Befehl direkt eingebe bekomme ich diese Meldung: Device : /dev/ttyS0 UCL filename : TomCat_ram.ucl --- Writing compressed firmware (168433 bytes / 42 chunks of 4096 bytes)... Writing chunk 42 of 42 - 100.0% - 14.7 sec / 0 sec left Error: Timeout while reading response from DSO! Firmware update was NOT successful! Please fix the connection issue and retry! Gruß Hayo
Hayo W. schrieb: > Wenn ich den Befehl direkt eingebe bekomme ich diese Meldung: Wenn Du welchen Befehl direkt eingibst? Nach der Ausgabe zu urteilen lässt du das Schreiben des Dekompressors weg. Dann läufst du freilich in ein Timeout. Bitte gib doch mal deine Befehlszeile mit an, das kannst du doch mit Copy'n'paste direkt hier einfügen.
Hayo W. schrieb: > Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere > Version ist. Kommt drauf an, wie man den Zeitbalken für "neuer" oder "älter" legt. Mein W2024 mit HW 1C9.0L habe ich im Jan 2009 von T. Wittig erhalten. Da nicht klar ist, in welcher Reihenfolge die Geräte aus dem Regal genommen wurden, sagt das natürlich nicht allzu viel. Gruß Rainer
Guten Morgen an alle! Hayo W. schrieb: > Was nicht ganz klar ist, das ist ob es eine neuere oder eine ältere > Version ist. Because it is probable that the DSOs sold by Mr. Wittig were inventories and that among the material on sale there were also some returns and refurbished DSOs, perhaps there is no a real chronological order. It is probably that the firsts DSO sold by Wittig were the most recent, expecially those sold directly. Then as time goes Mr. Wittig also put them on eBay and among those that were sold there surely some were returned and other else were refurbished material returned as repair and this break the temporal chronological order. I believe that production was stopped, ie, DSOs were no longer in production at the time when Mr. Wittig sold them. So talking about the hardware release, I think it is difficult to determine which are new and which old. Not necessarily the DSOs with a specified number release would surely be the most recent, I believe only Mr. Wittig could confirm it and say how things really are. However, here my two cents: W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 2009. W2012A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010. Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Noch einen guten Morgen an alle! Luc. schrieb: >However, here my two cents: >W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, >2009. >W2012A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010. Ich entschuldige mich, ich vertippt. unter den richtigen Text. W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 2009. W2022A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010. Ich für diesen Fehler zu entschuldigen Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
In Bezug auf die Versionsentwicklung wäre es evtl. gut, die Geräteliste auf SourceForge um Seriennr. und Kaufdatum zu erweitern. Möglicherweise ist die SN erkennbar fortlaufend vergeben und ein Hinweis auf die Entwicklungsfolge. http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument Gruß Rainer
Johannes S. schrieb: > Wenn Du welchen Befehl direkt eingibst? Den von Jörg geposteten Befehl. perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl Rainer W. schrieb: > In Bezug auf die Versionsentwicklung wäre es evtl. gut, die Geräteliste > auf SourceForge um Seriennr. und Kaufdatum zu erweitern. Ja das ist eine gute Idee. Die Möglichkeiten von OSOZ sind natürlich begrenzt wenn die Hardware so unterschiedlich reagiert, dass wir nicht alle Varianten korrekt bedienen können. So Mittagspause ist vorbei - muß wieder los. Tschüß Hayo
Hayo W. schrieb: >> Wenn Du welchen Befehl direkt eingibst? > > Den von Jörg geposteten Befehl. > > perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl De war aber nur zum Test, ob bei dir überhaupt Daten rausgeschoben werden. Für einen Download braucht es vorn noch den Loader, der Aufruf sieht dann so aus:
1 | perl GERMSloader.pl -d /dev/ttyS0 -w ramloader.germs -b TomCat_ram.ucl |
(Wie man mit einem Blick in das Shellscript leicht erkennen kann.) Weil das Script ja fast nix tut gibt das dann vermutlich keinen Unterschied und du kriegst wieder den Fehler 5, merkwürdigerweise. Da wäre dann mal ein Vergleich interessant, aber bitte mit allen beteiligten Dateien: Shellscript, Perlscript, ramloader.germs, TomCat_ram.ucl. Jörg
Sorry 1: Bin gerade erst zurück und hab noch schnell nen Blick ins Forum geworfen. Bin Momentan ziemlich eingespannt... Sorry 2: Hatte den Befehl nur schnell kopiert und ausprobiert und dann wieder los zum nächsten Termin. Nix mit nachdenken oder so... Hast natürlich recht. Hätte man einfach aus der Shell-Datei kopieren können. Ergebnis ist wie erwartet: Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Writing line 000025 of 000025: S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.3 seconds! --- Writing compressed firmware (168437 bytes / 42 chunks of 4096 bytes)... Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left Error: bad response from DSO! Error response was: '5' Firmware update was NOT successful! Liegt also nicht an der Shell-Datei sondern entweder an der Perlversion oder an irgendeiner anderen Sache. Gruß Hayo p.s. bin morgen auch nur zwischendurch mal für kurze Zeit online
Hayo W. schrieb: > --- Writing compressed firmware (168437 bytes / 42 chunks of 4096 > bytes)... Warum sind das bei dir 40 Byte mehr als bei mir (s.u.)?
1 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl> perl GERMSloader.pl -w ramloader.germs -b TomCat_ram.ucl |
2 | |
3 | GERMSloader.pl Ver 1.2.0 |
4 | |
5 | *** No Warranty |
6 | *** |
7 | *** This program is distributed in the hope that it will be useful, |
8 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
9 | *** The entire risk as to the quality and performance |
10 | *** of the program is with you. Should the program prove defective, |
11 | *** you assume the cost of all necessary servicing, repair or correction. |
12 | *** In no event will any of the developers, or any other party, |
13 | *** be liable to anyone for damages arising out of the use or inability |
14 | *** to use the program. |
15 | |
16 | Device : /dev/ttyUSB0 |
17 | Flash filename : ramloader.germs |
18 | UCL filename : TomCat_ram.ucl |
19 | |
20 | --- Writing GERMS firmware... |
21 | Writing line 000025 of 000025: S8 detected, end of GERMS transmission. |
22 | Successfully wrote GERMS firmware in 0.3 seconds! |
23 | |
24 | --- Writing compressed firmware (168397 bytes / 42 chunks of 4096 bytes)... |
25 | Successfully wrote compressed firmware in 15.9 seconds! |
26 | Please reboot DSO if it didn't restart automatically. |
27 | |
28 | READY! |
29 | Thanks for all the fish. |
30 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl> |
Also, ohne das ihr mal die beteiligten Files austauscht wird das nix, imho... Sprich, Hayo veröffentlicht mal genau die 4 Files mit denen es bei ihm nicht klappt, und/oder Johannes die Files mit denen es klappt? Jörg
Jörg H. schrieb: > Sprich, Hayo veröffentlicht mal genau die 4 Files mit denen es bei ihm > nicht klappt, und/oder Johannes die Files mit denen es klappt? Darum bitte ich ja seit Tagen, weil ich irgendwie nie Dateien finde, die der (vom Perlskript ausgegebenen) Größe entsprechen, welche Hayo dort flasht. Ich habe gestern abend das hier > Hayo W. schrieb: > > So ich hab da mal was für Dich (Euch) vorbereitet. gepostete Prerelease heruntergeladen, ausgepackt und es aus dem Unterordner ucl wie in meinem Posting ersichtlich geflasht. Geht aus dem Stand. Johannes S. schrieb:
1 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre2/ucl> perl GERMSloader.pl -w ramloader.germs -b TomCat_ram.ucl |
(Bei allen, die ein anderes Device als /dev/ttyUSB0 verwenden, muss noch der Parameter -d <device name> ergänzt werden.) /Hannes
Hallo , die Dateien waren doch schon längst im Umlauf - und zwar die 5.5Pre, also die erste Pre Version. Ich kann aber gerne noch mal eine Version als Referenz raustun. Grundsätzlich ist zu sagen, dass es bei mir unter Windows funktioniert und unter Linux nicht. Gruß Hayo
Hayo, woher kommt dann diese Dateigröße? Hayo W. schrieb: > --- Writing compressed firmware (168433 bytes / 42 chunks of 4096 > bytes).. Ich habe beide 5.5Pre-Versionen runtergeladen, diese Datei ist bei beiden akkurat gleich groß:
1 | hannes@gurkenkiste:~/Workspace/Welec> l FW1.2.BF.5.5Pre*/ucl/TomCat_ram.ucl |
2 | -rw-r--r-- 1 hannes users 168397 22. Feb 23:12 FW1.2.BF.5.5Pre2/ucl/TomCat_ram.ucl |
3 | -rw-r--r-- 1 hannes users 168397 22. Feb 23:12 FW1.2.BF.5.5Pre/ucl/TomCat_ram.ucl |
Also, was flashst du dort? EDIT: Ich sehe jetzt erst, dass du bei den beiden geposteten Logs der Fehlversuche unterschiedliche Dateigrößen schreibst, einmal 168433 und einmal 168437 Byte, und beides passt nicht zur Dateigröße. Die Frage wird nicht kleiner.
Liebe großartig arbeitenden Welec/Wittig Mit-Leidensgenossen, bitte verweist mich an den richtigen Thread, falls ihr mir hier nicht mit wenigen Zeilen helfen könnt, oder löscht meinen Text nach 2-3 Tagen: Habe ein DSO W2022A mit Originalsoftware, 2007 oder 2008 gekauft. War bis vor 1 Jahr "brauchbar". Auf einmal: Bildschirm leer (eher dunkel). Usache unbekannt und unklar, ob jemand "falsche" Tasten gedrückt hat. Auch Neu-Einstecken und Neu-Einschalten hilft nicht, keine Anzeige am Bildschirm. Run/Stop leuchtet aber grün. Habe durch zufälliges Drücken von Tasten festgestellt, dass nach Drücken der 2 linken Tasten unterm Bildschirm dieser die Farbe wechselt (also noch funktionert), wobei nach jedem Versuch andere Tastenkombinationen (bunt) aufleuchten, darunter auch (beim W2022A nicht vorhandene) Tasten, die dem 3. und 4. Kanal entsprechen würden. Habe auch schon versucht, das Problem durch Aufspielen eurer 1.2.BF.5.4 zu beheben, doch gelingt mir die Kommunikation über euren WelecUpdater ebenfalls nicht. Mögliche Gründe: a) W2022A hat sich so aufgehängt, dass das auch nicht möglich ist. b) Ich habe die Verbindung falsch zusammengesteckt. c) Die Schnittstelle arbeitet nicht richtig, z.B. weil normalerweise ein Modem dranhängt. Fragen: zu a) Hat das DSO eine Batterie oder dgl., die leer sein könnte und ohne die es nicht funktioniert? Hat jemand das beschriebene Verhalten schon einmal gehabt? Falls ja, wie lässt sich dieses beenden? zu b) Mein rel. billiger Rechner (von HP, Bj.2007od.2008, Windows XP voll gepatcht) hat eine 25-polige und eine 9-polige Schnittstelle, im Gerätemanager aber COM1, COM2 und LPT1 betriebsbereit. Heißt das, dass die 25-polige (LPT1?) als COM2 fungiert oder fungieren kann? (Beide haben IRQ3, COM1 mit dem Modem hat IRQ4). Wie kann ich prüfen, ob das Verbindungskabel bzw. die Kabel-Adapter-Kombination für die serielle Verbindung richtig verdrahtet ist? zu c) Kann ich das Modem bei eingeschaltetem Rechner abstecken, das W2022A anstecken und dann mit dem WelecUpdater die Firmware auslesen, oder sind davor weitere Maßnahmen nötig? Wichtig: Muss ich die beiden Tasten links unterhalb des Bildschirms drücken, bevor WelecUpdater den Verbindungsaufbau versucht, oder währenddessen? Und muss ich die linke oder die rechte Taste zuerst loslassen? (die beiden Möglichkeiten führen jeweils zu anderen aufleuchtenden Tastenkombinationen!) Ich hoffe, dass ich alle Fragen so genau gestellt habe, dass ihr mir rasch und helfen könnt und eure wertvolle Arbeit möglichst nicht unterbrochen wird - es tut mir ohnehin so leid, dass ich selbst nicht die Fähigkeit zur Mithilfe am Projekt habe. Deshalb besonderen Dank im Voraus. Rudolf
Rudolf, ich mache für dich und dein Problem mal einen neuen Thread auf, damit das hier nicht zu unübersichtlich wird. So, jetzt kann es hier Beitrag "Wittig- Oszi meldet sich nicht mehr" weitergehen.
@Johannes Tut mir leid, bin momentan die meiste Zeit unterwegs und komme zu nix. Da scheinen wohl die Dateien durcheinander gekommen zu sein. Hier also noch mal eine konsolidierte Version zum Abgleich. Meldung unter Linux ist: Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Writing line 000025 of 000025: S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.3 seconds! --- Writing compressed firmware (168437 bytes / 42 chunks of 4096 bytes)... Writing chunk 42 of 42 - 100.0% - 15.7 sec / 0 sec left Error: bad response from DSO! Error response was: '5' Firmware update was NOT successful! done. Meldung unter Windows kommt gleich nach. Nicht wundern, im "About" steht noch Pev 2, hatte ich noch nicht geändert. Hayo
Und so sieht das unter Windows aus... Device : COM1 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Writing line 000025 of 000025: S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.3 seconds! --- Writing compressed firmware (168437 bytes / 42 chunks of 4096 bytes)... Successfully wrote compressed firmware in 14.7 seconds! Please reboot DSO if it didn't restart automatically. READY! Thanks for all the fish. Gruß Hayo
1 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> ./ramloader.sh |
2 | loading firmware to RAM... |
3 | |
4 | GERMSloader.pl Ver 1.2.0 |
5 | |
6 | *** No Warranty |
7 | *** |
8 | *** This program is distributed in the hope that it will be useful, |
9 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
10 | *** The entire risk as to the quality and performance |
11 | *** of the program is with you. Should the program prove defective, |
12 | *** you assume the cost of all necessary servicing, repair or correction. |
13 | *** In no event will any of the developers, or any other party, |
14 | *** be liable to anyone for damages arising out of the use or inability |
15 | *** to use the program. |
16 | |
17 | Device : /dev/ttyUSB0 |
18 | Flash filename : ramloader.germs |
19 | UCL filename : TomCat_ram.ucl |
20 | |
21 | --- Writing GERMS firmware... |
22 | Writing line 000025 of 000025: S8 detected, end of GERMS transmission. |
23 | Successfully wrote GERMS firmware in 0.3 seconds! |
24 | |
25 | --- Writing compressed firmware (168437 bytes / 42 chunks of 4096 bytes)... |
26 | Successfully wrote compressed firmware in 15.9 seconds! |
27 | Please reboot DSO if it didn't restart automatically. |
28 | |
29 | READY! |
30 | Thanks for all the fish. |
31 | done. |
Und nun? /Hannes
@Hayo Was sagen folgende Befehle bei dir?
1 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> perl -v|grep version |
2 | This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi |
3 | hannes@gurkenkiste:~/Workspace/Welec/FW1.2.BF.5.5Pre3/ucl> perl -MDevice::SerialPort -e 'print "$Device::SerialPort::VERSION\n"' |
4 | 1.04 |
/Hannes
Hi Hannes, bin grad (wie kann es anders sein) vom Griechen zurück und schon etwas zu duselig um hier noch was vernünftig auf die Reihe zu kriegen. Ich check das mal morgen und poste dann das Ergebnis. Gruß Hayo
Angehängte Dateien:
-
W2024_Knobs_klein.jpg
74 KB
Hi Leute, falls noch Interesse an einem W2024 besteht: ich möchte mein Gerät verkaufen, da ich auf ein Owon umgestiegen bin. Hier die Eckdaten meiner Anpassungen: - neuer Lüfter eingebaut - Schirmblech eingebaut - Drehknöpfe aus Alu gefertigt, schraubbar (Madenschrauben) - 4 unbestückte AddOn Platinen für die Erweiterung der Eingangsstufen (mir waren die Lötungen zu filigran) lege ich bei Ansonsten ist das Teil im Originalzustand mit der aktuellen Blueflash Firmware und 4 Messleitungen. Bitte nur ernstgemeinte Angebote an michel-werner[at]gmx[dot]de. Michel
Hallo Hannes, so sieht das aus bei mir: perl -v|grep version This is perl 5, version 14, subversion 2 (v5.14.2) built for i586-linux-thread-multi perl -MDevice::SerialPort -e 'print "$Device::SerialPort::VERSION\n"' 1.04 Gruß Hayo
So heute ist mal wieder Download-Day. Die BF.5.5 final ist fertig. Ich habe da zwei neue Guties eingebaut und noch ein bisschen an der Geschwindigkeitschraube gedreht. Auch erhältlich hier: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.5.x/1.2.BF.5.5.zip/download Was gibt's Neues? Eine Auslesefunktion für die Flash Manufacturer ID und Device ID. Diese wird jetzt angezeigt in Utility->About Oscilloscope. Bei mir steht bei beiden Geräten C293. So jetzt muß man nur noch wissen was das heißt. Also die ersten beiden Zeichen sind die Manufacturer ID. Wenn wie zuerst vermutet ein AMD-Chip drin wäre, dann stünde da eine 01xx. Macronix hat die ID C2xx. Diese IDs sind in einer Tabelle (von Jedec) gelistet die ich bei Bedarf zur Verfügung stellen kann. Interessant ist auch, ob noch weitere Hers teller verwendet wurden. Also postet mal Eure IDs hierr damit wir ein Gefühl dafür kriegen welche Hardware (variationen) wir mit OSOZ berücksichtigen müssen. Und den Alternating Trigger dazu im nächsten Beitrag mehr...
Angehängte Dateien:
-
Asynchron_1.jpeg
52 KB -
Asynchron_2.jpeg
51 KB -
Alternate.jpeg
52 KB
Also wozu braucht man diesen komischen ALT-Trigger und wie komm ich darauf? Die Inspiration kommt vom OWON, da hatte ich doch tatsächlich mal die Gelegenheit von den China-Men zu klauen ;-) Die Funktion gefiel mir so gut, dass ich die auf jeden Fall auch in unsere Büchse einbauen wollte. Also, wir haben zwei Signale die absolut asynchron sind, wollen diese aber direkt miteinander vergleichen und brauchen die Flanken daher direkt übereinander. Mit Trigger Source 1 sieht das dann aus wie in Bild 1 und mit Trigger Source 2 wie in Bild 2. Und jetzt kommt der ALT-Trigger ins Spiel, dann sieht das aus wie in Bild 3. Nett, oder? Und das funktioniert nicht nur mit zwei Kanälen sondern auf allen aktiven Kanälen gleichzeitig (in Wirklichkeit natürlich im Multiplexverfahren) Gruß Hayo
Sehr brauchbar, respect! Werde ich gleich mal testen...
Hayo W. schrieb: > This is perl 5, version 14, subversion 2 (v5.14.2) built for > i586-linux-thread-multi > 1.04 Dort liegt der Hase schon mal nicht im Pfeffer, weil es akkurat wie meine Versionen ist, mal abgesehen von dem Umstand, dass ich die 64bit-Version verwende. Kannst du das Ganze an einem anderen Rechner mit einer anderen Linuxinstallation und v.a. einem anderen RS232-Adapter testen? /Hannes
Hallo Hayo, habe die Firmware mal geflasht und die ID ausgelesen. Mein Oszi ist ein W2022A, dass ich September 2011 bei einer eBay Auktion von Welec erstanden habe. Flash ID ist die 0193 - also scheinbar der AMD Flash Chip. Gruß Sebastian
@Sebastian Du Glücklicher, dann hält dein Chip 10x so lange wie meiner... @Hannes Mein Port ist kein Adapter sondern ein echter Port. Ja ich habe noch meine alte Suse-Installation auf einem Backup-Rechner. Da könnte ich drangehen. Weitere Möglichkeit ist ein Ubuntu (glaube ich) das ich auf einer virtuellen Maschine auf meinem aktuellen Rechner laufen habe. Mal sehen wann ich dazu komme, bin heute Abend wieder unterwegs. Gruß Hayo
@Sebastian btw. Deine Hardware ID wäre für unsere Statistik auch interessant, kannst Du die auch noch mal posten, und evtl. die Seriennummer? Gruß Hayo
Endlich habe ich den Perl Updater hier zum Laufen bekommen. Mein Fehler: ich hatte die 64bit Version runtergeladen und da funzt der Win32-SerialPort-0.22 halt nicht. Hätte ich eher drauf kommen können :) Nachdem ich nun auf meiner W764bit Maschinedie Perl32 Version installiert habe... ist das Updaten ein Traum. Thx! Mit der 1.2.BF.5.5 ist die Darstellung nun irgendwie auffällig 'zappeliger' geworden, eben deutlich mehr als vorher. Von 10mV- bis zum 5V-Bereich ist das durchgehend auf beiden Spuren zu erkennen. Default Setup und Calibrate Offsets habe ich durchgeführt. ADC Setup und PreGain Einstellungen verändern daran nichts. Kann ich, ausser nun die alte Version wieder aufzuspielen, evtl. noch was versuchen um das Gezappel vielleicht wegzubekommen? Ausgelesene Werte: Modell: W2022A Hardware Version: 8C7.0E Software Version: 1.2.BF.5.5 Serial Number: 07060106C8 Flash ID: C293 Gruß Robert
Die Geräteliste auf SF habe ich mal um die Flash-ID erweitert und deine Daten, Robert, gleich mit aufgenommen. https://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument Gruß Rainer
Robert schrieb: > Mit der 1.2.BF.5.5 ist die Darstellung nun irgendwie auffällig > 'zappeliger' geworden, eben deutlich mehr als vorher. Das Gezappel liegt an der deutlich höheren Wiederholrate und ist eigentlich gewollt. Wenn Dir das zu schnell ist einfach Quick Measure und Filter anmachen, dann wird es wieder langsamer. Zum ALT-Trigger: Kanäle auf denen kein Signal anliegt sollte man ausschalten, weil sonst der ALT-Trigger ausgebremst wird und das Signal hin und herzuckt. Gruß Hayo
Hallo, klar, dass ist kein Problem: Modell: W2022A Hardware-Version: 8C7.0E Seriennummer: 00129602C7 Flash ID: 0193 gekauft: September 2011 Die Probleme mit den Signal-Flanken habe ich auf keinem meiner 2 Kanäle. Wäre schön wenn's jemand in das Wiki mit aufnimmt, ich habe keinen Sourceforge-Account. Gruß Sebastian
@Hayo > Die BF.5.5 final ist fertig. Ich habe da zwei neue Guties eingebaut und > noch ein bisschen an der Geschwindigkeitschraube gedreht. Im "Hauptverzeichnis" steht noch die alte Version des Perl-Skripts, dafür gibt es keinen sinnvollen Grund. Die neue Version des Skripts ist für UCL und non-UCL tauglich. Ansonsten: W2024A 8C7.0H 04092701C9 C293 ca. Mitte 2009 gekauft /Hannes
Hm, ich hatte gerade ein sehr seltsames Phänomen nach dem Flashen der 5.5: - geflasht - Default Setup - Zeitbasis hin- und hergedreht - Calibrate Offsets Soweit alles hübsch, bis auf dass Kanal 4 ein geringfügig höheres Rauschen bzw. kleine Spikes in negativer Richtung aufweist, was vorher nicht so war. - alle Kanäle nacheinander aktiviert und "Center Channel X" gedrückt Auf einmal hatte Kanal 4 Rauschen in Höhe von ca. 1.5-2 div. Das blieb auch, als ich alle anderen Kanäle testweise deaktiviert habe. Sobald ich den Kanal auch nur wenige Pixel nach oben oder unten aus der Mitte gedreht habe, war das Rauschen weg bzw. auf Normalniveau. Wieder in die Mitte gedreht bzw. gedrückt und es rauscht. Als ich alles für ein paar hübsche Screenshots vorbereiten wollte und nochmal alles durchgeschaltet habe, verschwand der Effekt urplötzlich. Ich hau jetzt nochmal die 5.4 drauf und guck mir das genauer an. /Hannes
Angehängte Dateien:
-
screen-0003.png
5 KB -
screen-0000.png
4,5 KB -
screen-0001.png
4,4 KB
Johannes S. schrieb: > Soweit alles hübsch, bis auf dass Kanal 4 ein geringfügig höheres > Rauschen bzw. kleine Spikes in negativer Richtung aufweist, was vorher > nicht so war. Zu den Spikes siehe Bild 0003, da sind sie zu sehen, weil ich das Noise Filter abgeschaltet habe. Ist mir mit den älteren Versionen nur nicht aufgefallen, weil ich sonst als erstes das Filter vom Typ "Smooth" einschalte, und das bügelt diese Spikes weg. > Ich hau jetzt nochmal die 5.4 drauf und guck mir das genauer an. Ich habe das Problem nicht mehr provozieren können, aber weil ich einmal dabei war: die Verschiebung der Kanäle erzeugt nach wie vor ein Offset der Nulllinie. In Bild 0000 sieht man eine leichte Verschiebung von Kanal 1 nach oben, während nach Druck auf "Center Channel 1" dieses Offset nicht mehr vorhanden ist (Bild 0001). Gibt es dagegen schon ein Mittel, welches ich nur überlesen habe? /Hannes
Angehängte Dateien:
-
fast_spikes.jpg
64 KB
Hallo, ich möchte nochmal was zum "Spike-Problem" beitragen. Das Bild oben ergibt sich bei mir, wenn ich längere Zeit den "Edge ok" Test mache. Ich finde es auffällig, dass die Fehler immer das Niveau des anderen Pegels haben. Kann das evtl. auch an der RAM-Adressierung liegen, d.h. die Soft-CPU greift an falsche Adressen bzw. ist der RAM-Zugriff vom Timing her nicht optimal (zu schnell)? @Hayo: Gibt es die Möglichkeit testweise langsamer aufs RAM zuzugreifen? Oder bietet Osoz eine RAM-Testmöglichkeit? Viele Grüße, Rainer
Hi, durch den neuen Schwung in diesem und den anderen W20xx Threads ist das Interesse an dem Scope größer als ich dachte. Kurzum - das W2024 ist weg. Michel
Hallo, Vorgeschichte: Hatte mir vor einigen Jahren ein W2022 zugelegt und war von der Kiste überhaupt nicht überzeugt. Also lag das Teil in den Jahren nur so unbenutzt im Schrank rum. Aber gestern hatte ich hier mal so zufällig rumgeschüffelt und war von den Iniziativen überwältigt. Die ganzen Threads hatte ich nicht lesen können, das hätte sicher Tage gedauert. Welec also geholt, geflasht (1.2.BF.5.5) und U N G L A U B L I C H... Wahnsinn, was hier geleistet wurde! Wenn ich es richtig verstanden habe hauptsächlich vom Hajo (Blueflash). Seine Fähigkeiten möchte ich haben, oder wenigstens 5% davon. Aus dem Welec ist ja nun ein für mich brauchbares Scope geworden. Leider kann ich selbst mangels Fachkenntnissen nichts zur Weiterentwicklung beitragen, bin also nur "Trittbrettfahrer". Es bleibt für mich also nur übrig ganz laut D A N K E S C H Ö N zu schreiben und jetzt liebe ich mein Welec! Träum: Wenn jetzt noch ein Komponententester softmässig machbar wäre (habe mich so daran gewöhnt), dann wäre der Traumgipfel erreicht. Thomas, der sich über sein Welec nun freut.
Ein Komponententester ist ein Signalgenerator mit Auswertung. Unser Wellec hat nur Eingänge. Dein Traum wird wohl Traum bleiben müssen. Gruß
Rainer H. schrieb: > ich möchte nochmal was zum "Spike-Problem" beitragen. Das Bild oben > ergibt sich bei mir, wenn ich längere Zeit den "Edge ok" Test mache. das kann ich so bei meinem Gerät bestätigen, HW 8C7.0C Tritt also nicht nur bei den 50µS auf (bzw. dort konnte ich es bisher noch nicht reproduzieren), wohl aber auf 10ns.
Angehängte Dateien:
-
Spike_PreTrig.png
4 KB
Rainer H. schrieb: > Ich finde es auffällig, dass die Fehler immer das Niveau des anderen > Pegels haben. Die Idee mit der falschen Adressierung hatte ich auch schon. Für eine Zuordnung könnte man es mal mit einem Sägezahn füttern. Ich habe die Beobachtung gemacht, dass wenn das Scope frei läuft (d.h. Auto Trigger mit Trig.-Level außerhalb des Signals) der Peak um die als PreTrigger eingestellte Zeit vor dem rechten Ende des Trace-Speichers auftaucht (Horizontalposition ganz nach recht). Gruß Rainer W.
Hallo Jungs, bin mal wieder grad vom Griechen zurück (wir sind quasi schon adoptiert). Also die Idee mit der Adressierung geht schon in die richtige Richtung. Es ist im wesentlichen ein Timingproblem beim Auslesen/Synchronisieren der vier einzelnen ADC. Diese müssen ja Ihre Werte abwechselnd ins schnelle RAM schreiben. Wie uns der frühere Entwickler (mit dem Jörg Kontakt aufgenommen hat) bestätigt hat, gab es von Anfang an Timingprobleme in diesem Bereich, die die Wittigs (die den VHDL-Teil entwickelt haben) nie so richtig in den Griff bekommen haben. Das Ganze ist also ein FPGA-internes Problem, an dem wir mit der Firmware wenig ändern können. Einzige Möglichkeit ist, ein wenig die Registereinstellungen zu variieren oder Softwarefilter nachzuschieben. Allerdings ergeben sich im Gespräch mit diesem Entwickler gerade neue Perspektiven, aber da möchte ich Jörg jetzt nicht vorgreifen. Sagen wir mal so, ich bin optimistisch und gespannt was sich da so ergibt. Gruß Hayo
Jetzt Welec-Fan schrieb: > Thomas, der sich über sein Welec nun freut. Ach ja, bevor ich es vergesse, danke für die Blumen und willkommen im Club! Übrigens möchte ich auch noch mal auf die vielen anderen unermüdlichen Tester, Ideenspender und Mitentwickler hier im Kreise hinweisen die durch Ihr Zutun das Projekt vorangebracht haben. Einen schönen Abend Hayo
Jetzt wollte ich auch mal wieder testen, irre Framerate aber auch böse Spikes. Das kann aber auch an den Einstellungen gelegen haben, ich konnte es wg. dem Netzschalter nicht mehr weiter probieren. Da muss ich mak ran. Michael, bist du noch da? Grüße, Guido
Noch mal Nachschlag. Ich habe im Hardwaremenu die Möglichkeit eingebaut den ADC-Treiber selbst auszusuchen. Standard (default) ist der etwas langsamere Treiber mit Byte overflow protection. Der zweite ist der schnelle (Quick + Dirty) Treiber ohne byte overflow protection. Ich hatte mit dem schnellen Treiber bislang noch keine Probleme. Weitere Treiber (z.B. aus dem OSOZ-Projekt) können jederzeit zur Auswahl hinzugefügt werden. Das erleichtert das Testen und Vergleichen. Wer die Frameraten selber messen will startet ein Terminal und greift sich eine Uhr mit Sekundenanzeige. Mit shift + K resettet man den Counter. Nach genau einer Minute macht man das noch einmal. Der Angezeigte Wert ist dann die Anzahl Frames per Minute (FPM). Weiterhin habe ich den invertierten Modus beim USTB repariert, der durch die neuen Treiber nicht mehr funktionierte. Der Download ist auch über diesen Link erreichbar: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.5.x/1.2.BF.5.6.zip/download Gruß Hayo
Ach ja noch zum Edge-Test. Kanal 3 + 4 sind bei mir auch ausgefranst. Leider läßt sich das auch mit diversen Registervariationen nicht beseitigen. @Johannes Bin noch nicht dazu gekommen meinen Backuprechner aus dem Rack zu ziehen um damit den Pearlloader zu testen - kommt aber noch. Gruß Hayo
Hi there Jetzt Welec-Fan, Hayo and all guys! Jetzt Welec-Fan schrieb: >Träum: Wenn jetzt noch ein Komponententester softmässig machbar wäre >(habe mich so daran gewöhnt), dann wäre der Traumgipfel erreicht. Willkommen bei Jetzt Welec-Fan! A simple components' tester to be coupled to the Welec DSO may be this: h t t p : s n i p u r l . c o m / 2 2 g 4 r b 2 Here a simple guide to understand how it works and how to use it: h t t p : s n i p u r l . c o m / 2 2 g 4 s 7 g Simple but powerful. However You find more detail on any search engine using the query "Octopus oscilloscope tester" or "Analog Signature Analysis". Have fun and joy with your Welec DSO and this simple curve tracer! @Hayo Vielen Dank für die neue Firmware und neue Features alternate Trigger! Wir sehen uns morgen für meine Rezension. ;-) Hayo W. schrieb: >Der zweite ist der schnelle (Quick + Dirty) >Treiber ohne byte overflow protection. >Ich hatte mit dem schnellen Treiber >bislang noch keine Probleme. Selbst ich, mit dem gleichen Setup habe ich keine Probleme bemerkt. Es scheint mir, dass das Spikes Problem hat sich verbessert, oder vielleicht ist es mein Eindruck. This time I tried to write in German, I hope I was understandable. ;-) Mit freundlichen Grüßen, Luc
Hi Luc, dein deutsch wird von Post zu Post besser. Gratulation, wenn du damit etwas anfangen kannst;-). @ Hayo: mal ne blöde Frage: Gibt es im Menü Utility schon den Punkt Firmware-Update? Damit könnten wir uns mal vom GERMS-Monitor verabschieden und ihn als Fallback betrachten. Grüße, Guido
Nein noch nicht, aber Deine Frage bringt mich auf eine Idee. Anstatt den Dekompressor jedesmal mit dem Germsloader hochzuladen, kann man ihn natürlich auch in der Firmware verankern genauso wie den weiteren Upload der Firmware. Remotebefehle nimmt das DSO ja schon über RS232 entgegen, da könnte man natürlich auch ein Firmwareupdate implementieren. Über USB läuft das auch nicht anders. @Luc Respect, Your german is really good. I'm looking forward to Your recension... Gruß Hayo
Angehängte Dateien:
-
CORRUPTED.gif
20 KB -
1_2Hz_sine_DC_COUPLING.gif
17 KB -
1_2Hz_sine_AC_COUPLING.gif
14 KB -
Pulse_2V_Div.gif
13 KB -
Pulse_500mV_Div.gif
13 KB -
Pulse_1V_Div.gif
14 KB -
Pulse_200mV_Div.gif
14 KB
Hi there Hayo, Guido and all guys! As promised here my review of the new 1.2.BF.5.6 firmware. As always are not a criticism but only for knowledge and reference. I tested it on my W2012A setting it both Normal and Fast the ADC configuration. 1)External Trigger selection do not works, when You push its button trying to select between Ext and TV then Ext is stuck on >LF Reject< and TV on >TV Vert Sync<, the respective buttons do not work. 2)After I tried to use Ext Trigger even if CH1 or CH2 are set, then trigger do not works and the waveforms dance back and forth on the screen a little bit as when ALT Trigger is set. Sometime this fact it is also if formerly it is used ALT Trigger. Only way to fix it is to performing a reset, after this all it is OK and trigger resumes its operation. No matter what is trigger mode (Auto, Normal or Combi), it happens regardless their. 3)When there are changes on the bottom labels (i.e. using Cursors or Quick Measure), I get corruption on the bottom of the screen, sometimes even in upper and middle parts. This is even using USTB. Please take a look at my screenshots, thanks. 4) Sometime I noticed freeze, especially after I used slow time base range. Also as in former releases, amplitude of a slow sinusoidal waveform changes it with setting AC or DC coupling: when DC is set the amplitude is right but when the choice it is AC then amplitude it is wrong (little than before with the DC setting). Even when I test pulse behavior, as I already wrote with the previous firmwares release, the signal amplitude change with the Volt/Div choice, so passing from 2V/Div to 500mV/Div the waveforms drawn on the screen decreases instead of increasing. For both the anomalies please look at my screenshots, thanks. ALT Trigger seem to me to be useful and that it works great, a really excellent implementation, thank You very much Hayo: RESPECT!!!!!!! Talking about improvements. Now we can choose to show or hide markers' line when Quick Measure are switched on, but I believe that could be useful to have the cursors visible in Quick Measure. Let me explain better. I mean set the cursors in the Cursors screen, not necessarily simultaneously Time and Voltage cursors but even only one type at a time, then keep them visible on the Quick Measure screen to be use them as reference (example performing a bandwidth measure). I do not mean to have functioning cursors on the Quick Measure screen but only set them in the Cursors screen and then keep them visible on that of Quick Measure. Practically this would to superimpose some static references (cursors lines) on the Quick Measure screen, not necessarily that cursor lines are to be adjustable when Quick Measure it is selected Many DSOs allow it, for example the TDS220 do it, not Time and Voltage cursors at same time but only one at a time but it is however useful in my opinion. I hope I was understandable. I know anything is put on the DSO's screen then there is a speed decrease but now the DSO is very fast and responsive and perhaps it is no a problem in these circumstances and in any case could be turned off if necessary. I would like to have your opinion. @Guido und Hayo Danke für die Ermutigung! ;-) Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Guten Abend an alle. Eine notwendige Klarstellung. Luc schrieb: >Also as in former releases, amplitude of a slow sinusoidal waveform >changes it with setting AC or DC coupling: when DC is set the amplitude >is right but when the choice it is AC then amplitude it is wrong (little >than before with the DC setting). I think I expressed myself badly so I could be misunderstood. What I wanted to write it was related to the the AC behavior in the low frequencies range about few Hz, I did not want to mean a software or hardware problem. I just wanted to describe the AC behavior when inputs are affected by low frequency signals. I know when AC coupling is selected then signal passes through a capacitor to reach input stage. This capacitor's value is 61nF, so its impedance is 2,2Mohm @1,2Hz (261kohm @10Hz), nothing strange if there is attenuation with so low frequencies. As I am already wrote, I am interested about the Welec's bandwidth so I wrote about the low frequencies behavior when AC coupling is set because other DSOs do not show it. I am here only for this little clarification because I would not anyone thought that the cause is in the open source firmware, my clarification it is necessary. See You later. Please, apologize me for the imprecision. Ich entschuldige mich für das Missverständnis. Mit freundlichen Grüßen, Luc
Hi Luc and all others, thanks for testing and reporting. Ext. trigger should be ok now. Freezing can normaly be solved by using Run/Stop button - I'm just searching for the reason... AC coupling is only good for higher frequencies! For lower frquencies the input capacitors are working as high pass filters. So You have to choose DC coupling for lower frequencies. kind regards Hayo
Luc schrieb: > 3)When there are changes on the bottom labels (i.e. using Cursors or > Quick Measure), I get corruption on the bottom of the screen, sometimes > even in upper and middle parts. > This is even using USTB. I'm checking this. Hope I can solve this soon. Hayo
@Johannes Ich habe den Linuxserver noch nicht aus dem Rack gezogen, aber ich habe mal einen weiteren Test unter Windows absolviert. Hardware: - Samsung Netbook NC10 - USB-RS232 Adapter OS: - WinXP Home 32bit FW: - BF.5.7 Der ungepackte Upload funktioniert einwandfrei, der UCL-Upload endet mit dem gleichen Fehler wie unter Linux. Kann das ein Timingproblem sein? Das Netbook ist natürlich langsamer. Der normale Upload dauert 250 Sekunden gegenüber 160 Sekunden auf dem Fest-PC. Gruß Hayo
Naja, aktuell schreibe ich die Chunks grußlos ins DSO, weil der Dekompressor bisher keine Rückmeldung nach jedem Chunk liefert, könnte also durchaus sein. Man könnte versuchshalber die Chunkgröße verringern bzw. nach jedem Chunk eine Pause einlegen, oder auch die Baudrate verkleinern. Du kannst mal - in Zeile 98 die Baudrate halbieren und damit testen, oder - in Zeile 284 die Chunkgröße verkleinern, oder (bzw. und) - vor Zeile 307 eine Zeile mit 'sleep 1;' hinzufügen. Wenn eins davon anschlägt, haben wir schon mal eine Spur. /Hannes
Johannes S. schrieb: > Du kannst mal > > - in Zeile 98 die Baudrate halbieren und damit testen, oder Das hat erwartungsgemäß nicht funktioniert, da keine Verbindung aufgebaut wird. > - in Zeile 284 die Chunkgröße verkleinern, oder (bzw. und) Damit bekomme ich das Ganze unter Linux zum Laufen. Ich habe mich von 2048 bis 4095 nach oben gearbeitet. Alle Chunkgrößen laufen unter Linux bei mir. Nur 4096 mag er nicht. Anders mit dem Netbook und dem RS232 Adapter (WinXP32). Hier bekomme ich den komprimierten Upload auch mit kleineren Chunkgrößen nicht zum Laufen. Bis 1024 habe ich getestet. > - vor Zeile 307 eine Zeile mit 'sleep 1;' hinzufügen. noch ungetestet > Wenn eins davon anschlägt, haben wir schon mal eine Spur. Ich würde sagen das ist eine heiße Spur. Ich habe bei mir unter Linux jetzt 4095 eingestellt. Nun muß ich beim Entwickeln nicht mehr so lange warten, da kommt man doch schneller voran. Jörgs neuer Assembler-Dekompressor arbeitet dabei genauso gut wie die alten Routinen. Nur mit dem Assembler Dekompressor aber der Chunkgröße von 4096 geht es auch nicht. Die Chunkgröße ist hier also anscheinend der Schlüssel zum Erfolg. Gruß Hayo
Hallo Ihr, ich freu(t)e mich auch ein stolzer Besitzer eines W2024A zu sein. Vielen Dank allen und besonders an blueflash für die letzte Version ich gerade aufgespielt hatte. GENIAL .... Nun aber meine peinlichste Frage ... Ich "D..." habe leider die Urdaten des Hersteller gelöscht. Wisst Ihr an welchen Stellen die Daten der Hardwarerevision und SN stehen??? Gibt es noch andere wichtige Parameter die gerätespezifisch sind??? Hat jemand eine Sicherung dieser Daten mit der Hardwarerevisionsnummer 1C9, Softwareversion V1.4 und dem Oszityp W2024A? Ich wäre dem Retter zu tiefstem Dank verpflichtet ... Gruß Andreas
Andreas W. schrieb: > Hallo Ihr, > > ich freu(t)e mich auch ein stolzer Besitzer eines W2024A zu sein. Willkommen im Club. > > Nun aber meine peinlichste Frage ... > > Ich "D..." habe leider die Urdaten des Hersteller gelöscht. Wie hast Du das denn gemacht? > Wisst Ihr an > welchen Stellen die Daten der Hardwarerevision und SN stehen??? Das ist eigentlich im FPGA fest eingebrannt - zumindest nach meinen Erkenntnissen. > Gibt es noch andere wichtige Parameter die gerätespezifisch sind??? Ja, die Registerwerte im Protected Flash. Aber auch die sind nicht so leicht zu löschen. Wenn Du das geschafft hast wüßte ich gerne wie! > Hat jemand eine Sicherung dieser Daten mit der Hardwarerevisionsnummer > 1C9, Softwareversion V1.4 und dem Oszityp W2024A? Eine kleine Übersicht von verschiedenen Revisionen und deren Besitzer findest Du hier: http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument > Ich wäre dem Retter zu tiefstem Dank verpflichtet ... Das sollte kein Problem sein. Meine beiden sind leider 8C7 Geräte bei denen die Register anders gesetzt werden. Die Registersettings der 1C9 Geräte ist mir aber bekannt. Zur Not kann man die erzwingen. So oder so kriegen wir das schon hin. Gruß Hayo p.s. ich sehe gerade, dass Crazor eines seiner Geräte in der Bucht anbietet. Wer also noch aufspringen möchte...
Hayo W. schrieb: >> Wisst Ihr an >> welchen Stellen die Daten der Hardwarerevision und SN stehen??? > Das ist eigentlich im FPGA fest eingebrannt - zumindest nach meinen > Erkenntnissen. Hallo Hayo, hallo Andreas W., ich erinnere mich dunkel, daß ich schon mal diesbezüglich geforscht hatte. Habe auch das betreffende Dateifragment gefunden. Es war fast exakt vor 3 Jahren :-) Damals hatte ich den Welec-Updater-Abzug meines W2024A zur Verfügung gestellt und irgendwie durch Vergleich zwischen W2012A und W2024A herausgefunden, wo der Unterschied liegt: Offenbar ist das auch im Flash gespeichert und nicht nur im FPGA. Beiliegend eine kurze Datei zum Löschen der Seriennummer. Kann allerdings im Moment nicht nachvollziehen wie das exakt funktionierte. Die Datei stammt aus dem alten Backup. Anhand der Adressen sollte sich herausfinden lassen wo die Daten liegen. Das müsste ich mir morgen nochmal ansehen, falls Interesse besteht. Gruß Jürgen
Hast Recht, ich habe das mit der Hardwareversion verwechselt. Seriennummer und auch die anderen Herstellerdaten liegen im Protected Flash. Sollte man das löschen ist das unwiederbringlich weg. Hört sich schlimm an, ist es aber nicht. Dei Seriennummer braucht man für nix (wenn man die irgendwo aufgeschrieben hat kann man sie auch wieder reinbrennen), das Modell kennt man ja bzw. wird beim Start selbst ermittelt und die Registerwerte sind bekannt und können restauriert werden. Sollte also bei jemandem das Protected Flash defekt sein (gelöscht oder falsch restauriert) gibt es zwei Möglichkeiten. Entweder ein Komplettbackup eines identischen Gerätes einspielen oder(und) ich kann eine spezielle FW-Version zusammenbauen die diese Werte individuell wiederherstellt (mit Seriennummer nach Wunsch). Gruß Hayo
Hallo Hajo, hallo Jürgen, ich freue mich über die schnellen Antworten. Bitte fragt lieber nicht wie ich das geschafft habe ... meine Frau lacht schon, da sie Ihren Perfektionisten noch nie so gesehen hat. Ich glaube das ist das erste Gerät wo ich nur die hälfte des Flash-Speichers ausgelesen habe ... mit einer großen Rachekeule. Löschen war ganz einfach ... e00040000 bis e7F0000 ... nun ist alles leer ;-) (schön wenn man noch selbst lachen kann) Mit der Seriennummer habe ich gestern auch noch einmal die Quellen durchforstet: void AMDFlash::Write_Protected_Flash(void) ... Flash_Protect_Buffer[0] = 0xFF2332FF; // Kennung Flash_Protect_Buffer[1] = tc_model; // model 2012, 2022 ... Flash_Protect_Buffer[2] = tc_serial; // serial nr (1 = 0x0) wobei #define protected_Config_Flash (unsigned long *) 0x000F0000 unsigned long tc_hw_sw_version = 0x00000000; // Type 0 = W2012 1 = W2014 2 = W2022 3 = W2024 Ich denke ich werde jetzt mal auf die Besitzer der Hardware 1C9 hoffen und dann noch einmal alles zurückspielen.
Hallo Hajo, das wäre ja die beste Idee. Gibt es denn noch andere geräteabhängige Einstellungen? Logisch wären mir z.B.: * Anzahl der Kanäle also Typ * Seriennummer (meine war mal 1305) * Production Lot 1 und 2 (sieht aus als wenn diese nur angezeigt und gesendet wird) * shipment date (genauso) Was wäre denn noch wichtig zu wissen? Gruß Andreas
Hallo Andreas, ich habe hier ein W2024A mit HW 1C9.0L. Mein Backup ist tief verkramt, aber ich könnte dir den relevanten Speicherbereich runterziehen. Was hättest du denn gerne?
Hallo Rainer, um sicher zu gehen, wäre ich über den ganzen Inhalt sehr dankbar. Da ich den komplette Inhalt zerstört habe, vermute ich noch wichtige andere Teile an die ich jetzt noch nicht denke. Wenn Du Hayo's letztes Flash drauf hast, könntest Du diesen Bereich weglassen. Ich wäre Dir absolut dankbar und ich könnte bald dieses gute Stück wieder nutzen. Gruß Andreas
Ja, spiel ein Komplettbackup ein. In einem anderen Teil des Flashs liegen auch noch die Bitmaps für das WELEC-Logo. Die werden sonst beim Start nicht angezeigt, was nicht schlimm ist, aber es soll ja alles korrekt sein ;-). Wenn noch was klemmt können wir das dann Stück für Stück aus dem Weg räumen. Gruß Hayo p.s. ...und wenn es Dich tröstet, bei mir (und einigen Anderen) hat es auch so angefangen. Ich hab mir beim Upload das Flash zerschossen - nur war damals dieses ganze Projekt nicht soweit. Da hat mir dann auch jemend mit einem Backup weitergeholfen und für mich war es der Ansporn dieses Projekt ins Leben zu rufen.
Hallo Andreas, nach dem letzten von Hayo beigelegten W2000A Programmers Reference V8.06 müßten nach meinem Verständnis die folgenden drei Bereiche ausreichen: 000F0000 .. 000FFFFF 006C0000 .. 006EFFFF 007D0000 .. 007FFFFF Probier's doch erstmal damit. Hayo, vielleicht kannst du zu den relevanten Speicherbereichen sonst noch was sagen. Gruß Rainer
Hallo Rainer, vielen Dank. Ich werde mal alle Bereiche löschen und dann die von Dir zur Verfügung gestellten Quellen einspielen. Danach Hayo's letzte Version... Ich hoffe so ... Gruß Andreas
Die ersten beiden würden schon reichen. Der letzte Teil ist nicht zwingend notwendig da diese Werte durch Defaultwerte beim Start versorgt werden wenn nichts Vernünftiges gefunden wird. Hayo
Andreas W. schrieb: > Ich werde mal alle Bereiche löschen und dann die von Dir zur Verfügung > gestellten Quellen einspielen. @Andreas Der Löschbefehl steht vorne schon mit drin. Viel Erfolg. @Hayo Das gibt dann ja einen sehr handlichen Wiederbelebungs-Kit. Danke für die Info. Gruß Rainer
Die Daten werden gerade geschrieben... Leider habe ich ab und zu einen Timeoutfehler und muß den Teil noch einmal schreiben. Ich melde mich wieder wenn alles geschrieben ist! Danke und Gruß Andreas
Ich verschwinde mal wieder in den Keller - Renovierung steht an. Schau nachher nochmal rein. Hayo
Es gab ein kurzes Lebenszeichen nach folgendem Vorgehen: 1. alle Bereiche noch einmal gelöscht 2. vom Rainer alle 3 Dateien eingespielt (obwohl die Teilbereiche noch einmal gelöscht wurden) 3. vom Hayo die letzte Version eingespielt 4. Reboot ... Startbildschirm und danach Wechsel in den normalen Screen (mit Fehlern). Dann waren in Abständen einige undefinierte Streifen zu sehen und es war keine Bedienung mehr möglich. Nach einem Reboot bleibt der Bildschirm schwarz mit aktiver Hindergrundbeleuchtung. Zum Timeoutfehler kann ich sagen, dass dieser nur unter Win7 kommt. Deswegen habe bin ich auf meine XP-Partition gewechselt. Alles noch einmal durchgeführt ... aber ohne Erfolg (diesmal mit einem Foto in der Hand - brachte nur nichts). Ich würde den Rainer noch einmal um ein komplettes Backup bitten. Evtl. ist da noch etwas was ich(wir) übersehe(n). Gibt es einen Ort auf der Platine wo die Hardwarerevision steht - nur um noch einmal sicher zu gehen?? Gesehe habe ich derzeit nur solche Angaben wie beim Rainer ... V1.03 2006 10C6 (2DS54L 0022 W2024). Gruß Andreas
Andreas W. schrieb: > Nach einem Reboot bleibt der Bildschirm > schwarz mit aktiver Hindergrundbeleuchtung. Das ist ja sehr bedauerlich. Andreas W. schrieb: > Ich würde den Rainer noch einmal um ein komplettes Backup bitten. Evtl. > ist da noch etwas was ich(wir) übersehe(n). Ich habe den Sauger mal angeschmissen, soll noch 40 Minuten dauern, falls die Anzeige stimmt.
VIELEN DANK ... ich bin dann mal gespannt. Gruß Andreas
Das ist das komplette Backup incl. Firmware 1.2 BF 5.6. Bin gespannt, ob das was nützt. Drück dir die Daumen. Eigentlich kennt Hayo den Flash ganz gut ;-) Gruß Rainer
Ich werde Euch informieren ... oder ich bin dann auch im Keller mit Oszi-Überreste ;-) Gruß
Womit flashst Du? Perl Skript komprimiert/unkomprimiert? Gruß Hayo
OH OH ... 2 Stunden und 28 Minuten ... leider ohne Erfolg. Kann ich überhaupt eine Flash-Datei mit Perl-Script erstellt mit dem Welec Updater V0.4.8A22 verwenden ??? Gruß Andi
Wenn ich mir die zurück gelesenen Daten (nur mal ein kleiner Teil) ansehe, dann kann ich keinen Unterschied erkennen. Mich wundert, dass die Hardware beim Booten nicht richtig angesprochen wird (schalten der Relais). Noch mal meine Frage zur Hardwareversion. Kann man das auf dem Mainboard auch erkennen? Gibt es evtl. noch Ideen? Gruß Andi
Hallo Andreas, ich hatte vor kurzem das gleiche Problem mit meinem W2014. Ich habe dann das Backup von brandiac aus dem Thread : http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=53 geflasht. Dabei habe ich es über USB mit dem USBBlaster per JTAG geflasht. Leider kenne ich den Unterschied zwischen dem 2014 und dem 2024 nicht aber bei mit lief es danach wieder. Ich hoffe das es bei dir genauso funktioniert. Gruß, Martin
@Hayo, Hayo W. schrieb: > Womit flashst Du? jetzt auch mit dem Perl-Script ... (superschnelle 2400 sek. für alles) > Perl Skript komprimiert/unkomprimiert? perl GERMSloader.pl -d COM1 -w XYZ.backup Gruß Andi
Hallo Martin, hallo Hayo, ja auch mit dem Perl-Script gibt es kein Erwachen mehr. Die neue Updatedauer mit dem Script liegt bei 1163.2 Sekunden. @Matin Die beiden Geräte unterscheiden sich nur in der Bandbreite ... 2014 ... 4 Kanal mit 100 MHz 2024 ... 4 Kanal mit 200 MHz Ich frage mich nur wie die FW des FPGA's teilweise weg sein soll. Ich hatte auch das originale Welec-Update-Tool per USB verwendet. Das war vermutlich mein Fehler ... Da kann ich jetzt nur noch auf die Suche nach dem Abbild des FPGA's machen. Oh wie bitter ... ich glaube da brauche ich noch weitere Hilfe. Gruß Andi
Hallo Andreas, Ist der Unterschied eigentlich nur die FW oder ist auch die HW anders bei der 200Mhz Version als bei dem 100Mhz Modell ? Gruß, Martin
Martin H. schrieb: > Ist der Unterschied eigentlich nur die FW oder ist auch die HW anders > bei der 200Mhz Version als bei dem 100Mhz Modell ? "Das würde drauf hindeuten, dass der HW-Unterschied zwischen W2014 und W2024 nur in der Bestückung(Bauteilauswahl) liegt." @ Beitrag "Wittig(welec) DSO W20xxA Hardware" Ich denke Hayo hat bestimmt die bessere Antwort! @Hayo, Da ich mir nun mit nichts mehr sicher bin, möchte ich noch einmal die Frage nach der Hardwareversion stellen. Kann ich diese auf dem Board erkennen? Nicht das ich schon so viel geflasht habe, dass ich völlig auf dem Holzweg bin. Was natürlich dagegen spricht ist das kurze Laden des Startbildschirmes nach den ersten Quellen vom Rainer. FPGA muss die allerletze Option sein. Wobei mir der Eintrag vom Martin wieder etwas Mut macht... Gruß Andi
Hi Andi, bin grad erst vom Griechen zurück (die Anderen kennen das ja schon) und muß jetzt dringend in die Badewanne ne Runde rauspaddeln ;-). Ich melde mich morgen noch mal dazu. Guats Nächtle Hayo
Martin H. schrieb: Hallo Martin, > > Dabei habe ich es über USB mit dem USBBlaster per JTAG > geflasht. Leider kenne ich den Unterschied zwischen dem 2014 und dem > 2024 nicht aber bei mit lief es danach wieder. Ist ja interessant, das du über USB flashen konntest! Der USB-Blaster-Treiber ist ja klar. Was heißt per JTAG geflasht??? Über USB-Kabel mit dem Quartus-Programmer, oder wie? Weil der JTAG-Hesder ist ja auf dem Mutterbrett vom DSO. > Gruß Michael
Hallo Michael, Ja genau. Ich habe erst mit dem HID-Inf Treiber das gerät in den Nios Dev Board Modus versetzt und danach die Treiber aus dem Quartus Programmer genommen. Danach kann man das Oszi mit dem Quartus Programmer flashen. Die Beschreibung dazu steht auch im Wiki bei dem Upgrade von W2000 zum W2000A. Gruß Martin
Martin H. schrieb: > Hallo Michael, > > Ja genau. Ich habe erst mit dem HID-Inf Treiber das gerät in den Nios > Dev Board Modus versetzt und danach die Treiber aus dem Quartus > Programmer genommen. das geht ja klar! Mit dem Treiber geht dann halt die Software vom Welec nicht mehr, aber die ist ja eh' für die Füsse! Mit dem Quartus habe ich das Leon3 immer mal aufgespielt. Leider geht die Entwicklung nicht mehr weiter, schade auch... > > Danach kann man das Oszi mit dem Quartus Programmer flashen. Die > Beschreibung dazu steht auch im Wiki bei dem Upgrade von W2000 zum > W2000A. Entweder bin ich zu doof, ich finde das nicht. Hast du einen Link dafür? Gruß Michael
Nabend Michael, hier der Link : http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade dort steht eigentlich fast alles, außer die Bedienung der Quartus Programmer. Gruß, Martin
Martin H. schrieb: > Nabend Michael, nabend Martin, > > hier der Link : > > http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade > den kenne ich ja schon... > dort steht eigentlich fast alles, außer die Bedienung der Quartus > Programmer. Ja, eben. Wie ich das Leon in das RAM bekomme, weiß ich ja. Nur wie die Soft bzw. FW per Quatus über USB ins Flash kriege, wäre eine Hilfestellung sehr hilfreich, bevor man Mist baut. Könntest du vielleicht eine kurze Anleitung dazu geben, vielleicht mit ein paar Pics? Also z.B. Quartusoberfläche, welche Häkchen gesetzt werden müssen, etc. Die Installation vom Blaster usw. kann aussen vor bleiben, steht ja zu genüge, unter Anderem auch von mir, hier im Thread! Es wäre auch für die anderen User, vorallem "Hayo", von Interesse! Da es sehr oft in der Vergangenheit, Probleme mit der RS232 gab und man eine Alternative zur Verfügung hätte. Gruß Michael
Nabend, Leider musste ich das auch durch testen herausfinden :) Aber hier die Liste: 1. Unter dem Installationspfad folgendes Programm Starten qprogrammer\bin\quartus_pgmw.exe Du solltest dann den Quartus 2 Programmer vor dir haben 2. In der linken oberen Ecke gibt es einen Button "Hardware Setup" den anklicken und unter "Current selected Hardware" das Nios Dev Board auswählen, dann auf close 3. Anschließend gehst du auf "Add File" und wählst die .jic Datei aus die du flashen möchtest, jetzt sollte in dem oberen Feld der FPGA und das Flash angezeigt werden 4. Hinter den neuen Daten gibt es nun Checkboxen, Programm und Verify, die aktivierst du nun, ausgegraute kannst du ignorieren. 5. Dann auf Start und abwarten bis oben nur noch 100 % und Sucessfull steht 6. Fertig :) Gruß, Martin
Martin H. schrieb: > Nabend, > > Leider musste ich das auch durch testen herausfinden :) Sonst wird's ja langweilig... ;-) > > Aber hier die Liste: > > 1. Unter dem Installationspfad folgendes Programm Starten > qprogrammer\bin\quartus_pgmw.exe > Du solltest dann den Quartus 2 Programmer vor dir haben Ist klar. > > 2. In der linken oberen Ecke gibt es einen Button "Hardware Setup" den > anklicken und unter "Current selected Hardware" das Nios Dev Board > auswählen, dann auf close Ist auch klar. > > 3. Anschließend gehst du auf "Add File" und wählst die .jic Datei aus > die du flashen möchtest, jetzt sollte in dem oberen Feld der FPGA und > das Flash angezeigt werden Und da hängts! Quartus frist ja nur: pof, sof, jam, jbc, ekp, usw. Woher bekommst du denn eine ".jic" ??? Konvertierst du voher die .flash, oder wie komst du dazu? Jetzt wird's spannend, solange bleibe ich noch wach. :-) > > 4. Hinter den neuen Daten gibt es nun Checkboxen, Programm und Verify, > die aktivierst du nun, ausgegraute kannst du ignorieren. Die Checkboxen gehen auch klar. Anzumerken wäre noch, das wenn "Auto-Detect" gedrückt ist, das dann das Device angezeigt wird, in unserem Fall wäre es: EP2C35 Soweit ich weiß, sollte das vorher aus dem Fenster entfernt werden. > > 5. Dann auf Start und abwarten bis oben nur noch 100 % und Sucessfull > steht So sollte es dann sein... > Gruß Michael
Guten Morgen Michael, ich war dann doch mal schlafen gegangen. das .jic File habe ich aus einem Backup das jemand mit dem Quartus Programmer gemacht hat. Bei dem Auto Detect wird der Flash Chip nicht mit erkannt, den muss man um ein Backup zu machen noch selbst hinzufügen. Wenn man allerdings ein fertiges .jic File hat weis er automatisch das dort ein Flash ist. Wie man nun aus den Flash Dumps ein .jic File baut weis ich leider nicht, ich arbeite auch erst seit 2 Wochen mit Quartus :) Es gibt im Sourceforge Forum einige Backups in dem Format. daher hatte ich meins auch. Gruß, Martin
Moin Martin, das Quartus ist schon sehr umfangreich, konnte es nicht lassen und habe das gestern noch mal unter die Lupe genommen. @Hayo Wäre auch für dich interessant, da kann man dem Altera bis in die Gedärme glotzen, wahrscheinlich auch unter Anderem zu reparaturzwecken. Bekommst du es mittlerweile zum laufen? Ich hatte mal die Möglichkeit mit dem Quartus das Flash zu konvertieren, ist leider beim Update und "Supergau" einer meiner Festplatten mit weg geflogen! Du weißt nicht zufällig welches Altera-Tool das war? Was heisst einige Backups? Ein Link dahin, wäre schick! Sind denn da auch die Aktuellen FW's ausgestellt? Gruß Michael
Ihr macht ja abgefahrene Sachen! Das muß ich bei Gelegenheit auch mal lernen, wenn's in Richtung FPGA geht. Könnt ihr dem Rest der Welt den Gefallen tun und ggf. die Anleitung im Wiki pflegen? Viele Dank Jörg
Guten Tag Jörg, Das kann ich gerne machen. Habe nur leider selbst erst ein begrenztes Wissen über das Thema. Gruß, Martin
@Andi Sorry, bin heute zu nichts gekommen - habe aber Deine Notlage nicht vergessen. Also zum Flaschen - wenn Du mit einem der Upload Tools geflasht hast kann Dein FPGA eigentlich nicht beschädigt sein. Das schafft man nur mit dem Altera Programmer. Dass das Rückspielen des Flash nicht gleich beim ersten Mal erfolgreich ist, ist auch nicht ungewöhnlich - ich hab mir das auch schon öfters zerschossen bei meinen Experimenten und dann erst nach einigen Anläufen wieder hingekriegt. Grundsätzlich kannst Du Backups aller Hardwareversionen einspielen um Dein Gerät wiederzubeleben. Wenn die Registereinstellungen dann nicht passen, kann es aber sein, dass Du Spikes auf dem Signal hast, das ist aber auch schon alles. Wenigstens läuft es dann wieder. Interessant wäre noch, ob es an Deinem seriellen Port liegen könnte. Hast Du die Möglichkeit das auf einem anderen Rechner zu probieren? Die Serielle kann da unter Umständen etwas bockig sein. Ich habe gerade eine Mail von Klaus erhalten der neu zu unserer Gemeinde gestoßen ist und sich anbietet ein Komplettbackup seiner 1C9 Version zur Verfügung zu stellen. Da hättest Du dann eine zweite Möglichkeit ein frisches Backup einzuspielen. Gruß Hayo
Angehängte Dateien:
Hallo Andreas. Ich habejetzt ein wenig mit dem Quartus-Programmer herum experimentiert. Dabei habe ich natürlich mein Welec quasi "abgeschossen", na toll... @Martin ...das war dein Original.jic Das Teil ist 2049kB groß, was ein Quartus-Dump ja auch ist, nur konnte ich danach nicht mehr die FW's aufspielen, da der Germsmonitor per Tasten, nicht mehr zu aktivieren war! :-((( Ebenfalls geht das auch nicht, wenn der Quartus-Programmer das DSO per USB in den Programmiermodus versetzt hat. Es lässt sich die RS232 nicht mehr ansprechen, keine Ahnung warum das so ist, vielleicht wird die dadurch blockiert?!? Eigentlich wollte ich ins Bett, hat mir aber keine Ruhe gelassen und das Teil wieder zum Leben erweckt! Also, Festplatte durchsucht und einen originalen Dump von meinem DSO (2009) im .jic Format gefunden, den ich damals mal gezogen hatte. Das Teil geladen, benötigte Haken gesetzt und in einer Minute war der Dump im Device EP2C35 mit EPCS16 . Anbei mal ein Shot Morgen Abend kann ich, wenn Interesse besteht, eine kurze Anleitung geben, wie man einen kompletten Dump mit dem Quartus-Programmer über USB zieht, hab's gerade heraus gefunden. ;-) Gruß Michael
Guten Tag, @Michael Entschuldige, ich wollte dir damit nur helfen. Das Backup konnte ich leider nie testen da ich ein 4 Kanal Oszi habe, und es für das 2-Kanal ist. Wenn ich dir bei der Anleitung helfen kann sag bescheid, ich war noch nicht dazu gekommen selbst eine zu schreiben. Irgendwo im Wiki habe ich glaube ich auch schon eine gesehen, es fehlten blos ein paar Punkte. Vielleicht sollten wir einfach mal eine Backup DB im Wiki machen, ich weis nur nicht ob es da rechtlich irgendwelche Bedenken gibt. Aber das Würde sicher einigen hier weiterhelfen. Gruß, Martin
Oh ja ;-) @Hayo, ich versuche gerade noch einmal das Backup mit einem anderen USB/RS232 Wandler (mit FTDI-Chip) einzuspielen. Wenn das nicht gelingt, wäre ich über die Backup-Alternative sehr begeistert. Die angezeigte Übertragungszeit ist mit diesem Wandler deutlich höher ... ca. 4000 Sekunden! Das Thema mit dem FPGA habe ich mir auch so gedacht. Kennst Du einen Fall wo die RS232 erreichbar (inkl.Loader) und die FPGA-FW nicht in Ordnung war? Danke erst einmal für das Mut machen ... wir hören uns nach der Einspielung ... Gruß Andi
@Hayo, nach 3000 Sekunden erfolglos ... Gruß Andi
Hallo, wie Hayo schon weiter oben beschrieben habe ich seit einer Woche auch ein W2024 bei Welecgmbh "geschossen". Nach kurzem Einschalten und an allen Knöpfen gedreht gleich mal ein Vollbackup gezogen und Hayos neuste SW (--.5.6C2) eingespielt - welch ein Unterschied. DANKE HAYO!!! Zur Zeit habe ich es wieder zerlegt und warte bis ich eine ruhige Hand habe um die 0603er SMDs (24,9 u. 150 Ohm) einzulöten. Fotos des Umbaus kommen später im HW-Thread. Bis dahin ein weiteres Vollbackup - vielleicht hilft es einigen. Daten: W2024A HW: 1C9.0E SW: 1.4 Bis dann Gruß Klaus
Um es noch mal deutlich zu sagen für alle die noch so mitlesen und überlegen ob sie die Open Source Firmware einspielen sollen: - Das original WELEC-Updateprogramm welches über USB die WELEC Firmware flasht, ist nicht geeignet für die OS-Firmware! - Das Hochladen der Open Source Firmware geschieht über die RS232-Schnittstelle und das mitgelieferte 1:1 RS232 Kabel. Als Uploadsoftware kann man den alten WELEC-Updater von Markus nehmen, dieser ist aber extrem langsam. Empfehlenswert ist die Installation von Perl und dem WIN32:Serial Port. Damit kann das beigelegte Perlsktipt verwendet werden, dass schnell und sicher arbeitet. Der Uploadvorgang wird immer eingeleitet durch das Aktivieren des GERMS-Monitors. Das geschieht durch das Drücken der beiden linken Funktionstasten (erst die ganz linke und halten, dann die zweite). Der Bildschirm leuchtet dann kurz weiß auf und wird dann schwarz. Wenn das nicht funktioniert ist etwas an der FPGA-Konfiguration nicht in Ordnung. Gruß Hayo
@Hayo, der 2. Versuch per Perl-Script mit dem vom Klaus freundlicherweise zur Verfügung gestellten Download war auch NICHT erfolgreich (per RS232!!!). Nach einem Neustart zuckt das Gerät überhaupt nicht. Es leuchtet die Hintergrundbeleuchtung und mehr nicht!!! Gruß Andreas
Das ist aber sehr ungewöhnlich. Ist die RS232 bei Dir in Ordnung? Welches Perl hast Du installiert? Hast Du evtl. mit dem Altera-Programmer vorher rumgespiuelt und dabei die FPGA-Konfiguration abgeschossen? Gruß Hayo
Erste Lebenszeichen ... Start der Version vom Klaus ... aber nur im geöffneten Zustand ohne Lüfter ohne sichtbare Darstellungsfehler und mit 4 Kanälen! So ein Mist ... also könnte es noch ein Hardwareproblem zusätzlich sein! ABER ... es sind die Eingänge mit sehr großen Signalen zu sehen bzw. füllen die Signale die komplette Bildschirmoberfläche! Leider hatte es wieder zusammengeschraubt um ein Foto zu machen ... aber nun startet das Gerät wieder nicht. @Hayo, Hättest Du eine Erklärung für diese Signaldarstellung? Gruß Andi
@Hayo, ich hatte noch KEINEN Altera am Gerät!!! Grüße Andi
Also nach Deinen Schilderungen ist ein Hardwareproblem nicht auszuschließen. Beliebt sind schlechte Lötverbindungen an den RAM Bausteinen. Diverse Berichte zu dem Thema sind im Hardwareforum zu finden. Die hartnäckige Weigerung Wiederbelebungsmaßnahmen anzunehmen könnte darauf hindeuten. Das Zusammentreffen mit dem Löschen des Flashs ist aber schon sehr ungewöhnlich. Wenn es vor dem Zusammenbau funktionierte und danach nicht mehr deutet das auf jeden Fall darauf hin, dass es nicht nur das Flash ist. Stecken alle Steckverbindungen richtig zusammen? Man kann da auch schnell um eine Pinreihe verrutschen ohne es zu merken. Andreas W. schrieb: > ich hatte noch KEINEN Altera am Gerät!!! Das ist die Windows Software zum Programmieren des FPGA und der Peripherie. Also kein externes Gerät. Aber dann sollte es irgendwie hinzukriegen sein. Man kann also davon ausgehen, dass das FPGA und die Peripherie in Ordnung sind. Als Erstes muß dann das Flash in einen stabilen Zustand gebracht werden. Dafür ist das Backup von Klaus sicher am Besten geignet. Alternativ kann ich auch noch Backups zur Verfügung stellen. Probiere doch mal Folgendes: - spiele das Backup von Klaus ein - dann das protected Flash von Rainer drüber - und zum Schluß die aktuelle Firmware So ähnlich bin ich bei meiner Kiste auch vorgegangen als sie nicht mehr wollte. Gruß Hayo
Hayo W. schrieb: > Also nach Deinen Schilderungen ist ein Hardwareproblem nicht > auszuschließen. Beliebt sind schlechte Lötverbindungen an den RAM > Bausteinen. Diverse Berichte zu dem Thema sind im Hardwareforum zu > finden. Ja, die habe ich mit einer Reflow-Lötstation nachbearbeitet ... > Wenn es vor dem Zusammenbau funktionierte und danach nicht mehr deutet > das auf jeden Fall darauf hin, dass es nicht nur das Flash ist. Stecken > alle Steckverbindungen richtig zusammen? Man kann da auch schnell um > eine Pinreihe verrutschen ohne es zu merken. Nee ... > Probiere doch mal Folgendes: > > - spiele das Backup von Klaus ein > - dann das protected Flash von Rainer drüber > - und zum Schluß die aktuelle Firmware erledigt ... ohne Erfolg ... Alle Spannungen im Oszi nachgemessen ... i.O. Gruß
Hallo Andreas, mein Oszi ist seit kurzem auch tot und ich weiß biser auch noch nicht was das Problem ist. Die Geschichte: Oszi ging nicht mehr, Fehlersuche brachte einen defekten MAX1967(Step-Down Regler) und einen kaputten FDS-6990A (Doppen n-FET) zu Tage. Kein Problem: die Teile getauscht, Oszi startete wieder. Also habe ich es glücklich wieder zusammengebaut und seitdem geht nichts mehr. LCD Backlight leuchtet, Run/Stop Button leuchtet. Germsmonitor scheint sich starten zu lassen, jedenfalls lädt das Perl Script nach wie vor die Firmware runter. Die Spannungen habe ich bei mir auch nachgemessen. Dazu ein Zitat von mir aus nem anderen Thread (Beitrag "Re: Wittig- Oszi meldet sich nicht mehr"), in dem ich dazu gepostet habe: " Die Kernspannung des 1. FPGA liegt bei mir knapp unterhalb der zulässigen Untergrenze von 1,15V, beim zweiten messe ich sogar nur 1,07V. Gemessen direkt unter den FPGAs an den Abblockkondensatoren für den Kern. Hier wieder die Frage: hat jemand Vergleichswerte? Da es auf jeden Fall zu wenig ist, werde ich die Versorgung mal überarbeiten und sehen, was passiert. Dasselbe Problem ist übrigens auch bei den ADCs vorhanden: die digitale Versorgung liegt direkt an der Grenze des Erlaubten (die werden direkt aus dem 1.8V Schaltregler versorgt, der eine halbe Meile weit entfernt sitzt...). Eventuell könnte das bei den Vierkanalgeräten die Probleme auf Kanal 3/4 verursachen, würde mich jedenfalls nicht wundern. " Sind deine Kernspannungen auch zu niedrig? Gerade wollte ich mein Original Dump File ins Oszi laden. Leider scheint das nicht zu klappen, der Welec Updater erkennt weder Seriennummer noch Hardware Revision des Gerätes. Wer ist so nett und sagt mir, wo die Daten hinterlegt sind? Im Protected Flash Bereich? Welches IC? Im Logfile trägt das Programm in endloser Folge ein: "14.03.2012 18:21:34 : Step : 0/67516 Timer redo the step" Falls irgendjemand Ideen zur Reanimierung hat: hier habt ihr einen dankbaren Empfänger! Wie ist eigentlich der Germsmonitor realisiert? Soweit ich weiß ist er ja unabhängig vom Nios, wer kann mir mehr dazu sagen? Gruß Michael
Hallo Leidensgenosse ... Michael H. schrieb: > Hallo Andreas, > mein Oszi ist seit kurzem auch tot und ich weiß biser auch noch nicht > was das Problem ist. Die Geschichte: Oszi ging nicht mehr, Fehlersuche > brachte einen defekten MAX1967(Step-Down Regler) und einen kaputten > FDS-6990A (Doppen n-FET) zu Tage. Kein Problem: die Teile getauscht, > Oszi startete wieder. Also habe ich es glücklich wieder zusammengebaut > und seitdem geht nichts mehr.LCD Backlight leuchtet, Run/Stop Button > leuchtet. ... genau wie bei mir!!! Germsmonitor scheint sich starten zu lassen, jedenfalls lädt > das Perl Script nach wie vor die Firmware runter. ... genau wie bei mir!!! > Die Spannungen habe ich bei mir auch nachgemessen. Dazu ein Zitat von > mir aus nem anderen Thread > (Beitrag "Re: Wittig- Oszi meldet sich nicht mehr"), in > dem ich dazu gepostet habe: > > " > Die Kernspannung des > 1. FPGA liegt bei mir knapp unterhalb der zulässigen Untergrenze von > 1,15V, beim zweiten messe ich sogar nur 1,07V. Gemessen direkt unter den > FPGAs an den Abblockkondensatoren für den Kern. Hier wieder die Frage: > hat jemand Vergleichswerte? Da es auf jeden Fall zu wenig ist, werde ich > die Versorgung mal überarbeiten und sehen, was passiert. Dasselbe > Problem ist übrigens auch bei den ADCs vorhanden: die digitale > Versorgung liegt direkt an der Grenze des Erlaubten (die werden direkt > aus dem 1.8V Schaltregler versorgt, der eine halbe Meile weit entfernt > sitzt...). Eventuell könnte das bei den Vierkanalgeräten die Probleme > auf Kanal 3/4 verursachen, würde mich jedenfalls nicht wundern. > " > > Sind deine Kernspannungen auch zu niedrig? Ich werde die auch mal an der FPGA messen! > Gerade wollte ich mein Original Dump File ins Oszi laden. Leider scheint > das nicht zu klappen, der Welec Updater erkennt weder Seriennummer noch > Hardware Revision des Gerätes. Wer ist so nett und sagt mir, wo die > Daten hinterlegt sind? Im Protected Flash Bereich? Welches IC? > Im Logfile trägt das Programm in endloser Folge ein: > "14.03.2012 18:21:34 : Step : 0/67516 Timer redo the step" Nee das geht nicht mehr mit dem originalen FW-Loader von Welec. Bitte mal die Anleitung in Hayo's aktueller Flash-Version und "Doc" nutzen. Dort ist der alternative Welec-Updater beschrieben. Viel besser und schneller läuft das Perl-Script. Siehe ... [[http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload]] > Falls irgendjemand Ideen zur Reanimierung hat: hier habt ihr einen > dankbaren Empfänger! Wie ist eigentlich der Germsmonitor realisiert? > Soweit ich weiß ist er ja unabhängig vom Nios, wer kann mir mehr dazu > sagen? > > Gruß > Michael Gruß Andi
@Hayo, da ich ja nun nichts mehr so direkt falsch machen kann, würde ich noch einmal ein komplettes Backup von Dir nutzen wollen. Wäre das OK? So jetzt versuche ich es erst einmal mit dem Selbstheilungseffekt ;-) Gruß Andi
Den Germsloader kenne ich, irgendwie hatte ich wohl das irrationale Bedürfnis, das Backup mit dem Welec Tool zu flashen... Vorhin habe ich versucht, ein Backup hier aus dem Forum zu flashen. Der Flashvorgang lief erfolgreich durch aber es hat sich nichts geändert. Mistding. Morgen löte ich mal das Flash nach, vielleicht liegts ja daran - optisch sieht die Lötung aber gut aus. Wenn das nichts bringt (wovon ich ausgehe) was dann? Zunächst müssen ja die FPGAs konfiguriert werden, danach kann der NIOS seine Firmware aus dem Flash laden. Man müsste also einen Weg finden, zu bestätigen, dass die FPGAs korrekt konfiguriert werden, um das Problem auf den NIOS einzugrenzen. Wenn der Flashspeicher des Nios das Problem ist, könnte man den ja auch tauschen...nur wüsste ich nicht warum er so plötzlich gestorben sein sollte. Hast du schon versucht, ob du den Flashinhalt korrekt zurücklesen kannst? Meine Kiste ist gerade in sämtliche Einzelteile zerlegt, darum kann ich es selbst momentan nicht testen. Gruß Michael
@Michael, ich hatte den Inhalt auszugsweise mal zurückgespielt. Der Inhalt war gleich ... Welche Hardwareversion ist Dein Modell? Welches Modell hast Du (wenn ich richtig gelesen habe einen 4-Kanal)? Gruß Andi
Ich lade mal ein Backup von mir hoch, dauert aber ein wenig...
Hm. Wenn der Inhalt des Flashs korrekt ist, dann müsste der Nios ja laufen...der NIOS selbst verwendet ja keine externen RAMs, richtig? Insofern müsste dann ja etwas an der FPGA Konfiguration schiefgehen oder es gibt ein Lötproblem an den FPGAs. Siehst jemand andere sinnvolle Ansatzpunkte? Vielleicht schaffe ich es am Wochenende mal, eine Version des LEON Designs zu testen...so sollte sich doch herausfinden lassen, ob die FPGAs das tun was sie sollen. So oder so werde ich aber auch die 1.2V Versorgung erneuern. Gruß Michael
Achso, mein Oszi ist ein W2024A, die Hardwarerevision kann ich dir leider nicht nennen oder steht die auch irgendwo auf der Hardware? Michael
Das ist von meinem 4 Kanaler ein Komplettdump mit der originalen Firmware 1.4 - ich benutze das immer wenn ich mal wieder sehen möchte was wir so geschafft haben. Man weiß ja schon gar nicht mehr was für Entbehrungen man früher auf sich genommen hat... :-) Wenn das bei Dir läuft brauchst Du nur den Protected Dump von Rainer drüberzubügeln, dann ist alles wieder im Originalzustand. Drücke die Daumen Hayo
Um sicher zu gehen habe ich den Dump mal eben bei mir eingespielt. Erschreckend! So langsam und sooo schlecht hatte ich das gar nicht mehr in Erinnerung. Erschütternd... Aber zum Upload. Also das funktionierte sofort. Der Upload dauerte 411 Sekunden mit dem alten Perlskript 1.1.2 und das Gerät startete nach einem Reset sofort ohne Probleme. Der Dump ist also in Ordnung. Gruß Hayo
Was noch von Interesse wäre - wenn das Gerät angeschaltet wird, gibt es da auf dem Terminal Meldungen aus? wenn ja welche -> bitte posten! Gruß Hayo
Hallo Hayo, ich werde dein Dump mal testen, danke dafür. Muss ich dafür dem Perlscript besondere Parameter übergeben (Adressbereich o.ä.)? Auf der seriellen tut sich beim Booten gar nichts, nur wenn man den Germsmonitor startet gibt es ein paar kümmerliche Lebenszeichen wie im anderen Thread von Rudolf und mir beschrieben. Schätze bei Andreas wird es das selbe sein... Gruß Michael
Nein, keine Parameter nötig. Die Adressen ergeben sich aus dem Inhalt des Dumps automatisch. Einfach die Batchdatei die Du sonst für den Upload benutzt auf den Dateinamen des Dumps anpassen und fertig. Hayo
@Hayo, ja auch bei mir wird nichts im Terminalmodus übergeben (beim normalen Start). Starte ich den GERMS-Modus kommt +C CPU3048 ... Ich spiele jetzt mal Dein Update ein ... mal sehen. Gruß
@Hayo FW = 5.6C2 hab noch einen fehler gefunden, versuch mal: X=2ns nur Ch1 aktiv und dann dreh mal Y nach unten, ganz viel, oder nach oben ganz viel, oben kommt mann dann gar nicht mehr raus ;( i hoff i hab das nachvollziehbar erklaert... vlG Charly ps. koennen die anderen Mitleser es event. auch mal versuchen nitt das es bei mir ein 'dummy' fehler ist
@Hayo, Michael, ich muss mich verbessern - im Germsmodus ist nun nichts mehr zu sehen (Flash kann ich aber noch laden). Das war mal ... scheint schon länger her zu sein. Ich hatte mir diese Meldung mal aufgeschrieben. Gruß
Hallo, ich habe Hayos Dump gerade geflasht - nach wie vor kein Mucks von der Kiste. D.h. bei Andreas wird es nicht anders aussehen. Flash habe ich heute nachgelötet, natürlich auch hier keine Änderung. Auch sonst kann ich noch keine Probleme an der Hardware finden, abgesehen von der wie erwähnt zu niedrigen Kernspannung der FPGAs. Wenn nur endlich die Post mein Zeug bringen würde, dann könnte ich das endlich umbauen und entweder jubeln oder wieder einen Punkt abhaken. Danach werde ich mir dann mal die FPGAs vornehmen, dann sehen wir mal weiter. Gruß Michael
Ich möchte mich jetzt mal daran machen, das FPGA Config Flash auszulesen, mal sehen ob das klappt. Falls ich es auslesen kann, würde sich jemand finden, der meine Datei mit seinem Readout vergleicht? Oder hat jemand ein Dump seines W2024A Config Flashs zur Hand, das ich testweise reinladen könnte? Schonmal danke für eure Hilfe! Michael
Bei meinem Dump war auch Config und Protected Config dabei. Ist zwar für 8C7, aber laufen tun die 1C9 auch damit. Haben nur einige Spikes auf dem Signal. Wenn ich das richtig verstanden habe habt Ihr aber eigentlich unterschiedliche Probleme oder? Andi -> Irgendwie das Flash zerschossen und beim Auseinandernehmen irgendwas ausgelöst. Stronzo -> mit dem Altera Programmer was weggeschossen... Richtig? Gruß Hayo
Hallo Hayo, den Altera habe ich noch nie verwendet. Bei mir ist ein Teil des Schaltnetzteiles gestorben (warum weiß wohl nur Wittig), nach Tausch der defekten Teile lief die Kiste in offenem Zustand aber nach Zusammenbau nicht mehr. Die Vorgeschichte ist also eine andere als bei Andreas, aber die Symptome sind komplett identisch. Bei Rudolf ebenfalls exakt die gleiche Situation. Gruß Michael
Ach so, dann hatte ich die Posts über den Altera Programmer wohl mißverstanden. Aber dann ist das Problem doch zumindest eher einschätzbar. Ich komme da noch mal auf die Pfostenleiste zurück die das Netzteil mit dem Mainboard verbindet. Da kann man beim Zusammenbau leicht um einen Pin oder eine Reihe verrutschen, was u.U. den Defekt von Teilen im Netzteil und oder dem Mainboard zur Folge haben kann. Gruß Hayo
Angehängte Dateien:
-
WriteRead_Diff.JPG
76 KB
@Hayo leider muss ich Dich enttäuschen - der Flashspeicher ist in Ordnung. Ich habe das komplette Programm geladen, Oszi ausgeschalten und Flash komplett gelesen. Der einzige Unterschied lag wie erwartet in der Datumszeile ... siehe Bild. Als nächstes versuche ich mal einen Speichertest durchzuführen. Hattes Du evtl. schon mal ein kleines Programm geschrieben??? Das wäre jetzt sehr hilfreich. Alternativ werde ich über den Germsloader auch den Speicher (RAM) beschreiben und gleich wieder lesen ... mal sehen was da raus kommt. Gruß Andi
@Hayo haste das mal versucht: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" oder ist es hier 'untergegangen' ? vlG Charly
@Andii Jörg hat glaube ich für das OSOZ-Projekt einige kleine Testroutinen geschrieben die man dafür mißbrauchen könnte. Am besten Jörg direkt drauf ansprechen da er hier den besseren Überblick hat. Damit kann man gezielt bestimmte Funktionen des Oszis ansteuern. Notfalls kann ich das auch raussuchen, das dauert aber etwas weil ich momentan kaum Zeit habe. @Charly Nein ist nicht untergegangen. In der neuen Version die ich gleich rausgebe (mit neuem Treiber) konnte ich das nicht mehr feststellen. Gruß Hayo
Da ich momentan nicht viel zum Programmieren komme, hier der aktuelle Stand in Sachen ADC-Treiber. Ich habe den ADC-Treiber neu handoptimiert in Assembler geschrieben. Er läuft jetzt stabil und schnell. Im Gegensatz zum ultraschnellen Quick and Dirty Treiber hat der Assembler Treiber Overflow Protection und Limiter für den oberen und unteren Grenzwert. Neu ist ebenfalls, dass ich das Invertieren und Averaging wieder in den ADC-Treiber zurückverlegt habe allerdings optimiert in Assembler und dadurch richtig schnell. Der Averaging Mode wurde auch noch von der Wirkung her verbessert. Der Standard C-Code Treiber und der Quick and Dirty Treiber stehen momentan nicht zur Verfügung, da beide den Averaging Mode noch nicht unterstützen - kommt aber noch. Ansonsten habe ich noch einige Kleinigkeiten aus dem OSOZ-Projekt übernommen. Gruß Hayo p.s. Die Assembler Treiberroutinen werde ich bei nächster Gelegenheit bei OSOZ einpflegen, bin nur momentan noch nicht dazu gekommen. Download auch hier: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/
Hayo W. schrieb: > Jörg hat glaube ich für das OSOZ-Projekt einige kleine Testroutinen > geschrieben die man dafür mißbrauchen könnte. Am besten Jörg direkt > drauf ansprechen da er hier den besseren Überblick hat. Einen Speichertest habe ich nicht im Programm. "Man" könnte einen schreiben, aber soo einfach ist das nicht. Das Programm steht ja normalerweise auch im RAM, sowie der Stack und die Interruptvektoren. Entweder man testet nur einen freien Bereich, oder das Programm muß sich umlagern (Stack?) oder es ist ein kleines Assemblerprogramm ohne Stack und Variablen, was rein im Flash läuft. Ich glaube ehrlich gesagt nicht, daß das RAM das Problem ist. So aus dem Bauch raus, weil ich bisher viel zu wenig Ramdefekte gesehen habe. Hayo W. schrieb: > hier der aktuelle > Stand in Sachen ADC-Treiber. Ich habe den ADC-Treiber neu handoptimiert > in Assembler geschrieben. Er läuft jetzt stabil und schnell. Könnte noch schneller laufen. ;-) Ich habe bisher nur flüchtig draufgeschaut, mir fiel auf daß du die Delay Slots nicht nutzt, da steht immer(?) ein NOP drin. Noch ein Trick: wenn's geht (meist geht's leider nicht) zwischen einen Ladebefehl und die Verwendung des geladenen Registers einen unabhängigen Befehl packen. Dann kann die CPU den während des Ladens ausführen, ansonsten gibt es hier einen Pipeline Stall. Das Alignment des Codes im Speicher kann auch eine Rolle spielen. Es passen ja immer 2 Befehle in ein 32-Bit Speicherwort, die CPU muß also nur für jeden 2. einen Buszyklus machen. Dann sind mir die vielen Sign Extends aufgefallen. Die ADCs können wir mit einer SPI-Leitung umschalten, ob sie ihr Ergebnis als signed oder unsigned ausgeben sollen. Vielleicht ist die andere Betriebsart für die Numerik besser? Vielleicht verwirren wir dann das FPGA aber vollends, weil es auch bereits damit rumrechnet und den Triggerpegel überwacht? Jörg
Guten Abend Hayo und alle. @Hayo Hayo, danke für die neue Version 1.2.BF.5.7!!!!!!! Now I am in a bit of a hurry, so quickly only a pair of things: 1)I upgraded both my W2022A and W2012A, the first one works great while the second show abnormal noise on CH1 expecially on 5uS and 50nS range of the Time Base. 2)Performing Calibrate Offset procedures on W2012A, which shows noisy on the CH1, fails. Instead all it is OK with the W2022A which works like a charm. I tried both STANDARD and ASSEMBLER of the ADC configuration but nothing changes. (W2012A number 09850712C9, hardware 8C7.0B purchased on December 20, 2009 and W2022A number 78002031D0, hardware 8C7.0C purchased on January 15, 2010) As always this report is only for knowledge and no as criticism Going to ahead, quick glance to the new AVERAGE implementation, seems to me it works really well, as always really impressive, I have no words!: thank You Hayo. The rest will follow, see you later. ;-) Vielen Dank! Mit freundlichen Grüßen, Luc
So, grad erst wieder zuhause aufgeschlagen. Bevor ich abtauche und die Matratze abhorche noch kurze Antworten. @Jörg Ich hatte schon vermutet, dass da noch nicht das Ende der Fahnenstange erreicht ist. Die Delay Slots hatte ich bislang unbenutzt gelassen da mir da keine gute Idee kam wie ich das nutzen könnte. Das Optimierungspotential ist wohl nur noch minimal denke ich. Die übelsten Designfehler unseres Welec-Programmierers habe ich jedenfalls beseitigt bzw. beim Neudesign weiträumig umfahren :-). Vielleicht läßt sich da ja noch mit einigen Tricks was rausquetschen. Quetschwillige sind herzlich eimgeladen... ;-) Ich habe der Übersichtlichkeits halber und weil mehr als 6 Übergabeparameter etwas aufwändig sind, die Funktionen in kleine Einzelfunktionen aufgespalten. Soll ich das so mal bei Gelegenheit bei OSOZ einpflegen? Wenn Du da Optimierungsideen hast kannst Du das ja dann noch nachtunen bzw. rausschmeißen was nicht so optimal ist. @Luc Hi there, thanks again for reporting. I can't imagine why there is the noise on Your Device. On my DSOs I had no problems. Nevertheless I will check it and try to solve it. Regards/Grüße Hayo
Angehängte Dateien:
Guten Abend Hayo und alle. Hayo W. schrieb: >Hi there, thanks again for reporting. I can't imagine why there is the >noise on Your Device. Hayo, vielen Dank für Ihr Zinsen. Perhaps I have a suspicion about this strange behaviour. I upgraded the W2012A and since the beginning the traces on the screen were abnormally noisy. Then I performed Default Setup and only the CH1 was noisy, CH2 was as usual. Immediately after when I was in the Utility menu I seen all related records setted to default, I had to reset them as well as display setting (background colours, graticule and so). Playing a bit around I noticed that although the W2012A was correctly warmed up, Calibrate Offset procedures fail when performed on it. Accidentally I went in the SAVE/RECALL menu and I recalled some memories (strangely the memories 1,2 and 3 were not empty, seems to me they still contain the waveforms I had memorized before the upgrade, though I had filled more than three memory), at this point CH1 took the usual form and the abnormal noise is gone! So I tried to perform Default Setup noting that some parameters (as CH delay setting for example) were changed it taking the values previously stored in the DSO. I performed the Default Setup in order to follow it with Calibrate Offset and CH1 turn noisy again! Perhaps a memory conflict issue? It is from a little time that I wanted to ask a question because often when I run the Default Setup then the entries in the Hardware menu do not return to default setting but remain as setted before, so: is this behavior correct? And performing Default Setup then are the memories in SAVE/RECALL erased? As I already wrote time ago I happen to have problems recalling the waveforms stored in the DSO but not for hardware problem: happens the same way on the W2022A and W2012A and returning to a old firmware release the problem disappears, so for me it is not an hardware problem (defective RAM for example). Hayo W. schrieb: >On my DSOs I had no problems. Of course, also my W2022A do not shows any problem: Calibrate Offset works and no abnormal noise on any channel. Maybe it is really a memory conflict issue, this explain why it is random depending it from the memory usage. Hayo W. schrieb: >Nevertheless I will check it and try to solve it. Thank You very much Hayo! I know this is a hard job due to the randomly nature of the problem. For now I fix downgrading the DSO to an old firmware release, so no problem, however even with older firmware DSO works much better than with the original Welec/Wittig firmware! With a similar philosophy I have overcome the spikes simply setting Pretrigger Left Edge: they are still there but are hidden. ;-) Vielen Dank! Mit freundlichen Grüßen, Luc
Hi Luc, please try this special version I made for You. It would be interesting to see if the noise disappears. Please make a default setup, change to the assembler driver and calibrate the device. I'm tight awaiting Your report Hayo
Hayo W. schrieb: > Soll ich das so mal bei Gelegenheit bei > OSOZ einpflegen? Wenn Du da Optimierungsideen hast kannst Du das ja dann > noch nachtunen bzw. rausschmeißen was nicht so optimal ist. Klar, gern! Osoz braucht von Grund auf einen Treiber für Capture+Trigger, da muß also auch noch die API definiert werden. Was ganz anderes: Es gab hier so Diskussionen um FPGA-Uploads. Haben wir das Wissen und die Mittel beisammen, um zwischen FPGA-Versionen hin- und herzuflashen? Wenn ja, kann mir mal jemand erklären wie? Wie fertigt man einen Dump vom Bitstream-Flash an? Ich habe Hardware-Version "8C7.0E". Laut Sourcecode ist vor dem Punkt die FPGA-Version, dahinter zwei aus dem Flash gelesene Ziffern des Produktionsloses. Laut Wiki-Tabelle gibt es nur 2 FPGA-Versionen, "meine" 8C7 und die 1C9. Welche Hardware ist denn die neueste/bessere? Ich würde z.B. gern mal ausprobieren, wie sich die ominösen User-Instructions mit anderer Hardware verhalten, ob da vielleicht schon mehr drin ist. Wer kann einen Dump von der 1C9 bereitstellen? Jörg
Hallo Jörg, du musst den FPGA nicht flashen, sondern kannst seine Konfiguration direkt in ihn laden. Nach dem Ausschalten ist dann alles wie vorher. Zunächst muss mittels USB der EasyUSB mit slogs Firmware zum Altera- Developement-Board umgewandelt werden. Das geht temporär (RAM) oder endgültig ins EEPROM. Die FPGA-Konfiguration kann wohl nur mit der Quartus-Software von Altera aufgespielt werden. Ich habe es mal mit urjtag probiert, bin da aber nicht sehr weit gekommen (FPGA wurde erkannt). Gruß, Guido
Angehängte Dateien:
-
Quartus.jpg
130 KB
@Jörg, da ich nun so hilflos war, hab ich mich auch mit dem EPCS16 beschäftigen müssen und wollen. Tatkräftig stand mir Michael (mike0815) zur Verfügung. 1. Quartus installieren 2. Wenn der Treiber installiert ist ... http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster Schau zusätzlich mal in den Eintrag vom Michael bezüglich vollständigen Treiber... Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" 3. Die Brücke geschlossen ist ... (Derzeit kann ich nur für die W2024A User sprechen) ... siehe Bild auf dem Link vorher im Kapitel "Notes for Welec 20X4 users" 4. "Auto Detect" im Quartus drücken ... sollte einen EP2C35 anzeigen! 5. Der folgenden Anleitung folgen ... http://sourceforge.net/apps/trac/welecw2000a/wiki/FPGAConfigFlash siehe angehangenes Bild ... FERTIG Ich habe mal meinen Dump angehangen. Was mich wundert ist die Checksumme die kein anderes Gerät unter ... http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument ... aufzeigt. Diese lautet: 071612A5 Ob dieser Dump funktioniert kann ich leider nicht sagen, da mein Gerät mich nicht ansehen will ;-) Welches Gerät hast Du? Kannst Du Deinen Dump danach auch mal zur Verfügung stellen? @All Hat jemand mit einem 4-kanaligen Gerät auch mal mit dem Quartus versucht einen Dump zu erstellen??? Seht Ihr 2 EP2C35??? Es sind ja auch 2 Stück bei dem W2024A verbaut ... Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ... Gruß Andi
Hayo W. schrieb: > Hi Luc, > > please try this special version I made for You. It would be interesting > to see if the noise disappears. Hi Hayo, Hi Luc, I had the same problem and this 5.7_Luc version is much more better with respect to the noise. Thanks, Jürgen
ich habe nochmal eine Frage zu einem anderem Thema.Die Übertragung für die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas optimieren? Was ist der Unterscheid zw. BMP und PPM da sich von der Dateigröße nichts ändert.
Ach ja, der Hayo ist daran schuld! ;-) Da hat er sich doch einfach mit einem #define TRIG_ALT zwischen die anderen, älteren Definitionen gedrängt und vergessen diese verschobenen Definitionen im Code entsprechend zu korrigieren. Und siehe da, schon geht die Triggerverstellung für den externen Trigger nicht mehr (z.B. siehe On-Trigger_Level()). Gruß Jürgen
@Andi Mein Kumpel hat unter anderem ein 2024A (wenn ich das richtig in Erinnerung habe). Notfalls könnte ich da mal anfragen, kann aber etwas dauern. Ich selbst habe ein 2014A. Die FPGAs und die Peripherie sollten eigentlich identisch sein, der einzige Unterschied scheint da die selektion der Analogbauteile zu sein die in einer etwas beseren Bandbreite resultiert. Meine Versuche mit Quartus verliefen aber aus irgendeinem Grund erfolglos. Im nachherein bin ich mir nicht ganz sicher mit welchem Gerät ich das versucht hatte. Möglicherweise hatte ich das 2014A verwendet und da aber keine Brücke eingesetzt - was dann den Mißerfolg wohl erklären würde. @Jürgen (+ Luc) > I had the same problem and this 5.7_Luc version is much more better So this confirmed my suspicion what the problem could be. I changed the ADC-Offset format from unsigned to signed to be able to shift the offset compensation into negative range. But this seems not to work in all cases (I think depending on the offset values). So I will return to the old unsigned format in the next version (as in this "Luc-Version"). All with the same problem I would recommend to use this version until I can provide a corrected Version. Hayo
Jürgen schrieb: > Ach ja, der Hayo ist daran schuld! Oh, wo hab ich da was verbockt? Das Define ist relativ neu, stimmt. Wo hatte ich da vergessen das zu ergänzen? Gruß Hayo
@Hayo > Möglicherweise hatte ich das > 2014A verwendet und da aber keine Brücke eingesetzt - was dann den > Mißerfolg wohl erklären würde. ja ohne der Brücke konnte ich keinen FPGA entdecken (per Quartus). Diese war bei mir ein muss ... Gruß
@Jürgen Ok hab's schon, wie konnte ich das übersehen ;-) - danke für den Hinweis. Hab zwar eigentlich keine Zeit, aber dann hau ich gleich noch eine Korrektur raus, kann man ja so nicht lassen... @Andi Dann müßte das mit dem 2022A aber ja ohne Brücke funktionieren. Muß wohl noch mal ran da. Hayo
Thomas O. schrieb: > Die Übertragung für > die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung > eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas > optimieren? evtl. ja, allerdings sind die Anforderungen bei der Bildkomprimierrung anders als bei normalen Daten. Der verwendete Lauflängenalgorithmus ist auch nicht unbedingt das Ende der Fahnenstange. > Was ist der Unterscheid zw. BMP und PPM da sich von der Dateigröße > nichts ändert. Die Reihenfolge in der die Werte in der Datei abgelegt werden ist bei den beidemn Formaten genau entgegengesetzt. Ansonsten sind sie identisch. Findet man per Googlesuche im Wiki. Hayo
ok die beiden Formate sind anscheinend am einfachsten zu programmieren. Oder haben wir hier jemanden der sich mit soetwas auskennt und für PNG etwas schreiben kann, bei der geringen Farbpalette wäre das sehr platzsparend und würde das Übertragen aufgrund der geringen Datenmenge extrem verkürzen.
Ich muß zugeben, dass ich mich da erst einarbeiten müßte. Wenn sich da jemand auskennt ist er herzlich eingeladen sich einzubringen. Gruß Hayo
Ok, hier die Korrektur. Dran denken, neue Kalibrierung durchführen! Gruß Hayo
Hayo W. schrieb: > Ok, hier die Korrektur. Danke, aber ich hoffe Du hattest wirklich keine Zeit und hast nicht inzwischen weitere Änderungen an den Dateien eingebracht :-) Ich habe mal alle TRIG-#defines von 137 bis 143 eingepflegt und hoffe, ich habe alle "erwischt". Hier die Dateien die ich geändert habe. Kannst sie ja nochmal gegen 5.7C2 vergleichen, um zu sehen was sich geändert hat. Wie kann ich vom S-Record "tomcat.flash" die "tomcat.ucl" erzeugen? Ich will nach der ext.Trig Hardware-Mod. nach Jörg an meinen Oszis noch mal die Pegel nachmessen und denke, daß da noch beim Umschalten zum Linetrigger ein bestimmter PWM-Wert gesetzt werden muss. Gruß Jürgen
Andreas W. schrieb: > Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ... Bitteschön! Ich hoffe, auch dieses Format lässt sich programmieren.. Ist schon zu lange her. Jedenfalls habe ich es so abgezogen. Gruß Jürgen
Guten Abend Hayo, Jürgen an und alle Unterstützer des Projekts Welec! Hayo W. schrieb: >please try this special version I made for You. It would be interesting >to see if the noise disappears. Hayo Bitte entschuldigen Sie mich für meine Verspätung. Oh, I really have no words, thank You very much for the aid: klasse! Und dann, was eine große Ehre für mich, meinen Nick-Namen auf dem Startbildschirm haben: Hayo du bist wirklich klasse!!!!!!! Es ist eine Ehre, die ich nicht verdient, jedoch dank Hayo! Hayo W. schrieb: >Please make a default setup, change to the assembler driver and >calibrate the device. Hayo as usual You are right! I followed your instructions and now the abnormal noise is gone on all the Time Base's range, I think even that noise in general has fallen, but I might confuse me although I do not think so. However everything is OK now, repeat I am speechless, I have no words: RESPECT and KLASSE!!!!!!! Only one question Hayo, You wrote "change to the assembler driver" but only that entry is present in the menu, the other two are deactivated (grey): this is not a real problem but rather a my curiosity Hayo W. schrieb: >I'm tight awaiting Your report Hayo thanks You very much for the free time You provided generously to me (us) and for this new great firmware's improvement!!! Very impressive and fast work, no words, Hayo You are the best one, the big one, the number one!: KLASSE!!!!!!! Hayo as usual You are very kind, many thanks for your help. I really much regret for the workload that You had to play to fix my problem and I am very sorry for the time that You lost to fulfill it, thank You very, very much Hayo!: KLASSE. Jürgen schrieb: >I had the same problem and this 5.7_Luc version is much more better with >respect to the noise. Guten Abend Jürgen und danke für eure Hilfe. You have been faster than me but I also confirm that with the new 1.2.BF.5.7_Luc firmware the problems about abnormal noise disappear. So thank You Hayo! Ah, hätte ich fast vergessen, Und natürlich vielen Dank Jurgen für Ihre Anregung in Bezug auf den TRIGGER! Hayo W. schrieb: >[1.2.BF.5.7C2] >Ok, hier die Korrektur. >Dran denken, neue Kalibrierung durchführen! Oh boys, Hayo You are too fast then I'll try to be I too, so I immediately run to try this new firmware version. Thank You again Hayo: RESPECT and KLASSE!!!!!!! Keep in touch! ;-) Jürgen schrieb: >[geaenderte_src_5.7c2] and [my_w2024A] >Hier die Dateien die ich geändert habe. Kannst sie ja nochmal gegen >5.7C2 vergleichen, um zu sehen was sich geändert hat. Jürgen, Danke nochmal für die praktische Hilfe: KLASSE!!!!!!! Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Guten Abend Hayo an und alle Unterstützer des Projekts Welec! Hayo W. schrieb: >[1.2.BF.5.7C2] >Ok, hier die Korrektur. >Dran denken, neue Kalibrierung durchführen! Schnell. I just tried the new 1.2.BF.5.7C2 version and seems to me as regards the noise it works even better than the previous 1.2.BF.5.7_Luc version! Now for me it is perfect and my W2012A works like a charm, as usual I have no words: KLASSE!!!!!!! I play it a bit 'and then report back on it. For now, once again many thanks Hayo! Keep in touch! Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Oh, viel los, ich schreibe mal eine Sammelantwort: Andreas W. schrieb: > Hat jemand mit einem 4-kanaligen Gerät auch mal mit dem Quartus versucht > einen Dump zu erstellen??? Seht Ihr 2 EP2C35??? Es sind ja auch 2 Stück > bei dem W2024A verbaut ... > > Ich wäre über einen alternativen Dump für ein W2024A auch dankbar ... Ich habe ein W2024, ohne 'A'. Ist das auch interessant? Der Unterschied ist mir zugegeben nicht geläufig. Dank für den Bitstream. Ich versuche mal, deiner Beschreibung zu folgen. Hinter so harmlosen Halbsätzen wie "Quartus installieren" verbirgt sich bestimmt eine mehrstündige Aktion? Thomas O. schrieb: > ich habe nochmal eine Frage zu einem anderem Thema.Die Übertragung für > die Firmware geht ja jetzt richtig flott vonstatten, die Übertragung > eines Screenshots ist aber noch gemächlich, läßt sich hier och etwas > optimieren? Ohne draufgeschaut zu haben wie's jetzt gemacht wird kann ich noch nichts zu sagen, aber gefühlsmäßig vermutlich schon. Bildkompression ist (u.A.) mein Beruf, zu gegebener Zeit kann ich da mal ran. OK, nun habe ich draufgeschaut. Der Kompressor ist extrem primitiv, kann nur direkte Bytewiederholungen, kodiert sie recht ineffizient. Sowas wie LZO dürfte da mehr bringen. (Lauflängen)kodierung ist das eine, Prädiktion das andere. Wir könnten einen der Fax-Algorithmen ausprobieren. Im einfachen Falle jede Zeile mit der drüberliegenden verXodern. Das dürfte viel mehr Nullbytes erzeugen. Jürgen schrieb: > Ach ja, der Hayo ist daran schuld! ;-) > > Da hat er sich doch einfach mit einem #define TRIG_ALT zwischen die > anderen, älteren Definitionen gedrängt und vergessen diese verschobenen > Definitionen im Code entsprechend zu korrigieren. Der Jürgen erstaunt mich mitunter. Da haut der solche Dinger raus und kennt sich auf einmal mindestens so gut wie Hayo in der BF-Firmware aus. Jürgen, magst du vielleicht auch mal Osoz angucken? ;-) Jürgen schrieb: > Wie kann ich vom S-Record "tomcat.flash" die "tomcat.ucl" erzeugen? Das macht "heutzutage" der Build-Flow, das Makefile kümmert sich drum. Nachträglich zu Fuß ist das ziemlich blöd. Aber weil du gefragt hast: srec_cat TomCat.flash -Output bloat.bin -Binary dd if=bloat.bin of=loader.bin bs=1 skip=256K count=256 dd if=bloat.bin of=app.bin bs=8M skip=1 cat loader.bin app.bin > flash.bin uclpack --best --2e -b8000000 flash.bin TomCat_flash.ucl Die Tools "srec_cat" und "uclpack" brauchst du. Ersteres kommt aus dem Paket "srecord", letzteres von Oberhumer, hatte ich hier oder bei Osoz mal gepostet. Jörg
Angehängte Dateien:
-
Optokoppler_LTV814_2.png
3,7 KB
Jörg H. Super da sitzt ja der richtige Man an Board. .PNG wäre eine Überlegung wert ist Lizenzfrei und vielleicht gibts ja nen fertigen Quelltext zum implementieren. Für unseren Anwendungsfall ziehe ich das dem verlustbehaftetem .JPG absolut vor. Man beachte die Dateigröße.
Thomas O. schrieb: > .PNG wäre eine > Überlegung wert ist Lizenzfrei und vielleicht gibts ja nen fertigen > Quelltext zum implementieren. Für unseren Anwendungsfall ziehe ich das > dem verlustbehaftetem .JPG absolut vor. Man beachte die Dateigröße. Das ist Sache des PC-Programms. Diese komplexen Formate werden (hoffentlich) nie auf dem Scope erzeugt. Das Scope soll nur seine Bitplanes mit effizienter aber trotzdem schneller Kompression über die Leitung pusten. Auf dem PC werden dann die Bitplanes zusammengesetzt, die auf dem Scope fest eingestellten Farben und Z-Order berücksichtigt, und dann das zu speichernde Bildformat erzeugt. Für letzteres gibt es Bibliotheken. Jörg
und wie schätz du den möglichen Kompressionsfaktor ein, also im Vergleich zu den jetzigen 900 kBytes der BMP/PPM Bilder
Jörg H. schrieb: > Der Jürgen erstaunt mich mitunter. Da haut der solche Dinger raus und > kennt sich auf einmal mindestens so gut wie Hayo in der BF-Firmware aus. > Jürgen, magst du vielleicht auch mal Osoz angucken? ;-) Danke für die Blumen! Von dem "mindestens so gut auskennen" bin ich aber trotzdem weit entfernt! Aber ich habe mich erstens schon mal in die Geschichte externer Trigger und Pulse Width Trigger eingearbeitet und zweitens war die Änderung nun nicht so doll: Die Funktion Search in files im Editor ist Dein Freund! :-) Die Komprimierung schaue ich mir mal an, da seeehr hilfreich beim Testen. Ich bin aber meist unter Windof unterwegs... Gruß, Jürgen
Thomas, Du kriegst da was durcheinander. Die BMP/PPM Bilder werden so nicht über die Schnittstelle übertragen. Wie Jörg schon schrieb sind das nur die komprimierten Rohdaten, die auf dem PC wieder dekomprimiert werden und dann erst in das entsprechende Bildformat konvertiert werden. Das kann auch PNG oder JPG sein. Auf dem Oszi wird für die Kompression ein eigener Algorithmus verwendet. Den Kompressionsfaktor zeigt das Programm übrigens beim Erzeugen der Screenshots an (liegt so rund bei 20 - 25%). Gruß Hayo
Achso ich dachte das BMPs werden unkomprimiert als Rohdaten zum PC geschickt. Ok so lange dauert die Übertragung nun auch wieder nicht aber eine Konvertierung ins platzsparende PNG Format auf PC Seite wäre interessant. Ich schaue mal ob ich einen Kommandozeilen-Konverter finde den ich in meine Batch Datei einbinden kann so das ich gleich PNG erhalte und die BMP danach gleich entsorge.
Jürgen schrieb: > Die Komprimierung schaue ich mir mal an, da seeehr hilfreich beim > Testen. Ich bin aber meist unter Windof unterwegs... Gibt es genauso auch für Cygwin, siehe Anhang. Ich habe die Tools unter usr/local/bin. Andreas W. schrieb: > 1. Quartus installieren > > 2. Wenn der Treiber installiert ist ... > http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster > > Schau zusätzlich mal in den Eintrag vom Michael bezüglich vollständigen > Treiber... > Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Quartus habe ich installiert, aber mit dem USB-Teil hapert es noch. Geht das unter Windows 7 überhaupt? Da habe ich den ganzen Morgen dran rumgewürgt, ohne Erfolg. Erstmal ist das Scope ein HID-Device und mit dem Standardtreiber von Microsoft so glücklich, daß er keine neuen Treiber haben will, unsere .inf lockt ihn nicht. ("...befindet sich bereits auf dem neuesten Stand...") Nach Web-Recherche habe ich das Gerät deinstalliert, per Policy in den Systemrichtlinien die Automatik verboten und es nochmal versucht. Dann fängt er zwar an zu installieren, aber bricht ab, eine Datei fehlt, Windows sagt aber nicht welche, grr. Mit dem SysInternals ProcessMonitor habe ich hinter die Kulissen geguckt und die Datei CyUsb.spt auch nach Drivers kopiert, wo sie anscheinend gesucht wurde. Zwischenzeitlich sah ich ein Gerät "Nios II Evaluation Board", aber mit gelbem Ausrufezeichen. Es hat die PID 0x6003, die in der .inf Datei auskommentiert ist ("W2000 from slog")? Die habe ich probehalber wieder einkommentiert, dann ging das USB-Gerät in eine Art Endlos-Disconnect-Reconnect, machte alle 2 Sekunden Bing und die Geräteansicht aktualisierte sich, ich konnte da nichts mehr anklicken. Den Spuk wurde ich durch Löschen der Treiberdateien wieder los. Jetzt ist alles wieder wie am Anfang, mit HID-Treiber...
Angehängte Dateien:
-
USB-Blaster-01.png
26 KB -
USB-Blaster-02.png
14 KB -
USB-Blaster-03.png
14 KB -
USB-Blaster-04.png
13 KB
Hallo Jörg, hast du die Treiber von dem Link hier benutzt? http://www.mikrocontroller.net/topic/goto_post/2389642 Die im SF, vergesse erst mal... Wenn du genau nach meiner Beschreibung gehst, muß das hinhauen! Also erst die angegebenen Files in die richtigen Verzeichnisse kopieren, dann den USB-Blaster gegen das HID-Interface ersetzen. Das zickt unter XP auch ein wenig, haut aber hin. Wenn der Blaster erkannt wurde, bzw. das DSO eingeschaltet wird, dann darf sich das DSO maximal 2x an u. wieder anmelden(so ist das bei mir)also 2x Pingen, bei dir loopt das? > Zwischenzeitlich sah ich ein Gerät "Nios II Evaluation Board" Das ist absolut korrekt! Vergleiche doch mal die Treiberdetails im Anhang. Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder 64bit Version? Gruß Michael EDIT: @Hayo Der ADC-Treiber "Standart" ist ausgegraut, Absicht?
Michael D. schrieb: > hast du die Treiber von dem Link hier benutzt? > http://www.mikrocontroller.net/topic/goto_post/2389642 Ja, habe ich. > Die im SF, vergesse erst mal... Ist aber das gleiche drin. > Wenn der Blaster erkannt wurde, bzw. das DSO eingeschaltet wird, dann > darf sich das DSO maximal 2x an u. wieder anmelden(so ist das bei > mir)also 2x Pingen, bei dir loopt das? Ja. Ich kann nachher mal meinen Installationsverlauf genauer dokumentieren, das war jetzt aus der Erinnerung. > Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder > 64bit Version? 32 Bit. Du hast XP? Ich habe quch noch ein XP-Notebook, mit dem ich es testweise probieren könnte. Das wäre aber keine endgültige Lösung. Jörg
Jörg H. schrieb: >> Die im SF, vergesse erst mal... > Ist aber das gleiche drin. Irgendwas war da nicht vollständig oder wie auch immer, ist ja wurscht. > > Ja. Ich kann nachher mal meinen Installationsverlauf genauer > dokumentieren, das war jetzt aus der Erinnerung. dann kann man das ja mal vergleichen. Der Andreas hat die gleiche Winkonf. wie ich... > >> Kann natürlich auch sein, das es an Windoof7 liegt, hast du die 32 oder >> 64bit Version? > 32 Bit. > > Du hast XP? Jo, XP-Sp3 und auf dem aktuellsten Stand > > Ich habe quch noch ein XP-Notebook, mit dem ich es testweise probieren > könnte. Das wäre aber keine endgültige Lösung. Auf meinem Notebook (Packard Bell) läuft das auch mit XP ohne Probleme. Den Treiber kann man zwar rückgängig machen, weil dann die mitgelieferte Soft von Welec nicht funktioniert, Diese ist aber eh für die Füsse... > Jörg Gruß Michael
Michael D. schrieb: > Der ADC-Treiber "Standart" ist ausgegraut, Absicht? Ja hatte ich auch schon erklärt. Hast Du wohl übersehen. Also nochmal ausführlich. Die Averagefunktion war vorher als separate Routine ausgeführt und daher unabhängig vom ADC-Treiber, ebenso die Invert-Funktion. Um Geschwindigkeit herauszukitzeln mußte ich die Speicherzugriffe minimieren. Das ging aber nur durch Integration in den ADC-Treiber. Daher habe ich die externe Routine rausgeschmissen. Der Assemblertreiber hat die neuen Funktionen schon an Bord, die anderen Beiden nicht. Daher habe ich die erstmal deaktiviert. Die Nachrüstung soll aber noch erfolgen. Weiterhin will ich auch versuchen den C-Code Treiber so weit zu optimieren dass er an die Performance des Assemblertreibers heran kommt. Im Zweifelsfalle ist das C-Coding wartungsfreundlicher und besser lesbar. Gruß Hayo EDIT: in einzelnen Fällen kam es in der 5.6 vor, dass der Standardtreiber noch auswählbar war weil die Initialisierung nicht ganz korrekt war. Das sollte aber in der aktuellen Version abgestellt sein
@Michael D. et al: Immer noch kein Erfolg mit dem USB-Gebläse. Auch unter XP drängelt sich der eingebaute HID-Treiber vor, von dem anderen will er dann nix mehr wissen. Im Unterschied zu Win7 weiß ich noch nicht, wie ich das unter XP verhindere. Ein Kollege meinte was von Shift/Ctrl festhalten beim reinstöpseln, das muß ich mal versuchen. Unabhängig davon habe ich mir jetzt in der Firma was "originales" zu dem Thema suchen lassen. Fand sich in einer hinteren Schrankecke... Nun habe ich einen original Byteblaster mit Parallelport, sowie anscheinend 2 Clone mit USB-Anschluß. Beide melden sich mit VID:PID 09fb:6001. Kommen jeweils 10polige Kabel raus. Auf dem Welec-Board sind ja gleich 2 solche Anschlüsse, ist bekannt welcher wofür ist? Muß ich irgendwas wieder auslöten, um den onboard-Cypress abzutrennen? Jörg
Hi Jörg, ich habe diese Woche auch schon mehrere Stunden mit meinem W2024A herumgekämpft. Windows 7 beharrt nach wie vor auf dem verdammten HID Device, bisher haben alle Tricks nicht weitergeholfen. Achja die Lötbrücke ist natürlich gesetzt. Mal sehen ob ich am Wochenende dazu komme, da weiterzumachen... wenn ich es hinbekomme poste ich es natürlich sofort. Gruß Michael
Nur ganz kurz, zu angenehmerer Zeit mehr: Ich habe das mit dem USB-Treiber jetzt hinbekommen, Quartus spricht mit mir. Der Durchbruch war, die HID-Treiber erst zu löschen, automatische Treiberinstallation zu verbieten (mehr dazu später), nicht am .inf-File herumzufummeln, es darf sich nicht für PID 6003 zuständig fühlen, nach neuem Auftauchen mit PID 6003 dann auf die Altera-Treiber im Qartus-Verzeichnis lenken. Ich sehe nur ein FPGA, scheint aber immer so zu sein? Das (bzw. das Config-Flash) habe ich nun mit dem Inhalt von Andreas W. (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") beschrieben. Nach einem Reboot meldet es sich nun mit Hardwareversion 1C9, und funktioniert augenscheinlich soweit. Später werde ich dann mal die User-Instructions neu testen, ob sich da was verändert hat. Jörg
Thomas O. schrieb: > Ich schaue mal ob ich einen Kommandozeilen-Konverter finde > den ich in meine Batch Datei einbinden kann so das ich gleich PNG > erhalte und die BMP danach gleich entsorge. Für die Konvertierung der PPMs in PNGs tut bei mir das Tool pnmtopng unter Windows seit Urzeiten seinen Dienst. Eingebaut in eine Batch-Datei läßt es sich per Drag und Drop benutzen http://netpbm.sourceforge.net/doc/pnmtopng.html
1 | w2000a-screenshot.exe -a -f <folder> |
liefert die Bilder in einem festen Ordner ab und eine Batchdatei mit
1 | pnmtopng %1 >%1.png |
übernimmt die Konvertierung. Gruß Rainer
Hier ein paar "Komponenten", wie man die automatische HID-Installation unter Windows 7 unterbindet: http://www.windows-7-forum.net/windows-7-treiber-hardware/3046-automatische-geraete-treiberinstallation-deaktivieren.html#post20932 Das habe ich temporär aktiviert und nach dem Anstöpseln wieder zurückgenommen, dann blieb das Gerät "unbetreibert" und ließ sich von Hand versorgen. Zuvor hatte ich die HID-Geräte deinstalliert. "gpedit.msc" existiert bei den Home-Varianten von Win7 glaube ich nicht. Vielleicht läßt sich ähnliches mit irgendwelchen Registry-Keys hinbekommen? Das hier ist jedenfalls der bei mir zwingende Schlüssel zum Erfolg. Bei vermurksten .inf-Dateien hilft Löschen der Cachedatei "INFCACHE.1": http://answers.microsoft.com/de-de/windows/forum/windows_7-hardware/windows-7-erkennt-usb-anschl%C3%BCsse-nicht-mehr/e6b391c4-e100-4a11-b5a3-78721b7c8267 (Die Antwort von Nadine, Neustart ist nicht nötig.) Gegen automatische Treiberwahl hilft ferner das hier, ist vermutlich nicht nötig: http://forum.chip.de/windows-7/automatische-treibersuche-internet-abstellen-1449048.html#post8778613 Irgendwas mit Ctrl/Shift festhalten beim Einstöpseln bringt nichts. Das hat der Kollege wohl mit Autoplay verwechselt. Ich bin noch auf der Suche nach dem zweiten FPGA. Habe jetzt mal das echte Blaster-Kästchen in Betrieb gesetzt. An die linke Stiftleiste angeschlossen kann ich damit genau das gleiche bewirken wie mit dem Slog-Treiber und dem onboard-USB. Die rechte Stiftleiste ist merkwürdig. Es wird nix JTAG-artiges gefunden. Stattdessen macht das Scope aber einen Reset. Jörg
Hallo Jörg, Wegen der zweiten Stiftleiste hab ich dir mal nen Uralt- Link rausgesucht, evtl hilft dir das etwas weiter... Wir haben uns schon vor über 3 Jahren mit Quartus und JTAG beim WELEC beschäftigt... ein echt spannendes Thema! http://groups.google.com/group/welec-dso/browse_thread/thread/e7240b9f13f0e254# Gruß, Brunowe
Hallo, nach langer Zeit gebe ich wieder einmal meinen Senf dazu. Das Problem mit dem JTAG Treiber hatte ich auch eine Zeit lange, wie ich das damals unter dem XP endgültig löste, weis ich heute nicht mehr. Möglicherweise hilft das Deaktivieren des komischen Treibererweiterungsprozesses. Vielleicht war es auch die Firewall mit der ich die Treiberidentitätsüberprüfung abgewürgt habe: (Programm X möchte Programm Y aufrufen. Zulassen?) Mit der richtigen Kombination aus zulassen und verweigern ging es dann irgendwann. Sollte sich der Treiber installiert haben lassen und Quartus erkennt die Schnittstelle am PC und kann trotzdem nichts runterladen, dann liegt es warscheinlich an einem Timeout verursacht durch einen USB-Hub (intern!!! oder extern). PC(USB-Host)<->USB-Hub<->Slogs Treiber verträgt sich nicht. PC(USB-Host)<->Slogs Treiber sollte gehen. @Jörg Das mit dem Reset hört sich schon gut an. Vielleicht lift dir das Errata Sheet weiter. Altera hatte irgendwann mal aus versehen in der Dokumentation die JTAG Pins vertauscht. MfG Alexander
Jörg H. schrieb: > Das (bzw. das Config-Flash) habe ich nun mit dem Inhalt von Andreas W. > (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") beschrieben. > Nach einem Reboot meldet es sich nun mit Hardwareversion 1C9, und > funktioniert augenscheinlich soweit. Hallo Jörg, das freut mich, dass die EPCS16 Version bei Dir läuft ... d.h. bei mir ist der Inhalt der FPGA's in Ordnung. Flash ist auch in Ordnung ... na was soll das dann noch sein? Frage: Wenn das Display einen Fehler hätte, würde dann das Oszi starten ??? Kommt dann evtl. nur die grüne LED der RUN/STOP-Taste??? Gruß Andi
ich hätte da noch einen Wunsch an die Firmware wenn man ins Menü geht um einen Screenshot abzuspeichern, könnte man beim Wählen des Speicherplatzes das dort gespeicherte Bild anzeigen lassen? So sieht man ob der Speicherplatz frei ist bzw. ob dort ein älteres Bild liegt das man gerne überschreiben könnte. Oder aber eine fortlaufende Erhöhung des Speicherplatzes, angenommen ich speichere etwas auf Platz 1 nehme ein neues Bild auf wechsle in diese Menü mit der Speicherfunktion könnte doch automatisch Speicherplatz 2 angezeigt werden. Zu dem NETPBM muss ich mir noch anschauen
zur Konvertierung BMP ins PNG Format habe ich gerade eine Freeware gefunden 24 kByte großes Tool (benötigt keine Installation zumindestens DOS/WIN), das könnte man doch mit ins Firmwarepaket stecken. http://cetus.sakura.ne.jp/softlab/b2p-home/ DOS/WIN32/Unix inkl. Quelltexte und Makefile für Linux Könnte mir bitte jemand mal ein BMP aus dem Oszi zuschicken, bin gerade nicht zu hause, würde es aber gerne mal probieren. mayn.de@kosmos (einfach vertauschen)
hallo Thomas... Das Ding ist klasse! Konvertiert die BMP in einer Sekunde! Jetzt wollte ich das mit in die Batch aufnehmen, will aber nicht so recht, kann das mal einer bauen, wahrscheinlich war ich heute zu lange in der Sonne... :-))) Hier die Batch von der screenshot-0.97os C3 --------------------------------------------------------------------- rem rem Change -c argument to whatever COM port your DSO is connected to. rem Invoke "%~n0 -h" for a list of command line options. rem "%~dp0\w2000a-screenshot.exe" -c 3 -b -a %* bmp2png [-6] *.bmp rem png-conf.bat -------------------------------------------------------------------- das mit dem Schalter "-6" bedeutet die Namensvergabe fortlaufend. Konvertiert dann alle vorhandene BMP's. Wenn ich die separate Batch von bmp2png mit Schalter starte, dann klappt das. Man bräuchte so eine Art Warteschleife, wenn das BMP geschrieben ist, das danach konvertiert wird, wie macht man das am dümmsten? Früher war ich in DOS auch mal fitter, Windows verwöhnt...tztztz @Rainer Mit deinem Prog. hatte ich gestern ein wenig experimentiert, irgendwie bin ich da auch nicht so klar gekommen Gruß Michael
nach dem konvertieren vielleicht noch die BMPs löschen, damit das Tool das nächste mal nicht wieder alle BMPs abklappern muss ob die schon konvertiert worden sind. @Programmers: Könnt ihr mit den Quellcode etwas anfängen um vielleicht bei der neuen Firmware gleich PNGs zu übertragen, das würde die Datenübertragung um einiges Beschleunigen wenn man statt 900 kByte nur noch 20 kByte übertragen müsste, auch könnte man sehr viel mehr Bilder auf dem Flash speichern.
Michael D. schrieb: > Mit deinem Prog. hatte ich gestern ein wenig experimentiert, irgendwie > bin ich da auch nicht so klar gekommen Wo drückt's denn? Wenn ich mich recht entsinne, war es ein bisschen Fummelei, die Batch-Datei so hinzubauen, dass man Programme/Library, Bilder und konv. Bilder verzeichnismäßig vernünftig getrennt hat. Gruß Rainer
Hayo W. schrieb: > Den Kompressionsfaktor zeigt das Programm übrigens beim Erzeugen der > Screenshots an (liegt so rund bei 20 - 25%). Thomas O. schrieb: > ... das würde die Datenübertragung um einiges Beschleunigen wenn > man statt 900 kByte nur ... Keine Bange, die Daten werden komprimiert übertragen (z.B. leerer Screen mit 4 Linien -> 26k Byte Übertragung mit 17% Kompressionsfaktor) und w2000a-screenshot.exe zeigt am Ende der Übertragung die Datenmenge, wie Hayo schon schrieb, auch an. Das ist schon etwas schlechter kompremiert als PNG (6kByte), aber weit von 900 kByte entfernt. Gruß Rainer
ja ok die Daten werden schon komprimiert übertragen und dann erst nach BMP umgesetzt, es kommt aber einem trotz Komprimierung doch sehr lange vor. 115.200 bps sind doch knapp 14 kByte/Sek. Geht es mit dem USB-Host eigentlich schneller oder ist das auch eher so ein RS232 Adapter?
Der begrenzende Faktor sind die 115.200 bps die das Welec liefert. Erst wenn die Komprimierung bei gleichem Rechenaufwand verbessert werden kann wird es schneller.
also ist die Komprimierung noch der bremsende Faktor. kurze Frage mit welchen Programm kann ich die Speicherplätze das Oszi über USB auslesen bzw. zum PC übertragen oder geht das nur per RS232 und Screenshot.exe?
Hallo zusammen, die Frage von Andreas finde ich ebenfalls interessant - könnte einer von euch uns den Gefallen tun und mal testen, ob das Oszi bootet wenn das Display abgesteckt ist? Das wäre klasse! Mich wundert es ein wenig, dass es von niemandem einen Aufschrei gab, als ich die zu niedrigen Kernspannungen verkündet habe... entweder hat hier noch keiner mit FPGAs gearbeitet oder es ging einfach unter? Also nochmal: Bei mir habe ich bei beiden FPGAs zu niedrige Kernspannungen gemessen! Bei FPGA1 knapp unter Soll, bei FPGA2 relativ deutlich. Eine aus dem spezifizierten Bereich fallende Kernspannung kann alle möglichen Effekte haben und kann durchaus ein Grund für die Spikes auf den Kanälen drei und vier sein. Man kann die 1,2V auf Soll hieven, indem man dem Spannungsregler eine Sense-Leitung verpasst, so dass er die Spannung an der Last (den FPGAs) und nicht an seinem Ausgang regelt (dazu muss man natürich noch die Feedback Leiterbahn am Regler auftrennen). Auch die 2,5V sind deutlich unter Soll, die 1,8V ebenfalls leicht (jeweils an der Last gemessen, nicht am Regler!). Beides könnte Probleme verursachen(ADCS und SRAM). Leider streikt meine Kiste ja, deswegen kann ich nicht testen, ob sich damit Verbesserungen erzielen lassen - leider geht auch mit korrekten Spannungen bei mir zur Zeit gar nichts. Aber es gibt hier doch einige Leute die keine Berührungsängste in Sachen Hardware haben - vielleicht findet sich jemand der es testen möchte? Vor Anlegen der Spannung sollte man aber sicherstellen, dass die Senseleitung wirklich korrekt angeschlossen ist, sonst würde der Spannungsregler bis auf fast 12V rauffahren. Michael
wäre es nicht einfacher zum testen ein Poti zu nehmen und mit dem Mittenabgriff die Spannung am FPGA etwas anzuheben. Passt die Spannung nach dem Spannungsregler und fällt evtl. nur zum FPGA hin so arg ab? Vielleicht ist das wegen der Thermik gemacht worden oder sind das eher die ADC die gut warm werden?
Hallo, das wird wieder eine Sammelantwort, entschuldigt das Kuddelmuddel. Michael H. schrieb: > die Frage von Andreas finde ich ebenfalls interessant - könnte einer von > euch uns den Gefallen tun und mal testen, ob das Oszi bootet wenn das > Display abgesteckt ist? Das wäre klasse! Der Displayanschluß ist unidirektional, das Display passiv. Es kriegt Clock, Daten, uns Syncs ab, wird laufend gescannt. Daher hat es keine Auswirkung auf den Rest, ob es gesteckt ist oder nicht. > Mich wundert es ein wenig, dass es von niemandem einen Aufschrei gab, > als ich die zu niedrigen Kernspannungen verkündet habe... entweder hat > hier noch keiner mit FPGAs gearbeitet oder es ging einfach unter? Ich dachte es ging um die Fehlersuche in einem defekten Gerät, nicht um einen generellen Mangel. Bruno We schrieb: > Wegen der zweiten Stiftleiste hab ich dir mal nen Uralt- Link > rausgesucht, evtl hilft dir das etwas weiter... Danke, hilft ehrlich gesagt nicht. In dem Bild ging es um die gleiche Schnittstelle die auch bei mir funktioniert, die ich links genannt habe. Im Bild ist nur die Platine auf den Kopf gedreht. Ich kann mir nicht recht vorstellen, daß Wittig diesen JTAG-Anschluß richtig hat und beim zweiten irgendwas verdreht ist. Nochmal gefragt: Hat noch nie jemand Kontakt mit dem zweiten FPGA aufgenommen? Thomas O. schrieb: > Geht es mit dem USB-Host eigentlich schneller oder ist das auch eher so > ein RS232 Adapter? Das Thema hatten wir schon. Derzeit ginge es damit langsamer, die USB-Firmware macht nur 57600 Baud. Man bräuchte eine eigene Firmware für den USB-Controller, und passende Treiber am PC. Ist also kein kleines Thema. Wir suchen noch FX1-Entwickler... Jörg
@Rainer > Wo drückt's denn? > Wenn ich mich recht entsinne, war es ein bisschen Fummelei, die > Batch-Datei so hinzubauen, dass man Programme/Library, Bilder und konv. > Bilder verzeichnismäßig vernünftig getrennt hat. ja eben...auf dem Link habe ich ettliche Sachen runter geladen,ist aber irgendwie keine Executive dabei, die da so recht funzen will. Ansonsten finde ich da nur die Quellcodes?!? BtW. Ist die Konvertierung da auch so schnell, wie die "bmp2png.exe? Dann lade doch mal deine komplette Conf. inkl.Programm hier hoch, ist ja open Source, so wie ich das sehe!?! > Keine Bange, die Daten werden komprimiert übertragen... Also findet ja die Komprimierung im DSO statt, das ist dann wohl der Flaschenhals! Ich kann damit jetzt leben, ist ja keine Ewigkeit @Michael H. > Also nochmal: > Bei mir habe ich bei beiden FPGAs zu niedrige Kernspannungen gemessen! > Bei FPGA1 knapp unter Soll, bei FPGA2 relativ deutlich. Eine aus dem > spezifizierten Bereich fallende Kernspannung kann alle möglichen Effekte > haben und kann durchaus ein Grund für die Spikes auf den Kanälen drei > und vier sein. Das ist ja hoch interessant und klingt irgendwie plausible. Wenn du mal die genauen Messstellen fotografieren könntest, würde ich diese Woche das auch mal nachmessen und dann berichten. Bei mir sind extreme Spikes, wenn das DSO gerade eingeschaltet ist und nimmt dann während der Aufwärmphase etwas ab, (bilde ich mir ein) evtl. gibt es hier einen Temp-Drift in der Spannungsversorgung? Ich habe nur ein FPGA, da hält sich die Temp. in Grenzen. Was ordentlich Temparatur bekommt, sind die ADC's, daher habe ich denen auch ein paar Kühlkörper verpasst. Gruß Michael
Angehängte Dateien:
-
after_opening.JPG
210 KB
Hallo Thomas, bitte nimm auf gar keinen Fall ein Poti für diesen Zweck! Da gibt es verschiedene Probleme: a) beim Einschalten steht das Poti irgendwo, die Spannung entsprechend auch => bis du es einstellst hat es längst bumm gemacht b) der Schleifer eines normalen Potis prellt bei Betätigung => die Reglerspannung kann extreme Sprünge machen => wieder bumm @Michael Ich habe mal ein Foto aus dem Wiki kopiert und markiert, wo du messen kannst. Es sollte sich leicht finden lassen: gemessen wird an den Kondensatoren der jeweiligen Last, bei den FPGAs also direkt unterhalb an den etwas größeren Keramikkondensatoren. Das Problem ist, dass die Spannungsregler ewig weit weg sitzen und die Leiterbahnführung doch recht sparsam ausgefallen ist. Bei den niedrigen Spannungen fließen natürlich recht hohe Ströme zur Versorgung, daher gibt es einen recht beachtlichen Spannungsabfall entlang der Leitungen und des Steckverbinders. Oder auf deutsch: Pfusch. Das Datenblatt des FPGAs spezifiziert 1,15-1,25V. Am besten lötet man sich an die Kondensatoren kurze Drähtchen und schaut dann im Betrieb die Spannung mit einem Oszi an, da jede Spitze die den zulässigen Bereich verletzt zu Problemen führen kann. Wenn schon der Gleichspannungswert nicht stimmt kann man sich das natürlich sparen... Gruß Michael
@ Jörg Danke für die Auskunft zum LCD - damit ist wieder eine mögliche Ursache ausgeschlossen.
@Michael H. > Das Problem ist, dass die Spannungsregler ewig weit weg sitzen und die > Leiterbahnführung doch recht sparsam ausgefallen ist. Bei den niedrigen > Spannungen fließen natürlich recht hohe Ströme zur Versorgung, daher > gibt es einen recht beachtlichen Spannungsabfall entlang der Leitungen > und des Steckverbinders. Oder auf deutsch: Pfusch. > Das Datenblatt des FPGAs spezifiziert 1,15-1,25V. ...genau das wollte ich losslassen und konnte es mir noch gerade so verkneifen. Deine Aussage hat das aber bestätigt. Interessant wäre noch zu wissen, ob denn die Spannung bei längerem Laufen stabil bleibt, oder schwankt. Wenn man bedenkt, das die Pc-CPU's eine genaue u. absolut stabile Spannung mit 3 Stellen nach dem Komma benötigen um anständig zu funktionieren...mehr brauch man wohl nicht dazu sagen! Deine Markierungen sind sehr Hilfreich, ich will mal schauen, ob ich die nächste Zeit dazu komme und werde dann berichten. Gruß Michael
Angehängte Dateien:
-
Ripple.gif
190 KB
Guten Morgen, noch ein kleiner Nachtrag zur Spannungsmessung. Wenn man nicht nur den DC Fall betrachtetn möchte, sondern auch den Ripple auf der Versorgung, dann braucht man natürlich ein Oszi dazu. Die Messung ist aber nicht einfach mit dem Tastkopf und der Masseklemme durchführbar - die Masseklemme ist zum einen eine wirksame Antenne, zum anderen bildet sie eine relativ große Leiterschleife in die Magnetfelder wunderbar einkopplen können. Deshalb kann man den Ripple mit einem passiven Tastkopf nur so messen wie in dem Bildchen illustriert! Also einen blanken Draht um den Massekontakt des Tastkopfes wickeln, so erhält man die kürzestmögliche Masseanbindung. Wem das neu ist, der sollte sich den Spaß machen und einen Vergleich anstellen (Messung mit Masseklemme vs. Messung mit Drähtchen) - der Aha-Effekt ist garantiert. Ich wäre sehr interessiert wie die Spannungn bei dir aussehen, Michael (und bei jedem anderen). Ich habe wie gesagt DC Werte von ca. 1,15V und 1,07V bei den beiden FPGAs. Damit FPGA2 bei 1,2V liegt muss der Regler bei mir an seinem Ausgang ca. 1,3V liefern. Die Vierkanalgeräte sind hier klar im Nachteil, weil die Wittigs die FPGAs offensichtlich mit sehr dünner Leiterbahn versorgen, über der natürlich bei zwei FPGAs durch den doppelten Betriebsstrom die doppelte Spannung abfällt wie bei einem. Gruß Michael
Hallo Jörg, Jörg H. schrieb: > Ich kann mir nicht recht vorstellen, daß Wittig diesen JTAG-Anschluß > richtig hat und beim zweiten irgendwas verdreht ist. Nochmal gefragt: > Hat noch nie jemand Kontakt mit dem zweiten FPGA aufgenommen? Warum auch? Da gibt es ja nach wie vor nichts Neues, was man da hineinladen könnte. Eben auch nicht vom LEON3! :-) Im Datenblatt oder App.-Note von Altera findet man 2 oder 3 Möglichkeiten, wie mehrere FPGA's ihre Konfig.-Daten aus einem EPCS16 laden können. ES gibt nur ein EPCS16. Also muss man erstmal herausfinden nach welcher Methode die 2 FPGA's ihre Daten holen. Hatte ich zunächst auf "Todo" geschoben, da nicht nutzbar. Gruß, Jürgen
@Michael H: Ich würde das Poti nicht an 12V Klemmen, sondern eine niedrigere Spannung im Oszi abgreifen und dann erst mal auf die gewünschte Soll-Spannung am Mittenabgriff einstellen. Klar sollte es nicht das billigste Poti sein, aber jedes Poti das für Audio geeignet macht keine solchen Sprünge wie du es beschreibst. Ich würde jetzt mal so blind(ohne das Datenblatt des FPGA zu kennen), ein 100 Ohm Poti nehmen, da kann also gar nicht soviel Strom fließen, die Spannung am Mittenabgriff auf die Sollspannung des FPGAs einstellen und dann erst auf die Stromversorgung des FPGA geben. Die Spannung des FPGAs kann also bestenfalls auf die Sollspannung angehoben werden, wenn ihm der Strom von knapp 15mA reichen. PS. Gestern habe ich festgestellt das das eingeschaltete Oszi neben meinem Laptop die WLAN-Verbindung stört. War mit einem Hotspot in etwa 150 Metern Verbindung nicht so schnell aber stabil, beim Einschalten war dann reproduzierbar die Verbindung weg. Die AVR Steckbrett daneben mit Nullpunkterkennung und Zündimpuls verursachte hingegen keine Störungen die die WLAN-Verbindung unterbrachen. Meint ihr es würde etwas bringen das Gehäuse innen mit Kupferspray oder ähnlichen ein zu sprühen und mit auf den Schutzleiter zu legen?
Jürgen schrieb: > ES gibt nur ein EPCS16. Ah so, das ist doch mal eine Aussage. ;-) Dann haben wir nach dem Auslesen/Umprogrogrammieren ja höchstvermutlich beides in einem Rutsch. Ich habe noch etwas mit den USR-Instructions rumgespielt, aber noch nichts Interessantes gefunden. :-( Jörg
Guten Tag, hasst du dir mal die Kontakte auf der Stiftleiste vom Netzteil Board zum Logic Board angeschaut ? Ich kann mir gut vorstellen das die qualitativ auch nicht die besten sind und schon dadurch eine größere Spannungsdifferenz entsteht. Wenn dort auch etwas abfällt könnte man es durch den Austausch der Kontakte ja leicht beheben. Gruß, Martin
Hallo, Thomas O. schrieb: > Gestern habe ich festgestellt das das eingeschaltete Oszi neben > meinem Laptop die WLAN-Verbindung stört. War mit einem Hotspot in etwa > 150 Metern Verbindung nicht so schnell aber stabil, beim Einschalten war > dann reproduzierbar die Verbindung weg. Die AVR Steckbrett daneben mit > Nullpunkterkennung und Zündimpuls verursachte hingegen keine Störungen > die die WLAN-Verbindung unterbrachen.- Da ich in einem akkreditierten EMV- Prüflabor arbeite und mir das entsprechende Equipment zur Verfügung steht, hatte ich eh vor die Abstrahlungen unseres Oszilloskops zu messen(Radiate Emission). Das lässt nicht nur Rückschlüsse zu wie sehr das WELEC andere Geräte stört, sondern auch welche Frequenzen besonders stark vertreten sind und ggf. geräteintern zu Problemen führen können. Gruß
@Bruno: Das wäre wirklich mal interessant. Wenn du dann Ergebnis hast, lass sie uns bitte zukommen. Ich kann dir schon mal mehr oder weniger versprechen, dass um die 50kHz viel los sein wird - wer seinen Tastkopf schon mal über dem internen Schaltnetzteil abgelegt hat wird wissen was ich meine ;)
Jo, das seh ich auch so. Da dürfte im Diagramm eine ziemliche Spitze sein. Wobei ich meine dass die Hauptfrequenz eher zwischen 12 und 16KHz liegt. Aber mal abwarten was die Profis so rausfinden. Gruß Hayo (der leider im Augenblick wenig Zeit hat aber einige gute Ideen)
Hallo Michael, Michael D. schrieb: > BtW. Ist die Konvertierung da auch so schnell, wie die "bmp2png.exe? > ... > Dann lade doch mal deine komplette Conf. inkl.Programm hier hoch Die Konvertierung der PPM in PNG geht "gut zügig". Meine angehängte Konfiguration sollte direkt funktionsfähig sein, wenn du sie nach C:\ entpackst. Sonst müssen in den beiden Batch-Dateien die Pfade angepaßt werden. Gruß Rainer
Hallo
Kurze off Topic Frage :
@Bruno We
>Da ich in einem akkreditierten EMV- Prüflabor arbeite
Hast Du vielleicht einen Link, wo steht, wo die Grenzwerte bei einer
EMV-Messung sind.. (finde da nix im Netz :-( )
Hätte da ein anderes Gerät, dass ich diesbezüglich mal testen will.
Danke und l.G. Roberto
Hallo Roberto, natürlich kann ich dir helfen. Meine AW findest du im HW Thread, passt da einfach besser hin! Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Gruß, Brunowe
@Hayo eine gute Idee hab i auch noch: Bei eingeschaltetem Quick Meas wird das Oszi ja viel langsamer, meine idee: die QM routine wird erst nach einem Trigger Event angesprungen denn sonst macht es keinen sinn ausser man braucht einen Lottozahlengenerator ;) Dadurch sollte sich doch sie Geschwindigkeit wieder etwas ehoehen, was meinste dazu ? vlG Charly
Hallo, ich hoffe ich bin hier richtig und es kann mir jemand helfen. Ich habe mein Welec W2022A kaum benutzt. Das stand jetzt über ein Jahr im Schrank, da ich keine Zeit hatte. Jetzt habe ich es mal wieder herausgeholt und es Bootet leider nicht mehr. Mit dem WelecUpdater konnte ich einen Dump ziehen. Habe dann mal versucht die Open Source Firmware (1.2.BF.2.10) aufzuspielen, aber leider ohne Erfolg. Wenn ich mit dem W2000-Update von der Welec Seite auf das DSO zugreife, bekomme ich keine Daten angezeigt (Seriennummer, Hardware Version ...). Über Google habe ich gefunden, das hier im Forum auch schon mal so ein Fehler nach einem erfolglosen Firmware update aufgetaucht ist und behoben werden konnte. Hänge den Dump am besten gleich mal an. Gruß und danke schon mal Timo
Hallo Timo, Du bist definitiv richtig hier. Was zu klären wäre: - ist Dein Gerät ein W2000 oder ein W2000A. Das läßt sich leider nicht aus der Gehäuseaufschrift ableiten. Daher die nächste Frage -> - mit welcher Firmwareversion wurde das Gerät ausgeliefert bzw. welche FW war zuletzt drauf? - Wenn Dein Gerät ein W2000 (ohne A) ist must Du erst diverse Änderungen vornehmen - Anleitung auf der Wikiseite verfügbar. - welche Hardwareversion wurde angezeigt? (evtl. Kaufdatum noch bekannt?) - Kam der Blackout erst nach dem Update? Lief das Gerät nach der Schrankrettung noch? - warum hast Du versucht eine so alte FW-Version draufzuspielen? Aktueller Stand ist 1.2.BF.5.7C2 - Du solltest unbedingt Active Perl installieren (und den Win32 Serial Port) und dann den Upload mit dem Perlskript versuchen. Wenn der Upload mit dem Kompressor (16s) nicht funktioniert nimm den unkomprimierten Modus (180s). Gruß Hayo (der leider zur Zeit in Seeschiffahrtsvorschriften versinkt und deshalb nicht zum Programmieren kommt)
Halo Hayo, danke für die schnelle Antwort. Welche FW als letztes auf dem Gerät war kann ich leider nicht mehr sagen. Alles was ich noch ziehen konnte ist in der flash Datei. Kann ich irgendwo sehen, ob es die Serie mit oder ohne A ist? Welche Wiki-Seite meinst du? Habe den Beitrag Beitrag "W2000 Serie nach W2000A Serie aufrüsten" gefunden. Werde ihm mir mal durchlesen. An die Hardwareversion kann ich mich nicht mehr erinnern. Ich habe es am 20.05.2011 über Ebay gekauft (Verkäufer war „Wittig Electronics GmbH“ tek4you.eu ). Kann ich die HW-Version auf der Platine sehen? Der Blackout war da, als ich das Gerät wieder aus seinem „Winterschlaf“ geholt habe. Das Update war ein Rettungsversuch, da sich von Wittig keiner auf meine EMail gemeldet hat. (Exististiert die Firma überhaupt noch?) Sorry, bei der Angabe der FW-Version habe ich mich vertan. Ich habe die 1.2.BF.5.7C2 aufgespielt. Die alte hatte ich zuerst versehentlich runter geladen, aber nicht installiert. Active Perl habe ich mir gestern geladen und installiert. Damit will ich heute mein Glück versuchen. Gruß Timo
Hello everyone! I read often the interesting posts on this forum. I would like to submit my problem arose 2 days ago. I have a Welec W2022A about a year, I made the upgrade with firmware up to version written by Hayo 5.6C2 using the script from linux. Two weeks ago I also made hardware changes using the 24.9 ohm and 150 ohm resistors instead of 0 ohm and 150 Kohm. After I noticed a good improvement in performance in noise and linearity. The oscilloscope was switched on several hours these days without any problem. Yesterday there was the ugly fact, I tried to turn the DSO and no longer boot, meaning that lights only the green button RUN / STOP. I've done several tests since then 1) Apparently you activate the "germsmonitor" mode using the usual two buttons, the screen turns gray and after black normally. I tried to reload the firmware (5.7C2) with GERMSloader, took about 180 seconds instead of the usual 160sec or so, either in RAM or in FLASH, but without success. 2) I also tried the ucl mode (16 seconds) but gives error in the phase 2 of the firmware upload. 3) I tried to use the utility Welecupdater.exe with the original firmware 1.3, apparently is loaded after 30 minutes, but the scope does not boot anyway. 4) Apparently GERMSloader manages to read the contents of flash memory. 5) If I connect the USB port, the DSO is regularly recognized in windows. 6) If I press the two buttons of germsmonitor sometimes random LEDs are lit. (Normally I would have to get the instrument reboot.) At this point I fear that there may be a hardware failure, even though I can not understand if it is random problem or is related to the mods made 2 weeks ago. And after the mods, the oscilloscope worked indeed regularly on the first try and for several hours. I am very sorry for what happened, because I'm very "attached" to the little "guy" who now works very well thanks to your work :-( Thanks for your kind attention. Errico
Ok, jetzt haben wir schon zwei Geräte die ins Koma gefallen sind. Woll'n mal sehen ob ich da im Parallelflug helfen kann. timo r. schrieb: > Active Perl habe ich mir gestern geladen und installiert. Damit will ich > heute mein Glück versuchen. Das ist schon mal ein guiter Ansatz. Als nächstes solltest Du ein Terminal mit den bekannten Einstellungen (stehen in der Datei How to use a Terminal) starten und mal gucken ob beim Booten was ausgegeben wird - wenn ja was. Errico schrieb: > At this point I fear that there may be a hardware failure, even though I > can not understand if it is random problem or is related to the mods > made 2 weeks ago. Hi Errico, this makes the analysis a little bit more difficult. First try (as Timo) to check the boot messages. Start a Terminal (settings in "how to use a Terminal") and then start the DSO. It might be interresting if the DSO tries to start the firmware or not. Hayo
@Hayo dieses Fehlerbild kommt mir auch sehr bekannt vor. Leider habe ich noch keine Abhilfe für mein und die vielen anderen defekten Geräte (trotz allmöglicher Tests ... und Quartus ;-)! Mein Trost ist, dass ich mir noch ein Neues gekauft habe ... HW: 8C7.0E FW: V1.4 Grüße Andi
Hallo Hayo, das Perl-Script ist erfolgreich durch gelaufen. Habe Putty eingestellt und das DSO gebootet, empfange aber nichts. Auch auf „h“ oder “,“ kommt keine Reaktion. Was macht der „USB_Blaster“ genau? Ich habe gelesen, dass man diesen für das Upgrade bracht. Könnte der etwas helfen oder bringt der das DSO noch mehr durcheinander? Gruß Timo
Der Blaster ist zum Programmieren des/der FPGAs vorgesehen und hat mit unserer Firmware nichts direkt zu tun. Wenn die Firmware nicht mal startet könnte es das bekannte Problem mit den kalten Lötstellen am RAM sein. Das Screiben ins Flash scheint ja zu funktionieren. Da könnte generelles Nachlöten helfen, oder mal bei geöffnetem laufenden Gerät aufs RAM drücken. Generell scheinen die Verlötungen nicht die beste Qualität zu sein. Gruß Hayo
Habe das Gerät jetzt mal aufgeschraub. Wo sitzt das RAM?
Hello Dear Hayo, thanks for the answer!
I used Teraterm, do not I see anything when I turn on the DSO, "h" and
"," give no answer.
If I go into "germsmonitor" I get this on the terminal
+
‚š
Í048
TC CPU
+
#0000: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0010: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0020: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0030: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
+
#0040: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0050: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0060: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
#0070: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
+l
?
+h
?
+
I have upload latest 5.7C2 firmware :
GERMSloader.pl Ver 1.2.0
*** No Warranty
***
*** This program is distributed in the hope that it will be useful,
*** but is provided AS IS with ABSOLUTELY NO WARRANTY;
*** The entire risk as to the quality and performance
*** of the program is with you. Should the program prove defective,
*** you assume the cost of all necessary servicing, repair or
correction.
*** In no event will any of the developers, or any other party,
*** be liable to anyone for damages arising out of the use or inability
*** to use the program.
Device
: /dev/ttyUSB0
Flash filename : TomCat.flash
--- Writing GERMS firmware...
Writing line 027233 of 027233: S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 218.8 seconds!
Please reboot DSO if it didn't restart automatically.
READY!
Thanks for all the fish.upload finshed
I think that firmware does not start at all. :-(
I think also... Maybe it is the RAM soldering. See Picture in the next post.
Angehängte Dateien:
-
Ram01.jpg
670 KB
One RAM is on the ADC side of the PCB (see picture) and one is directly on the other Side same position. @Timo die Lage des einen RAM siehst Du im Bild markiert. Das andere ist direkt darunter auf der anderen Platinenseite. Da kommt man nur ran wenn man die Platine abbaut. Hayo
Ach ja, Timo, da Dein Gerät 2011 gekauft wurde, ist auf jeden Fall davon auszugehen, dass Du ein W2000A hast. Als nächsten Schritt könntest Du die Spannungen am Netzteil nachmessen. Es könnte evtl. sein, dass da vielleicht was abgeraucht ist. Allerdings ist das Netzteil eigentlich recht zuverlässig, da nicht von Wittig selbst hergestellt sondern zugekauft. Aber das läßt sich recht schnell und einfach überprüfen. Die Spannungen an den einzelnen Pads hatte auch schon mal jemend hier gepostet (bzw. im W2000 Hardwarethread). Muß mal sehen ob ich das noch finde. Hayo
Hayo OK, now I open the DSO and I go to see the chips with the magnifying glass. Then let you know Errico
@Timo Hier der Link zur Wiki-Seite http://sourceforge.net/apps/trac/welecw2000a/ Da findet man schon Einiges. Ansonsten mal im Hardware Thread (im alten) stöbern, da finden sich ähnliche Probleme. Beitrag "Wittig(welec) DSO W20xxA Hardware" Gruß Hayo
Hm interessant, dass sich dieser Fehler bei immer mehr Leuten zeigt. Leider habe ich bisher auch noch keine Lösung gefunden, die meine Kiste wieder flott gemacht hätte...aber je mehr dasselbe Problem haben, desto größer ist die Wahrscheinlichkeit, dass jemand eine Lösung findet :) Gruß Michael
Also entweder ist es ein Bauteil das schlecht ausgelegt ist und öfters kaputt geht (glaube ich eher nicht) oder es sind kalte Lötstellen - was mein Favorit ist. Ich denke bei der Herstellung wurde schlampig gearbeitet und gerade kalte Lötstellen sind eine üble Sache weil sie sich nicht sofort auswirken müssen und schwer zu finden sind. Gruß Hayo p.s. so ich tauche jetzt ab - morgen bin ich wieder online
Hallo Hayo, habe das DSO jetzt komplett auseinander genommen um das zweite RAM zu sehen. Ist das normal, das der Teil für die Messschaltung so „zusammengeschustert“ aussieht? Habe das Foto unter "imageshack . us f 220 / wp000700.jpg" gestellt, da es etwas größer ist. Werde jetzt off gehen und morgen weiter machen. Gruß Timo
@Hayo OK, I checked carefully the PCB, the two RAM, and the others but I do not notice anything special to view. (Pins desoldered, shorts or other problem) The behaviour of the DSO it's the same. Can I do anything else to diagnose the problem? Something might be defective ... :-( What is the small button next to the RAM? Thanks Errico
@ Hayo Maybe I found two friends who have the same problem: www.mikrocontroller.net/topic/250182 I don't understand well German also with the Google Translator, but I think that the situation it's the same. I forget the DSO switched on for 4/5 hours during the night and the day after is no longer running properly as described here. :-((
Hallo Hayo, ich habe jetzt mal das Perl-Script für den RAM Loader ausgeführt. Dies lief ohne Fehler durch. Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM OK ist oder dass der LOADER es nur fehlerfrei angenommen hat und der Status der weiteren Verarbeitung ungewiss ist? Gruß Timo
Hi, bin leider momentan nur kurz mal zwischendurch online. timo r. schrieb: > Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM > OK ist oder dass der LOADER es nur fehlerfrei angenommen hat Es gibt beim Schreiben keine Rückmeldung ob der Vorgang erfolgreich war. Daher kann man das nicht unbedingt als Indikator verwenden. Ich habe inzwischen noch mal in anderen Threads zu dem Thema gestöbert. Anscheinend ist auch die Verlötung des/der FPGAs ein Kandidat für diese Probleme. Die FPGAs werden im Betrieb recht warm, da kann es sein, dass schlechte Lötverbindungen sich quasi "abarbeiten" durch die entstehenden thermischen Spannungen. Grundsätzlich tippe ich aber so oder so auf kalte Lötstellen. Die Suche ist natürlich nicht ganz einfach. Wer über einen Lötkolben mit feiner Spitze und etwas Löterfahrung verfügt, kann die Beinchen einfach mal auf Verdacht nachlöten. Leider lassen sich kalte Lötstellen nicht unbedingt mit einer Lupe erkennen. Gruß Hayo
Hayo W. schrieb: > Wer über einen Lötkolben mit feiner Spitze und etwas Löterfahrung > verfügt, kann die Beinchen einfach mal auf Verdacht nachlöten. Mit einer breiten Lötspitze - wegen des besseren Wärmeflusses - und Flußmittel geht es noch besser. So sieht das dann aus: http://www.youtube.com/watch?v=erb6-i54tbo Gruß Rainer
Noch mein Senf: timo r. schrieb: > Heißt das jetzt, dass die FW in das RAM geschrieben wurde, somit das RAM > OK ist oder dass der LOADER es nur fehlerfrei angenommen hat und der > Status der weiteren Verarbeitung ungewiss ist? Kommt drauf an. welcher Loader das war. Für den alten 3-Minuten Loader gilt wohl das was Hayo gesagt hat. Wenn du aber vom 15-Sekunden UCL-Loader sprichst liegen die Dinge etwas anders. Da ist in der 2.Phase meine Software im RAM am Ackern. Es wird eine Prüfsumme der dekomprimierten Daten gebildet. Anfangs habe ich dafür tatsächlich blockweise aus den RAM zurückgelesen, erst die neuere Assemblerversion macht das on the fly. Letztere ist noch nicht verbreitet. Jörg
E U R E K A !!! The problem was the ram, I proceeded to resolder the pins with a few drops of flux and tin and the little Welec is running back, is great with the latest firmware 5.7C2 Thanks Hayo!
Thanks Rainer Actually I did not expect to see him running so soon, with a really simple remedy. Errico
@All (with no running welec) SUUUPPPIIII mein W2024A geht wieder ... Nun wird die vermutete Hardware 1C9.0E auch erkannt. Interessant ist, dass ich vorher eine komplette Softwarerücksicherung von meinem Neuen mit der HW: 8C7.0E eingespielt hatte. Die Hardware-ID auf dem Bildschirm kommt also aus dem EPCS16. Fehlersuche ergab wie von vielen vermutet auch schlechte Lötstellen an den Speicherchips. Leider war das mein zweiter Versuch ... aber gut Ding will Weile haben. DANKE ALLEN ... PS: Ich werde wohl gleich mal die aktuelle Version von Hayo einspielen ... Grüße Andi
Hallo, danke an alle, besonders an Hayo. Mein DSO hat sich gerade wieder gemeldet. Es war bei mir auch der RAM und zwar der Chip, bei dem man das Gerät ganz zerlegen muss. Das flashen hat sogar mit der kalten Lötstelle funktioniert. Werde die FW aber zur Sicherheit noch mal neu aufspielen. ---------------------------------------------- Version : 1.2.BF.5.7 C2 Hardware: 8C7.0E Serial : 00128402C7 Model : W2022A / 2 Channels ---------------------------------------------- Gruss Timo
Holla die Waldfee... gleich drei Patienten aus dem Koma erwacht und alle drei wie vermutet mit kalten Lötstellen am RAM. Das ist ja ziemlich eindeutig. Das sind ja mal richtig gute Nachrichten. Glückwunsch auch von mir. It is nice to hear the success message. It is also an approvement for me that the RAM soldering is not the best... I think we will hear more from such problems in future. Wish You much fun with Your little toy Hayo
@Rainer Sehr schönes Video. Der Kollege der das vorführt hat es gut drauf. Sehen ja besser aus als werksverlötet die Beinchen. Gruß Hayo
@Hayo, ja jetzt kann es losgehen ... Der Versionssprung (von 1.4 Welec auf Deine letzte) ist ja absolut der Hammer ... ich konnte ja die letzte Nacht gar nicht mehr ruhig schlafen ;-) Grüße
Angehängte Dateien:
@Hayo,
ich hätte da noch einen kleinen Schönheitsfehler ...
Versuche mal im normalen Horizontalen "Main"-Modus die manuelle Messung
("Cursors"). Dann über "Main/Delayed" auf FFT umstellen ...
... dann sind noch die alten Buttons und Linien (bei mir) zu sehen.
PS: Leider bin ich für mein Käferreporting bekannt ... ;-)
Grüße Andi
Hi Andi, durch solche Fehlermeldungen konnte die Firmware entscheidend verbessert werden. Sobald ich etwas Zeit habe werde ich mir das mal ansehen. Danke für den Hinweis. Gruß Hayo
Angehängte Dateien:
@Hayo, sehr schön ... Im Zusammenhang stehend evtl. noch ein Hinweis zum Remote Export einer B/W-Grafik ... ... bei den Zusatzlabeln ist das Gitter noch zu sehen. Könnten diese Label evtl. noch mit weiß gefüllt werden? Das sieht etwas besser aus wenn man die Bilder vewenden möchte. PS: Nice to have! Evtl. gibt es ja noch Gegenargumente ... Grüße Andi
Angehängte Dateien:
@Hayo Noch etwas was mit dem Browse-Button ... Im MAIN mit BROWSE ... Umstellung auf FFT ... zeigt folgendes Bild! PS: Viel Spaß beim Lernen ... ;-) Grüße Andi
hm, könnte ich die Experten nochmals um einen Kommentar bitten ? Ich wollte heute Hayos letzte Softwareversion aufspielen, leider verhält sich das DSO dabei sehr sonderbar. Ich schaffe es nämlich nicht, es in den "Downloadmodus" zu versetzen. Zwar reagieren die zwei berühmten grauen Knöpfe links unterm Schirm bei der entsprechenden Menüwahl jeweils wie sie sollen, gleichzeitiges Drücken (egal in welchem Grundmenü ich gerade bin) bringt aber nicht den ersehnten "weißen Schirm" den ich brauche um das Aufspielen zu starten. Alles andere scheint normal zu funktionieren. Auch mehrfaches Ein und Ausschalten hat nichts gebracht ... Mir tun schon die Finger weh' vom vielen Knöpfe drücken ! Hätte jemand vielleicht 'ne schlaue Idee ? Danke: Hermann
Bei mir wird der Bildschirm in der Regel auch nicht weiß, bleibt eher schwarz, bzw. wird es nach dem Loslassen wieder. Hat du die Knöpfe in der richtigen Reihenfolge losgelassen? Den äußeren (linken) länger halten, den anderen zuerst freigeben. Die Drück-Reihenfolge scheint egal zu sein, wichtig ist das sie mal beide gleichzeitig gedrückt waren. Den linken länger halten ist Bootloader, andersrum einfacher Reset. Jörg
wow, dat war fix ! danke Jörg für die schnelle Antwort! Leider ändert die Reihenfolge mit der ich die Knöpfe drücke bzw. loslasse nichts. Der Schirm bleibt immer "an" (dh. er wird nie schwarz bzw. weiß und verbleibt in seinem momentanen Modus) egal wie rum ich's angehe. Ach ja, die Version die ich momentan drauf habe ist die 1.2.BF.5.1C4 obwohl das hier kaum relevant sein dürfte. Grüsse: Hermann
Hermann E. schrieb: > Ach ja, die Version die ich momentan drauf habe ist die 1.2.BF.5.1C4 > obwohl das hier kaum relevant sein dürfte. In der Tat. Probiere die Tasten mal im Menu, ob die vllt. defekt sind. Erst die ganz linke Taste drücken, dann die zweite von links. Anschließend die 2. von links loslassen und zuletzt die ganz linke.
Da sind ja noch jede Menge Nachteulen unterwegs ! War gerade weg da ich im Keller noch mein altes Tektronix (ursprünglich vom Müll) wieder ausgegraben habe. Erst mal Danke für eure Hilfe, in der Not schätze ich diese gleich doppelt ! Was die Tasten angeht habe ich so ziemlich alle möglichen Sequenzen und Dauer versucht - ohne Erfolg. Wie gesagt, jede einzelne Taste reagiert noch im Sinne des Menus (soweit ich das sehen kann). Ich denke also nicht das die Tasten bzw ihre Anschlüsse selbst defekt sind. Gibt's vielleicht die Möglichkeit so 'ne Art "Hard reset" zu machen indem man auf dem PCB irgendwelche Kontakte kurzschliesst bzw auf Null zieht, ähnlich wie beim AVR-Programmieren ? Grüsse: Hermann
Ich hab sowas auch schon mal erlebt, geholfen hatte bei mir den Flash nachlöten(W2022A). Allerdings sah das Fehlerbild anders aus, timeout beim flashen. Gute Nacht - Jochen
Die Lötstellen scheinen ja ein echter Schwachpunkt zu sein. Wüsstest Du an was man das Flash erkennen kann, bzw wo es sitzt ? Gute Nacht auch meinerseits: Hermann
Ja, gibt eine schöne Doku dazu - ich poste gleich mal den link, moment....
...im dritten Bild unter der Stiftleiste, ungefair in der Mitte oberhalb der 16(beim 2024) adc´s - sourceforge.net/apps/trac/welecw2000a/wiki/Hardware http... voran
Danke ! Ich gehe davon aus das es das etwas grössere Chip ist !? Schaut schwer zu Löten aus da mir auf dem Bild die Kontakte ziemlich klein erscheinen. Jetzt muss ich aber wirklich in die Heia ... Gute Nacht: Hermann
Wenn Du das Gehäuse aufgeschraubt hast, kannst Du ihn nicht verfehlen. In der Nähe, eher rechts von der Stiftleiste gibt es auch einen Taster für den manuellen Reset. Sei ganz vorsichtig beim Löten, nicht ohne Flussmittel!! Viel Erfolg!
Würde der Taster auch das Neuaufspielen der Firmware ermöglichen (Falls er denn geht ?) Ich geh' mal schon Zähneputzen ... Hermann
@Hermann bei mir ist das nur ein normaler Reset (der kleine Taster auf der Platine). Um in den GERMS Modus zu kommen, benötigst Du schon die beiden linken Tasten wie vom Jörg beschrieben. Gruß Andi
Danke Andi, das erspart mir ein unnötiges Ausprobieren. Ich zier mich noch ein wenig mit dem Löteisen ranzugehen, die Frage ist es so zu lassen (der Spatz in der Hand) oder es zu versuchen für das Update (Die Schwalbe auf dem Dach). Muss eh' erst noch Flussmittel bestellen, das läßt mir Zeit zum Nachdenken. Nochmals Danke: Hermann
Ich hatte mir auch die Arbeit gemacht und alle Pins des Flash nachgelötet. Leider ist der Pinabstand so klein, dass das Flussmittel (wie schon beschrieben) dringend verwendet werden sollte(muss). PS: ... das alte Geigenkolophonium mit Spiritus würde es auch machen ;-) ... mir wäre die Schwalbe lieber ... und Hayo freut sich. Grüße
Hi there. Any news about the spikes fix? It seemed me we were on the right way, maybe through updating the fpga by quartus to reach 1c9.0e version or so and adjusting the power supply value of the FPGA. Cheer, Cy
boh ! wollte heute das Flash nachlöten und habe davor einen letzten Versuch gemacht das DSO in Lademodus zu versetzen - und siehe da es hat funktioniert (aber nach wie vor bei weitem nicht bei jedem Mal). Nach ca 20 Versuchen konnte ich die letzte BF Version (endlich) erfolgreich flashen. In der Regel verschwinden solche Probleme natürlich nicht von alleine, aber solange ich eine Operation am offenen Herzen vermeiden kann ... Nochmals vielen Dank an alle (Jochen, Jörg, Andreas, Guido) die mir mit Rat und Tat zur Seite gestanden sind und natürlich vor allem an Hayo: Die ersten Tests der letzten Version sehen vielversprechend aus ! Hermann
Welec scheint dazu gelernt zu haben... Ich hab meines damals auch direkt bei Welec ersteigert (war aber noch ein anderen eBay Account) - und für 140€ bekommen, ein anderes ging zeitgleich für 160€ raus - da war der Startpreis noch wesentlich geringer und bei so einem Nieschenprodukt war es nicht sehr klug vom Verkäufer, mehrere Auktionen zeitgleich enden zu lassen.
Sebastian S. schrieb: > Ich hab meines damals auch direkt bei Welec ersteigert (war aber > noch ein anderen eBay Account) Wahrscheinlich tek4you_eu. Der Account scheint inzwischen nicht mehr zu existieren.
ich bin nun auch im Club, habe heute mal Oszi auf die Arbeit mitgenommen und nach dem Einschalten bleibt es dunkel, wobei Bootloadermodus zeigt er an also dieser weiß/schwarz Wechsel. Komischerweise geht das WLAN, was sonst bei eingeschaltetem Oszi nicht ging, anscheinend bleibt es irgendwo hängen wo noch keine Display angesteuert wird, da dieses bzw. die Abstrahlung der Displayleitungen zur Störung des WLANs führen. Die Firmware kann leider erst heute Abend wieder einführen. Jemand eine Idee woran dieses unerwartete Nichtstarten liegt. Oder könnte es ein Netzteil sein welches den FPGA versorgt? Wie war nochmal die Tastenkombi für einen Neustart, Taste 2 und danach Taste 1?
Hallo Thomas, ich zitier mal Jörg der mir bei meinem Problem weitergeholfen hat: "Den äußeren (linken Knopf) länger halten, den anderen zuerst freigeben. Die Drück-Reihenfolge scheint egal zu sein, wichtig ist das sie mal beide gleichzeitig gedrückt waren. Den linken länger halten ist Bootloader, andersrum einfacher Reset". Bei mir hat erneutes Versuchen nach einigen Tagen das Problem (zeitweilig ?) gelöst, leider weis ich auch nicht mehr ... Grüsse und viel Erfolg: Hermann
ich hatte mal eine Mail an alle Wittigs geschrieben. Einer bot mir eine Reparatur als Garantieleistung an, einer wollte einen Reparaturversuch für 120€ starten oder 300€ für ein Neugerät. Werde da nochmal anrufen und es klären, 120€ für einen Versuch ist mir zuviel Risiko, gerade wenn es sich nur um einen Lötversuch handeln würde. Gibt es eigentlich noch andere Oszilloskope für die es Open Source gibt?
Thomas O. schrieb: > Gibt es eigentlich noch > andere Oszilloskope für die es Open Source gibt? Meines Wissens nicht, das macht ja unser Oszi trotz seiner kleinen Schwächen so attraktiv. Gruß Hayo
Hey Skipper, wie sieht es aus, können wir gratulieren? Grüße, Guido
Jupp die Sache ist geritzt! Boot ist auch schon gechartert. Vorraussichtlicher Termin für die Weiterentwicklung unseres Projektes ist ab Mitte/Ende Juli. Vorher werde ich da nicht zu kommen, da ich meinen Fuhrpark noch auf Vordermann bringen muß. Gruß Hayo
Macht es tatsächlich noch Sinn an der BF-Firmware weiter zu arbeiten, obwohl Osoz nun schon einen Stand erreicht hat, bei dem es sich lohnt anzuknüpfen? Nicht nur der ernorme Geschwindigkeitszuwachs sprechen dafür. Ich möchte nicht zuletzt auch erwähnen, dass Osoz die Huckepackplatine und die neue gewonnenen Vertikalablenkungen super unterstützt. branadic
Ich gehe mal davon aus, daß Hayo mit "unser Projekt" auch Osoz meinte. Jörg
Hayo W. schrieb: > Jupp die Sache ist geritzt! Na dann meine Glückwünsche, und natürlich: Schönen Urlaub.
Jörg H. schrieb: > Ich gehe mal davon aus, daß Hayo mit "unser Projekt" auch Osoz meinte. > > Jörg Korrekt, so ist es! Guido schrieb: > Na dann meine Glückwünsche, und natürlich: Schönen Urlaub. Besten Dank, bei dem Sch....wetter hier brauche ich das auch. Gruß Hayo
Hallo Hayo and the team, any news about this project,may be within Christmas? Regards, Sandro
Hi there, yes I know it is really quiet here now but don't worry about that, it will go on. Unfortunately I'm really busy with several things at this time but I have good ideas about our old firmware and I'm really looking forward what the other guys are working out with the new FPGA design. The WELEC never will die... So I hope I will find the time to go on with some further improvements which we also can overtake into the new osoz firmware. Have a nice evening Hayo
Hi, who knows personally the engineers who sold the oscilloscope? I am still waiting to receive it won on EBAY! Disappeared? if anyone can contact them look a refund.
Giuseppe schrieb: > Hi, who knows personally the engineers who sold the oscilloscope? > I am still waiting to receive it won on EBAY! > Disappeared? > > if anyone can contact them look a refund. Hi Giuseppe, just if the sellers ebay name was 'welecgmbh', you may get in contact with Mr. Erich Wittig (E.Wittig@welec.de). He seems to be an honest person. Kind regards, Peter M.
> So I hope I will find the time to go on with some further improvements > which we also can overtake into the new osoz firmware. Und Hayo, was gibt es denn inzwischen so Neues zu berichten? Das ist hier so richtig still geworden, schade! Wohin treibt das Schiff?
Hi Robert, auch wenn es hier momentan sehr ruhig ist - ich bin immer noch dabei, zur Zeit halt passiv. Leider hatte ich bislang eine Menge anderer Sachen um die Ohren. Zudem ist der Stand der BF-Firmware eigentlich recht stabil. Die Not und der Druck etwas zu tun ist daher nicht sooo groß. Echte Verbesserungen sind aus diesem FPGA-Design leider ohnenhin nicht mehr rauszuholen. Deswegen verfolge ich auch mit Spannung die Fortschritte die Jörg macht. Denn echte Verbesserungen werden nur so möglich sein. Es lohnt daher eigentlich nicht für das alte Design größere Neuentwicklungen zu starten. Sollte es noch kleinere Wünsche (zusätzliche Funktionen oder Menüeinträge), Verbesserungen oder Bugs geben die ich beheben kann mache ich das natürlich gerne. Gibt es da konkrete Wünsche die sich noch lohnen in die bisherige FW einzubauen? Gruß Hayo
>Gibt es da konkrete Wünsche die sich noch lohnen in die bisherige FW >einzubauen? Von meiner Seite aus zur Zeit nicht. Wollte halt nur mal den Stand der Dinge wissen. Aber schön zu wissen das Du noch am Ball bist!
Hayos Posting hatte ich doch glatt eine Weile übersehen, irgendwie ist die Benachrichtigungsfunktion nicht mehr scharf. Ich bin nächste+übernächste Woche voraussichtlich ein paar Tage dienstlich in Hamburg, wir planen auch ein Treffen. Vor etwa einem Jahr war ich schon mal bei Hayo, wird nun schon fast eine Tradition! ;-) Noch was: Sourceforge "droht" mit einer Umstellung, wir müßten auf deren neue Allura-Platform migrieren. Was das genau bedeutet weiß ich nicht. Die Adresse soll sich in dem Zuge auch ändern. Ich habe natürlich noch nicht auf das angebotene Knöpfchen gedrückt, aber es soll im ersten Quartal 2013 durch sein. Jörg
Angeregt durch Robert habe ich noch mal über die letzte BF-Version sinniert und bin darauf gestoßen, dass es noch einige Sachen gibt mit denen ich etwas unzufrieden bin, die aber völlig Hardwareunabhängig sind und somit eigentlich als Basis für OSOZ dienen könnten. Dazu gehört zum Beispiel der zentrale FFT-Algorithmus und noch einige andere Berechnungen. Mal sehen ob ich mich aufraffen kann da noch eine aktualisierte Version zu bauen. Gruß Hayo
Hi there. Hayo, about improvements to be introduced in the calculations are you thinking something for the sin(x)/x interpolation? I believe it would be a great thing, seems to me some attemps was had already been made in the past and the routine already drafted but never implemented in firmware. And again, any news about the spikes fix? It seemed me we were on the right way, maybe through updating the fpga by quartus to reach 1c9.0e version or so and adjusting the power supply value of the FPGA, but then no news about this important issue. Cheer, Cy
Cy schrieb: > Hayo, about improvements to be introduced in the calculations are you > thinking something for the sin(x)/x interpolation? The sinc interpolation is implemented yet as a draft. But it costs a lot of time of development and there have to be done some more improvements. The main problem is the slow NIOS cpu. The calculation of the sinc algorithm is very slow, although I tried to optimize the calculation speed. But it is not forgotten, I just made a little break to solve some other issues. If Jörgs new OSOZ FPGA with multiplication unit is running stable, it will be no problem to implement the sinc interpolation. > And again, any news about the spikes fix? I got no news about that, but maybe some of the other guys here? This problem will also be obsolete with Jörgs new FPGA-design. I'm looking forward... But the good news are: I'm working on a new BF-version with improved FFT routines. Maybe I will get ready until XMas. Kind regards Hayo
Das "Gipfeltreffen" mit Hayo fiel erstmal aus, weil ich einen Tag später als geplant in Hamburg anfing, Hayo hatte nur am ersten Tag Zeit. Im Januar könnte sich nochmal die Gelegenheit bieten. Für die FFT könnte ich im neuen Design Hilfestellung anbieten. Der Nios erlaubt ja "custom instructions", man könnte vielleicht sowas wie einen Butterfly-Befehl bauen. Im Moment bin ich aber noch an anderen Baustellen. Ein etwas anderer Programmierstiel kann nützen, Tabellen sind nicht mehr unbedingt so angesagt wenn sie nur wenige Rechenoperationen ersetzen. Der Nios II hat als neues Feature zwar einen Datencache, aber der ist leider nicht mehrfach assoziativ. Heißt, wenn 2 Adressen binär hinten gleich enden (modulo Cachegröße in die gleiche Cacheline fallen), dann werfen sie sich zwingend gegenseitig aus dem Cache. Ein Lesezugriff der einen anderen Cacheeintrag verdrängt führt erstmal zu einem Burst aus 8 Schreibzugriffen, dann ein Burst aus 8 Lesezugriffen, in Summe vielleicht 20 Takte. Die Datenbursts können leider auch nicht "critical word first", also die Zugriffsreihenfolge so sortieren daß das gewünschte Datum zuerst gelesen wird und es möglichst schnell weitergeht. Der Instruction-Cache hingegen beherrscht diese Umsortierung, das wäre sonst wohl auch echt übel. Die Länge einer Datencacheline ist einstellbar, man kann die auch verkürzen, für Anwendungen die viel random access machen. Wegen des Instruction-Cache sollte man von loop unrolling eher Abstand nehmen, das bringt nicht viel und verdrängt anderswo Code aus dem Cache. Jörg
Hallo, ich hätte da noch einen Vorschlag für eine Funktion die mich da brennend interessieren würde. Ich bastle ab und an mal an analogen Verstärkerschaltungen und habe dann das normale und das verstärkte Signale an einem Kanal. Wäre es möglich softwaremäßig 2 Kanäle automatisch über einander legen zu lassen und das schwächere Signal per Software zu verstärken bzw. das stärke abzuschwächen. Bei einem analog Oszi kann man neben der 1:10 1:100...Auswahl noch manual stufenlos das Signal noch etwas abschwächen. Wodurch man dann beide signale übereinanderschieben kann. Das ganze müsste auch nur im Single Shot Modus funktionieren dann könnte man soetwas direkt übereinanderlegen und vergleichen. http://www.hobby-bastelecke.de/bilder/schirmbilder/sinus2gleich.jpg
@Jörg Ja die Optimierungen werden beim NIOS II sicher anders aussehen. Da muß man sicher auch etwas mit Try and Error experimentieren was unter dem Strich wirklich was bringt. Nicht desto Trotz bin ich momentan mit dem Ergebnis der überarbeiteten FFT-Routinen recht zufrieden. Das hat auch wieder Lust auf "Mehr" gemacht. Als Referenz verwende ich unter Anderem auch die FFT des chinesischen OWON SDS8102 welches ich seit einiger Zeit besitze. Da muß sich unser Teil nicht verstecken, im Gegenteil. @Thomas Das Thema variable Skalierung hatten wir in der Vergangenheit öfters mal. Grundsätzlich: Ja, ist machbar! Ist aber etwas Fummelkram mit den Skalierungstabellen, da diese dann für jede Einstellung neu berechnet werden müssen. Habe ich aber auch schon drüber nachgedacht. Wäre auf jeden Fall eine nette Herausforderung. Als weitere interessante Herausforderung hatte ich mir schon mal Gedanken zu einer Peak-Detect-Funktion gemacht. Auch nicht trivial aber machbar. Da müßte ich dann Teile in Assembler schreiben um einigermaßen performant zu sein. Sicher auch für OSOZ nicht uninteressant. Gruß Hayo
So Liebe W2000A Gemeinde, es gibt wieder neues Futter. Die neue Xmas Edition ist rechtzeitig zum Fest fertig. Diesmal habe ich an der FFT herumgeschraubt. Achtung - beim ersten Start kommt ein Popup hoch welches darüber informiert, dass die trigonometrischen Tabellen ins Flash geladen werden. Dieser Vorgang dauert ziemlich genau 10 Minuten. Eine Fortschrittsanzeige informiert über den aktuellen Stand. Also bitte mit einplanen und gegebenenfalls Kaffee bereithalten... Wird der Vorgang abgebrochen erscheint das Popup beim nächsten Start erneut, nach Abschluß des Ladevorgangs erscheint das Popup nicht wieder. Dear not german speaking users. Please read the attached read me file because of special upload notes. Gruß Hayo
Danke für das Weihnachtsgeschenk!! Spiele ich morgen gleich auf. Frohes Fest!
Hallo Hayo, willkommen zurück! Apropos Flash: ich hatte mal hier (Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)") u.A. geschrieben, das wir für den Nios-II eine Einteilung des Flash brauche, von wo der denn sein Image ablegen soll. Momentan holt es mein Bootloader von Adresse 0, ab dort habe ich aber nur 3 Pages (a 64k) frei, in der 4. speichert Osoz seine Einstelungen, ab der 5. beginnt das klassische Image. Ich überblicke den Rest nicht, könntest du mal eine Memory Map erstellen, oder gibt es schon eine? Jörg
Moin Jörg. Ja es gibt schon eine. Die aktuelle Version ist immer im jeweiligen Download im DOCS Verzeichnis zu finden unter W2000A Programmers Reference. Da mein Libre-Office die Dateien im Excelformat auf über 13MB aufbläht habe ich diesmal nur die .ods Datei mit reingetan. Ich habe aber gerade auf meinem alten Rechner mit Open Office 3 eine kleine kompakte Datei erzeugt und hänge sie hier mal dran. Zu den Änderungen in der neuen Firmware: Ich habe die bisherigen Tabellen die fest im Code abgelegt waren und damit zur Laufzeit das RAM unnötig blockiert haben rausgeschmissen. Stattdessen gibt es jetzt Generatorfunktionen, die die Tabellen berechnen und eine weitere Funktion, die diese dann ins Flash schreibt. Zur Laufzeit holt sich die FFT nur die jeweils benötigten Tabellen aus dem Flash ins RAM. Dadurch haben wir jetzt genügend Platz um jede Menge Fensterfunktionen in 4096er Breite unterzubringen. Das wäre sonst mit den fest codierten Tabellen etwas eng geworden. Mit der nächsten Version ist es auch geplant die FFT Menüs scrollbar zu machen, da es momentan etwas mühselig ist sich durch die vielen Einträge zu arbeiten. Gruß Hayo
Hallo Hayo, sehr schön, vielen Dank! Wenn das so stimmt gibt es ja tatsächlich geeignet große unbenutzte Bereiche, dann brauchen wir zunächst nichts limitieren oder herumschieben. Ich könnte z.B. die 10 Sektoren ab 0x600000 für das Nios II Image definieren? Bei 0x30000 liegt wie gesagt derzeit der Sektor für die Osoz-Settings, falls du das auch mit in die Tabelle aufnehmen magst. Kann von mir aus auch in einen anderen Sektor. Was ist das diverse "Kleinzeug" gegen Ende? Für die fernere Zukunft mit dem Nios II schwebt mir vor, den Code größtenteils aus dem RAM rauszuhalten (dafür ist es nämlich eigentlich zu schade) und direkt aus dem Flash auszuführen, Cache sei dank. Dann können wir uns feature-mäßig richtig austoben, vielleicht auch modular mit einem Plugin-System. Bis dahin sollten wir die Flash-Map aufgeräumt haben. Jörg
Jörg H. schrieb: > Ich könnte z.B. die 10 Sektoren ab 0x600000 für das Nios II Image > definieren? Ja, die sind leer. > Bei 0x30000 liegt wie gesagt derzeit der Sektor für die Osoz-Settings, > falls du das auch mit in die Tabelle aufnehmen magst. Kann von mir aus > auch in einen anderen Sektor. Ich kann das mit eintragen. > Was ist das diverse "Kleinzeug" gegen Ende? Das ist der Bereich in dem die Konfigurationsdaten liegen. "Protected" sind die festen Einstellungen, das Andere sind die gerade aktuellen Einstellungen die bei jedem Start restauriert werden. > Für die fernere Zukunft mit dem Nios II schwebt mir vor, den Code > größtenteils aus.... dem Flash auszuführen... Wie willst Du das machen? Mit einem Sprungbefehl direkt an eine Flashadresse verzweigen und dann den Code von da weiter ausführen? Hab ich so noch nicht gemacht, interessanter Gedanke. Gruß Hayo
Als Nachtrag: man müßte doch beim Code im Flash alle Sprungaddressen korrigieren um den Addressoffset zwischen RAM und Flash, sonst würde die Ausführung doch wieder zurück an eine RAM-Adresse springen. Oder wie hast Du Dir das gedacht? Hayo
Hallo Hayo, sorry, du bist völlig auf dem Holzweg. :-/ Der Linker täte das für uns erledigen. Man würde eine Section definieren die im RAM liegt und eine die im Flash liegt. Dann kann man für Funktionen oder Daten per #pragma oder auch globaler vorgeben, in welche Section sie sollen. Der Linker berechnet dann automatisch alle Sprungadressen korrekt, da muß man sich um nichts mehr kümmern. Etwas komplizierter ist der Startup-Code. Eine Section muß ins RAM kopiert werden (so wie derzeit alles), die andere bleibt unangetastet, liegt bereits an der richtigen Adresse. Beim alten Nios beginnt "unsere" Programmausführung sowieso im Flash. Der ROM-Bootloader springt dorthin, wenn eine Kennung vorhanden ist und nicht die magische Tastenkombi F1+F2 gehalten wurde. Dort liegt der Startup-Code, der von mir seinerzeit optimierte Hexfile-Schnipsel der immer vorangestellt wird. Der kopiert unser Zeug ins RAM und springt dorthin. Beim Nios-II ist es etwas intelligenter. Der ROM-Bootloader guckt im Flash nach einem "Boot Image", das ist eine Liste von zu kopierenden Speicherblöcken. Die arbeitet er selber ab, am Ende der Liste steht ein Sprungziel. Derzeit besteht die Liste aus nur einem Block, der ins RAM kopiert und angesprungen wird. Jörg
Aaah, verstehe. Also lag ich ja nicht sooo verkehrt, nur dass der Linker dann die Adressen gleich richtig berechnet. Wird die Ausführungsgeschwindigkeit nicht etwas gebremst? Schließlich müssen ja die Daten erstmal in den Cache geladen werden, insbesondere bei Cache-Miss. Die Zugriffszeiten auf das Flash sind doch nicht sonderlich schnell. Bei Cache-Hit läuft es dann natürlich mit voller Geschwindigkeit. Gibt es da Erfahrungswerte, oder sind das eher Vermutungen. Hayo
Hayo W. schrieb: > Wird die Ausführungsgeschwindigkeit nicht etwas gebremst? Schließlich > müssen ja die Daten erstmal in den Cache geladen werden, insbesondere > bei Cache-Miss. Die Zugriffszeiten auf das Flash sind doch nicht > sonderlich schnell. Mal rechnen...: "nicht sonderlich schnell" ist sogar geschmeichelt. Ich habe es am 25MHz Peripherie-Bus hängen, damit möglichst wenig am schnellen Bus hängt. Diese "Clock Crossing Bridge" kostet uns pro Richtung ca. 2 Takte, in Rückrichtung 2 von den langsamen. Das Flash ist nur 8 Bit breit, um eine Cacheline mit 8 32bit Worten zu füllen werden also 32 Zugriffe gebraucht. Das Flash hat 90 ns Zugriffszeit, wegen Aufrundung auf ganze Takte werden derzeit 120 ns draus. Das kann ich noch optimieren, der Peripherietakt kommt neuerdings aus einer PLL. Wenn ich da 44 MHz draus mache wären es 4 Takte für einen Zyklus, also 128 für eine Cacheline, plus 2 für die Bridge macht 130 von den 44MHz Takten plus noch 2 von den 75MHz Takten macht bestenfalls rund 3 us. Das SRAM schafft eine Cacheline in 11 von den 75MHz Takten, macht 0,15 us, ist also gut 20 mal schneller. Klingt erstmal dramatisch. > Bei Cache-Hit läuft es dann natürlich mit voller Geschwindigkeit. Gibt > es da Erfahrungswerte, oder sind das eher Vermutungen. Die geschwindigkeitskritischen Funktionen zum Zeichnen und Rechnen sowie Interrupthandler würde ich natürlich im SRAM lassen. Aber der ganze Menü-Code, Zeichensätze, etc. ist meiner Erfahrung nach völlig egal. Jörg
PS, gerade nachgemessen: Im Moment dauert eine Flash-Cacheline 3,85 us, das kommt hin, entspricht etwa der jetzigen Verlangsamung von 90 auf 120 ns.
Hmm, vermutlich muß man es am "lebenden" Objekt mal probieren wie es sich auswirkt bzw. bei welchen Funktionen es sich eher nicht auswirkt. Aber ist natürlich eine Möglichkeit das RAM freizuhalten. Wieviel RAM gibts denn im neuen Design? Hayo
Hayo W. schrieb: > Wieviel RAM gibts denn im neuen Design? Nach wie vor 2 MB SRAM, von den Chips verschwindet keiner, und ich habe leider auch keine Magie zu bieten da mehr draus zu machen. ;-) Verwechselst du das gerade mit FPGA-internem Speicher? Capture-Memory bleibt wohl auch bei 16K/Kanal, soll aber effizienter genutzt werden. Volle Größe auch bei Zeitbasen mit <4 ADCs, 32K wenn nur ein Kanal pro FPGA benutzt wird. Jörg
Ups, ja hab das mit dem RAM und dem Capture-Speicher verwechselt. Hayo
Hi Hayo, Jörg H., Thomas O. and guys all! Hayo, thanks You very, very much for the free time You provided generously to us and for this new firmware's version!!! I downloaded your latest great job, the new 1.2.BF.5.8XE and I will go to test it a bit. I will let you know, keep in touch! ;-) As always I am speechless, RESPECT!!! Jörg H schrieb: >Ein etwas anderer Programmierstiel kann nützen, Tabellen sind nicht mehr >unbedingt so angesagt wenn sie nur wenige Rechenoperationen ersetzen. Hayo, in the ultimate 1.2.BF.5.8XE firmware you moved FFT tables from RAM to flash memory. Is it also for compatibility with the Jörg H. new OSOZ FPGA design? Working synergically follow suggestions and planned road map will take us far, great work! Thanks Jörg H., Hayo and all which are involved in the Welec Project! Hayo W. schrieb: >The main problem is the slow NIOS cpu. >But it is not forgotten, I just made a little break to solve some >other issues. If Jörgs new OSOZ FPGA with multiplication unit is running >stable, it will be no problem to implement the sinc interpolation. Hayo, this is a good news, i believe sin(x)/x interpolation will be an important improvement for our beloved DSOs. Thanks a lot! Hayo W. schrieb: >> And again, any news about the spikes fix? >I got no news about that, but maybe some of the other guys here? This >problem will also be obsolete with Jörgs new FPGA-design. I'm looking >forward... OK Hayo and all. I hope someone fix the problem in a way or other. As it is now it is one of the great trouble with the Welec's DSOs. Lucky are the people which they have the 1C9.0E FPGA version because seems that have not the spikes problem if I am not wrong reading old posts in the forum. May be the new FPGA design surely solve the problem. Thomas O. schrieb: >Wäre es möglich softwaremäßig 2 Kanäle automatisch über einander legen >zu lassen und das schwächere Signal per Software zu verstärken bzw. das >stärke abzuschwächen. > >Bei einem analog Oszi kann man neben der 1:10 1:100...Auswahl noch >manual stufenlos das Signal noch etwas abschwächen. Wodurch man dann >beide signale übereinanderschieben kann. > >Das ganze müsste auch nur im Single Shot Modus funktionieren dann könnte >man soetwas direkt übereinanderlegen und vergleichen. I agree, good suggestion Thomas O.! That is roughly I wrote in the past about the possibility to implement FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx family DSO have it). I know, it is not simple, but perhaps with the new Jörg's new OSOZ FPGA... :-) We will see! ;-) A last thing if I can. It is about the anomaly in the scale factor when measuring pulse waveforms. Please refer at these: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" May be due an hardware lack, but it could even be a software problem. Has somebody noticed something like that? Thanks in advance Vielen Dank und Frohes Fest! Mit freundlichen Grüßen, Luc
Hallo an alle, Grüße aus dem Samnaun in der Schweiz und habe gerade festgestellt, dass es hier im Hotel WLAN gibt. Werde also mal zum Forum und auf die Mails antworten. Hi Luc, greetings from Swiss, the country of clocks. I will try to answer Your questions carefully. > I downloaded your latest great job, the new 1.2.BF.5.8XE and I will go > to test it a bit. > I will let you know, keep in touch! ;-) Thanks from my side too for your really good testing. In this version I only improved the FFT - not enough time. But it was a good possibility to start a comeback ;-) > Hayo, in the ultimate 1.2.BF.5.8XE firmware you moved FFT tables from > RAM to flash memory. > Is it also for compatibility with the Jörg H. new OSOZ FPGA design? Indeed, it is. Although the new design will have a much faster multiplication, the calculation of the trigonometric function, especially the window functions will cost too much time. So this part of the FFT calculation will be the same in the new design. But there are some other calculations that might be much faster in the new design and maybe we won't need tables for the scaling anymore. Also it may be possible to implement special "signal processor like" registers or processing options which will speed up combined multiplication and addition like FFT calculations (butterfly) or filter calculations like sinc interpolation. >>> And again, any news about the spikes fix? > I hope someone fix the problem in a way or other. This problem is for sure a problem with the timing in the FPGA when writing ADC values into the capture memory. If I'm informed right there are existing two main versions (in three FPGA versions) Version 1 (which are both of mine) has spikes only on some special situations and as my 4 Channel DSO when it is hot after using for some hours. Version 2 has the spike problem every time! If you got this version, the only possibility might be to change the FPGA version to one of the version 1 (don't know if someone tried this). The ultimative change will be the new OSOZ-Design, because of continuous development and improvement - and open source! > I agree, good suggestion Thomas O.! > That is roughly I wrote in the past about the possibility to implement > FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal > in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx > family DSO have it). Yes I know, my analog Tek does have it too and I like it. I will think about it... > A last thing if I can. > It is about the anomaly in the scale factor when measuring pulse > waveforms. > Please refer at these: > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" > May be due an hardware lack, but it could even be a software problem. I did not see this problem when I tested different wave forms. Maybe I have to check it once more... Wish you all a happy xmas ...and some snow and lower temperatures for me ;-) Hayo
Happy 2013 and thank you to Hayo and the team from Sandro
Neues Jahr, neues Glück. Wieder einige Bugfixes (auch von Dir Andi), Erweiterungen und Verbesserungen. Für diejenigen die die letzte Version (5.8 XE) noch nicht aufgespielt hatten: Nach dem Upload werden die trigonometrischen Tabellen neu berechnet und ins Flash geschrieben. Das dauert 10 Minuten. Ein Popup informiert über den Fortschritt. Viel Spaß
Hallo an alle, und vielen Dank Hayo für die neue Version. Die Erweiterung ist wirklich sehr brauchbar, freu! Gruß Jochen
Hallo allerseits, schon gibt es das nächste Update. Hintergrund ist der Beitrag von Jörg in dem er darauf hinweist, dass der Abschlußwiderstand im DSO Eingang aufgrund der parallel liegenden ADCs nicht 150 Ohm betragen muß sondern 174 Ohm um einen Gesamtwiderstand von 150 Ohm zu erreichen. Durch den falschen Abschluß wird sonst der Vorverstärker am Ausgang überlastet. Ich habe also den Widerstand gegen 180 Ohm (ist eine gängige Größe) ausgetauscht und kann bestätigen, dass die vorher aufgetretenen leichten Verzerrungen (Treppchenbildung) verschwunden sind. Wer also in seiner Eingangsstufe etwas ohne großen Aufwand optimieren will sollte die Kombination 24.9 Ohm / 180 Ohm verwenden. Passend dazu habe ich die Skalierungsfaktoren in der neuen Version angepaßt. Die Faktoren für die Kombination 24.9 Ohm / 150 Ohm stehen weiterhin zur Verfügung, sozusagen als Bestandsschutz. Gruß Hayo p.s. wer absolut keine Widerstände auf Teileträgern findet - ich habe noch 4998 Stück in 180R rumliegen.
Moin Hayo, werden die trigonometrischen Tabellen nach dem letzten Update nicht wieder in das Flash geladen, oder bleiben diese erhalten? Wo werden die denn hingeschrieben, vielleicht in den protected Bereich? Denn nach dem Flashen, wird sonst nichts geladen, das Welec ist danach sofort betriebsbereit! Gruß Michael
Moin Michael, > werden die trigonometrischen Tabellen nach dem letzten Update nicht > wieder in das Flash geladen, oder bleiben diese erhalten? Genau, einmal ins Flash geschrieben bleiben die auf ewig (so ungefähr jedenfalls) drin und müssen nicht mehr neu geschrieben werden. > Wo werden die denn hingeschrieben, vielleicht in den protected Bereich? Nein, die Tabellen liegen in drei eigenen Sektoren im hinteren Drittel des Flash. Dort ist noch eine ganze Menge ungenutzter Platz. Die Config und Protected Sektoren liegen ganz am Ende. Die genaue Belegung kann man sich in der Programmers Reference auf dem Tab "Flash" ansehen. > Denn nach dem Flashen, wird sonst nichts geladen, das Welec ist danach > sofort betriebsbereit! Genau, so soll es sein. Gruß Hayo
Hi, ich melde mich auch mal wieder, nachdem ich eine Weile nicht öffentlich in Erscheinung getreten bin. Letzte Woche habe ich Hayo besucht. Wir haben unsere Zeit leider nicht sehr effizient genutzt, haben hauptsächlich Quartus installiert (und sind nicht ganz fertig geworden damit), statt eine Roadmap zu pflegen, Hayo in Osoz und Nios II einzuarbeiten, etc... Den zweiten Teil des Abends waren wir beim berühmten Griechen. Nun weiß ich, warum es Hayo da so gefällt. ;-) Hayo W. schrieb: > Hintergrund ist der Beitrag von Jörg > in dem er darauf hinweist, dass der Abschlußwiderstand im DSO Eingang > aufgrund der parallel liegenden ADCs nicht 150 Ohm betragen muß sondern > 174 Ohm um einen Gesamtwiderstand von 150 Ohm zu erreichen. Durch den > falschen Abschluß wird sonst der Vorverstärker am Ausgang überlastet. > > Ich habe also den Widerstand gegen 180 Ohm (ist eine gängige Größe) > ausgetauscht und kann bestätigen, dass die vorher aufgetretenen leichten > Verzerrungen (Treppchenbildung) verschwunden sind. Die Ehre gebührt Branadic, nicht mir. Überlastung ist weniger das Problem (glaube ich mich zu erinnern), eher eine Fehlanpassung, was die HF-Eigenschaften verschlechtert. Warum nicht gleich den richtigen Widerstand von 174 Ohm einlöten? Den "Fehler" hatten wir doch schon mal, mit 33 oder 22 Ohm statt der 24,9. Wer will denn diesen Zoo von Fehlbestückungen im UI haben? Ich finde, wir sollten nur die Originalbestückung und den korrekten Wert unterstützen, nicht alles mögliche was irgendwer gerade in der Bastelkiste hatte. Wer das löten kann, der kann sich auch die korrekten Werte besorgen. Und wenn sich die Erkenntnis ändert, dem folgen. Wir sind nicht im Hardwarethread, aber im Zusammenhang der Längswiderstände: Mit denen verringert sich die Spannung am ADC und der Vorteiler kann im Ausgleich mehr draufgeben, eine Stufe unempfindlicher werden. Beides zusammen sorgt dafür, das der ADC wesentlich besser ausgesteuert wird, quasi perfekt statt vorher nur gut zur Hälfte. Die Darstellung wird deutlich feiner, weil die Software die Rohwerte nicht so aufzoomen muß. Leider beginnt im neu erreichten Aussteuerbereich bereits die Sättigung der letzten Ausgangsstufe, die wird dort etwas nichtlinear. (Müßte in der FFT-Darstellung gut als K3 zu sehen sein.) Um das zu vermeiden kann laut Branadic die Versorgungsspannung des letzten OpAmp von 3,3V auf 5V umgeändert werden. Das hat aber noch keiner ausprobiert. Scheint zusammen mit Längswiderständen eine sinnvolle Modifikation zu sein. Jörg
Damit das hier nicht zu offtopic wird habe ich das mal in den Hardwarethread umgebogen: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Kleine aber feine Info über die Tests mit dem OSOZ Triger-API in der BF-Firmware: Ich habe jetzt den Pulsweitentrigger überreden können in allen drei Betriebsarten zu arbeiten: - Trigger wenn die Pulsbreite kleiner als der Schwellwert - Trigger wenn die Pulsbreite größer als der Schwellwert - Trigger wenn die Pulsbreite zwischen zwei Schwellwerten Das funktioniert tatsächlich ganz gut. Ich war selbst überascht. Wahrscheinlich haben die Jungs von WELEC das selber noch nie funktionierend gesehen. Ihr seht schon, die nächste Firmwareversion hat dank der Arbeiten an OSOZ einiges an Verbesserungen zu bieten. Gruß Hayo
Und da ist sie auch schon. Da sich ziemlich viel getan hat, habe ich die Firmware auf die nächste Major-Version gebracht. Die Änderungen am Triggerinterface sind so umfangreich, dass man vom alten Coding kaum noch was wiederfindet. Der Einbau des OSOZ Trigger-API hat den Vorteil, das man Erkenntnisse aus Tests sowohl aus der einen als auch der anderen Richtung sofort in das jeweils andere Coding übernehmen kann. In Kürze die Änderungen: - OSOZ-Trigger-API - neuer Triggermodus "Free Run" - Pulsweitentrigger funktioniert jetzt in allen drei Bereichen - Alle Triggermodes sind jetzt auch für den Pulsweitentrigger verfügbar Gruß Hayo p.s. Holdoff ist zum Teil getestet und scheint ganz anständig zu funktionieren. Detailiertere Tests folgen noch.
moin Hayo, war gerade am Rechner und habe das Welec angestöppselt, dann die 6.0 in 10sek. aufgespielt... Nach dem Neustart und Default Setup, ist im Edge-Modus kein Triggerlevel einstellbar! Nach einiger Sucherei, hatte ich den Übeltäter! Der Source-Button war quasi leer!? Ein Haken steht unter Source, keine Quelle. Als Source dann Kanal eins angewählt und es triggert. Nur mal so zur Info! Gruß Michael
Danke für die Info, den Effekt hatte ich bei mir auch, nur dachte ich, dass das durch die Testerei passiert ist. Ich schau mal nach wo das herkommt. Also an Alle: Nach dem Update die Trigger Source neu einstellen! Please setup the trigger source after updating Your firmware! There is a little failure which deletes the correct entry. Hayo
Im Puls-Width Modus ist alles hübsch soweit, da funktioniert der Trigger-Level nach dem Update! Irgendwie komme ich mit dem Free run-Modus nicht klar, was bedeutet das denn? Im Free run-Mode, hat der Trigger-Level keine Wirkung auf das Signal... Gruß Michael
Ok Fehler gefunden und behoben. Im Default Setup wurde das Menü falsch vorbelegt. @ Michael Free Run heißt zu gut Deutsch -> Trigger ausgeschaltet. Daher auch keine Reaktion auf den Level. Das DSO wartet also nicht bis zum nächsten Ereignis, sondern liest sofort die neue Dataline ein. Deswegen sieht das Signal dann so unruhig aus. p.s. Mist falsche readme erwischt - die zweite ist die aktuelle
@Hayo > Im Default Setup wurde das Menü falsch vorbelegt. Wenn man es weiß, passt das ja. Sonst hast du nix geändert? > @ Michael > Free Run heißt zu gut Deutsch -> Trigger ausgeschaltet. Daher auch keine > Reaktion auf den Level. Das DSO wartet also nicht bis zum nächsten > Ereignis, sondern liest sofort die neue Dataline ein. Deswegen sieht das > Signal dann so unruhig aus. Mit anderen Worten, kann man das Signal nur im Stop bzw. im Single-Modus betrachten? Ich habe das gerade mal getestet, im Single-Modus bleibt das Signal nach jedem drücken, schön auf der selben Stelle! Das finde ich jetzt praktisch. Gruß Michael
Michael D. schrieb: > Sonst hast du nix geändert? Zur ersten Compilation nicht. Ich habe außer den besagten Änderungen auch wieder weiter in den Variablen aufgeräumt. Heißt überflüssige nicht benutzte Variablen gelöscht, kontextabhängige Variablen als Attribute in die entsprechenden Klassen verschoben und sinnig neu benannt. Nebenbei gehe ich dann immer noch durch und tausche numerische Array-Indices gegen sprechende Defines oder Enumeratoren. Und bei letzterem ist mir einfach das falsche Define in das Menü geraten. Vielleicht sollte ich nicht immer bis früh morgens programmieren, da bleibt irgendwann die Konzentration auf der Strecke... Hayo
Hayo W. schrieb: > Vielleicht sollte ich > nicht immer bis früh morgens programmieren, da bleibt irgendwann die > Konzentration auf der Strecke... Außerdem gibt das auf die Dauer nur Stress mit der besten ... ;-) Grüße, Guido
Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt kommt... ;-)
Hayo W. schrieb: > Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt > kommt... Vielleicht sollte sie dann mal eine Arztserie gucken? ;-) Zum Oszi: ist der Trigger jetzt für Osoz aktuell eingecheckt? Ich hätte da noch Fragen: - Es gibt 2 Funktionen, die am SPI drehen, namentlich CaptureTrigSetExtSource() und CaptureTrigSetExtCoupling(). Die gehören nicht in den Capture-Treiber, der soll sich nur mit dem FPGA beschäftigen. Ich hatte in trigger.c bereits TiggerSetExtSrc() und TiggerSetExtCoupling() vorgesehen. Da ist auch bereits Code, ist der in Ordnung? Ich hatte auch bereits den TV-Trigger vorgesehen. - Du hast die "magischen Registerwerte" für ctrl und adc_ctrl verändert, wie kamst du darauf, klappt das auch noch mit einem 2Kanäler? Mußte man da nicht was aus dem Protected Flash auslesen oder die FPGA-Version heranziehen, um die korrekten Werte einzustellen? Ich meine das hatte ich noch nicht fertig. Geht das auch ohne, machst du das in deiner BF-Firmware nun auch so? Jörg
Jörg H. schrieb: > Hayo W. schrieb: >> Die nutzt die Gelegenheit und guckt Frauensendungen bis der Arzt >> kommt... > > Vielleicht sollte sie dann mal eine Arztserie gucken? ;-) Die sind ihr auch zu doof... > Zum Oszi: ist der Trigger jetzt für Osoz aktuell eingecheckt? Ich hätte > da noch Fragen: Nicht ganz, einige Kleinigkeiten sind noch offen, siehe unten... > beschäftigen. Ich hatte in trigger.c bereits TiggerSetExtSrc() und > TiggerSetExtCoupling() vorgesehen. Da ist auch bereits Code, ist der in > Ordnung? Ich hatte auch bereits den TV-Trigger vorgesehen. Aah, das war der Hinweis den ich brauchte. Baue ich natürlich noch ein. Beim TV-Trigger habe ich das Problem, dass ich nicht genau weiß was der eigentlich machen soll, da mir die Anforderungen eines Fernsehtechnikers unbekannt sind. Grundsätzlich soll der ja wohl irgendwie auf das jeweilige Syncsignal (hor. / vert.) triggern. Mir fehlen da aber Details. Ich weiß auch nicht ob das von unserer Hardware unterstützt wird. Irgendeinen Sync-Interupt gab es ja glaube ich. Dazu kommt, dass das eine aussterbende Technik ist. Bei uns z.B. gibt es keinen einzigen Röhren-TV mehr. > - Du hast die "magischen Registerwerte" für ctrl und adc_ctrl verändert, > wie kamst du darauf, klappt das auch noch mit einem 2Kanäler? Alles durch Ausprobieren. Natürlich immer für beide Versionen, deshalb hab ich ja auch den "DSO-Stack" auf meinem Tisch stehen. Außerdem wurden die Registerwerte in der alten FW auch noch direkt während des Schreibens verändert ohne das diese Werte in den Shadow zurückgeschrieben wurden. D.h. die angezeigten Werte waren nicht die tatsächlich eingestellten Werte! >Mußte man > da nicht was aus dem Protected Flash auslesen oder die FPGA-Version > heranziehen, um die korrekten Werte einzustellen? Nein, nicht bei diesen Registern. Das sind channel_Adr und adc_change. Die werden aus dem Protected Flash gezogen. > Ich meine das hatte > ich noch nicht fertig. Geht das auch ohne, machst du das in deiner > BF-Firmware nun auch so? Die Triggerregister werden in beiden Firmwareversionen identisch gesetzt. Das API ist genau das Gleiche. Die beiden ADC-Steuerregister hattest Du mit Defaultwerten vorbelegt. Eine Flashleseroutine habe ich nicht gebaut, das müßte noch gemacht werden. Soll ich da irgendwie tätig werden? Die Trigger-Register werden bei mir vor jedem Einstellvorgang auf einen Initialwert gesetzt und dann mit dem API richtig eingestellt. Dafür fehlt eigentlich noch eine entsprechende Funktion im API (CaptureTrigPrepare() oder CaptureTrigReset() oder so ähnlich). Die CaptureInit() ist dafür nicht geeignet da hier alle Register initialisiert werden. Hayo
> Die Trigger-Register werden bei mir vor jedem Einstellvorgang auf einen > Initialwert gesetzt und dann mit dem API richtig eingestellt. Ich habe noch mal einige Tests gemacht, und festgestellt, das die Initialisierung vor jedem Einstellvorgang nicht notwendig ist. Diese hatte ich am Anfang eingeführt um immer eine saubere Ausgangssituation zu haben. Das API scheint aber so konsistent zu sein das nur beim Systemstart einmal initialisiert werden muß. Eine Prepare() Funktion ist damit also überflüssig. Hayo
Hayo W. schrieb: > Beim TV-Trigger habe ich das Problem, dass ich nicht genau weiß was der > eigentlich machen soll, da mir die Anforderungen eines Fernsehtechnikers > unbekannt sind. Grundsätzlich soll der ja wohl irgendwie auf das > jeweilige Syncsignal (hor. / vert.) triggern. Mir fehlen da aber > Details. Ich weiß auch nicht ob das von unserer Hardware unterstützt > wird. Irgendeinen Sync-Interupt gab es ja glaube ich. Im Welec ist sogar ein extra Chip für den TV-Trigger. Insofern fände ich es schade, das brachliegen zu lassen. Ich hatte da mal ein Stück weit verfolgt. Dieser Sync-Separator ist an Kanal 1 angeschlossen. Alle TV-Optionen machen also nur dort Sinn. Mit den SPI-Bits wird ein Mux gesteuert, der die externe Triggerquelle umschaltet. In Software muß man also wenig tun, nur diesen Mux bedienen. (Ein zukünftiges FPGA-Design könnte noch die gewünschte Zeile auszählen und dann erst triggern...) > Dazu kommt, dass > das eine aussterbende Technik ist. Bei uns z.B. gibt es keinen einzigen > Röhren-TV mehr. Auch eure Flachbildschirme können mit einem FBAS-Signal umgehen... ;-) Seit einiger Zeit ist es beliebt, mit Microcontrollern durch Bitbanging ein Fernsehsignal zu erzeugen, um so z.B. günstig ein Display zu haben. Gibt's diverse Postings zu, hier im Forum. Auch von daher finde ich das nicht ausgestorben. >>Mußte man >> da nicht was aus dem Protected Flash auslesen oder die FPGA-Version >> heranziehen, um die korrekten Werte einzustellen? > > Die Triggerregister werden in beiden Firmwareversionen identisch > gesetzt. Das API ist genau das Gleiche. Die beiden ADC-Steuerregister > hattest Du mit Defaultwerten vorbelegt. Eine Flashleseroutine habe ich > nicht gebaut, das müßte noch gemacht werden. Soll ich da irgendwie tätig > werden? Sehr gern. Das Flash ist ja direkt lesbar, also braucht es da keine großartige API, einfach einen Zeiger aufsetzen und los. Jörg
Jörg H. schrieb: > Sehr gern. Das Flash ist ja direkt lesbar, also braucht es da keine > großartige API, einfach einen Zeiger aufsetzen und los. PS: Wenn's netter ausschauen soll, mit FlashSectorGetAddr() holen.
Nett aussehen soll es ja auf jeden Fall...
Bin gerade dabei das API zu überarbeiten und stelle erst jetzt fest, dass ja das API für den externen Trigger schon komplett fertig in trigger.c enthalten ist. Ich schmeiße das also aus capture.c wieder raus und passe auch das API in der BF Firmware an damit die Ergebnisse reproduzierbar sind. Ist in Arbeit...
Hallo, habe heute gerade mein W2022A auf die neue Firmware aktualisiert. Wenn ich mit dem w200a-screenshot Tool probiere auf das Oszi zuzugreifen bekomme ich folgende Meldung:
1 | * Connecting to DSO and retrieving version information... done |
2 | w2000a-screenshot: This version needs at least firmware version 2.20, but you've got 0.0. |
3 | Please update your DSO. |
Außerdem habe ich noch folgende Probleme: CH1: Auf 1:1 eingestellt (Tastkopf auch): Sobald ich die Skalierung auf größer 1V/div Stelle bekomme ich kein Signal mehr. Normal oder habe ich es irgendwie geschafft den Eingangsverstärker oder so zu schießen? Bei Tastkopf 10:1 ergibt sich das selbe ab Skalierung 10V/div. CH2: Sobald ich einen Offset einstelle (Position der Waveform am Bildschirm) und Teile des Signals liegen in der oberen Hälfte zeigt das Oszi starke Spitzen bzw einen dicken grünen Balken für die Signalteile, unabhängig von der eingestellten Skalierung. Ist dies normal? Danke, Stefan
Hallo Stefan, Stefan S. schrieb: > CH1: Auf 1:1 eingestellt (Tastkopf auch): Sobald ich die Skalierung auf > größer 1V/div Stelle bekomme ich kein Signal mehr. Normal oder habe ich > es irgendwie geschafft den Eingangsverstärker oder so zu schießen? Bei > Tastkopf 10:1 ergibt sich das selbe ab Skalierung 10V/div. Das beschriebene Verhalten habe ich auf meinem Gerät nicht! Ich habe zusätzlich noch einen Test beim Kanal 2 durchgeführt .... auch da kann ich Deinen Fehler nicht reproduzieren. Probier noch einmal "Utility", "Default Setup" ... Gruß Andi
Hallo Stefan, mein Screenshot funktioniert einwandfrei. Hast Du als Destination "PC" gewählt? Auch die anderen Probleme treten bei meinen Geräten nicht auf. Wie Andi schon sagt Default Setup machen. Bzw. vielleicht die Firmware nochmal flashen. Gruß Hayo
Angehängte Dateien:
-
ch1_2v.jpg
86 KB -
ch1_5v.jpg
85 KB -
ch1_10v.jpg
85 KB -
ch2_5v.jpg
83 KB -
ch2_5v_offset.jpg
84 KB -
ch2_5v_more_offset.jpg
86 KB -
ch2_offset_persist.jpg
60 KB
Hallo, Default Setup und Firmware nochmals flashen haben nichts gebracht. Im Anhang noch ein paar Bildchen. Stefan
Angehängte Dateien:
-
ch2_10ns.jpg
80 KB
Hallo, also das Problem auf Channel 2 tritt nur auf bei einer Timebase kleiner 10us. Bei 10us ist alles o.k. doch sobald ich auf 5us drehe kommen die Störungen. Hier noch ein Bild der Spitzen bei 10ns Timebase. Bei CH1 hört man ein Relais umschalten wenn ich bei 1:1 von 500mV auf 1V schalte. Bei 500mV sehe ich noch was bei 1V nichts mehr. Da scheint es mir irgendwas intern zerstört zu haben. Komisch da ich bis jetzt nur an 5V uC-Schaltungen / FPGA gemessen habe und eigentlich immer mit 10:1 Tastkopf.... Hatte das Oszi lange nicht im Betrieb und jetzt diese Probleme. Hoffe jemand von euch kann mit weiter helfen. Danke, Stefan
Stefan: die Spitzen sehen mir aus wie die berüchtigten Spikes, Datenübernamefehler intern im FPGA wegen zu agressivem Timing, sprich schlechtem Design. Bessert sich das wieder, wenn du auf die ältere Software zurückgehst? Hayo: wird das vielleicht mit dem neuen Code forciert, weil die magischen Register nicht so stehen wie vorher? Jörg
Hallo Jörg, In der Zwischenzeit habe ich mich größtenteils durch die Welec Threads hier gekämpft. Ich habe mein Scope jetzt auseinandergenommen und die RAM und ADC Bausteine nachgelötet. Nach dem Zusammenbau sind die Probleme von Kanal 2 verschwunden. Juhu. Für Kanal 1 werde ich in den nächsten Tagen mal das Scope wieder auseinander nehmen und unter der Abschirmung nachschauen was es mir da zerstört hat. Danke, Stefan
War wieder fleißig gestern nacht und heute. Die neue Version enthält das OSOZ API für den externen Trigger und den TV-Trigger. Angeregt durch Jörgs Hinweise habe ich den TV-Trgger auch gleich implementiert und getestet. Das Sync-Signal liegt an Kanal 1 an. Ich habe mit einem 15.6 KHz Rechtecksignal getestet (was ungefähr dem Vertikalsync entspricht). Der externe Triggerlevel muß einen positiven Wert haben, dann triggert es. Scheint soweit also tatsächlich zu funktionieren. Detailiertere Tests müßte man an einem echten Syncsignal vornehmen. Gruß Hayo
Hallo Hayo, mal kurz zwischendurch, ein kleiner Vorschlag... Wäre es sinnvoll den Noise-Filtern statt den Namen: Smooth, Strong, usw... vielleicht in die Grenzfrequenzen umzubennen? Z.B. 20MHz, 30MHz... oder cut-20MHz, cut-30MHz... fände ich etwas informativer. Gruß Michael EDIT: Zusätzlich vielleicht noch ein kleines Info-Fenster oben in der Leiste, welcher Filter gerade aktiv ist...
komisch ist die Sache mit den Spikes aber trotzdem. Bin ja scheinbar nicht der einzige bei dem das jetzt auf einmal verstärkt bzw. überhaupt auftaucht. Zwar konnten wir die Sache auf einen Temperatureinfluss zurückführen (siehe Hardware Thread) (unter 10°C gibts wohl bei allen Geräten die Spikes?), allerdings habe ich die Spikes definitv jetzt auch bei etwas niedrigeren Raumtemperaturen direkt nach dem Einschalten, wo sie früher nicht vorhanden waren. Unabhängig auch wenn ich eine alte FW aufspiele. @sar: kannst du das Spike Problem nach deiner Lötaktion auch bei niedrigeren Temperaturen als erledigt bezeichnen? Hast du mit Heissluft oder mit dem Lötkolben nachgelötet? Fast ein Hardware Beitrag geworden, sorry.
@ben: Ich habe mit Heißluft gelötet. Werde mal schauen ob ich das Oszi an die frische Luft für einen Test bewegen kann.
@Michael Du willst aber auch wieder alles... ;-) Das Problem bei der Benennung ist, dass mir nichts wirklich Sinnvolles eingefallen ist. Die Grenzfrequenz beim Smooth-Filter ist die halbe Abtastfrequenz, da dieser verlustfrei arbeitet mit den ungenutzten Werten zwischen den angezeigten Punkten. Der Strong Filter liegt da etwas niedriger, ist aber auch abhängig von der eingestellten Abtastrate und der Anzahl der Punkte die zwischen der angezeigten Abtastung liegen. Du siehst also - nicht so einfach. Gute Ideen sind aber willkommen und fließen auch sofort in die Firmware ein. Also macht weitere Vorschläge... Übrigens - in der Leiste ist kein Platz mehr, die ist schon voll. Jedenfalls bei den 4 Kanalern. @Ben Mir war es nie aufgefallen, weil meine DSOs immer den ganzen Tag lang laufen wenn ich programmiere und teste. Die sind also immer auf Temperatur. Geht evtl. einigen Anderen ähnlich. Ich habe es erst gemerkt als ich wegen des Hinweises meine Büchse mal bei niedrigen Temperaturen auf der Terrasse angemacht habe. Da war ich echt erstaunt. Das Problem gab es aber wahrscheinlich schon von Anfang an. Falls die Lötaktion tatsächlich Abhilfe geschaffen hat wäre das natürlich eine Maßnahme um dem zu Leibe zu rücken. Gruß Hayo
Hayo W. schrieb: > Gute Ideen sind aber willkommen und > fließen auch sofort in die Firmware ein. Also macht weitere > Vorschläge... kein Problem, hier ist ein SEHR guter Vorschlag: bei Buttons die den 'Wert' mit anzeigen nervt (zumindest mich) das 'popup' extrem, i denk das koennte man doch abschalten. Z.B. bei Coupling steht DC , mochte ich auf AC umschalten druecke ich den Button, dann ein popup, und dann nochmal druecken um auf AC zu schalten, ohne Popup waehre es nur ein Tastendruck und auch von der zeit her schneller, unn was meist du dazu ? vlG Charly
@Hayo > Du willst aber auch wieder alles... ;-) Selbstverständlich! ;-) Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz gedacht, kann jetzt aber durch einen Hack um die 200MHz. Da drin werkelt ein Hantek-Board, welches ursprünglich für diese Bandbreite gedacht war. Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, was aber praktischer Weise auch auf dem Display angezeigt wird, daher kam mir diese Idee. > Das Problem bei der Benennung ist, dass mir nichts wirklich Sinnvolles > eingefallen ist. Die Grenzfrequenz beim Smooth-Filter ist die halbe > Abtastfrequenz, da dieser verlustfrei arbeitet mit den ungenutzten > Werten zwischen den angezeigten Punkten. Das wäre doch schon mal ein Anhaltspunkt!? > Der Strong Filter liegt da > etwas niedriger, ist aber auch abhängig von der eingestellten Abtastrate > und der Anzahl der Punkte die zwischen der angezeigten Abtastung liegen. Der Strong Filter bügelt ja quasi alles weg. Irgendwo war doch mal eine Liste der Grenzfrequenzen, die auch u.a. IIR 1-3 Stage beschreiben, oder? Ich finde die leider nicht mehr. > Du siehst also - nicht so einfach. Gute Ideen sind aber willkommen und > fließen auch sofort in die Firmware ein. Also macht weitere > Vorschläge... > Übrigens - in der Leiste ist kein Platz mehr, die ist schon voll. > Jedenfalls bei den 4 Kanalern. Ja, eben. Jetzt könnten die 2Kanaler ja egoistisch sein...kann man da nicht noch etwas rücken? Oder, wie sieht es denn rechts oder links, neben dem Grit aus? Könnte ja auch mit den Cursern bzw. mit der Nullinie mit wandern, oder... Vielleicht hat ja noch jemand einen guten Vorschlag? @Charly mich nervt das auch ein wenig. Leider hat das Gerät auch keine Drehgeber mit Drucktaster, da wäre es einfacher. Nur wo willst du dann mit der GND-Option hin? 3x drücken, müßte man ja trotzdem Gruß Michael
@Michael einmal druecken = um eins weiterschalten, warum eigentlich einmal druecken um das popup zu oeffnen und dann nochmal druecken um eins weiterzuschalten ? vlG Charly
@Charly Ich verstehe schon was Du meinst. Bei meinen alten Analog-Oszis ist das auch bequemer, aber da steht auch auf dem Panel dran was der Knopf macht. Bei dem Bedienkonzept der modernen Oszis wird aber Platz auf der Front gespart, indem eine Menügesteuerte Bedienung eingesetzt wird. Da hat man aber nicht die Möglichkeit die Bedienoptionen eines Knopfes auf dem Panel unterzubringen, sondern muß das irgendwie als Popup umsetzen oder bei weniger Optionen gäbe es die Möglichkeit in der ersten Zeile des Knopfes die Optionen anzuzeigen, und in der zweiten Zeile ein Symbol für die Auswahl (so wie beim Pulsweitentrigger der < > >< Knopf). Bei AC DC GND wird es aber schon ganz schön eng in der ersten Zeile. Weitere Möglichkeit wäre, das nicht das Popup mit der aktuellen Einstellung aufpopt, sondern gleich beim Drücken einen weiter springt und die neue Einstellung anzeigt, dann wäre kein weiterer Druck mehr nötig. @Michael Die Liste mit den Frequenzen findest Du in dem "Docs" Verzeichnis in der Datei "Special Functions". > Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz > gedacht, kann jetzt aber durch einen Hack um die 200MHz. Ja ich hatte davon in einem Forum gelesen. Und? Bist Du mit dem Gerät zufrieden? Wie ist die Benutzerführung/Bedienbarkeit? (ist etwas offtopic hier, aber evtl. kann man ja gute Umsetzungen in unsere Firmware übernehmen). Ich habe ja auch ein Vergleichsgerät von den China Boys hier bei mir, Das OWON SDS8102. Technisch ist das Gerät unserem ziemlich überlegen, aber die Bedienung und die Spezialfunktionen sind nicht so gut Revision von mir gibt es hier: Beitrag "WELEC W2000A vs. OWON SDS8102" ...aber die kennst Du glaube ich schon. Wieder zurück zum Filter. > Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, Ja das ist Standard, und das hat unseres auch, das ist die "BW Limit" Option. Das ist aber ein Hardwarefilter, das eigentlich die meisten Oszis haben. Damit kriegt man aber nicht das ADC-Rauschen oder intern erzeugte Spikes weg. Die Filter die ich da eingebaut habe sind Softwarefilter, die erst nach der ADC-Wandlung greifen und daher auch interne Einflüsse glattbügeln. Sowas haben nur wenige Oszis im Angebot. > Oder, wie sieht es denn rechts oder links, neben dem Grit aus? > Könnte ja auch mit den Cursern bzw. mit der Nullinie > mit wandern, oder... Hmm, da wäre ich eher dafür das in der Gridfarbe in der oberen linken oder rechten Ecke im Grid selbst einzublenden. Das Signal würde dann einfach drüberliegen wenn es denn mal in die Ecke käme, was aber eher nicht die Regel ist. Wäre das eine Option? Gruß Hayo
@Hayo > Die Liste mit den Frequenzen findest Du in dem "Docs" Verzeichnis in der > Datei "Special Functions". Ups, sollte da doch öfter mal vorbei schauen... >> Ich habe hier noch ein Voltcraft 3062C. Dies war eigentlich als 60MHz >> gedacht, kann jetzt aber durch einen Hack um die 200MHz. > Ja ich hatte davon in einem Forum gelesen. Und? Bist Du mit dem Gerät > zufrieden? Ich bin damit "soweit" zufrieden, weil es ziehmlich schnell ist. Z.B. Beim einblenden von Measure(wird eingeblendet rechts vom Display), was bei uns "Quick Measure" ist, gibt es keine Geschwindigkeitseinbuse, egal ob ein oder zwei Kanäle eingeschaltet sind, da lahmt ja schon das Welec. Der Bildschirm ist riesig und es passt natürlich jede Menge drauf, die Auflösung ist 800x480 Pixel. Noch ein großer Vorteil ist eine USB-Schnittstelle und ein USB-Slot für Speichersticks. Auf die Sticks kann man bequem Screenshots speichern und über diese werden auch Software-Updates auf das DSO gespielt, also ist man nicht vom PC abhängig. Das war mal ein kleiner Auszug. Um etwas mehr darüber zu erfahren müsstest du mal in diese Threads schauen, die auch schon eine beachtliche länge erreicht haben: Beitrag "VOLTCRAFT DSO-3062C 60 MHz = baugleich mit?" Beitrag "TEKWAY DST1xx2B Oszilloskop" Natürlich wird auch dort das Eine oder Andere schlecht geredet, man hat eben keine Eierlegende Wollmilchsau und für den Preis, ist das Voltcraft völlich in Ordnung! > Wie ist die Benutzerführung/Bedienbarkeit? (ist etwas > offtopic hier, aber evtl. kann man ja gute Umsetzungen in unsere > Firmware übernehmen). Eben, warum denn nicht? Der Vorteil von der Bediehnbarkeit her ist, das "fast" alle Drehgeber, Drucktaster besitzen, da ist das Einstellungsziehl schneller erreicht. Ansonsten hat das Teil so viele Funktionen und um diese zu erreichen, muß man sich natürlich auch etwas durch die Menus und deren Untermenus rangeln. Ansonsten hat man es mit etwas Übung schnell raus. Manchmal erwische ich mich dabei beim Welec auf den Knöppen herum zu drücken, wie doof ist das denn? Ich habe ja auch ein Vergleichsgerät von den China > Boys hier bei mir, Das OWON SDS8102. Technisch ist das Gerät unserem > ziemlich überlegen, aber die Bedienung und die Spezialfunktionen sind > nicht so gut Revision von mir gibt es hier: > Beitrag "WELEC W2000A vs. OWON SDS8102" > ...aber die kennst Du glaube ich schon. Ja, ist aber auch schon eine Weile her und wieder in Vergessenheit geraten. Ich hatte tatsächlich mal mit dem Gedanken gespielt, mir ein Exemplar zuzulegen. Ich hatte das wieder verworfen, da mir das Angebot von Voltcraft in die Quere kam. Ich hätte es nie erstanden, wären die oben angegebeben Threads nicht gewesen! > Wieder zurück zum Filter. >> Wie auch immer, im Moment kann man nur einen Filter von 20MHz setzen, > Ja das ist Standard, und das hat unseres auch, das ist die "BW Limit" > Option. Das ist aber ein Hardwarefilter, das eigentlich die meisten > Oszis haben. Du Schande, ich wußte bisher nichts damit anzufangen, dabei ist die Definition ja eindeutig: Bandbreitenbegrenzung? > Damit kriegt man aber nicht das ADC-Rauschen oder intern erzeugte Spikes > weg. Die Filter die ich da eingebaut habe sind Softwarefilter, die erst > nach der ADC-Wandlung greifen und daher auch interne Einflüsse > glattbügeln. Genau! Das Voltcraft/Hantek/Tekway, haben ebenfalls diese Softwarefilter, sind aber leider ohne Funktion! Mich stört das ein wenig, wenn ich beim messen, diverse Überlagerungen wegfiltern möchte. Da punktet dann das Welec! Da kann ich Einiges platt machen und mich später um die HF-Störungen kümmern... > Sowas haben nur wenige Oszis im Angebot. >> Oder, wie sieht es denn rechts oder links, neben dem Grit aus? >> Könnte ja auch mit den Cursern bzw. mit der Nullinie >> mit wandern, oder... > Hmm, da wäre ich eher dafür das in der Gridfarbe in der oberen linken > oder rechten Ecke im Grid selbst einzublenden. Das Signal würde dann > einfach drüberliegen wenn es denn mal in die Ecke käme, was aber eher > nicht die Regel ist. Wäre das eine Option? Allerdings! Sowas in der Richtung dachte ich mir erst auch, der Platz wird eh kaum benutzt. Ich bin schon auf deine Umsetzung gespannt! Du weißt ja, für einen User gibt es nichts schöneres, als ein Update mit neuen Funktionen!!! Gruß Michael
Ist schon in Arbeit, die ersten Versuche sehen ganz nett aus. Leider habe ich den Rest der Woche eine Schulung bei der ich der Referent bin. Da bin ich Abends immer ziemlich platt - mal sehen ob ich da noch Lust habe mich dranzusetzen. Ansonsten am Wochenende. Hayo
Angehängte Dateien:
-
OnScreenStatus01.jpeg
48 KB
Hier schon mal eine kleine Kostprobe. Der OnScreen Status ist natürlich im Display Menü abschaltbar. Hayo
na, das ist ja mal was! Durch den quasi "Hologramm" Effekt, wirkt sich das nicht störend auf das Grid aus. Da könnte man ja noch reichlich Infos einblenden, bei Bedarf! Was wäre denn noch so relevant? Sieht schon mal gut aus!!! Gruß Michael
Hayo W. schrieb: > sondern gleich beim Drücken einen weiter springt > und die neue Einstellung anzeigt, dann wäre kein weiterer Druck mehr > nötig. Genau so meine ich das, sowas waehre super, und dann wenn machbar noch als kleine 'luxuserweiterung' ein druck wechselt zw AC & DC und ein langer druck zb. > 1s schaltet auf GND ich meine das Agilent machte das so vlG Charly
So, nachdem ich mich den ganzen Tag mit Programmieranfängern rumschlagen mußte habe ich mich mal rangesetzt und ein paar entspannte Zeilen reingehämmert. Hier eine Beta zum Ausprobieren. 1. Der On Screen Status (OSS). Läßt sich im Display Sub-Menü anschalten. Der Zustand wird aber noch nicht im Flash gespeichert. Ist also beim nächsten Anschalten wieder aus. Auch sind die Texte noch an festen Positionen. Angedacht sind variable Slots, die immer linksbündig verschoben werden je nachdem was gerade angezeigt wird oder nicht. Bedient werden zur Zeit Logic Average Noise Filter 2. Der AC/DC Button. Auf Kanal 1 habe ich mal eine mögliche Lösung implementiert die eigentlich alle Bedürfnisse abdeckt. Langsames Einfachdrücken -> das bekannte Menü poppt hoch Schneller Doppeldruck -> es wird zwischen AC / DC hin und her geschaltet Probiert mal aus ob das Euren Vorstellungen entgegen kommt. Gruß Hayo
@Hayo dankeschoen!, wenn du jetzt das noch umdrehst/vertauscht wuerde ich es als PERFEKT ansehen also quasi so: Schneller Doppeldruck -> das bekannte Menü poppt hoch Langsames Einfachdrücken-> es wird zwischen AC / DC hin und her geschaltet denn man (ich) schaltet vieeeel oefter zw. ac & dc um als ich das popup mit GND brauche vlG Charly
Hahaha, das hatte ich mir gedacht. Hab ich auch im ersten Anlauf so gemacht, aber das Popup das dann beim Doppeldruck hochkommt läßt sich mit dem Doppeldruck nicht richtig bedienen. Ich kann mal versuchen ob ich da mit einem Hackentrick weiterkomme, kann aber nichts versprechen. Gruß Hayo
noch ein Vorschlag: (wenn besser realisierbar) kurzer druck wechselt AC/DC langer druck = GND ne Frage am Rande, wozu wird hier GND eigentlich noch gebrauch? bei meinem 'Analog-Oszi' brauch i es manchmal aber hier nie 2. was passiert bei GND ? wird da der Eingang wirklich auf GND geschaltet oder nur der Wert des AD Wandlers einfach durch $80 ersetzt ? vlG Charly
Charly B. schrieb: > ne Frage am Rande, wozu wird hier GND eigentlich noch > gebrauch? bei meinem 'Analog-Oszi' brauch i es manchmal > aber hier nie > 2. was passiert bei GND ? wird da der Eingang wirklich auf > GND geschaltet oder nur der Wert des AD Wandlers einfach > durch $80 ersetzt ? Üblicherweise ist diese Funktion dazu da das Rauschen der Eingangsstufe zu quantifizieren, nicht zuletzt auch für die Kalibration. Beim Welec und bei vielen anderen DSOs der unteren Preisklasse ist diese Funktion jedoch nicht in Hardware umgesetzt, sondern eine reine Softwaresache und damit eigentlich obsolet. Theoretisch könnte sie hier daher auch gelöscht werden, weil sie niemandem einen wirklichen Nutzen bringt. branadic
Danke branadic, das hatte ich vermutet, i denke Hayo kann 'das GND' weglassen vlG Charly
Leider hat branadic recht, schöner wäre ein Relais, welches den Eingang des ADC auf Masse schaltet. Leider ist das dem Geiz zum Opfer gefallen. Evtl. kann man das Signal für Tests einiger mathematischer Funktionen verwenden, da es halt die mathematisch exakte Nulllinie des ADC simuliert. Ansonsten ist der Nutzen in der Tat eher kosmetischer Natur. > noch ein Vorschlag: (wenn besser realisierbar) > kurzer druck wechselt AC/DC langer druck = GND Das mit dem Kurz oder Lang ist nicht so einfach, das kann man nur mit einem Timer realisieren. Da muß man dann einen Timer mit einer Zeitkonstante laden und in einer Interuptserviceroutine entsprechend reagieren. Unsere drei Timer sind aber schon für diverse Sachen in Benutzung. Andere Möglichkeit wäre ein Zeittakt, den Jörg für seinen Heartbeat-timer nutzt, den Vsync-Interrupt, den könnte man evtl. nutzen. Ist aber alles etwas aufwändiger. Ich schau mal... Hayo
Halo Hayo, saubere Arbeit, fällt kaum auf im Grid und stört keinesfalls! Gefällt mir sehr gut!!! Die Werte würde ich nicht nachrücken lassen, sondern auf einer festen Position belassen. Das geht mir schon beim Quickmeasure auf den Geist, das da die Einheiten immer herum wandern, nur dort geht es wohl nicht anders... Ich habe hier mal den Auszug der Cutoff-Frequenzen: - Smooth ca. 80-90 Mhz - Strong ca. 30 Mhz - IIR 1 Stage ca. 70-80Mhz - IIR 2 Stage ca. 35-40Mhz - IIR 3 Stage ca. 20MHhz mir würde es besser gefallen, nur die Frequenzen der Filter im Grit-Menu einzublenden. Das hat eine klare Aussage, finde ich! Was meint der Rest dazu? Gruß Michael EDIT: Wäre es nicht praktischer den BW-Limit Button in das Average Menu zu verschieben?
@Hayo i denk du sollst da nicht unnoetig energie reinstecken, mein vorschlag: lass Gnd und das popup weg und ein druck auf die Taste schaltet zw. AC und DC um, fertich vlG Charly
Die Cutoff-Frequenzen sind nur für Abtastrate 1GS/s richtig! Die Eckfrequenzen der Softwarefilter hängen natürlich immer von der Abtastfrequenz ab. Der Smoothfilter hat in allen langsameren Zeitbasen die Cutoff-Frequenz der halben virtuellen Abtastrate, da die tatsächliche Abtastrate viel höher ist und die ungenutzetn Samples für die Filterung benutzt werden. > Wäre es nicht praktischer den BW-Limit Button in das Average Menu > zu verschieben? Da passen keine 4 weiteren Buttons rein! Hayo
Charly B. schrieb: > mein vorschlag: lass Gnd und das popup weg und ein druck > auf die Taste schaltet zw. AC und DC um, fertich Ja ich glaube Du hast recht, das scheint das Praktischste zu sein. Hayo
Die "alte" Hardware kann nicht zwischen kurzem und langem Drücken unterscheiden, weil nur die eine Flanke gemeldet wird, der Status nicht abfragbar ist. So zumindest mein Forschungsstand. Die neue Nios II Hardware kann das "natürlich". ;-) Jörg
War ja klar :-) I'm looking forward... Hayo
Hier eine geänderte Version mit einfacher Druckfunktion. GND ist nicht mehr auswählbar. So wird es dann wohl auch bleiben. Hayo
Hi Hayo and guys all!
Apologize me for my lack in communication in recent months but
I was a bit busy.
Hayo, again thanks You very much for the free time You generously
provided to us and for this new firmware's version!!!
I downloaded your latest great job, the new 1.2.BF.6.2beta and I've
tried it a little.
Now I'm a bit hurry but in the week end I hope to let You know my
impression on it but I'd like to take this opportunity to say some
things about what I could see: of course as always this is only for
knowledge and no for criticism.
I noted that the graticule setting in the display menu doesn't work.
Only line is drawn on the screen, dotted never appeared or if it is in
its place I get some corruption on the line graticule.
Sometime even changing modality (entering FFT, X-Y or Delay for
instance) I get garbage on the screen expecially in graticule but
may be also on other things on the screen.
This I tested either W2022a and W2012a.
Hayo W. schrieb:
> GND ist nicht mehr auswählbar. So wird es dann wohl auch bleiben.
I understand GND flag is always been as a cosmetic function without
any functionality but I would have preferred it was not removed because
I often used it as a marker on the screen.
That is on my opinion.
As I have already had occasion to write now we can choose to show or
hide markers' line when Quick Measure are switched on, but I believe
that could be useful to have the cursors visible in Quick Measure.
Let me explain better.
I mean set the cursors in the Cursors screen, not necessarily
simultaneously Time and Voltage cursors but even only one type at a
time, then keep them fixed visible on the Quick Measure screen in order
to use them as reference.
I do not mean to have functioning cursors on the Quick Measure screen
(that already there is it and we know it can be switch on or off by
setting
in DISPLAY menu) but only set them in the Cursors screen and then
keep them visible on that of the Quick Measure.
Practically this would to superimpose some static marker on the Quick
Measure screen, not necessarily that they have to be adjustable when
on the Quick Measure screen.
Many DSOs allow it, for example the TDS220 do it, not Time and Voltage
cursors at same time but only one at a time but it is however useful in
my opinion.
In some occasion I happened to sacrifice one channel by putting it in
GND mode and using it as a marker on the screen in order to perform
some measures.
Okay, okay, I know there are other way to reach the same result hence
GND is not so indispensable, but IHMO for me would be better not to be
cleared it from the choices
Hayo thank You very much again, You are great: RESPECT!!!!!!!
Vielen Dank!
Mit freundlichen Grüßen,
Luc
P.S. Today, yesterday due the time ;-), my W2022a and W2012a "battled"
against some DSO (LeCroy and Tektronix) winning on them in the display
of an elusive short and fast signal.
The W2012a has achieved similar performance than a Wave Ace 224 by
LeCroy whch is a 200MHz bandwidth DSO, the W2022a was better than
the WaveAce 224.
The results were confirmed by a 500MHz bandwidth DPO by Tektronix,
where the W2022a showed the real shape of the signal that the WaveAce
224 and the W2012a could only do suppose.
* Vielen Dank an alle Unterstützer des Projekts Welec! *
* * * * R E S P E C T ! ! ! * * *
Hi Luc, as always I enjoyed reading Your precise description of Your analysis and tests :-) The grid problem is a "beta" bug and disappeared in the version 6.3 which is coming out soon. What to do with the GND function is - indeed - difficult to decide. Without it the handling is much faster and more pleasant but sometimes (I agree) it is a littlebit useful to have the ground line (which is created by writing ADC zero into the memory). I racked my brain to get a solution which fits all requirements - but without success. One Idea I got just in this moment. What about using the button as AC/DC switch only but offering the complete Menu with GND/AC/DC when turning the main wheel? Is that a suggestion? If You have a better idea - don't hesitate to tell us! Kind regards Hayo
@Hayo im 'Mode/Coupling' Menu koennte man auch die beiden ersten Tasten ohne 'popup' konfigurieren, dankeschoen! @Luc i use as Marker one of the Grid Lines, then you can switch off the not used Channel and you 'speedup' the Scope ;) best regards & vlG Charly
Hi, wenn jemand daran interessiert ist mein W2022A zu kaufen, dann biete ich es hier jetzt an. Es hat die oben beschriebenen Macken. Preisvorschläge bitte per PN. lg, Stefan
@all: Bevor ich das Scope verkaufe habe ich jetzt gerade nochmals die 1.3er orginal Firmware aufgespielt. Die oben beschrieben Spikes (Heißluft behob das Problem nur temporär) und auch die Probleme mit dem Kanal 1 sind mit der orginal FW nicht vorhanden! Hat mich gewundert, ist aber so. Gibt es noch irgendwas, was ich testen kann um auch die neue Firmware zu verwenden? Danke, Stefan
Hab ich das jetzt richtig verstanden? Mit der WELEC Gurken-FW hast Du zwar auch die Spikes, aber keine Probleme mit Kanal 1, während Du mit der BF-Firmware auf Kanal 1 Probleme hast? Gruß Hayo
Hallo Hayo, Die Spikes sind weg. Wegen Kanal 1 habe ich mich getäuscht. Da habe ich nur auf die angezeigte Kanal-Skalierung geachtet. Diese wird allerdings beim Umschalten 1:1 zu 10:1 nicht angepasst bei der orginal FW. Aber die Spikes sind weg und sind bis jetzt auch nicht wieder da. Stefan
Angehängte Dateien:
-
EXT_Trig_slope_high.png
4,8 KB -
EXT_Trig_slope_high.jpg
47 KB -
EXT_Trig_slope_low.jpg
47 KB -
ALT_TRIG.jpg
55 KB -
DELAYED.jpg
76 KB -
Spikes_when_two_trace.jpg
55 KB -
512_points.jpg
55 KB -
1024_points.jpg
55 KB -
2048_points.jpg
55 KB -
4096_points.jpg
55 KB -
Q-Measure.jpg
43 KB -
X-Y.jpg
47 KB -
HOLD_OFF.jpg
56 KB -
Delayed_.jpg
75 KB
Guten Abend Hayo, Charly B., Rainer W. und alle! Wie versprochen Hier ist eine kurze Anleitung, die neue Firmware 1.2.BF.6.2beta. I briefly tested it with my poor equipment, nothing exceptional, but I want to contribute. Because I'm a little dumb sadly I missed some of my screenshots, few in this occasion, so Rainer W. (rawi) not have to worry this time: they are only 13! ;-) I think I had better save screenshots directly from DSO instead of being stored in it and then sent to the computer, this because I saw some parameters were changed in values when I read them from the DSO in order to put them in the computer, strange thing but it is so (of course some parameters are missed in that way, for instance the HOLD OFF value, but that is normal). However doing so I tested memory function and it works fine! Due the fact my reference is a 150MHz bandwidth analog oscilloscope I tested my W2012a comparing it with the first, even if the Welec has the 24,9/150 ohm hardware modifications, so its bandwidth is now about 170MHz for what I could see. The W2012a also have all the hardware modifications on the trigger stage as they was described on this Forum. The W2012a DSO was set like follow: ADC SETUP: High Frequ PRE GAIN: 24,9/150 ohm DRAW MODE: Accurate ACQUIRE: Normal As always what will it to follow is only for knowledge and no for criticism. Said that, here the results. Pulse Trigger works fine in all setting (Normal, Auto, Combi). I tested it with my old and trusted Lyons Instruments pulse generator, I tried it quickly and seems to me there isn't any issue on it, RESPECT! EXT Trigger also works fine but I noticed something strange Using a sine wave in order to test it there are not problems when slope is changed, while using a pulse then changing slope have no effect if trigger level have not tuning. Tuning the trigger level fix the issue but however saving the waveforms in the DSO, after recalling them the sine ones are OK but pulse ones are shifted in respect with the trigger position on the top of the screen. I hope I was understandable. Please see screenshots "EXT Trig slope low" and "EXT Trig slope high". ALT TRIGGER, it works. However, the value in the top of the screen is strange: for instance I had trigger level set to 1,10V but when I switched to the ALT TRIGGER it became 50,4V, I don't know why and if this is normal or no, I emphasize it only as knowledge. Please see screenshot named "ALT TRIG". Using DELAYED screen, as well using "Pre Triffìgger Keep+follow", "Keep Value and "Trace Middle", get garbage on the waveforms at the trigger time expecially analyzing two waveforms, seems to me something related with the infamous "spikes problem". Same issue is present in MAIN screen using "Pre Triffìgger Keep+follow", "Keep Value and "Trace Middle", others configurations are OK. Seems to me setting "PRETRIGGER GRID MIDDLE" occasionally moves from the center of the grid and it is necessary to reset it. Please see screenshots "DELAYED" and "Spikes when two trace". FFT had some issues. The graticule had garbage(*) on it and this is known, but seems to me "div" and "fN" values change when choosing for 512, 1024, 2048 and 4096 points. 512 and 1024 points has not changed, but 2048 and 4096 they have their own values. Seems to me also scale factor changed setting 2048 and 4096 points but may be a consequently to other problems in this beta version. Good the rotary controls, of course 2048 and 4096 points slow down the screen refresh. Please look at the screenshots "512 points", "1024 points", "2048 points" and "4096 points". (*)Graticule issue also involves certain buttons, for instance sometimes FFT and X-Y become gray even if they can be activated by pushing their buttons. Perform reset do not fix grey buttons problem but only graticule and garbage on the screen. HOLD OFF seems to me it works great: RESPECT! As always the Quick Measure and the X-Y (**) mode they work like a charm. In reference to the precision attainable by the Quick Measure screen, please to look at the screenshot named "Q-Measure" (*) where you can see Quick Measure working on the output of my Lyons pulse generator setting for a 25Vpp pulse with a 10nS of rise time, 8nS of the fall time and 100nS width...RESPECT! (*) The time trigger position is wrong on the screenshot for the reason I anticipated when I wrote about the fact some parameters were changed in values when recalled from memory location, in real time it was right. (**)"X-Y" it show a 3,6MHz sine wave on X axis and a 44ns pulse repeated at 1MHz range on Y axis Sadly I was unable to verify the TV trigger, maybe next time ;-) And that's all, I hope I was understandable. @Charly B. You are right, thanks for the hint! Doing that way the DSO becomes speedy, me too sometimes use it. However for some kind of measures sometime I can't use that way because waveforms don't reach two lines on the graticule and sadly Volt/DIV aren't adjustable. Here is why I wrote in the past about the possibility to implement FINE/COARSE in the rotatory amplitude setting, thing it is pretty normal in analog oscilloscopes and some DSO(Tektronixs TDS2xx and TDS 1xxx family DSO have it, but this is another story. @Hayo (or somebody else which know the answer) I'm very dumb, I don't understand how to use "FREE RUN" trigger. Maybe elsewhere it was already explained but I can't find it. I would have more to say here and in the hardware thread, but sadly it's late now. Hayo thank you once again for the excellent work and the time devoted to us, as I also thank all those who are involved in the Welec project. Vielen Dank!!! Gruß Luc P.S. apologize me for my poor English, today even more bad than ever! I sent "EXT_Trig_slope_high.png" as error, sorry about that!
Stefan S. schrieb: > wenn jemand daran interessiert ist mein W2022A zu kaufen, dann biete ich > es hier jetzt an. Es hat die oben beschriebenen Macken. Bevor sich irgendwer über Spikes frustriert, wartet erstmal das Nios II Design ab. Mein Gerät ist mit dem Original-FPGA auch quasi unbrauchbar, bei den höheren Abtastraten kriege ich sogar Bildstörungen im LCD. Mit der neuen Hardware ist davon nichts zu sehen, die sonst unvermeidlichen Spikes sind auch weg. Das Originaldesign ist halt über-kritisch, vermutlich an diversen Stellen außerhalb des legalen Timings. Stay tuned... Jörg
@ Luc Thanks for testing so much and for reporting so detailed. I'm a little bit out of time, so let me say four things first: - the setting "High Frequ" in the hardware setup may fit some demands when measuring higher frequencies, but You have to disregard that spikes or other distortions may occur on the signal in some conditions. If You are measuring at lower Frequencies (< 10MHz) the factory setting is recommended. - Grid and drawing failures are only an beta problem and solved since BF.6.3 - FFT df/div are correct. Length 512 / 1024 both use full frequency range 0.5 * sample rate. Because of only 512 points available on screen the length 2048 uses 0.25 * sample rate and 4096 uses 0.125 * sample rate. So you can calculate by Your self which value is correct. - Trigger -> free run simply means trigger switched off. Data acquistion is running completely asynchronous as fast as it is possible without waiting until any event may occur. All other issues I have to check later Kind regards Hayo
Die neue BF.6.3 ist jetzt im SVN eingecheckt. Den Download hier bereite ich gerade vor. Die Switchlogik für Channel-Coupling habe ich so gelöst: 1 mal drücken wechselt sofort zwischen AC/DC. Mehrfaches Drücken bietet frei Auswahl im Popupmenü. Hoffe das findet Wohlwollen. Gruß Hayo
Ok wie versprochen die 6.3 zum download. Den neuen OnScreenStatus könnt ihr im Display-Submenü anschalten. Gruß Hayo
Beitrag #3042250 wurde von einem Moderator gelöscht.
Hallo Hayo, > Den neuen OnScreenStatus könnt > ihr im Display-Submenü anschalten. leider nicht, da du die 6.1 hier hochgeladen hast. Ich dachte schon, hätte einen an der Waffel und habe mir einen Wolf gedrückt, nix gefunden. Dann schaute ich in die FW-Info, da steht die 6.1 drin. Gruß Michael
Kann man den nicht sperren? Edit: Danke für das Löschen.
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo Sie wie immer schnell sein, so schnell, dass meine Antwort spät kam!:KLASSE!!! Hayo W. schrieb: >Die neue BF.6.3 ist jetzt im SVN eingecheckt. Den Download hier bereite >ich gerade vor. > >Die Switchlogik für Channel-Coupling habe ich so gelöst: > >1 mal drücken wechselt sofort zwischen AC/DC. Mehrfaches Drücken bietet >frei Auswahl im Popupmenü. Hoffe das findet Wohlwollen. klasse! :-) @Hayo about the new 1.2.BF.6.3 firmware release Hayo Vielen Dank für die unermüdliche Arbeit, dass Geschenke zu uns, Sie sehr freundlich: KLASSE!!! Ich laufe, es zu versuchen, nochmals vielen Dank! Vielen Dank!!! Gruß Luc
Was war das denn jetzt? Das war ja schnell gelöscht... Kann meine Aussage Jemand bestätigen?
Michael D. schrieb: > Hallo Hayo, > leider nicht, da du die 6.1 hier hochgeladen hast. Nein, das ist die 6.3, hab sie nochmal hier runtergeladen und geflasht. Im Utility-Menü kommt 6.3! Allerdings sehe ich gerade, dass die gepackten Dateien fehlen. Werd ich nochmal nachreichen. Was läuft da bei Dir schief? Gruß Hayo
Angehängte Dateien:
-
OnScreenStatus02.jpeg
44 KB
Wenn alles gut läuft sollte der Screen so aussehen! @Luc The Problem with Logic Analyser and QM should be solved now. If not, please contact me. @Michael Sag was, hast Du noch Probleme? Hayo
> Was läuft da bei Dir schief?
das ist ja interessant.
Ich habe den UCL-Ordner mit der schnelleren Übertragung in den Ordner
der 6.3 kopiert, dann das aktuelle Flash eingesetzt und es erschien in
der Info die 6.1 auch dessen Funktionen, also ohne OSS.
Jetzt habe ich den originalen Germsloader verwendet (der braucht ja um
Einiges länger), die Aktuelle 6.3 hinein kopiert und jetzt habe ich
plötzlich die richtige Version geladen, wie geht das denn?
Bevor ich los plärrte, hatte ich das noch mal mit der 6.2 getestet, die
auch geladen wurde. OSS konnte ich dort auch anwählen, allerdings noch
die Betaversion.
Verstehe ich jetzt nicht so ganz...
Gruß Michael
Das von Dir beschriebene Phänomen hatte ich auch - bei der Umstellung der Versionsnummer von 6.2beta auf 6.3. Dabei hatte ich nur die Versionsnummer geändert, sonst nichts. Nach dem Laden mit der normalen Flashdatei ging alles wieder. Ich dachte ich hätte mich im Verzeichnis geirrt. Sollte die UCL-Routine hier eine Macke haben? Jedenfalls ging es danach bei mir wieder ohne jegliche Beanstandung. Hat sonst noch jemand Probleme?
Ok, ich hab's rausgefunden! Die Endung im UCL-Verzeichnis heißt nicht "TomCat.flash" sondern "TomCat_flash.ucl" !!! Die Datei ist ja nur ganze 163kB groß!? Das heißt, ich muß die fette Flash gar nicht da rein kopieren! Na, jetzt bin ich schlauer. Wie habt ihr die denn so klein bekommen? Gruß Michael EDIT: Die Filter werden in MHz angezeigt, wie fein ist das denn? Sieht prima aus, du bist mein Held!!!
Michael D. schrieb: > Die Filter werden in MHz angezeigt, Und auch in KHz für die etwas langsameren TB. War ja Dein Vorschlag. Habe eine eigene Funktion geschrieben, die die Cutoff berechnet. :-) Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? Hayo
> Und auch in KHz für die etwas langsameren TB. War ja Dein Vorschlag. > Habe eine eigene Funktion geschrieben, die die Cutoff berechnet. Wie jetzt, da sind noch niedrigere Cutoff-Filter? Kannst du dazu noch was sagen? > :-) > Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? Optimaler geht's ja wohl nicht, da freut sich der Charly. BtW. mich hatte es jetzt nicht so gestört... Gruß Michael EDIT: Mit was hast du, (oder war es Jörg) denn jetzt das Flashfile komprimiert bzw. wo wird es wieder dekomprimiert?
Michael D. schrieb: > EDIT: Mit was hast du, (oder war es Jörg) denn jetzt das Flashfile > komprimiert bzw. wo wird es wieder dekomprimiert? Ich war's. Das Komprimieren passiert als Teil des Build nach dem Kompilieren, mit einem Tool namens "uclpack". Das ist zugegeben exotisch, aber komprimiert besser als zip und der Dekompressor ist sehr klein. Dekomprimiert wird es im Gerät. nach der Übertragung, vor dem eigentlichen Schreiben ins Flash. Das macht ein kleiner Loader, der zuerst auf "konventionelle Weise" geladen wird. So verbessern wir den Flaschenhals der seriellen Schnittstelle. Ich weiß gar nicht, warum der Hayo den alten Weg immer noch mit ausliefert, und das ucl-Flashing in einem Unterverzeichnis versteckt. Sorgt wie man sieht für Verwirrung, kipp' das doch mal auf den Müllhaufen der Geschichte! Jörg
Sorry, ich hab das so gepackt wie es bei mir auf der Platte liegt. Ich hab für mich ganz gerne noch die normalen Flashfiles als Backup, auch wenn ich sie nicht benutze. Beim nächsten Mal gibts dann nur noch die UCLs. Hayo
OK, gut, ich gebe schon Ruhe. ;-) Mir fällt auf, vielleicht sollten wir ein Make-Target "release" oder so haben, was alles nötige zusammenzipt? Jörg
Keine schlechte Idee, ich bin aber mit Make nicht unbedungt auf Du und Du. Ich müßte mich da erst tiefer reinarbeiten, da ich da sonst nur einfache Änderungen dran gemacht habe. Ich schau mir das mal an, ob mir da was Sinniges einfällt.
Michael D. schrieb: > Wie jetzt, da sind noch niedrigere Cutoff-Filter? Kannst du dazu noch > was sagen? Wie schon angedeutet sind es digitale Softwarefilter. Deren absoluter Bezugspunkt ist immer die Abtastrate. Alle Parameter dieser Filter sind immer relativ zur Abtastfrequenz (bei "Smooth" und "Strong" zur virtuellen, die indirekt durch die Zeit/div angegeben wird). Heißt etwas direkter gesagt, je niedriger die Abtastfrequenz, desto niedriger auch die Eckfrequenzen eines digitalen Filters. Gruß Hayo
Hallo Jörg und Hayo, Hayo W. schrieb: > Sorry, ich hab das so gepackt wie es bei mir auf der Platte liegt. Ich > hab für mich ganz gerne noch die normalen Flashfiles als Backup, auch > wenn ich sie nicht benutze. Beim nächsten Mal gibts dann nur noch die > UCLs. Lasst doch bitte die normalen Flashfiles im Makefile drin! Sie sind nunmal der native Weg die Firmware zu laden. Ich hatte ja schon vor längerer Zeit geschrieben, daß ich vor den UCLs grundsätzlich mit einem normalen Terminalprogramm (OcConsole/Win und glaube GTKTerm/Linux) geflasht habe. Das lief dann nur 5 min. Eine kleine Ewigkeit gegenüber den gepackten Dateien :-) Aber immernoch schnell gegenüber den oft gelesenen 20 min mit den Perl-Scripten bzw. Welecupdater. Das muss(!) gehen, wenn nicht im Hintergrund noch aller Unsinn läuft, der etwa die Serielle checkt und man ein vernüftiges Terminalprogramm und eine richtige RS232 benutzt Es gibt vielleicht Leute, die nicht erst Perl installieren wollen und mal schnell das Oszi updaten wollen. Danke! Grüsse Jürgen
Jürgen schrieb: > Lasst doch bitte die normalen Flashfiles im Makefile drin! Sie sind > nunmal der native Weg die Firmware zu laden. Im Makefile ist das sowieso drin, keine Sorge. Wenn's unbedingt sein muß, wie wäre es denn, umgekehrt die "legacy" Hexfiles in ein Unterverzeichnis zu verstecken? > Es gibt vielleicht Leute, die nicht erst Perl installieren wollen und > mal schnell das Oszi updaten wollen. Mal schnell, hihi. Ich glaube, Perl ist schneller installiert als auf den alten Flow zu warten... :-)) Wenn ich richtig flüstern höre wird es auch nicht (nur) bei Perl bleiben. Jörg
Jörg H. schrieb: > enn's unbedingt sein muß, wie wäre es denn, umgekehrt die "legacy" > Hexfiles in ein Unterverzeichnis zu verstecken? > Kein Problem! > > Wenn ich richtig flüstern höre wird es auch nicht (nur) bei Perl > bleiben. Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC schon lange drauf und wartet ungeduldig auf Programmer Input. :-) Jürgen
Btw... make release ist als Prototyp fertig. Bin gerade am Testen. Geht ganz gut. Hayo
Angehängte Dateien:
-
Backup-Flash.png
12 KB
> Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC > schon lange drauf und wartet ungeduldig auf Programmer Input. :-) aber sowas von... @Hayo > make release ist als Prototyp fertig. Bin gerade am Testen. Geht ganz > gut. fein! auch mal BtW. ich benutze gerade den Germs für ein Backup mit den Parametern: perl GERMSloader.pl COM6 -r flash_dump.flash 40000 7fffff Leider werden dafür satte 2400 Sekunden gebraucht, das macht über 40min. Gibt es eine Möglichkeit, auch das Dump ziehen zu beschleunigen? Vielleicht ist es ja nicht so wichtig, ich dachte nur, im Falle eines Problems, könnte man dann verifizieren!? ...nur so eine Idee. Gruß Michael
Das neue Makefile ist eingecheckt. Die Verzeichnisstruktur habe ich im ersten Wurf noch nicht geändert (nur Verzeichnisnamen umbenannt). @Michael Nein, das Gesamtbackup dauert halt etwas länger. Aber es werden nachher weniger als 40 min wenn ich mich recht erinnere, das ist nur die Anfangskalkulation. Hayo
>> Meinst Du etwa noch Software von Altera? Das ist auf dem Desktop-PC >> schon lange drauf und wartet ungeduldig auf Programmer Input. :-) > aber sowas von... Nein, die meinte ich eigentlich nicht, aber: Über JTAG kann man mit dem Nios II ruckzuck das Flash auslesen (oder brennen). Und von wegen Input: Ihr könnt das Design und Osoz für Nios II gern mal bauen. Der Andiiy macht das auch gelegentlich. OK, ich sollte mal ein Pre-Pre-Release machen. Jörg
Jörg H. schrieb: > OK, ich sollte mal ein Pre-Pre-Release machen. Na das wäre dann eine Alpha-Version. :-)
Ich wäre auch interessiert... Ich habe ja meinen JTAG-Adapter noch unbenutzt liegen. Bislang hatte ich noch keine Gelegenheit den mal zu testen. Mal wieder offtopic: Hat jemand das Bild zur Hand auf dem zu erkennen ist wo beim 4-Kanaler die Brücke hinmuß, damit Quartus die Büchse über JTAG erkennt? Hayo
öhm, warum in der HW stochern? Dafür gibt es doch den Altera-USB-Blaster.
Angehängte Dateien:
-
USB_and_JTAG.png
160 KB
Hayo W. schrieb: > Hat jemand das Bild zur Hand auf dem zu erkennen ist wo beim 4-Kanaler > die Brücke hinmuß, damit Quartus die Büchse über JTAG erkennt? Das gab es hier: http://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/USBBlaster/Solder%20here%20kl.JPG @ Mike > Dafür gibt es doch den Altera-USB-Blaster. Der geht dann auch auf JTAG. Siehe Anhang Jürgen
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo, nochmals vielen Dank für die hervorragende und unermüdliche Arbeit! Vielen Dank für die Zeit, die Sie bei uns verbringen, Sie sind sehr freundlich! Wie immer bin ich sprachlos!: KLASSE! Hayo W. schrieb: >@Luc > >The Problem with Logic Analyser and QM should be solved now. If not, >please contact me. Hayo there isn't need, as always You are right and all troubles which I have reported in the former beta version are gone: RESPECT!!! I quickly tested all them and none of them is survived in the new 1.2.BF.6.3 firmware's release. As usual in the weekend it will follow my review with more accurate tests. ;-) I'm working to improve my 300pS pulse generator adding to it a coaxial line stub. As You and All other here know, I'm pretty interested about the Welec's bandwidth and about how to improve it and I read in the "Wittig(welec) DSO W20xxA Hardware (Teil 2)" that there are some good news (thanks to Branadic for the intuition and thanks to Jörg H., Jürgen, Michael D. and Hayo for the the research of the implementation: RESPECT to all You!). I know, that is a bit OT here, so sorry about it, see You later in the Hardware thread. ;-) Returning IT, maybe I'm wrong but seems to me in this new release the trigger works better than ever either inner than EXTernal trigger, really very good: KLASSE! Even very nice and impressive the screen status as it is now implemented: KLASSE! But only one thing and as always only for knowledge and no for criticism. Hayo, now using ALTernate trigger the trigger level on the top of the screen became 0 Volt but adjusting it throught its knob it is possible to change the level, which however it remain as it was setted when ALTernate trigger is switched off returning in usual trigger mode (CH1 or CH2 for two channels DSO version or even CH3 or CH4 for the four channels version). Instead if the trigger level knob is not adjusted then switching among ALTernate tiggers and the previous setting, the trigger level shown on the top of the screen return to be as it was setted before to switch in ALTernate mode. Seems to me the values that I obtain by adjusting the trigger level knob during the time which ALTernate trigger is settled on are dummy, they are not real. I hope I was understandable although I realize I explained badly. However I don't know why and if this is normal or no, I emphasize it only as knowledge. Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Michael D. schrieb: >> Was sagt Ihr zu der Lösung mit der AC/DC Umschaltung? > Optimaler geht's ja wohl nicht, da freut sich der Charly. naja, nicht wirklich ;( es geht schon wieder so ein Popup auf und vergeudet 3 wertvolle Sekunden meines Lebens ;) ne im ernst, ein schnelles umschalten ist jetzt durch das Popup nicht moeglich, vielleicht bin ich auch durch das Agilent zu sehr verwoehnt worden.Bei mir ist es auch so dass ich nach einer recht kurzen Zeit ein von mir verwendetes Geraet quasi 'Blind' bediene, zB. weis ich wenn eine bestimmte Einstellung vorhanden ist dass ich zB. 3 mal die Taste druecken muss um die neue Einstellung zu erreichen. Da ich das Oszi halt auch Beruflich nutze sitze ich halt schon oefter mehrere Stunden davor. Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich doch nur weiterschalten kann? @Hayo, vielleicht ueberdenkste das nochmal mit dem Popup, ich waehre dir auf jedenfall dankbar dafuer (und wieder happy) vlG Charly
@Jürgen Jupp das isses, danke. Dann werd ich mal den Lötkolben anspitzen... @Michael Die Brücke muß auch für den Blastertreiber beim 4-Kanaler rein. @Luc Yes I know that the level adjusting in alternate mode is a little bit "suboptimal". The adjusting is alternating (as the trigger channel) and it is a little bit confusing. So the work around is, to adjust it before switching to alternate mode. I'm working on a solution. @Charly > Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich > doch nur weiterschalten kann? Du kannst mit einzelnem Druck direkt umschalten (ohne hinzusehen), was viel schneller geht, das Popup hat natürlich trotzdem noch seine Timeout-Pause. Aber man kann mit mehrfachem Druck auch GND auswählen was ich als ganz guten Kompromiss empfinde. Bliebe nur noch die Variante die ich schon angedacht hatte mit dem Drehknopf, dann könnte das Popup beim Druckknopf wegfallen. Ich schau mal... Hayo
Hayo W. schrieb: >> Frage: was macht das Popup eigentlich fuer einen Sinn wenn ich >> doch nur weiterschalten kann? > > Du kannst mit einzelnem Druck direkt umschalten (ohne hinzusehen), was > viel schneller geht, das Popup hat natürlich trotzdem noch seine > Timeout-Pause. Ja und genau diese Timeout Phase ist das Stoerende > Bliebe nur noch die Variante die ich schon angedacht hatte mit dem > Drehknopf, dann könnte das Popup beim Druckknopf wegfallen. Ich schau > mal... das waehre dann die wesentlich bessere Alternative denk ich vlG Charly
Ach ja was ich zu den Änderungen der letzten beiden FW Versionen vergessen habe zu erwähnen, was mir aber durch Lucs Beitrag wieder eingefallen ist - die Triggerlevelregister haben (was wir ja schon länger wissen) ein stark nicht lineares Verhalten und der Level stimmte anfangs überhaupt nicht. Ich hatte dann mal eine einfache Korrektur eingebaut, die aber den Nachteil hatte, dass es einen blinden Fleck irgendwo in der Signalmitte gab und der Trigger nur ab einer Mindestsignalamplitude von einem div ansprach. Seit FW 6.0 habe ich da einen neuen Korrekturalgorithmus eingebaut, der besser arbeitet und auch Signale mit Amplituden < 0.5 div erkennt. Soweit zur allgemeinen Info Gruß Hayo
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >Yes I know that the level adjusting in alternate mode is a little bit >"suboptimal". The adjusting is alternating (as the trigger channel) and >it is a little bit confusing. So the work around is, to adjust it before >switching to alternate mode. I'm working on a solution. Ok Hayo, I understand and as always I thank you for the explanation: RESPECT! However I wrote about that only for knowledge as I already said, for me as it is now the new firmware it works well and the trigger level shown on the top of the screen when in ALTernate trigger isn't so important. Of course any further improvement there will it will not be despised, so thanks in advance! ;-) I'm not involved in software development but I imagine the difficulties that You have to overcome in order to be able to do what You do. It's very hard and honestly often I can not understand how You can reach the results You get, so RESPECT to You one time again! Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Guten Abend Hayo und all jene, die an dem Projekt beteiligt sind Welec! Wie heute bekannt gegeben, versuchte ich die neueste Version der Firmware, 1.2.BF.6.3. Es scheint mir, dass alles in Ordnung ist, habe ich nicht finden Mängeln, so vielen Dank Hayo: KLASSE! Ich spielte auch ein wenig mit einem 133MHz FPGA-Board Vergleich der Signale auf meinem Welec W2012A und W2022A angezeigt mit den von einem Logikanalysator erhaltene. Auffallend ähnliche Ergebnisse, indem Sie die Trigger-Logik bis 3,3 V. Ich habe schon gesagt, dass es nicht falsch zu unserer Welec als MSO Oszilloskope definieren ;-): KLASSE! Inzwischen, dass ich dort war Ich habe einen Blick auf die Impulsantwort wo aber habe ich nicht gefunden neue, Ich fand das Format der Skala von Proportionen falsch Unterschreiten 1V/div. Siehe hier Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" und hier Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beim Abstieg von 1V/div 500mV/DIV zu arbeiten, höre ich das Relais und dann das Signal auf dem Bildschirm wird kleiner, als ob der Größenskala des Gitters war falsch aber ich kann nicht verstehen, warum. In jedem Fall ist es offensichtlich, wie der Frequenzgang des W2022A signifikant besser als diejenige des W2012A ist (sowohl Welec mit dem Widerstand 24,9 / 150 Ohm aktualisiert werden). Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Ein kleiner Zwischenbericht aus der Programmiererecke. Während Jörg an unserer Hardwarezukunft dengelt hole ich noch das Letzte aus dem alten Design heraus bevor diese Entwicklungslinie stirbt. Jörg hat mich bei unserem letzten Telefonat auf die Idee gebracht die gelesenen Daten zu reduzieren um die Geschwindigkeit noch zu erhöhen. Gesagt getan. Es war etwas knifflig die Pointer vom schnellen ADC-Speicher, dem Lesebuffer und der Ausgabe auf dem Screen zu synchronisieren, aber es läuft jetzt stabil und schnell. Nur so als Anhaltspunkt: die schnellen Zeitbasen 200ns - 2ns (ja auch die interpolierten Zeitbasen!) sind jetzt doppelt so schnell. Das macht sich besonders positiv bemerkbar wenn man alle 4 Kanäle gleichzeitig in Betrieb hat. Die 6.4 wird auch noch weitere Features mitbringen. Gruß Hayo
So, da ist sie. Für die neue Version habe ich mich noch mal richtig ins Zeug gelegt, sprich sie ist schöner, schneller - besser! Hier die wesentlichen Punkte: - wie schon angekündigt sind die Zeitbasen ab 500ns deutlich schneller geworden - im Hardwaremenu kann man jetzt die Skalierung selber feinjustieren. Der Justierbereich geht von 0.5 - 2 - die IIR Cutoff Frequenzen im On Screen Status sind korrigiert - QM mißt jetzt endlich korrekte Spannungspegel! Vergleicht das mal vor dem Flashen und hinterher. Es wurden immer zu niedrige Werte gemessen. - Für Charly habe ich noch mal die Button Logik geändert. Wenn es so nicht passt dann weiß ich auch nicht... - Der Probe-Divider kann jetzt nicht nur Untersetzungen sondern auch Verstärkungen (0.5:1 / 0.2:1 / 0.1:1) - diverse kleinere Fixes Gruß Hayo
Angehängte Dateien:
Hallo Hayo, dann fange ich mal an: hier 2 Shots, vorher(6.3) und nachher(6.4) zu sehen ist ein PWM-Signal mit 131Hz von einem Selbstbau RGB-Dimmer. Nach dem Flashen der 6.4, habe ich jetzt aber mehr Grundrauschen ohne Signaleingang, das war vorher weniger. Für was ist jetzt die Gain im HW-Menu? Zur reinen Feinjustierung oder Skalierung? Ich denke eher ersteres? Gruß Michael
Angehängte Dateien:
-
6.3-Noise.png
4,6 KB -
6.4-Noise.png
4,7 KB
Hier mal die Bilder vom Grundrauschen. 1.Pic: Ver6.3 2.Pic. Ver6.4 Bei beiden Versionen habe ich Defaultsetup gemacht und danach mehrmals kalibriert. Gruß Michael
moinmoin Hayo & 'Leidensgenossen' ;) 1. das mit den hoheren Grundrauschen ist mir auch aufgefallen 2. das mit der Button Logik ist so BESTENS , 'NUR' haste das im Mode/Coupling menue bei den ersten 2 Tasten vergessen ;( i denke das kann man bei jeder Taste realisieren die ein Popup oeffnet und dann nur weiterschaltet, i wuerd wetten das nach kurzer eingewoehnung das keiner mehr missen moechte.... nochmals Danke! & ein schoenes WE Charly
Angehängte Dateien:
-
W2022A.jpg
87 KB
Ich möchte mein kleines Welec verkaufen: Zustand: - Neuwertig - Zusätzliches Schirmblech - 2 zusätzliche Triggerleds - 24,9Ohm/174Ohm Widerstandbestückung - 2 Tastköpfe inkl. Zubehör sowie Netzkabel - auf Wunsch inkl. Platine (ohne Bauteile) für USB-Host Realistische Preisvorschläge bitte per PN. Mfg, Kurt
Charly B. schrieb: > 1. das mit den hoheren Grundrauschen ist mir auch aufgefallen Sorry, anscheinend ist bei der Kalibrierroutine durch die umfangreichen Änderungen ein kleiner Bug reingeraten, Korrektur kommt so schnell wie möglich. > 2. das mit der Button Logik ist so BESTENS , 'NUR' haste das > im Mode/Coupling menue bei den ersten 2 Tasten vergessen ;( Nein, hab ich nich vergessen. Den Mode kann man schon seit Längerem durch mehrfaches Drücken des Mode/Coupling Buttons verstellen, was ich schnell genug finde und die Kopplung des externen Triggers ist wohl nicht so zeitkritisch denke ich oder? Hayo
So bin gerade erst wieder zu hause und hab mich gleich drangesetzt. War auch recht schnell gefunden. Zur Erklärung: Ich stelle gerade die Kanalnummerierung im ganzen Programm Stück für Stück um. Im normalen Leben zählt man ja von 1 bis 4, der geneigte Programmierer zählt aber anders, nämlich von 0 bis 3. Leider hat der gute WELEC-Programmierer sich etwas sehr am normalen Leben orientiert und alles von 1 bis 4 durchnummeriert. Dadurch kann man kein Array vernünftig ansteuern bzw. muß den Index immer wieder um eins zurückrechnen. Bei dieser Umstellung kann einem schon mal die eine oder andere Stelle entgehen. Ich bitte also um etwas Nachsicht wenn's da mal hakt. Jetzt habe ich aber erstmal nichts mehr gefunden. Gruß Hayo p.s. ach ja, eine Änderung hatte ich noch vergessen - die Anzeige des Triggerlevel hab ich noch korrigiert, die hat auch etwas falsch gerechnet, alles noch Altlasten die ich jetzt beseitigt habe.
Angehängte Dateien:
-
2.Kanal-Noise.png
4 KB
Halo Hayo, habe gerade hier gesessen, da hat die Email-Trulla geplärrt! ;-) Natürlich habe ich gleich die 6.4C2 geflasht, Default Setup, kalibriert... Der 1.Kanal ist erste Sahne vom Rauschverhalten, der 2.Kanal will nicht, hast du den vergessen zu korrigieren? Gruß Michael
Hmm, sieht ja komisch aus. Nein eigentlich sollte das gehen, bei mir sehen alle 4 Kanaäle gut aus. Warte mal, ich flash das mal eben in mein W2022A rein, da hab ich noch die 6.3 als Vergleich drin. Hayo
Ja Du hast recht, da ist noch der Wurm drin, bei mir ist auch der zweite Kanal nicht kalibriert. Komischerweise ist mein W2014A da ganz unbeeindruckt. Ist also in Arbeit, danke für den Hinweis. Hayo
Hi Hayo, das funktioniert jetzt! Tolle Arbeit! Da hat sich aber noch ein kleines Häkchen auf dem F6-Button unter Utility/Hardware/F6 versteckt, der ev. auch nur der Return-Pfeil nach oben sein soll? Irgendwie ist die stdint.h abhanden gekommen, bzw. wurde vorher noch nicht benutzt. Kannst Du die bitte mal hochladen und dann mit ins Archiv legen? Compilieren geht sonst nicht.... Danke und Gruß Jürgen
habe gerade am Trigger gespielt. Es tritt auf bei 50, 20, 10µs, ok 5µs, Noise 2µs, 1µs ok 500ns, Noise 200ns, ok 100ns, 50, 20... Noise
Seid Ihr schnell :-) Mein 2024 zeigt keine Macke bzgl. Kanal2
@Hayo, bitteschön...und du bekommst das schon hin ;-) @Jürgen, du kompilierst selbst? Warum? Gruß Michael
Es ist eine Macke drin! Und ich hab sie auch schon... Wie schon oben erklärt eine Stelle an der der Kanalindex zurückgerechnet wird - Altlast eben - jetzt ist auch mein W2022 richtig kalibriert. Moment, ich pack das mal eben in die C3 zusammen, kommt gleich...
Ok, hoffe jetzt ist es ok. @Jürgen die stdint.h gehört ins inc Verzeichnis, dann sollte es gehen. Die kann man auch aus dem Internet runterladen. Ich hab sie jetzt mal dazugetan. Gruß Hayo
Ach ja, der Haken im Hardwaresetup... Den hatte ich auch, konnte die Ursache aber nicht feststellen. Vermutlich irgendwas aus dem Flash. Bei mir ist das nach zwei mal benutzen (an/aus/an/aus) weg gewesen. Hayo
Hayo, gibt es eine Möglichkeit, die Berechnung und Ablage der Trigonometrie Tabellen im Flash manuell erneut zu starten? Hintergrund: Nach dem Flachen der 6.4 Version heute morgen startete wie erwartet der Berechnungsprozess. Auf halbem Weg trat aber dann das allseits gefürchtete Pixelflimmern im Display auf (RAM Lötstellen). Blöderweise habe ich aber den Berechnungsvorgang nicht abgebrochen, sondern durchlaufen lassen. Die RAMs sind jetzt nachgelötet und das Skope scheint auch einwandfrei zu arbeiten. Dennoch habe ich die Befürchtung, dass evtl. während der Generierung der Tabellen durch den RAM-Fehler falsche Werte generiert und im Flash abgelegt wurden. Danke! Lothar
Hayo W. schrieb: > @Jürgen > > die stdint.h gehört ins inc Verzeichnis, dann sollte es gehen. Die kann > man auch aus dem Internet runterladen. Das war mir bekannt, das die als Standard im Internet zu finden sein sollte. Das Problem war, wie so oft bei Standards, es gab zu viele davon :-) >Ich hab sie jetzt mal dazugetan. Danke. Compiliert aber noch nicht. Es werden 'undefined references to 'Opsys::_ExecHdl' angemault. Ich dachte Du hattest das wieder heraus genommen? Ok, werde ich mir später mal ansehen. > > Gruß Hayo Michael D. schrieb: > @Jürgen, > du kompilierst selbst? Warum? > > Gruß Michael Die Frage lautet doch eher "Warum nicht?" bei einem open source project :-) Gruß Jürgen
Jürgen schrieb: > Compiliert aber noch nicht. Es werden 'undefined references to > 'Opsys::_ExecHdl' angemault. Ich dachte Du hattest das wieder heraus > genommen? Nein, die Sourcen sind noch drin. Es wird zwar nicht mehr die volle Execution Queue benutzt, aber noch ein einzelner Execution Handler der in die Hauptschleife integriert ist. Hintergrund ist der reaktivierte Vsync-Interrupt. Ich benutze das zum verzögerten Ausführen von Routinen. Man kann beim VSync eine Sprungaddresse hinterlegen (z.B. SetupTrigger()) und einen Timeout. Nach Ablauf des Timeout wird die Adresse in den Execution Handler geschrieben und beim nächsten Schleifendurchlauf ausgeführt. Damit kann man verhindern, dass beim Kurbeln am Triggerlevel ständig ein Hardwarezugriff durchgeführt wird. Erst wenn man aufhört zu kurbeln und der Timeout eintritt werden die Neuen Einstellungen übernommen. Benutze ich an einigen Stellen. Benutzt Du das neue Makefile das ich mit ausliefere? Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF-Verzeichnis eingerichtet ist. Hayo
Hayo W. schrieb: > Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF- > Verzeichnis eingerichtet ist. ... und alle Änderungen ab der Version 1.2.BF.5.0 (Jahr 2011) sind so für alle sichtbar! Gruß Andi
@Hayo > Ok, > hoffe jetzt ist es ok. Jaaa, jetzt ist alles schick! Die 50ns hatten noch ein wenig gezickt, des öfteren die Offset u. Cal.Standart betätigt, dann war es endlich ok. Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den Offset dann Cal.Standart, oder besser umgekehrt? @Jürgen > Die Frage lautet doch eher "Warum nicht?" bei einem open source project > :-) Stimmt auch wieder... ;-) Gruß Michael
Michael D. schrieb: > Ist das eigentlich wurscht, was ich zuerst drücke? Also zuerst den > Offset dann Cal.Standart, oder besser umgekehrt? Da gibt es wohl ein kleines Mißverständnis, das Calibration Set brauchst Du eigentlich überhaupt nicht zu ändern, damit kannst Du nur einfach unterschiedliche Kalibrierungen für bestimmte Eingangsoffsets speichern. Das hatte ich (glaube ich) für Branadic und seine aktiven Tastköpfe eingebaut. Übrigens habe ich noch einen Bug gefunden, das Channel Delay für Kanal 4 und das Calibration Set wird nicht im Flash gespeichert, ich ermittle schon, aber die C4 wird es erst morgen geben. Vielleicht findet Ihr ja noch was, das kann ich dann gleich mit fixen. Gruß Hayo
Das Calibrationset ist mir schon klar, bleibt ja in meine Fall auf Standart stehen. Wenn ich es betätige, tut sich aber trotzdem was. Also nur den Offset benutzen? Der Lothar hat da ein Problem mit der Trigonometrie Tabelle. Die hattest du das erste Mal in der 5.8XE. Wenn ich auf eine Vorgängerversion z.B. 5.5 flashe(downgrade) und wieder zurück auch die 6.4, wird keine Tabelle mehr geladen, bleibt die jetzt für immer im Flash? Gruß Michael
Angehängte Dateien:
-
Browse.png
3,9 KB
jetzt fällt es mir wieder ein :-( früher mußten wir 2 Knöppe drücken, heute nur noch den Offset. Mir fällt gerade noch was zum OSS ein. Wenn ich die Browse-Leiste eingeblendet lasse, dann sieht man die OSS-Anzeige natürlich nicht mehr, wollen wir das so lassen, oder das OSS knapp unter die erste Gritlinie versetzen? Gruß Michael
Hi! Mir fällt gerade auf, dass die Save/Recall Funktion nicht mehr funktioniert. Zumindest bei meinem Skope. Bei "Recall" bekomme ich entweder eine Gleichspannung oder ein niederfrequents Rechtecksignal angezeigt. Egal was vorher gesaved wurde. Das passiert aber nur bei Zeitbasen ab 1ms/div oder langsamer. Bei schnelleren Zeitbasen ist alles OK. Lothar
Andreas W. schrieb: > > Hayo W. schrieb: >> Übrigens checke ich neuerdings alles im SVN ein, da dank Andi jetzt auch ein BF- >> Verzeichnis eingerichtet ist. > > ... und alle Änderungen ab der Version 1.2.BF.5.0 (Jahr 2011) sind so > für alle sichtbar! > > Gruß Andi Eben leider nicht! Es fehlen die Änderungen im /lib - Verzeichnis. Da wurde auch geändert und ich nehme doch an aus gutem Grund. Hajo, ich habe das geänderte Makefile übernommen und an meine Installation angepasst. Jetzt wird über nios_mul.s gemeckert. Gruß Jürgen
Angehängte Dateien:
-
save.jpg
33 KB -
restore.jpg
25 KB
Hier noch 2 Screenshots zur Verdeutlichung. Eingangssignal: Daumen auf dem Tastkopf ;-) save.jpg -> So sieht das Signal aus und wird gespeichert restore.jpg -> Das wird bei 'Recall' angezeigt Lothar
Ok, schnell noch geantwortet: @Lothar entweder Du spielst ein Backup ein, oder ich lade Dir hier morgen ein spezielles Flashfile hoch das Dein Trigo-Flash neu organisiert. Das Recall-Problem sehe ich mir morgen mal an. @Jürgen ich lade einfach mal das komplette Build hoch in SFN und poste hier den Link, dann sollte das gegessen sein. @Michael Ich würde das nur ungern tiefer setzen, dann habe ich das immer direkt im Signal. Hayo
Hallo Hayo, Danke für den Hinweis. Wenn es mit dem Einspielen der Originalsoftware getan ist, sollte ich das eigentlich hinbekommen. Wollte ich sowieso mal machen. Nur um zu sehen, wie unglaublich schlecht die Welec Firmware im Vergleich zur BF war. Lothar
Super! Hat geklappt. Momentan initialisiert mein Oszi die Trigonometrie Tabellen neu. Habe die Original Firmware 1.4 eingespielt. DAS GRAUEN!! Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen! Ich kann nur jedem empfehlen, das mal zu tun. Dann sieht man überdeutlich, welche Leistung hier mit der OpenFirmware erbracht wurde. Nochmal ausdrücklich 1000 Dank an alle, die das Projekt voran getrieben und ihre wertvolle Zeit geopfert haben! Lothar
Hallo Leute, auch von mir 1000 Dank für die Leistung die hier erbracht worden ist. Ich werde heute Abend auch mal die neue FW auf das Oszi spielen. Eine Frage habe ich aber noch. Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies manuell über JTAG und USB-Blaster drauf? Ist die FPGA FW auch im Zip-File enthalten? Danke und Gruß, Georg.
Lothar Merl schrieb: > DAS GRAUEN!! > Unglaublich, dass man DAMIT mal versucht hat, irgend etwas zu messen! Ein ähnlicher Effekt stellt sich nochmal ein, wenn man vom jetzigen FPGA auf das neue Nios II wechselt... ;-) Georg X. schrieb: > Wird beim Auspielen das FPGA auch gleich mit geflasht oder muß dies > manuell über JTAG und USB-Blaster drauf? > Ist die FPGA FW auch im Zip-File enthalten? Die BF-Software enthielt noch nie ein FPGA-Update, sie arbeitet stets mit der Originalhardware. Die Software kann den FPGA-Konfigurationsflash nicht erreichen. Dafür wirst du demnächst einen USB-Blaster oder den Slog-Treiber brauchen. Wir sind noch nicht besonders gut mit Anleitung zu dem Thema aufgestellt. In die neue Hardware könnte ich theoretisch einen Zugang zum Konfigurationsflash einbauen. Dann könnte man aus der Software heraus die Hardware updaten, aber sich bei Unterbrechung oder Fehlfunktion auch aussperren. In dem Fall bräuchte man eh wieder einen Blaster, und für's erste Mal auch. Deshalb habe ich da wenig Ambitionen. Jörg
@Georg in dem "doc" Verzeichnis sind Anleitungen was Du installieren must und wie Du die Firmware dann ins DSO kriegst. Die original WELEC Update-Software (über USB) geht nicht! Bei Fragen einfach hier melden. @Jürgen + alle Das aktuelle SDK-Build hab ich hier hochgeladen: http://sourceforge.net/projects/welecw2000a/files/Development/SDK_BlueFlash_Build.zip/download Einfach draufklicken sollte genügen. @Lothar Ja gruselig nicht wahr? Ich geb mir das auch ab und zu um mal zu sehen wie es früher war, dann freue ich mich hinterher immer über den aktuellen Stand. :-) Gruß Hayo
Alle gestern gemeldeten Fehler sind bereinigt. Gruß Hayo
Wow! So schnell, wie Du die Fehler fixt, kann man die ja kaum finden! Danke!
Hayo W. schrieb: > @Jürgen + Andi > > Ich habe jetzt /bin /lib und /inc ins SVN mit eingecheckt > > Hayo Hi Hayo, danke, es compiliert jetzt ohne Fehler!
Oh, einen hatte ich vergessen, habe noch Single Shot für FFT eingebaut. Hayo
Hab noch einen gefunden: Beim Kalibrieren wird die Delay-Einstellung aus dem Flash gelöscht. Die C6 ist in Arbeit... Hayo
Angehängte Dateien:
-
FW1.2.BF.6.4C6.png
5,5 KB
habe sie gleich mal geflasht. Was macht denn das Häkchen unten rechts im HW-Menu? Und wieso hat mein "Screenshot" ein Turkisefarbenes Grid, obwohl Weiß eingestellt ist? War bei der vorherigen Version nicht, habe das gerade getestet. Gruß Michael
Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab mir schon nen Wolf gesucht. Die Farbe vom Grid ist im Screenshotprogramm fest vorgegeben. Mit gefiel das Grünliche besser, deswegen habe ich das geändert. Kann aber jeder selbst im Coding verändern. Das Compilieren müßte eigentlich funktionieren wenn man die Cygwin Umgebung bei sich laufen hat, auf USB-Stick oder Platte. Ansonsten nehme ich auch Bestellungen zu Wunschfarben an :-) Hayo
@Hayo > Das mit dem Häkchen hatten wir schon weiter oben, das geht nach einmal > aus und wieder einschalten weg. Frag bloß nicht wo das her kommt. Hab > mir schon nen Wolf gesucht. Das ist ja Quatsch damit wertvolle Zeit zu verschwenden! Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig... Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre. Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version benutzen, also auch nicht lebenswichtig. ;-) Gruß Michael
Michael D. schrieb: > @Hayo > Mich stört es nicht, meinetwegen können noch 2 dazu, unwichtig... Mich stört es schon wenn ich nicht weiß warum... > Mit dem Screenshot, dachte ich nur, das es wäre ein Bug wäre. Nein ein Feature! > Wem die Farbe nicht gefällt, kann ja die vorherige Screenshot-Version > benutzen, also auch nicht lebenswichtig. ;-) Das stimmt, außer der Farbe sind die identisch. Habe auch keine neue Versionsnummer vergeben. Hayo
Und ich habe mir extra Mühe gegeben, am LCD-Stecker die genauen Bits pro Farbe gemessen, um für's neue FPGA und den Osoz-Screenshot die originalen Farben zu verwenden, und dann kommt ihr Künstlervolk daher! ;-) Jörg
Schande über mich, aber als einer der mit den alten Analog Oszis groß geworden ist hat das grüne Grid einfach was Vertrautes für mich... ;-) Hayo p.s. bin erstmal eine Woche Ski-fahren, hoffe aber dass ich da irgendwie Internetzugang habe.
> und dann kommt ihr Künstlervolk daher! > ;-) und das stimmt auch noch! ;-) fällt unter "Automotive-Design" oder "innovatives Design" :-) Jörg > Schande über mich, aber als einer der mit den alten Analog Oszis groß > geworden ist hat das grüne Grid einfach was Vertrautes für mich... > ;-) hm, im Displaymenu hast du diese Farbe "Teal" genannt. Ist eigendlich ein weiblicher Vorname, der aber auch die Farbe Patrol oder Blau-Grün definiert. Ich war mal ein Fan von dem Farbton. Wohin geht es denn zum Ski fahren? Gruß Michael
Nach Schladming, hoffe dass da noch Schnee liegt, sonst hab ich das Lappy dabei und programmiere ein wenig :-) Teal - die Farbe hab ich bei meiner Kiste eingestellt, das gefällt mir einfach am Besten. Soll ja auch dem Auge gefallen. Hayo
Angehängte Dateien:
-
1_25MHz-100ns-RT-0_0s.jpg
59 KB -
1_25MHz-200ns-RT-0_0s.jpg
68 KB
Ok, vom HW-Thread nach hier... > Hi Michael, > ich vermute Du hast für die Rise/Fall-Timemessung eine zu kleine > Zeitbasis eingestellt. Dann reichen ihm die Punkte zur Messung nicht > mehr aus. > Mach mal einen Screenshot - aber dann im Firmwarethread. Hier mal 2 Screenshots von der Rise/Fall-Anzeige Das Signal ist ein Rechteck 1,25 und mit einer Amplitude von 5V, Rise/Falltime 1-2ns, Jitter 25ps. Bei beiden Zeitbasen wird 0s angezeigt, oder es schwankt manchmal zwischen "s" und "ns". Dazwischen sollte doch "µs" liegen?! In höheren Zeitbasen, bzw. Frequenzen, wird die Rise/Falltime korrekt angezeigt. Gruß Michael EDIT. Achso, mußte leider fotografieren, da das ganze Geraffel zu weit vom PC hängt. Vielleicht stricke ich mir noch eine 8m RS232 Leitung... :-) >Gruß Hayo > p.s. zu Peak Detect sag ich noch was... ja, sag' was ;-)
Angehängte Dateien:
-
Rise_Time.jpeg
54 KB
Hi Michael, wie ich schon vermutet habe ist die Zeitbasis für die Messung zu langsam und die Pegelaussteuerung ist zu klein. Die Flanke auf Deinen Screenshots geht so steil hoch, dass auch bei einer manuellen Messung mit den Cursorn die Anstiegszeit Null wäre. Je schräger die "Rampe", desto genauer ist die Messung. Gemessen wird die Zeit von 10% bis 90% der Flanke. Das sind die beiden gepunkteten Linien im Grid. Die Signalamplitude sollte daher auf den jeweils letzten Gridlinien liegen. In etwa so wie auf dem Screenshot. Das ist die Anstiegszeit meines alten HP3310B Signalgenerators. Dein Signal scheint aber deutlich schneller zu sein. Evtl. ist auch einfach das Signal zu schnell für unser Oszi. Um das zu sehen müßtest Du aber auf 50 ns auflösen und einen Spannungsbereich wählen in dem Du die Amplitude weiter aussteuern kannst. Wenn dann immer noch nichts geht ist das WELEC einfach zu langsam... Ich denke eine Anstiegszeit von 5ns sollte es aber schaffen - und das ist schon ziemlich schnell. Gruß Hayo
Angehängte Dateien:
29ns das ist natürlich eine langsame Anstiegszeit.
Ich habe gestern noch ein paar Messungen mit dem schnellen Signal
gemacht, müßte so um die 2ns sein, angegeben ist der ICS511 mit
Rise/Fall-Time von 1nS bei 4pF load. Da kommt ja noch die Leitungslänge,
Stecker etc. dazu, da könnte es mit 2-3ns hinkommen.
Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann
ich nicht beurteilen.
Anbei ein paar Shots
Die 50MHz sehen noch einigermaßen gut aus, bis auf die viel zu hohe
Amplitude. Hier wird z.B. in ps gemessen.
bei 130MHz habe ich schon 12V
150MHz 14V :-(
183MHz 11,2V
200MHz 4,68V dieser Wert ist realistischer
Könnte es an den noch nicht ersetzten 24R und 150R bzw. 170R liegen?
Gruß Michael
Michael D. schrieb: > Das Welec ist in der Lage picosekunden zu messen, ob das real ist, kann > ich nicht beurteilen. Nein, kann es nicht. Das sind interpolierte Zeitbasen. da wird das Signal nur "gestretcht". Die schnellste reale Zeitbasis ist 50ns/Div. Da ist ein Pixel eine Nanosekunde. Bei einer Anstiegszeit von 2ns wird es tatsächlich etwas eng. Da ist das WELEC wohl einfach zu langsam. Das ist kein Firmwarefehler, sondern Du lotest gerade die Grenzen des Gerätes aus - auch nicht übel :-) Gruß Hayo
> Das ist kein Firmwarefehler...
Ja, das ist mir schon klar.
Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und
ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert?
Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie
1:1 ohne Abschluss gemessen.
Da ich noch die originale Bestückung in der Eingangsstufe habe, frage
ich mich, ob da merkliche Besserung nach der Modifizierung eintritt.
Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher?
Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn
Interesse besteht. Da steigt zwar auch die Amplitude, nur nicht so
extrem hoch.
Gruß Michael
Michael D. schrieb: > Wie kommt es, das so ab 100MHz die Amplitude extrem in die Höhe geht und > ab 200MHz wieder absackt auf einen einigermaßen realistischen Wert? Das ist der Frequenzgang des original bestückten WELEC. Das hatten ja einer unserer Hardwarespezi mal vor längerer Zeit genau ausgemessen und als Diagramm hier dargestellt (gleich das Erste): http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement > Übrigens habe ich ohne Tastkopf und direkt mit einem RG174 an BNC sowie > 1:1 ohne Abschluss gemessen. Das ist allerdings Messtechnisch eine Vollkatastrophe. Da dürfte es auf der Leitung lustig klingeln... Du hast zwei Möglichkeiten: 1. Du schließt den Ausgang Deiner Schaltung mit einem 50 Ohm Widerstand ab und machst am anderen Ende (Oszi-Eingang) auch einen Abschluß dran, was natürlich die Amplitude verkleinert. Es ist zu prüfen, ob Dein Ausgangskreis genügend Ausgangsleistung liefert um die 100 Ohm zu befeuern. 2. Du mißt mit einem Tastkopf im 10x Modus, ist am einfachsten, erfordert aber bei deinem Signal einen guten Tastkopf mit großer Bandbreite. > Da ich noch die originale Bestückung in der Eingangsstufe habe, frage > ich mich, ob da merkliche Besserung nach der Modifizierung eintritt. > Gibt es da nicht irgendwo eine Dokumentation für vorher u. nachher? Ich habe dazu mal eine Testreihe mit Bildern gemacht, ist aber etwas her. In Kürze - bei Verwendung von 24,9/174 Ohm wird der Frequenzgang wieder linear und die Eingangsstufe neigt nicht mehr so sehr zum Schwingen. Ich habe mir gerade einen 100er Streifen 24.9 Ohm Widerstände für mein W2014A geordert. Wenn Bedarf besteht kann ich die Kombination 24,9/180 anbieten, einfach PIN mit Adresse schreiben, dann schicke ich ein Briefchen... Gruß Hayo > Ich könnte noch einen Vergleich zum Voltcraft 3062C posten, wenn > Interesse besteht. Dann aber mit korrektem Messaufbau. Gruß Hayo
Gute Sonntag Michael D., Hayo, Jörg H. und all jene, die an dem Projekt beteiligt sind Welec! Nach langer Abwesenheit bin ich wieder. :-) Ich verlor ein wenig 'Arbeit, aber ich werde versuchen, zu fragen, Informationen beheben. ;-) Bereiten Sie die übliche Dosis Geduld... ...Ich vertraue in deine Güte :-) @Michael D. Michael, you can't directly get a so little rise time on the screen of the Welec because what You want to misure exceeded the DSO's features. Infact 200MHz (W202xA) bandwidth version have to be 1,75ns as the better fast rise time who can view on the screen, while 100MHz (W201xA) version reach 3,5ns, pico seconds are to small to be wiev on the screen as impulse response. Coming close to the scope rise time it is necessary to subtract the scope’s (and if used the probe’s) rise times geometrically from the rise time as seen on the screen. The true signal rise time will become: Ta= SQR((Ttot*Ttot) – (Tosc*Tosc) – (Tt2*Tt2)) Ttot is the rise time seen, Tosc is the scope’s own rise time (2,3ns for 150MHz bandwidth oscilloscope), Tt is the rise time of the probe, e.g. 2ns and Ta is the true waveform rise time. If the signal’s rise time is > 22 ns (in this example the DSO is 150MHz bandwidth so we have 22ns, more generally that is the result of about 10 times its specific rise time who is 2,3ns, so 10 * 2,3ns = ~22ns), the rise times of scope and probe may be neglected. So, if for instance you measure 8ns as signal's rise time on the screen of the oscilloscope, then the true signal rise time will become: Ta= SQR((8*8) - (2.3*2,3 *2,3) - (2*2)) = 7,4 ns For most amplifiers, even if their pulse behaviour is far from ideal, the following relationship holds: Ta=350/B hence B=350/Ta Where B is the oscilloscope's bandwidth and Ta is again the true waveform rise time tr/ns = 350/Bandwidth/MHz Resulting by my tests, seems to me the W2022a is a real 200MHz bandwidth oscilloscope when I tested it with a fast rise time pulse and W2012a is at least a real 170MHz bandwidth DSO. I used the Jim Williams avalanche fast pulse generator who the author described on LT App Note 47, it is a 300ps pulse generator, so much faster than Welec's impulse response capability. It is also cheap and easy to build. When I built mine then I verified it using a 500MHz Tektronix DSO who is the better instrument I can have, poor bandwidth you can say but I get about 980ps on its screen and because it is a real 700ps risetime DSO hence my avalanche pulse generator is a true 300ps or less (280ps I viewed). Please take a look at this: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Note: the pics and the post was wrote when my W2022A/W2012a has not yet been modified putting 24/150 ohm resistors. Michael D. schrieb: >Die 50MHz sehen noch einigermaßen gut aus, bis auf die viel zu hohe >Amplitude. Hier wird z.B. in ps gemessen. > >bei 130MHz habe ich schon 12V > 150MHz 14V :-( > 183MHz 11,2V > 200MHz 4,68V dieser Wert ist realistischer > >Könnte es an den noch nicht ersetzten 24R und 150R bzw. 170R liegen? Of course Michael, if your DSO yet have the original hardware's resistors it is normal the behaviour you described, otherwise I don't know why of that behaviour with the hardware's resistors changed to 24/150 or 24/174 ohm. What I can say for sure is that after I changed the resistors the my two units exhibit a flat response (flatness) from about 10Hz to 180MHz, I can't go over with my leveled signal generator who stop at 180MHz so I can't reach the W2022a's bandwidth that however I suppose to be real 200MHz. @Hayo. Good news from You even in the "hardware teil", very amazing, as always thank You Hayo! Much terrific the fine/coarse level setting for the inputs amplitude, as all You know I have always dreamed for that, even if as it is now it is better for servicing. Infact would have been better if it had been able to act independently on each channel, but also as it is now it is really usefull. I know it was very hard to obtain it, a miracle you can say, but just because You're the man of miracles, in the case You can reach the result to put fine/corse directly for each channel, it could be great. ;-) I warned all you about patience and kindly! ;-)) Thanks Hayo and RESPECT! Perhaps new Jörg design can aid... ;-) Very, very good even the hint for compensate/calibrate each input directly on the DSO's input circuitries, thank You very much Hayo: RESPECT! Interesting considerations about the performance achieved among different FPGA revisions, even if with the new FPGA development by Jörg all will be drammatically improved, also frame rate matter: as I wrote one time Jörg is the master of the time. Another dream who became true is the 'Peak Detect' function who is roughly what I demanded in an old post: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" Really awesome, thank You very much Hayo, no words, RESPETC! Now I go away, I have to verify something important in the new firmware, I cross my fingers because might be the right time! :-) Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Gute Sonntag Michael D. und all jene, die an dem Projekt beteiligt sind Welec! One important thing that I forgot to write before about the report I wrote time ago and all you can see here: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Fall time values in the pics are 0 (zero) because at that time Hayo's firmware wasn't yet able to show picoseconds in fal and rise time as it is now. Infact due to this I expressely demanded to Him to modify it, thing which He promptly did with His usual mastery that we all know. You can see the behaviour of other DSOs and analog oscilloscopes with different bandwidths. As visible up to 300MHz automeasures show true rise/fall time of the instrument, because 300ps are much less of its typical rise/fall time, so other factors may be neglected. Only the Tektronix DSO, who is a 500MHz bandwidth, begins to show the weight of 300ps because it is a 700ps instruments. I felt compelled to specify this things. Thanks. Nochmals vielen Dank Michael D. und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
So Michael ich hoffe diese kleine Doku beantwortet Deine Fragen zum Peak Detect. Ich habe gerade die aktuelle Release fertig und bereite den Upload vor. Dann könnt ihr selbst probieren. Hayo
So, viel Spaß beim Ausprobieren. You will find the english version of the peak detect docu inside the doc directory. enjoy... Hayo
Wie mache ich einen (oder mehrere) Screenshots? Ich beschreibe mal die Prozedur unter Windows, aber unter Linux geht es fast genauso. Also im Verzeichnis screenshot findet man eine Batchdatei scrsh.bat - diese muß mit einem Editor auf die eigene Hardware angepasst werden. Der String "%~dp0\w2000a-screenshot.exe" -c 1 -b -a %* enthält als Argument den zu benutzenden COM-Port, hier COM1. Das muß man entsprechend anpassen und dann sichern. Dann das DSO einschalten und per Doppelklick die Batchdatei starten. Das Programm verbindet sich mit dem DSO, prüft die aktuelle Firmware auf dem DSO und wartet dann auf Screenshots, die man am DSO per Doppeldruck auf die Quick Printtaste oder im Printmenü selbst auslöst. Die Bildschirmausgabe sollte so aussehen: * Connecting to DSO and retrieving version information... done - found firmware version: 6.5 - found hardware version: 8C7.0.G - found model: W2022A * Waiting for screenshot, trace, or measurement... Man kann das Programm natürlich auch direkt mit den Argumenten starten. Der Screenshot kann auch umgekehrt vom Programm aus getriggert werden. Mit -h als Argument bekommt man einen Hilfetext angezeigt. Das Programm wartet und verarbeitet so lange Screenshots bis es beendet wird. @Martin Die von Dir beschriebene Meldung läßt mich vermuten, dass Du das DSO erst hinterher eingeschaltet hast. Gruß Hayo
Angehängte Dateien:
-
Rise_Time_W2022A.jpeg
50 KB
Nachdem ich mir bei meinem Neuzugang - einem 100 MHz Pulsgenerator, der leider defekt bei mir ankam - einen Wolf gesucht habe bis ich die Fehlerquellen lokalisiert hatte, läuft das Teil jetzt wie Schmitts Katze. Ich habe die Gelegenheit genutzt und passend zu unserem Thema weiter oben ein paar Messungen vorzunehmen (gehört ja eigentlich in den HW Thread). Ich war doch positiv überrascht, das WELEC ist gar nicht so übel. Die Fakten: Der Pulsgenerator ist spezifziert mit 2.5ns Anstiegszeit. Gemessen habe ich mit dem Tektronix 2465A (Bw ~400MHz, Tr ~0,8ns) eine Anstiegszeit von 2.4ns. Wie man auf dem Screenshot sehen kann schafft das W2022A diese Anstiegszeit ebenfalls, was ich nicht vermutet hätte. Das entspricht einer Bandbreite von 140 - 150 MHz. Das ist schon ganz anständig. Das W2014A schafft da - genau wie mein OWON SDS8102 - "nur" 3ns, was einer Bandbreite von etwas über 100MHz entspricht. Für diese Messungen muß man im Hardwaremenü unbedingt die Einstellung "High Frequency" wählen, da es sonst zu überlagerten Schwingungen kommt. Gruß Hayo
Hallo, ich habe ein Problem mit dem Logikmodus. Ich versuche ein zyklisches I2C-Signal (alle 2s 10Byte, 100kHz) im TTL-Modus zu betrachten. Irgendwie scheint die Zeitauflösung zu spinnen. Das ist so auffällig, dass ich mir gar nicht vorstellen kann, dass das noch nicht aufgefallen ist. Wenn ich von 2V Auflösung und 20µs auf Logic TTL5V umschalte wird wie erwartet getriggert, wenn ich den Triggermodus wieder auf Normal gestellt habe. Allerdings führt dann ein Ändern der Zeitauflösung incl. neuem Triggern zu keiner Veränderung in der Zeitachse. Soll heißen das Signal bleibt scheinbar in der vorherigen Zeitauflösung, die Anzeige der Auflösung oben rechts ändert sich. Bei manchen Änderungen wird auch das Signal gestaucht obwohl eine Streckung zu erwarten wäre. Hat das schon mal jemand gesehen? Gruß, Rainer
Hat Dein I2C Signal denn TTL-Pegel? Welche Probe-Einstellung hast Du eingestellt? Es wird nur 1:1 und 1:10 unterstützt. Das muß auch genau passend zur Prüfspitze eingestellt werden, da sonst die Pegel nicht stimmen. Gruß Hayo
Hallo Hayo, Wenn ich mit der neuen Firmware eine Offset Calibration mache dann bekomme ich schöne Streifen auf dem Display. Ist ein W2022A. Sonst habe ich noch kein merkwürdiges Verhalten feststellen können.
Hallo Stefan, das ist kein gutes Zeichen. Die Streifen tauchen eigentlich immer nur dann auf, wenn es Probleme mit dem RAM oder dem Display gibt. Meine beiden W2xxxA machen beide keine Streifen bei der Kalibrierung. Kannst Du mit einer Kamera evtl. ein Foto davon machen? Gruß Hayo
habe das Thema lange nicht verfolgt, aber wie weit wird die Huckepackplatine eigentlich mittlerweile unterstützt? Ist das in der Software nun implementiert?
Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich nicht. Gruß Hayo
Hallo, anbei drei Beweisfotos für das beschriebene Verhalten. Ich bin von 2V zu Logik TTL gegangen, habe dann die Zeitachse verstellt (50µs, 20µs, 10µs). Es wurde auch erneut getriggert. Beim Umstellen von 10µs Logik auf 2V (Logik aus) bleibt die falsche Zeitachse. Erst ein Drehen an der Zeitauflösung stellt die korrekten Zustände wieder her. Gruß, Rainer
Hayo W. schrieb: > Ja, ist es. Jörg hat dafür einen Treiber geschrieben, der auch in der > aktuellen Firmware auswählbar ist. Wie die Erfahrungen damit sind mußt > Du Jörg und Branadic selbst fragen. Wer das noch eingebaut hat weiß ich > nicht. Ist schon lange her, ich meine mich dunkel zu erinnern daß das in der BF-Firmware noch nicht recht hinhaut. Ich habe den Lowlevel-Support dafür gebaut, dann gab es etwas Schwierigkeiten mit der Integration, weil das (aus meiner Sicht) alles so vermurkst ist. Kann sein, daß ich mich da auf Hayo verlassen habe, das zuende zu stricken, aber er hat seine Platine nie eingebaut. Sorry daß wir jetzt beide im Kreis aufeinander zeigen... In Osoz funktioniert es "richtig". Es ist auch möglich, die Kanäle unterschiedlich zu bestücken. Jörg
Rainer, Du hast recht, merkwürdige Dinge gehen da vor. Muß ich mir mal genauer ansehen. Da ich über Ostern Besuch bekomme, wird das wohl erst was nächste Woche. Gruß Hayo
Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm. Ich habe mich noch nicht getraut das anzuschubsen. Im Netz liest man aber nichts schlechtes. Sicherheitshalber habe ich mir heute ein Backup des gesamten Repositories gezogen, das ist die Checkin-Historie. Also nicht das Wiki. Das gleiche habe ich bei einem anderen Sourceforge-Projekt von mir gemacht (OpenHC, da mache ich derzeit nichts), und gewissermaßen als Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran muß. Mal sehen wie lange das braucht. Das blöde ist, das die Commits zwische Beantragung und vollzogener Migration verloren gehen können. Wir müssen dann also ein Weilchen die Füße still halten. Jörg
Ok Rainer hab doch noch mal schnell versucht das Problem zu lösen. Hatte aber keine Zeit das jetzt tiefschürfend zu testen. Sieht aber für mich besser aus jetzt. Ich muß jetzt los zum Training und schaue dann gegen 23:00 noch mal rein. Gruß Hayo
Naaa, noch keine neuen Erkenntnisse? Morgen (heute) ist doch frei... Hayo
Guten Abend Hayo und all jene die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >Nachdem ich mir bei meinem Neuzugang - einem 100 MHz Pulsgenerator, der >leider defekt bei mir ankam - einen Wolf gesucht habe bis ich die >Fehlerquellen lokalisiert hatte, läuft das Teil jetzt wie Schmitts >Katze. Ich habe die Gelegenheit genutzt und passend zu unserem Thema >weiter oben ein paar Messungen vorzunehmen (gehört ja eigentlich in den >HW Thread). Ich würde nicht wie ein neugieriger schauen, genau das, was Modell ist Ihre neue Pulsgenerator? Vielleicht könnten Sie verwenden, um controlloare was passiert, indem die vertikale Größe (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") Ich weiß, dass ich langweilig bin, Entschuldigen Sie mich bitte. Interessant Screenhot! Vielen Dank Hayo und alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Angehängte Dateien:
-
TR-0307.jpg
150 KB
Hi Luc, the pulse generator is an old device from the 80ies made in Hungary, type TR-0307 (EMG). It is completely analog controlled, no digital stuff in it. I like it because of the simple and uncomplicated handling. It is constructed very modular with high quality standard parts and is therefore good to repair if something is defect. It is working very fine now - and it was cheap! It has a rise time of 2.4ns and many possibilities of signal forming (variable rise and fall time), especially simulating fast glitches and spikes but also to produce a standard square wave up to 100MHz. Seems to be ideal for testing the W2000A models. > Vielleicht könnten Sie verwenden, um controlloare was passiert, indem > die vertikale Größe Unfortunately I did not understand, what you meant with this. Kind regards Hayo
Angehängte Dateien:
-
Lyons_PG_2B.jpg
130 KB
Guten Abend Hayo und all jene die an dem Projekt beteiligt sind Welec! Hayo W. schrieb: >the pulse generator is an old device from the 80ies made in Hungary, >type TR-0307 (EMG). Hi Hayo, thanks for your kind reply. Really a nice instrument, congratulation expecially for its repair: RESPECT! Me too I have a pulse generator, my equipment is an old Lyons Instruments PG-2B. It is maximum 10 MHz and its rise/fall time is 10ns minimum, so inadequate to test bandwidth in 100MHz DSO as Welec are claimed. Due this fact I built a 300ps pulse generator based on what Jim Williams described in LT App Note 47. By time I try to put my hands on some old oscilloscope calibrator but sadly to now yet I'm been not able to get one. Perhaps may be next time, we will see. Hayo W. schrieb: >Unfortunately I did not understand, what you meant with this. What I wanted to say is that perhaps your instrument could be capable to replicate my measure. I.E. set your pulse generator for a fast rise/fall time (about 300ps, otherwise surely less than 1ns) about 1ns duration 18Vpp amplitude pulse and see the waveform on your W2022a/W2014a changing Volt/Div setting in order to verify if the scale factor of the signal drawn on the screen remains correct, thing sadly do not succeed with both my W2022A and W2012A. But your instrument is only "2,4ns" as fast rise/fall time, so I think it is unable to do that test. That is why I asked for its identification. Of course, anyone else in possession of adequate instrumentation who wants try to repeat the measurements is welcome, thanks in advance! How I already wrote I'm interested about oscilloscopes' bandwidth verification, so I'd like to see a screenshot of the same pulse You posted in here (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") but this time catched by your Tektronix 2465A. So if You want and when You can easily get it, I'd like to take a look to a such kind of thing. Thanks in advance Hayo! I think the biggest difference, beyond the different pulse duration due to the different oscilloscopes performance as a rise and fall times, should be the waveform's amplitude, who it should be more great when it shown on the faster one instrument (better bandwidth). This is an important aspect of the matter, not only rise/fall time shape. By now a such kind of measure could be facilitated by the new "Peak to Peak detect" function. Of course, on the Welec side a such kind of measure must to be done using an hardware modified DSO, otherwise the lack in linearity bandwidth will hinder the achievement of the correct result. Hayo W. schrieb: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Hayo, as always I thank You very much for your priceless work, RESPECT! Grüße und frohe Ostern an alle! Mit freundlichen Grüßen, Luc
Hi, today i upload 1.2.BF.6.5C2 firmware on my welec, and i set adc_change12_reg to 0x0 for Hifrequency mode (with this seting i dont have ringing), but whan i turn off oscilloscope and on, adc_change12 register is missing my value. I dont have this problem on 1.2.BF.6.1 and early version. Greating from Bosnia
Sorry for mistake, adc_change12 = 28000 is my best setting.
Hi Sladjan, > ...but whan i turn off oscilloscope and on, adc_change12 > register is missing my value. I changed the storage location of calibration and register values. They now have an own flash sector. > adc_change12 = 28000 is my best setting. I tested it and it seems to work ok on my W2014A, on the W2022A I got strong ringing on the signal. I added it in the hardware menu as "High Freq 2" Regards Hayo
Thanks a lot, setup work ok for me. I see one litle think. When I push "Center Channel1 OR Center Channel2" and restart oscilloscope (turn off and on), "center" setting is missing and line is back to default value.
May be I forgot the saving call for this function. I will check it and add it. You can use a work around - after centering you can switch your timebase one higher or lower and then back. This will trigger the saving routine. Hayo
Thanks, settings save after switch timebase.
Hallo Hayo, ich bin während der Arbeitszeit am Welec, daher erst jetzt die Rückmeldung, sorry. Die Logikerkennung mit richtiger Timebase scheint zu funktionieren. Super, danke. Jetzt noch ein Analyser für I2C, SPI, UART... oder eine schnelle USB online Datenübertagung zur PC-Analyse, dann wäre der (serielle) Logicanalyser da. Bitte nicht als (Auf-)Forderung verstehen, nur ein Wunschtraum. Viele Grüße, Rainer
Auch hier kurz der Hinweis auf den WELEC Einsteiger-Thread: Beitrag "Wittig(welec) DSO W20xxA Einsteiger" Hayo
Hallo, ich habe bei meinem W2022A die 1.2.BF.6.5C3 eingespielt. Seitdem stürzt das Oszi manchmal ab, wenn ein "Calibrate Offsets" durchgeführt wird. Dies ist abhängig von der Zeitbasis. Im ns-Bereich funktioniert alles normal bis 5us runter, bei 10us oder größer stürzt es ab. Bin testweise auf die 1.2.BF.6.4C6 zurück, da ist alles gut, das Problem fängt mit 1.2.BF.6.5 an. Gruß Ricardo
Hallo Ricardo, das weist normalerweise auf das übliche Problem mit dem RAM hin. Bei mir konnte ich noch keine Abstürze feststellen. Das heißt - Anschlüsse nachlöten. An Alle: Hat einer von Euch auch Abstürze? Gruß Hayo
Hey Hayo, ja ich kann mich dem Ricardo nur anschließen. Ich habe nur den Vergleich zwischen der 6.3, 6.5 und 6.5C3 ... ... die 6.5 und 6.5C3 zeigen einen Blue Screen (rosa Steifen) auf dem Display. Bei Tests mit Jörg war mir der direkte Vergleich vor Tagen aufgefallen (leider noch nicht zum posten gekommen). Grüße Andiiiiy
Ok, danke für den Hinweis! Dann muß Ricardo ja doch nicht an seinem RAM rumlöten. Ich schau mir das mal an ob ich das nachstellen kann, sonst frag ich noch mal nach. Gruß Hayo
Hi, habe's leider zu spät gesehen. Heute Abend gingen bei Ebay 4 LCDs weg: LQ104V1DF21. 10 Zoll, 640x480 und identische Stecker/Belegung. Vom Timing leichte Differenzen, z.B. ist die Gesamt- Zeilenlänge etwas länger. Da ich kein zweites Oszi habe, kann ich leider die Wittig-Zeilenlänge bzw. das Timing nicht messen. Wenn das mal einer machen könnte, dann kann man sich ja mal einen grösseren LCD zulegen (Nachteil: gleiche Auflösung). Das angebotene LCD habe ich auch schon als 12"-Version gesehen. Gruss
Der Fehler mit den Abstürzen beim Kalibrieren ist bestätigt. Da ist irgendwo ein übler Bug drin. Korrektur kommt so schnell wie möglich. Bis dahin bitte nur bei Zeitbasen >= 5µs kalibrieren. Hayo
Der Versuchsballon ist durch, ein Sourceforge-Projekt von mir ist jetzt umgestellt: Jörg H. schrieb: > Sourceforge drängelt mit Erinnerungs-Emails, wir sollen unser Projekt > endlich auf deren neue "Allura" Plattform umstellen. Nun kriegt man > zusätzlich bei jedem Einchecken eine Erinnerung auf den Schirm. ... > und gewissermaßen als > Vorab-Test für uns das Update-Knöpfchen gedrückt. Damit ist das > beantragt, wird irgendwann ausgeführt, man bekommt Nachricht. Keine > Ahnung ob das ein automatisierter Prozeß ist oder da jemand werktags ran > muß. Mal sehen wie lange das braucht. Heute bekam ich Nachricht, also nach knapp einem Monat. In der ersten stand, daß das Repository migriert wird, etwa eine Stunde später bekam ich Nachricht das es abgeschlossen ist und unter neuere Adresse auschecken soll. Habe ich ausprobiert, scheint zu funktionieren. Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran, daß wir jetzt bereits mit Zwangsmigration bedroht werden: http://sourceforge.net/blog/upgrades-april22/ Wird also irgendwann passieren, nicht wundern. Jörg
Sorry, warum wusste ich schon immer, dass ich das nicht gut leiden kann? Auch die Spam von SF ist unerträglich. :-(
Hat wieder etwas gedauert, aber hier ist sie. Neu ist der Support für die Low Budget Mod. Ansonsten Bugfixes. Bitte nach dem Flashen im Hardwaremenü die Gain-Einstellung prüfen. Durch die LB-Mod haben sich die Einträge verschoben. Hayo
Not yet enough time to try but in the absence of other comments to this last work i say...THANKS!! :-)
Hallo Hayo, im Gain Menu steht standartmässig 1.000 ! Welche Gain Einstellung ist für die originale Bestückung relevant und welche für die modifizierte? Beim hochdrehen gehen die Nulllinien beider Kanäle auseinander (entgegengesetzt) dann gehen diese automatisch wieder in die ursprüngliche Position. Kannst du dazu etwas sagen? Gruß Michael
Bei 1.00 sind die Skalierungsfaktoren genau so wie sie im Programm vorgegeben sind bzw. wie Du sie im PreGain-Menu eingestellt hast. Für den Fall, dass bei Dir dann aufgrund von Bauteiltoleranzen oder Ähnliches die angezeigten Pegel nicht stimmen, kannst Du dann mit Werten die von 1.00 abweichen den Pegel korrigieren. Der eingestellte Skalierungsfaktor wird mit dem angezeigten Gain multipliziert. Beispiel: Wer die LB-Mod drin hat stellt im PreGain natürlich "LB-Mod" ein. Der Skalierungsfaktor ist dann 1.6 bei den 5er Bereichen (Bei Gain 1.00). Wenn Du z.B statt 330 Ohm Abschluß nur 300 Ohm verwendest, wirst Du einen größeren Skalierungsfaktor benötigen. Dann drehst Du den Gain langsam hoch z.B. auf 1.15) und kalibrierst das Gerät nochmal. Danach ist der Skalierungsfaktor 1.6 * 1.15 = 1.84 War das einigermaßen verständlich? Gruß Hayo p.s. Bin gerade dabei in meinem Zimmer neue Fenster einzubauen, daher bin ich etwas "offline".
Also bei meinem Scope scheint der Single Shot nicht mehr zu funktionieren. Man kann das Scope zwar noch für einen Single-Shot scharf schalten und er scheint auch zu Triggern (Run/Stop schaltet nach dem Trigger Event auf rot) aber auf dem Schirm wird immer noch das Signal angezeigt, das vor dem Single Shot schon da war. Verhalten war schon bei 1.2.BF.6.5 so und ist bei 6.6 immer noch so.
Jörg H. schrieb: > Unser Welec-Projekt ist über das Warten auf diesen Test so spät dran, > daß wir jetzt bereits mit Zwangsmigration bedroht werden: > http://sourceforge.net/blog/upgrades-april22/ > > Wird also irgendwann passieren, nicht wundern. Gestern ist es passiert, unser svn Repository ist umgezogen. Es ist ganz einfach, die Arbeitskopie auch drauf folgen zu lassen. Noch einfacher als die Email von Sourceforge beschreibt, man braucht nur im obersten Verzeichnis des eigenen Checkouts folgendes eingeben:
1 | svn relocate https://svn.code.sf.net/p/welecw2000a/code |
Beim nächsten Checkin wird man dann noch mal nach Username und Password gefragt. Zwei kleine Commits habe ich schon erfolgreich in das neue Repository gemacht. Wir sind jetzt übrigens bei svn Revision #999, der nächste Commit wird der "Jubiläumscommit" #1000. (Ziemlich genau die Hälfte der Checkins ist von mir.) Jörg
Herr Lehmann schrieb: > Also bei meinem Scope scheint der Single Shot nicht mehr zu > funktionieren. Ja es gibt einen Fehler, der indirekt durch die Umstellung der Ausleselänge zustande kommt. Das ist in der BF.6.7 bereits behoben, aber ich muß noch die Faktoren für die OPA653 Mod anpassen, dann kommt die neue Version. Gruß Hayo
Ah, schön zu hören, daß es tatsächlich an der Firmware liegt und nicht an meiner Unfähigkeit, das Gerät zu bedienen. Jetzt habe ich noch eine blöde Frage: wäre es möglich, den Drehsinn der Zeitbasis und der V/div Knöpfe umzukehren (Option im Setup)? Ich bin es gewohnt, daß Uhrzeigersinn größere Werte sind, bei unserem Scope ist es aber genau anders herum.
Oh wie peinlich, bitte vergißt die Geschichte mit dem Drehsinn ganz schnell. Ich habe gerade gesehen, daß dieses Thema schon länger durchgekaut wurde und jetzt komme ich schon wieder damit an. Entschuldigung, das tut mir leid.
Kein Problem, bei meinem Tek ist der Drehsinn übrigens auch im Uhrzeigersinn zu den kleineren Zeitbasen hin. Passt also gut wie es ist. Hier die neue Version mit Unterstüzung der OPA653 Mod und noch einigen Änderungen/Fixes. Gruß Hayo
Hey Hayo,
ich hatte ja schon Anfang des Jahres von meinen Spike Problemen auf
Kanal 2 berichtet. Schon damals hatte "sar" ähnliche Probleme geäußert.
Ich habe das Wittig mittlerweile ausgemustert, allerdings ist mir jetzt
ein Topic im Marktplatz aufgefallen wo auch wieder jemand ("sh0dan") von
vorher nicht vorhandenen Spikes auf Kanal 2 berichtet. Die Spikes traten
scheinbar nach einem Update auf und stehen eventuell wieder in
Zusammenhang mit der Temperatur.
Bei mir kann ich das zeitlich auf ca. die Version 5.8 eingrenzen,
möglicherweise auch etwas davor da ich nicht jede Version getestet habe.
Auf einmal waren jedenfalls dann die massiven Spikes da, die ich davor
nie! hatte.
Meine Frage:
Hat BF5.8 oder eine vorige Firmware Version einen Speicherbereich oder
sonstiges verändert, der beim löschen mit Welec Updater oder einem neuen
Flashen nicht mehr rückgesetzt werden kann?
Ich bekomme bei mir die Spikes in keiner Konfiguration mehr weg. Ich
denke da an die Funktionen, die ins Flash geschrieben wurden o.ä.
Einen alterungsbedingten Hardware-Defekt, der bei nun 3 Leuten innerhalb
von wenigen Monaten auftritt, halte ich mittlerweile für sehr
unwahrscheinlich. Diese "Hardcore-Spikes" (man beachte die Screenshots,
das ist mehr als "altbekannten" Spikes an der Flanke etc.) wurden
jedenfalls nach meiner Recherche noch nie vor Dezember 2012 berichtet.
Es ist mit Sicherheit ein Timingproblem das in Zusammenhang mit dem
FPGA-Design steht und die ADCs betrifft, nur wird dieses nach meinen
aktuellen Erkenntnissen durch eine Änderung der Firmware hervorgerufen
bzw. begünstigt.
Ich denke doch, dass das diese Sache mehr als ein Einzelproblem mit
manchen Scopes ist.
Wäre toll, wenn du dir das aus Firmware Sicht nochmal ansehen könntest.
Hallo Ben, nach zwei Tagen Sturm im Ionischen Meer in einer einsamen Bucht, bin ich heute mal wieder dank WLAN online. Ja das Thema Spikes ist ja kein Neues. Auch der Zusammenhang mit dem thermischen Zustand des Gerätes wurde mehrfach berichtet. Wobei aber interessanterweise bei einigen Geräten die Spikes mit warmem Gerät verschwinden, während bei anderen die Spikes erst bei warmem Gerät auftauchen. Wesentlich scheint hier die Hardwareversion (FPGA-Version) zu sein. Softwareseitig (Firmware) habe ich aber seit einiger Zeit nichts verändert. Bei meinen beiden Geräten kann ich auch keine Auffälligkeiten gegenüber vorher feststellen. Hast Du evtl. die Hardwareeinstellungen anders als vorher? Wenn man die "High Frequency" Einstellungen benutzt hat man teils deutlich mehr Spikes als in der "Factory" Einstellung - dafür aber keine Signalverzerrung bei hohen Frequenzen. Auch der Ausschnitt des Signals auf der Zeitachse (in denglisch "Pretrigger" und "Memory Browser") hat in Verbindung mit der Zeitbasis Einfluß darauf. Soll heißen, wenn man mit anderen Einstellungen arbeitet als vorher, kann es sein, dass es einem mehr auffällt. Als Gegentest kann man ein Komplettbackup mit der alten Originalfirmware einspielen um zu testen ob es da Unterschiede gibt. Das haben auch schon Einige getan um dann festzustellen, dass es vorher auch schon so war, aber irgendwie nicht so aufgefallen ist. Gruß vom Skipper Hayo
Hast du dir mal die Spike-Screenshots angesehen? Es rammelt die Spikes dauerhaft, das fällt jedem sofort auf. Natürlich sind nicht alle Geräte betroffen, genauere Untersuchungen welche HW Version es ist müssen wir noch anstellen. Bei mir sind die Spikes (wie berichtet) auch nie wieder verschwunden d.h. auch nicht nach einem Komplettbackup. Und dass hier mehrere auf einmal von Spikes berichten, die sie vorher nie hatten, ist schon merkwürdig, findest du nicht? Schau mal die Threads durch, es gab DIESE Spikes nicht vor Dez. 12. Unabhängig von der thermischen Abhängigkeit ist ja alleine schon das plötzliche auftreten der vorher_nie_vorhandenen Spikes merkwürdig! Achso, HW Einstellung ist Factory, sonst wird alles nur schlimmer.
Mit dem neuen FPGA-Design ist das Geschichte, da gibt es keine Spikes mehr. Kein Grund, Geräte dauerhaft auszumustern. Jörg
das stimmt, ich erwarte auch gespannt das finale FPGA Design. Aber als einziges Scopes war das Wittig schon immer sehr gewagt, und mit diesen Spikes ist es eben total unbrauchbar. Da kann ich also nicht warten... Obwohl dieses Projekt inkl. deiner sehr vielversprechenden Arbeit eigentlich der Hauptgrund ist, das Wittig noch im Regal stehen zu lassen :) Dennoch- es wurde halt zum Bastel- Scope degardiert und "gemessen" wird mit was anderem. Bleibt für mich auch unabhängig davon, dass der neue FPGA Entwurf besser ist ;) die Frage, warum das überhaupt passiert ist- das Original Design hatte diesen Fehler (starke Spikes Kanal 2) ja ursprünglich (bei mir und 2 anderen) nicht. Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter Speicher) mit der BF-FW?
@Ben > Hat mir jemand vielleicht ein aktuelles Dump vom 2022A (kompletter > Speicher) mit der BF-FW? welche Version denn???
elecBlu schrieb: > Hast du dir mal die Spike-Screenshots angesehen? Es rammelt die Spikes > dauerhaft, das fällt jedem sofort auf. > Natürlich sind nicht alle Geräte betroffen, genauere Untersuchungen > welche HW Version es ist müssen wir noch anstellen. > Bei mir sind die Spikes (wie berichtet) auch nie wieder verschwunden > d.h. auch nicht nach einem Komplettbackup. > Und dass hier mehrere auf einmal von Spikes berichten, die sie vorher > nie hatten, ist schon merkwürdig, findest du nicht? Hi, habe wieder WLAN hier auf dem Boot und nutze die Gelegenheit mal um zu antworten. Also wenn Du nach dem Einspielen eines Komplettbackups immer noch grobe Spikes hast, gibt es nach meiner Logik nur zwei Möglichkeiten: 1. Es ist Dir vorher nicht so aufgefallen, weil Du andere Einstellungen verwendet hast. 2. Irgendetwas an Deiner Hardware hat sich geändert (thermisch, Alterung, lose Pins etc.) Jedenfalls ist das Gerät ja nach dem Einspielen des Backups wieder im Originalzustand, so dass die BF-Firmware nicht dafür verantwortlich sein kann. An der FPGA-Konfiguration kann die Firmware nichts verändern, das scheidet also aus. Gruß Hayo
eben deshalb war ja meine Frage oben ob über oder unter dem üblichen Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das schreiben der Math- Funktionen ins Flash mit 5.7! Da es in einer folgenden Version (ich hatte nicht jedes Release geflasht) auftrat. Wenn das nicht der Fall ist, kann es das wohl nicht sein das ist mir auch klar. Und es wäre sofort aufgefallen, glaubs oder glaubs nicht, wenn die Spikes vorhanden waren, siehe Screens und damalige Beschreibung. Ich habe das Gerät 3 Jahre genutzt, genauso wie "sh0dan" mir fast identisches berichtet hat. @ Michael: Hardware 8C7.0, BF Version eigentlich egal. Also Obacht Leute, nach 3,5 - 4 Jahren verabschieden sich die Welecs bevorzugt, hardwarebedingt ;) Gabs nicht 3 Jahre Garantie? Höhö.
Ben L. schrieb: > eben deshalb war ja meine Frage oben ob über oder unter dem üblichen > Dump- Speicherbereich was geändert wurde/ wird! Insbesondere das > schreiben der Math- Funktionen ins Flash mit 5.7! Naja, wenn Du ein komplettes Backup wieder zurückspielst ist halt alles wieder original, also das komplette Flash. Da ist dann nix mehr oberhalb oder unterhalb was anders sein könnte. Das Einigen verstärkte Spikes aufgefallen sind glaube ich schon. Aber ich kann mir aus besagten Gründen nicht vorstellen, dass es einen Zusammenhang mit der BF-Firmware gibt. Beide Geräte die ich verwende arbeiten da genauso wie mit der originalen Firmware. Beide haben auch sehr unterschiedliches Spike-Verhalten. Aber wie Jörg schon anmerkte, ist das ja zum Glück bald Geschichte :-) Gruß vom Skipper
Morgen, ich hab jetzt das W2022A von sh0dan,von den Spikes merk ich nichts(ca. 20°C), aber das Oszilloskop hängt sich oft auf wenn ich Coupling oder Probe verstellen möchte, dann ignoriert es alle Eingaben abgesehen von den Drehgebern. Firmware ist 1.2.BF.6.7 MFG Henning
Angehängte Dateien:
-
25MSa-s-10us.png
4,4 KB -
250MSa-s-5us.png
4,6 KB
wo ich gerade mal dabei bin... 1kHz Rechteck, 25MSa/s 10µs, ist alles schön sauber. Eine Stufe weiter, also 250MSa/s 5µs, sind die Spikes extrem bis 20ns. Siehe Shots! Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv... EDIT: Die Screenshotsoftware kennt keinen COM10 ?
Michael D. schrieb: > Jetzt stellt sich mir die Frage, was wird ab 250MSa aktiv... Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. Sogar das LCD ist dann gestört. Die Hardware geht dann in einen Modus der alle 4 ADCs verwendet. Das ist wohl irgendwie anstrengender. Wo wir gerade dabei sind: in der BF-Firmware gibt es immer noch diesen merkwürdig großen Sprung von 25 MSa auf 250 MSa. Das muß nicht sein, habe ich Hayo auch schon früher drauf hingewiesen, aber vielleicht nicht deutlich genug. Hayo, guck dir mal die Funktion CaptureSetTimebase() in osoz/platform/nios/src/capture.c an. Die alte Hardware teilt von 1 GSa abwärts, erstmal mit Halbierungen: /1: 1 GSa /2: 500 MSa /4: 250 Msa /8: 125 MSa /16: 62,5 MSa Dann geht es in 8er Schritten quasi unendlich weiter: /32: 31,25 MSa /40: 25 MSa /48: 20,833 MSa /56: 17,857 Msa ... usw Es sind also noch 2 Stufen zwischen 25 und 250 MSa. Zu den langsameren Teilern werden die Abstände immer feiner, ist halt reziprok. Der Teiler hat volle 32 Bit Auflösung, das geht also bis grotesk langsam. Jörg
@Jörg > Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem > alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. > Sogar das LCD ist dann gestört. Ja, wie man sieht... Was händelt dann das neue Design die ADC's, das diese Spikes nicht auftreten?
Michael D. schrieb: > @Jörg >> Ich kann's grad nicht testen, aber bei meiner Hardware wird es (mit dem >> alten FPGA-Design, versteht sich) oberhalb von 250MSa ganz schlimm. >> Sogar das LCD ist dann gestört. > Ja, wie man sieht... Nein, anders, bei mir ist dann ein Teil des LCD grisselig. Vermutlich gibt es dann Timing-Fehler beim Auslesen des Bildschirmspeichers. Das ist also noch ein anderes Problem. Die Spikes hingegen sind vermutlich Timingfehler bei der Signalverarbeitung. > Was händelt dann das neue Design die ADC's, das diese Spikes nicht > auftreten? Frag' mich lieber, was das alte Design falsch macht... Soweit wir wissen hat es keinerlei Timingchecks. Die Synthese weiß gar nicht wie schnell die Logik laufen wird und kann deshalb nicht prüfen, ob das noch paßt. Die Daten werden dort mit den vollen 250 MHz verarbeitet. Das ist zwar das Maximum, was die Einzelkomponenten des FPGAs leisten können (Speicher, Multiplizierer, Logikzellen, etc.), aber für eine ganze Baugruppe eines Designs viel zu schnell, das Routing und die Logik ist auch noch da. (Das ist ungefähr so, wie ein Auto für 250 km/h zu bauen, weil's grad auf den Reifen und dem Tacho draufsteht, ohne den Konstukteuren von Bremsen und Fahrwerk zu erzählen was es werden soll.) Die Sampleverarbeitung van Alex arbeitet mit dem halben Takt und verarbeitet pro Takt doppelt so viele Werte, parallel. Zugegeben wird auch viel mehr gerechnet, die Filterei gab es ja vorher gar nicht, schon von daher können wir nicht so schnell. Wir fahren also halb so schnell, aber mit 2 Autos, schaffen das gleiche rüber. Jörg
Ich habe mir in der Bucht ein "jungfräuliches" W2022A geschossen und habe festgestellt, dass der Update auf eine neueste Version über den WelecUpdater nicht funktioniert. Der Upload kommt anscheinend bis Zeile 5. Anschließend kommt nur noch die Meldung "Uebertragungsfehler: ? xxxx" Bis kurz vor BF.5.2 (5.1C?) ist ein Update noch möglich. Bei den darauf folgenden Versionen wurde anscheinend ein schnellerer Loader eingeführt, was möglicherweise den Fehler verursacht. Erst über Perl konnte ich mein Gerät auf BF.6.7 updaten. Das Testsignal auf Kanal 2 sieht bei BF.6.7 merkwürdig aus. Es sollte vermutlich ein Sinus sein, besteht jetzt aber aus einzelnen Sinusperioden, welche durch Nullinien miteinander verbunden sind. Getestet habe ich auf zwei verschiedenen PCs jeweils mit XP. Hardwareversion des Gerätes ist 8C7.0E. Natürlich will ich nicht nur meckern, ganz im Gegenteil, Hut ab vor Euren Programmierkünsten.
Meines Wissens ist nach dem erstem Update auf Hayos FW die Wellec SW nicht mehr für Updates zu gebrauchen. Wurde mehrmals hier im Forum so beschrieben, man soll es gar nicht probieren. Ist auch kein Schaden, der Update-Vorgang mit Wellec-Sw dauerte gute halbe Stunde.
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. Having upgraded my W2012A with the OPA653 I installed the latest firmware 1.2.BF.6.7 by Hayo, so I noted some weird things. Maybe I'm wrong, however: 1) Coupling channels are labeled as [DC (ext)] and [AC (ext)], I can not find GND (yes, I know someone wanted it to be deleted because it is really just a dummy fiction, but it seemed to me that in the end it was decided to keep it). However, what means (ext)? 2) When the waveforms' amplitude exceeds some limit the upper and bottom become flat. I guess it is due the exceeded in the ADC range that now it is very different that before. It is not a real problem, but as it is now seems to me that the screen's area is not efficiently used. I hope to have been understandable. 3) Some fake labels and controls' icons when You play with the setting. I will more precise next time when I will test better this for me new firmware. As always all I wrote is not intended as criticisms but only for knowledge. And as always Hayo RESPECT for You and all your hard work! Thank You very much Hayo! Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Luc schrieb: > Coupling channels are labeled as [DC (ext)] and [AC (ext)], I can not > find GND (yes, I know someone wanted it to be deleted because it is > really just a dummy fiction, but it seemed to me that in the end it was > decided to keep it). > However, what means (ext)? ext -> External Trigger This are the settings for the external trigger. Therefore you won't find a GND coupling. The coupling for the channels You will find in the channel menu of each channel. > When the waveforms' amplitude exceeds some limit the upper and bottom > become flat. Seems that there is something wrong with the gain or with the resistors in your mod. Could you provide us with a screenshot? Kind regards Hayo
kingcopper schrieb: > Bis kurz vor BF.5.2 (5.1C?) ist ein Update noch möglich. Bei den darauf > folgenden Versionen wurde anscheinend ein schnellerer Loader eingeführt, > was möglicherweise den Fehler verursacht. Hi, etwas späte Antwort - ab 5.2 (glaube ich) wurde der Loader mit komprimiertem Coding eingeführt (UCL). Vermutlich ist das der Grund. Gruß Hayo
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. Thank You for the reply Hayo and happy to meet You again! :-) Hayo W. schrieb: >ext -> External Trigger > >This are the settings for the external trigger. Therefore you won't find >a GND coupling. The coupling for the channels You will find in the >channel menu of each channel. hhuummm... Hence I must to have a problem. Indeed I found [(ext)] and I am unable to find the correct ones. Maybe something has gone wrong performing the upgrade. I did firmware upgraded before the hardware modification, but I do not think it is the culprit. I will try to reprogram the DSO. Thank You for the hint Hayo! Hayo W. schrieb: >Seems that there is something wrong with the gain or with the resistors >in your mod. I am pretty sure components are correct and correctly placed and welded. I guess the culprit is somewhere else, I suspect bad tune in the compensation of the channels' input stages. I must to investigate about that. ;-) Hayo W. schrieb: Could you provide us with a screenshot? Sadly right now I am far from my DSOs, but stay tuned for the future: I warn You!... ;-) Again I thank You very much Hayo for all your contributions and hard work You share with us, RESPECT!!!!!!! Nochmals vielen Dank Hayo!!! Mit freundlichen Grüßen, Luc
Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind WELEC. @Hayo Hayo, wie immer, Sie hatten recht. Ich folgte Ihren Vorschlag durch das Laden der Firmware wieder und alles geregelt ist: KLASSE! Leider ist die Frage der Bandbreite hat sich nicht geändert. Als Lösung habe ich versucht, die Eingangskanäle zu kalibrieren mit dem Rechteckgenerator, die ich gebaut. Ich habe entdeckt, dass es nicht in Ordnung für diesen Zweck, Berühren der Kompensatoren nichts passiert. Ich vermute, dass selbst bei 33 MHz ist der Generator zu schnell auch als Zeit des Auf-und Abstieg. Statt der Generator funktioniert perfekt für die Auswertung der Bandbreite. Ich habe die Instrumente mit Generator 500ps und mit Marconi 2019A überprüft und praktisch habe ich die gleichen Ergebnisse. Also für die Bewertung der Bandbreite funktioniert gut für mich und ist ein nützliches Werkzeug, es ist jedoch nicht geeignet, um die Kompensations-Eingangs einzustellen. Ich habe, um die Eingänge mit dem alten Lyons Instruments PG-2B einstellen. Ich werde hier zu stoppen,der Nächste! Vielen Dank an alle Unterstützer des Projekts Welec! Mit freundlichen Grüßen, Luc
Angehängte Dateien:
-
test_50_MHz.JPG
59 KB
Hello I tested the last firmware with input OPA amp. modification(datasheet states a Ft of 600MHz),great job as usual from Hayo,low noise in the 10 mv volt /div and improved frequency response. But just a little bug in the trigger,please see enclosed file,using for example a 50MHz sinewave,the sine around trigger point has a distortion,didn't noticed with old firmware. Happy 2014 and thank you to all the DSO team and Hayo for this last project. Sandro
Hi Sandro, thanks for reporting. I will check this and try to fix it as soon as possible. Greetings and a happy new year to all from Valle de Aosta in bella Italia Hayo
Happy new year Sandro, I see trigger position on the axis of time it's out of the video area it being far left. By chance have you saw the same problem putting it within the area of the video? Glad you wrote about the OPA amp. modification. Was your DSO the 100MHz or the 200MHz version? Pretty good shape for the waveform but filter is on, would be better to see it with filters switched off. Even if 50MHz is low frequency, would be better increase it a bit. You can say ~100MHz or more. Noise and gain should be much improved for sure. While Ft is for sure 600MHz in the datasheet, but the real one on the DSO? Did you do some measures? You can read different opinions on it. Victor
moinmoin Hayo & Co., ziemlich ruhig hier ;) habe eben versucht im single mode signale 'einzufangen', leider wird bei einer TB groesser 5µS in der Ver 6.7 nix mehr dargestellt ;(, habe mich bis zur 6.3 zureckgeschafft, da scheint es noch zu funktionieren, koenntest du bitte mal nachsehen und uns ein update hochladen, vielen Dank! vlG Charly ps. wenn 'Single' auf warten steht (rot) und an der TB gedreht wird sollte die Signale auf dem Schirm geloescht werden
:
Bearbeitet durch User
Hallo Charly, ich habe Deine Email bekommen, antworte aber trotzdem mal hier im Forum. Zur Zeit bin ich mal wieder im Ski-Urlaub :-). Daher auch eine etwas verzögerte Reaktion. Die Probleme mit dem Singletrigger waren mir kürzlich auch schon aufgefallen.Da sich bisher noch keiner darüber beschwert hat war ich mir nicht ganz sicher ob ich bei mir was falsch eingestellt hatte. Bisher bin ich noch nicht dazu gekommen der Sache auf den Grund zu gehen, aber ich werde mich mal dransetzen sobald ich wieder zuhause bin. Gruß Hayo
Hallo, ich wollte nur mal sagen, dass ich auch das Problem mit dem Single-Modus habe. Außerdem ist mir aufgefallen, dass es einen Darstellungsfehler im USTB-Modus gibt: Wenn man die TB auf 1s stellt und im Roll-Forward-Modus das Zeitfenster mit der Browse-Option anzeigen lässt, wandert der rechte Begrenzungsstrich oben in der Zeitleiste aus selbiger heraus. Irgendwann kommt er dann von links wieder ins Bild. Grüße Lukas
Moinmoin Hayo, wollte nur mal kurz 'nachtriggern' ob es schon was neues gibt :) vG Charly
Moin, die Sache ist nicht vergessen. Der Messplatz ist bereits aufgebaut, aber ich bin zur Zeit etwas eingespannt und komme daher nicht so richtig dazu mich dran zu setzen. Soll aber auf jeden Fall in Kürze weiter gehen. Gruß Hayo
moinmoin, super Hayo, dann handelt es sich ja nur noch um nS bis es losgeht ;) wenn du soweit bist schreib mir event. eine PN, i haette noch ein paar 'unschoenheiten' die event. mit ein paar Zeilen auch zu beseitigen sind vlG Charly
Dem Charly geht's mal wieder nicht schnell genug :-))) Eigentlich könntest du uns deine erwähnten "Unschönheiten" mitteilen, oder? Gruß Michael
jojo, so ist das........ ich habe das Oszilloguck sehr oft im einsatz daher ist es manchmal schon a bissel stoerend wenns nicht so will wie ich mir das vorstelle.... mit den 'unschoenheiten' will ich jetzt noch keinen verrueckt machen da ich ein Downgrate auf die 6.3 gemacht habe und event. die meisten davon schon beseitigt sind, ist also nix geheimes, wenns hier interessiert kann ich es natuerlich auch hier posten vlG Charly
Hi Charly, bin gerade vom Griechen zurück. Poste das mal ruhig hier, dann kann man auch drüber diskutieren in wieweit man da Änderungen einfließen lassen sollte. Muss mich auch erst mal wieder in die ganze Sache reinwursteln da ich mich in letzter Zeit mehr mit Langwellen, Mittelwellen und Kurzwellenempfang beschäftigt habe. Als krassen Gegensatz zu unserem SMD-gespickten DSO habe ich über Winter einen alten U-Bootempfänger aus dem 2. Weltkrieg renoviert - da bekommt man schon ein anderes Gefühl für die Dimensionen von Bauteilen und Betriebsspannnungen (300V!!!). Wenn man bedenkt, dass diese Technik mit den Röhren und Bauteilen in Kartoffelgröße damals aktueller Stand der Technik war... Immerhin kann ich da noch alles ohne Brille erkennen :-) Gruß Hayo
moinmoin Hayo, beim Griechen haett i dir helfen koennen ;) bei dem U-Boot RX haett i auch gerne mitgemacht, ist immer interessant wie die Jungs damals gebaut haben, i hab hier auch 'grobtechnik' mit der 3-500Z, GS31 / GS35 u. 4CX1500 in der Pipeline, komme aber im moment nicht dazu ;( hier so ein paar Punkte dir mir einfallen: 1. die Einstellung f. den Tastkopf wird nicht dauerhaft gespeichert (z.B. 10:1) 2. wenn ein Signal zb. mit 5V anliegt das kurze impulse nach 0V hat und man dreht an der TB,, schaltet mal in den Single & wieder zurueck, usw dann triggert er nicht mehr, man muss die Probe abklemmen und wieder drann dann laufts als waehre nix gewesen 3. ruft man Speicher auf, und ueberlappt signal mit memory dann vergisst er irgendwann die einstellung f. Y und schaltet dort auf 2V/Div. (meine ich mich zu errinern) vielleicht bin i auch zu verwoeht, hatte durch meinen vorherigen job ein 'grosses' Agilent da, das ist jetzt leider weg ;(( ps. bitte denk daran dass i mit der 6.3 arbeite weil in spaetern versionen der Single nicht mehr wollte vlG Charly
Moin Hayo, über deine Ausdrucksweise könnte ich mich immer wegschmeißen..."Kartoffelgröße" :-))) Hast du deine Restauration dokumentiert? Ich finde sowas immer hochinteressant und es wäre bestimmt einen eigenen Thread wert! Es ist schon sehr lange her, das bei Entrümpelungen die Röhrengeräte auf der Straße standen. Die habe ich mir immer geschnappt, Röhren ausgebaut und gesammelt(als Ersatz für defekte Geräte). Heute würde ich dafür bestimmt gutes Geld bekommen, leider hatte die Verwandschaft alles entsorgt... Gruß Michael
Oh! Hätte ich gar nicht gedacht, dass hier auch an sowas Interesse besteht. Ist natürlich alles dokumentiert. Ich mache gerne einen Thread dafür auf. Das Gerät steht übrigens auch im Horchraum des U995 in Laboe - ich poste den Link im neuen Thread. Hayo
So, wie versprochen hier der Link zum neuen Thread über Röhrenradios - bevor es hier zu offtopic wird :-) Beitrag "Restaurierung alter Röhrenempfänger - Telefunken Ela1012a/b" Hayo
Hallo Leute, heute habe ich mich nach der Arbeit mal durchgerungen und mich um die Firmware gekümmert. Das Triggerproblem ist nun gefixt. Bei den anderen gemeldeten Problemen konnte ich das nicht so recht nachstellen. - Die Probeeinstellungen werden bei mir einwandfrei gespeichert. - die Triggeraussetzer nach drehen der TB und Singleshot habe ich nicht hinbekommen -> vielleicht noch mal prüfen und dann genauer beschreiben wie man das nachstellen kann - die Einstellungen beim Overlay haben bei mir problemlos funktioniert - Im Ultra Slow-TB Modus gab es (leider) auch keine Auffälligkeiten Das Ganze getestet mit der aktuellen 6.8. Falls da doch noch Bugs sein sollten bitte mit genauer Anleitung wie ich das nachstellen kann. Gruß Hayo
Danke Hayo!!! wie beschrieben waren die Fehler bei mir mit der 6.3, i bekomme verm. am Fr. die neue Platine und dann bin ich wieder 'verstaerkt' in der HW u.SW entwicklung und da 'qualmt' das oszi wieder ;) vlG Charly
Hallo zusammen! Lieber Hayo, Danke und schön, daß Du wieder etwas Zeit für die Oszi Firmware hattest! Ich habe mit der Version BF6.8 mal alles was mir so seit BF5.10 aufgefallen war nochmal durchgespielt und getestet. Hauptproblem bei der Arbeit mit dem Oszi war/ist die Triggerauslösung bzw, des erneuten Startes der Signalaquise nach der Änderung der Einstellungen zur Signaltriggerung. Dazu gab es ja immer wieder Hinweise im FW-Thread. Grundsätzlich soll der NORMAL-Mode der funktionierende Modus sein! Ich versuche mal zu beschreiben: Wenn man z.B. den Triggerpegel im Edge-Modus langsam und schrittweise höher als das dargestellte Signal stellt, hört die Triggerung auch korrekt auf.Wenn danach der Triggerpegel wieder kleiner gemacht wird und in das Signal hinein dreht, funktioniert die Triggerung auch wieder, wenn der Pegel wieder auf Signalhöhe ist. Im Pulsewidth-Modus funktioniert dies nicht immer.Zusätzlich kommen noch die Zeitparameter für die Impulse ins Spiel. Auch wenn man diese verstellt, soll die Triggerung/Signalaquise wieder starten, wenn die Parameter wieder zum Signal passen. Z.B. kann man im Modus "><" den größeren Wert herunter drehen. Falls die Impulslänge nicht mehr passt bleibt das Signal stehen. Dreht man danach wieder auf die alten Werte zurück, startet die Triggerung nicht mehr. Sie läßt sich meist erst durch Verstellen der Timebase (Mainwheel) wieder starten. Grundsätzlich sollen nach einer Änderung aller für den Modus relevanten Triggerparameter alle für den Modus relevanten Parameter wieder zur Hardware geschrieben werden und die Signalaquise auch wieder gestartet werden. Ich kann leider im Moment nicht übersehen, ob es in der Firmware noch Situaionen gibt, die dies verhindern?? Es gibt sicher noch andere Einstellungen, nach deren Wechsel es sinngemäß auch funktionieren muss. Vielleicht geht da ja noch was :-) Viele Grüße Jürgen
Hi Jürgen, die Probleme beim Pulsweitentrigger die Du beschreibst sind mir bekannt. Leider kann ich da firmwareseitig nicht viel machen, da das Hauptproblem eine lausige Implementierung der Triggerfunktion im FPGA ist. Gruß Hayo
Angehängte Dateien:
-
USTB-Bug.png
2,8 KB
Hallo, ich habe mal einen Screenshot von dem USTB-Bug angehängt. Um ihn zu reproduzieren muss ich nur einmal in "Utility" auf "Default Setup" drücken und dann die Zeitskala bis auf 1s/ drehen. Wenn mann dann "Browse" einschaltet, wandert der rechte Strich in der Leiste wie auf dem Bild zu sehen aus selbiger heraus. Gibt es außer auf "Default Setup" zu drücken vielleicht noch ne andere Möglichkeit die Standardeinstellungen wieder herzustellen? Also, um wirklich alles wieder auf Null zu setzen? Mir ist noch die Kleinigkeit aufgefallen, dass oben links auch die ganze Zeit der Pfeil eingeblendet ist, der normalerweise anzeigt, dass der Trigger links außerhalb des Bildbereichs liegt. Der sollte in diesem Modus wahrscheinlich eigentlich nicht angezeigt werden, oder? Grüße Lukas
Aahh, danke Lukas. Damit kann ich gezielt auf Fehlersuche gehen. Gruß Hayo
Hi at Victor, yes is possible to improve the max. frequency adjusting the RC network input OPA but each DSO flatness should be individually calibrated and there isn`t enough memory to do it. And higher bandwith means higher noise,now is one of the lowers in its class. Let`s wait for next improvements about fast trigger point and ustb. Thank you to Hayo and all the Team and happy Easter from Italy. Sandro
Hallo, ich hab mal ein bisschen daran "herumgeschraubt" und die Triggerei verbessert. Auch die Pulsewidth Triggerung geht jetzt besser. Hayo W. schrieb: > Leider kann ich da firmwareseitig nicht viel machen, da das Hauptproblem > eine lausige Implementierung der Triggerfunktion im FPGA ist. Liegt nicht nur am FPGA :-) Wer mag, kann ja mal etwas testen und Rückmeldung geben. Noch einen schönen Feiertag! Gruß Jürgen
Hi Juergen, koenntest du bitte auch ein .flash hochladen, Danke! vlG Charly
Hallo Jürgen, ich bin leider noch nicht dazu gekommen Deine Triggermodifikation zu testen. Aber vielleicht könntest Du mir sagen was Du genau verändert hast, dann kann ich das gezielter testen und evtl. in das nächste Release einbauen. Gruß Hayo
Charly B. schrieb: > koenntest du bitte auch ein .flash hochladen, Danke! Hallo Charly, hier die .flash und .ram Gruß Jürgen
Hallo Hayo, bin eben erst zurück. Ich würde gern erst einige Rückmeldungen haben, bevor ich mich hier äussere. Einfach, damit das nicht nur eine "eingebildete" Verbesserung ist :-) Danach gerne. Viel Grüße in den Norden! Jürgen
danke, werde uebers WE mal testen vlG Charly
Hallo Jürgen, bin gerade am Testen, kann zum Triggerverhalten aber noch nichts näheres sagen, zumindest ist es nicht schlechter geworden ;) Eine Macke hat sich allerdings eingeschlichen: Die Einstellung für PreTrigger wird nicht gespeichert; nach Aus-/Einschalten triggert das Welec immer auf den linken Bildschirmrand. Grüße, Ulrich
auch kurze Rueckmeldung v. mir: war am WE auf einer anderen Baustelle, hoffe jetzt auf das verlaengerte WE vlG Charly
Hallo werte Gemeinde, ich stecke zur Zeit in baulichen Maßnahmen am Haus (Carport) und komme daher nur dazu den Thread kurz zu lesen. Sobald ich wieder etwas mehr Zeit habe bin ich wieder am Ball. Gruß Hayo
Hallo, ich habe schon länger mein DSO nicht mehr in Benutzung gehabt. Daher wollte ich ihn nun endlich mal wieder einsetzen und das neuste Firmware update aufspielen. Von 1.2.BF.4.8 auf 1.2.BF.6.8 Aber leider schlägt bei mir das Update immer fehl.
1 | Flashloader: |
2 | |
3 | GERMSloader.pl Ver 1.2.0 |
4 | |
5 | *** No Warranty |
6 | *** |
7 | *** This program is distributed in the hope that it will be useful, |
8 | *** but is provided AS IS with ABSOLUTELY NO WARRANTY; |
9 | *** The entire risk as to the quality and performance |
10 | *** of the program is with you. Should the program prove defective, |
11 | *** you assume the cost of all necessary servicing, repair or correction. |
12 | *** In no event will any of the developers, or any other party, |
13 | *** be liable to anyone for damages arising out of the use or inability |
14 | *** to use the program. |
15 | |
16 | Device : COM3 |
17 | Flash filename : TomCat.flash |
18 | |
19 | --- Writing GERMS firmware... |
20 | Writing line 000016 of 027361: ........... transferred. |
21 | Error: Timeout while reading response from DSO! |
22 | Response was: 'r0' |
23 | Firmware update was NOT successful! |
24 | Please fix the connection issue and retry! |
Ich habe auch versucht auf 1.2.BF.4.9 zu updaten aber dies schlägt genauso fehl. Ein Backup bzw. den Flash auslesen mit GERMSloader oder WelecUpdater schlägt auch fehl. Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. Habt ihr eine Idee warum das Update nicht funktioniert?
Tom schrieb: > Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. Sicher daran. Was ist an > Please fix the connection issue and retry! so rätselhaft? ;-) Gruß, Guido
Hallo Tom, Guido hat recht, das sieht ganz nach der seriellen Schnittstelle aus. Das Beste was Du machen kannst ist, Dir einen alten Rechner mit echter serieller Schnittstelle zu suchen (Freunde, Bekannte) und damit das Update zu machen. Ich benutze auch einen USB zu seriell Wandler, aber es funktionieren halt nicht alle. Da hatten wir schon öfter entsprechende Rückmeldungen. Bei dieser Diagnose gehe ich mal davon aus, dass Du die Initialisierung des Updatevorgangs mit den beiden Funktionstasten F1/F2 am DSO korrekt gemacht hast. Gruß Hayo
Hallo, vielen dank für eure Rückmeldungen und Hilfe. >> Ich verwende einen Digitus Serial USB Converter (FTDI) mit Win8 x64. > > Sicher daran. Habe ich auch gedacht, aber ich bin mir nicht ganz sicher wie ich es früher gemacht habe. Ich bin der Meinung das ich es auch damals mit dem Serial Converter gemacht habe. > Was ist an > >> Please fix the connection issue and retry! > > so rätselhaft? ;-) Nicht so viel :D aber es hätte ja sein können das Respone "r0" etwas "besonders" bedeutet. > Guido hat recht, das sieht ganz nach der seriellen Schnittstelle aus. > Das Beste was Du machen kannst ist, Dir einen alten Rechner mit echter > serieller Schnittstelle zu suchen (Freunde, Bekannte) und damit das > Update zu machen. Ich benutze auch einen USB zu seriell Wandler, aber es > funktionieren halt nicht alle. Da hatten wir schon öfter entsprechende > Rückmeldungen. Welchen Converter/Wandler nutz du denn? Bis jetzt hatte ich noch nie Probleme mit dem Digitus. > Bei dieser Diagnose gehe ich mal davon aus, dass Du die Initialisierung > des Updatevorgangs mit den beiden Funktionstasten F1/F2 am DSO korrekt > gemacht hast. Jup, habe ich gemacht. Zum glück haben auch die neusten Mainboards immer noch eine COM-Schnittstelle. Da werde ich mich wohl mal um eine Blende kümmern müssen. Vielen Dank und liebe Grüße, Tom
Moin Tom, wenn du ganz sicher gehen möchtest, kannst du ja mal das Screenshot-Programm starten, da bekommst du auch noch mal eine Bestätigung auf den Schirm, bzw. Dos-Fenster. Nicht vergessen die korrekten Parameter (COM1-9, Baudrate...) in die Batch einzutragen. Desweiteren kommt es auch vor, das wenn du einen anderen USB-Port verwendest, das dieser eine andere COM-Port Nummer zugewiesen bekommt! Mal im Gerätemanager nachschauen, welche Zuweisung dein COM-Port von Windows gewählt hat. Auch dort, müssen die Parameter passen! Gruß Michael
Hallo, ich habe gerade mir ein Welec W2024A zu gelegt und musste feststellen das das sourceforge Wiki nicht mehr da ist (z.B. http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement). Gib es das noch irgend wo weil ohne ist schwer an Infos zu kommen? Gruß Mx
Das ist mir leider auch schon aufgefallen. Aber nachdem das Weleg-Geraffel schon so unbefriedigend ist, hatte ich auch keinen Nerv mehr, auch noch den (wirklich bemerkenswerten und heldenhaften) Open Source Bemühungen hinterherzulaufen. Irgendwie wird man müde und fragt sich, ob man an dem Punkt ist, das Teil in die Bucht zu setzen (denn hier im Markt wird ja alles zerrissen) und sich was Anständiges zu kaufen... Nichtsdestotrotz: Im Web-Archiv unter http://web.archive.org/web/20130326014650/http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement findet man noch Rudimente.
Oh, das hatte ich noch gar nicht bemerkt. Grundsätzlich kann ich empfehlen die letzte Firmwareversion (1.2BF6.8) herunter zu laden und aufzuspielen. Es ist Einiges an Dokumentation darin enthalten und mit dieser Firmwareversion kann man das DSO schon ganz gut benutzen. Ich bin zur Zeit dabei mich mit Langwellen/Mittelwellen/Kurzwellenempfang zu beschäftigen. Schwingkreise, Antennen, Vorverstärker etc. - dafür kann man das Oszi eigentlich sehr gut gebrauchen. Gruß Hayo
Hello everyone! Is it possible doing something like this with the witting DSO and using a pc based signal generator software? http://www.youtube.com/watch?v=uMH2hGvqhlE If so, can someone get in the details of how this is done? Using FFT function and hod function?
Angehängte Dateien:
-
screen-0002.png
5,9 KB
Zuerst möchte ich mich bei allen Beteiligten bedanken für diese großartige Firmware. Der Verbesserung gegenüber dem Original ist einfach gewaltig! Nun zu meinem Anliegen/Verbesserungsvorschlag. Beim Screenshot werden zwar die Messergebnisse bzw. die Cursor-Ergebnisse angezeigt (siehe Screenshot), jedoch nicht die Cursor-Werte in den Softkeys. Es wäre halt sehr hifreich wenn nicht nur die Werte über den Softkeys erhalten bleiben, sondern auch die Softkeys der vorherigen Anzeige (bevor man in das Print-Menue gewechselt hat) mit den Istwerten ausgedruckt würden. Andreas
Hallo Andreas, sowas in der Art ist mir auch damals durch den Kopf gegangen, deshalb gibt es die Möglichkeit mit einem doppelten Druck auf den Quick Print Button den Screenshot anzustoßen ohne dass die Funktionsbuttons wechseln. Diese Funktion ist ebenso wie die meisten Zusatzfunktionen in der Datei "Special Functions" beschrieben :-) Viel Spaß noch mit Deinem DSO
Hallo Hayo, Danke für die prompte Antwort. Ich war so glücklich darüber dass ich mein DSO innerhalb von nur wenigen Stunden "umgebaut" habe. In dieser Euphorie ist mir diese Datei leider "entgangen" :-0 Ich werde den Beitrag mal im Auge behalten, falls noch Erweiterungen kommen. Danke!
Angehängte Dateien:
-
01_Sweep_Generator.jpg
260 KB -
02_MW_Antenna.jpg
290 KB -
03_Bode_Plot_W2022A.jpg
68 KB -
04_Bode_Plot_W2022A.jpg
67 KB -
05_Bode_Persistent_W2022A.jpg
40 KB -
06_Bode_Plot_SDS8102.jpg
66 KB -
07_Bode_Plot_SDS8102.jpg
64 KB -
08_Bode_Plot_SDS8102.jpg
64 KB
Ja es kommt noch was. Und zwar zum Beitrag von Alessandro:
> Is it possible doing something like this with the witting DSO ...
Yes indeed it is! A very interesting link you posted there. To explain
it I used the following measuring configuration:
- object to be measured is a MW loop antenna like it had been used in
the 1930s to 1940s. It is a resonant circuit with resonance between 500
KHz and 2MHz which can be adjusted with a variable capacitor.
- function generator HP3325A. Every signal generator with sweep function
can be used - but there must be a special sync output. We don't need the
signal sync output but the sweep sync out. That means, we need to know
when the sweep starts and when the sweep stops.
- the DSO is a W2022A and as reference an Owon SDS8102
What we have to do is to connect the sweep sync to channel 2 as trigger
signal. Set the timebase so that you can see one or a half period of the
sync signal. The effect is that we can see the complete sweep range on
our screen.
Now we connect the normal signal output via T-piece adapter to channel 1
and the end of the wire terminated with 50 Ohm to the antenna.
The sweep generator starts at 10 KHz and stops at 2MHz in continuous run
mode. The starting edge of the trigger signal (our sweep sync) has to be
on the left screen side. Now we can see the frequency response of our
system with 10KHz on the left screen side and 2MHz on the right screen
side. The quality of the plot on the W2022A is a little bit worse than
the plot on the SDS8102. That may be caused by some speed optimizations
in the
graphic routine. Switching the display into persistent mode leads to a
better result.
I hope the explanation was helpful - otherwise don't hesitate to ask!
Hayo
:
Bearbeitet durch User
Hallo Hayo, I have in my lab the HP3325A also,will test the sweep with my 8GHz Wiltron. Another nice application for our dso W2022. Hope you will have time to improve the trigger stability also .. Thank you! Sandro
Hi Sandro, the sweep sync out is on the backside and is called 'Marker' (frequency). You have to set the marker frequency with the button 'MKR FREQ' on a value between sweep start frequency and sweep stop frequency.
Hallo werte Gemeinde, es haben verschiedene User meine "Triggertest-Version" herunter geladen, aber leider keine Resultate zurück gemeldet :-( Genauer gesagt, hatte ich mir besonders die Pulsweiten Triggerei vorgenommen und durch eine kleine Änderung zum Laufen gebracht. Ich habe inzwischen weiter getestet und geforscht und meine, der PW Trigger tut mit der Testversion im Normalmodus genau was er soll, wenn passende Parameter eingestellt sind und setzt nach dem Verändern von Parametern auch wieder ein, wenn die Parameter wieder passen. @Ulrich An anderen Geschichten hab ich mich nicht "vergriffen". Hayo W. schrieb: > Aber vielleicht könntest Du mir sagen was Du genau verändert > hast, dann kann ich das gezielter testen und evtl. in das nächste > Release einbauen. Hallo Hayo, wichtigste Änderung für die Funktion PW-Trigger ist die Freigabe von Start_Record() am Ende der SetupTrigger Funktion. Die hattest Du wohl wegen einem Single-Shot Problem auskommentiert, welches Du aber wohl in der 6.8 gefixt hattest :-) Allerdings denke ich nach weiterer Suche in den Quellen, das offenbar vielleicht das Aussetzen des Edge-Triggers nur ein vermeintliches Aussetzen ist, da die angezeigte Triggerposition auf dem Schirm teilweise nicht das ist, was als Pegel zur Hardware geschrieben wird. Ursache könnten die kleinen Korrekturen bei der Pegelberechnung sein (Hardware::TriggerCorrection). Ich habe Diverses versucht, bin letztendlich aber an der zeitlich zum Triggermarker versetzten Anzeige der z.B. Sinusschwingung hängen geblieben :-( Die Triggercorrection scheint auch teilweise wirkungslos zu sein? Mit welcher Variablen oder Funktion kann man denn den Schwingungszug auf dem Schirm relativ zum Triggermarker verschieben?? Hier muss der GURU wieder ran :-) Hayo, ich hab Dir mal meine Fragmente der hardware_t angehängt. Kannst ja mal vergleichen. Die meisten Änderungen sind Kommentare für mein Verständnis... Beste Grüße Jürgen PS: Ich nutze z.B. die Codewarrior IDE zum Dateivergleich. Macht sich sehr gut.(Search,Compare Files..)
Hi Jürgen, ich bin noch nicht zum Testen gekommen, aber ich werde insbesondere Deine Zeile am Ende von SetupTrigger mal genauer auf ihre Wirkung testen. Vielleicht bringt es ja was, dann mach ich eine neue Version fertig. > Mit welcher Variablen oder Funktion kann man denn den Schwingungszug auf > dem Schirm relativ zum Triggermarker verschieben?? Das ist die Funktion UserIF::ON_MemoryPosition(void) (hier werden die Interruptwerte des Drehgebers ausgewertet) wobei die Funktion Display::RecalcTimeParameters() innerhalb dieser Funktion eine wichtige Rolle spielt. Gruß Hayo
:
Bearbeitet durch User
Hi Hayo, > Das ist die Funktion UserIF::ON_MemoryPosition(void) (hier werden die > Interruptwerte des Drehgebers ausgewertet) wobei die Funktion > Display::RecalcTimeParameters() innerhalb dieser Funktion eine wichtige > Rolle spielt. Danke für den Hinweis, ich habe das eben mal überflogen. Das ist um diese Uhrzeit für mich zu schwere Kost :-) Ich sehe mir das aber auf jeden Fall genauer an! Gruß Jürgen
Hallo Jürgen, ich habe auch schon etwas mit der Konzentration zu kämpfen (könnte am Wein liegen) aber ich konnte mir nicht verkneifen schon mal vorab mit der unveränderten 6.8 ein paar Tests zu machen. Ich konnte hierbei nur eine Konstellation beim Pulsweitentrigger ausmachen, die zum Stillstand führt. Und zwar ist das im Modus Pulsweite zwischen Wert 1 und 2. Wenn Wert 1 (also der untere Wert) im Normaltrigger-Modus unterschritten wird, dann bleibt die Kiste stehen. Da hilft auch kein Ändern des Signals am Generator oder Ändern des unteren Grenzwertes. Wenn man allerdings die Timebase einmal vor und wieder zurück dreht, dann läuft es wieder. D.h. beim Ändern der TB wird ja ein StartRecord() abgesetzt. Also könnte es durchaus sein, dass Deine Änderung hier hilfreich ist. Guats Nächtle Hayo
:
Bearbeitet durch User
Ok, nach langer Zeit mal wieder eine neue Version! Angeregt durch Jürgen habe ich mich noch mal auf den Pulsweitentrigger gestürzt. Das Ergebnis ist ganz erfreulich. Im "Normal" Modus arbeitet der PW-Trigger jetzt in allen drei Bereichen (>, <, ><) ohne stehen zu bleiben. Zusätzlich habe ich noch einen Bug im Single Trigger des Peak Detect beseitigt. @Jürgen Ich habe die meisten Deiner Änderungen übernommen weil sie mir inhaltlich korrekt erschienen. Das hat aber nicht viel gebracht. Nur die letzte Zeile in SetupTrigger() hat dafür gesorgt, dass beim Unterschreiten des unteren Schwellwertes die Acquisition weiter ging wenn man den Wert am DSO nachgeregelt hat. Wenn jedoch stattdessen das Signal am Funktionsgenerator geändert wurde, blieb das Gerät trotzdem "eingefroren". Hierfür (oder vielmehr dagegen) habe ich jetzt im ADC-Handler einen kleinen Workaround eingebaut, der dafür sorgt, dass es beim Pulsweitentrigger keinen "Freeze" mehr gibt. Gruß Hayo p.s. ach ja, was dadurch jetzt natürlich auch geht, dass ist der Single PW-Trigger. D.h. wenn man den Single Trigger setzt solange die Pulsweiten unter dem unteren oder über dem oberen Schwellwert liegen, passiert nichts. Erst wenn ein Puls kommt, der von der Weite im richtigen Bereich liegt wird ein Event ausgelöst.
:
Bearbeitet durch User
Hallo allerseits, zur Zeit bin ich dabei meine Kurzwellenantennen via Bode Plott zu vermessen. Dabei sind mir einige Fehler in der aktuellen Firmware aufgefallen. Da musste ich natürlich gleich eine neue Version bauen. Gruß Hayo
Habe ich eben installiert - vielen Dank!! (Noch nix Negetives bemerkt) Viele Grüße, Egberto
Freut mich zu hören. Ich bin auch schon an der nächsten Version dran. Diesmal mit neuem Feature und einigen Umbauten unter der Haube. Ihr merkt schon, ich habe gerade einen Lauf... Gruß Hayo
Super, Danke Hayo! Seitdem ich das letzte mal reingeschaut habe, habe ich natürlich den Faden verloren und alten die SF.net-Seiten sind irgendwie futsch. Ich such mir 'nen Wolf und weiss irgendwie nicht, was der letzte Stand ist. Kannst Du mal bitte kurz sagen: 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem Anstand verwenden zu können)? 2. Wo sind die jeweils aktuellen Firmware-Sourcen zu finden (auf SF.net sind ja nur die Builds, die Source-Repositories sind oll). Github? Bis dann, Johann
Die Sourcen sind im Release dabei: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/ Ich würde mir auch wünschen, dass es eine vernünftige Webseite zu diesem Projekt gibt. Es steckt so viel Arbeit darin, dass das kaputte Sourceforge-Ding dem tollen Projekt in keiner Weise gerecht wird. Gerade als neuer hat man es schwerer als nötig.
Ein ganz kleiner Bugreport von mir, tritt zum Beispiel im Trigger menu auf und lässt sich wie folgt reproduzieren: - Funktionstaste 1 "Mode" drücken, Popup erscheint - Funktionstaste 3 "Trigger Auto Level" mehrfach drücken Es wird die Funktion Trigger Auto Level ausgeführt, aber das der Timeout des Mode-Popups wird bei jedem Druck zurückgesetzt. Vielen Dank für euer Engagement Hayo und Jörg!
keinGast schrieb: > Die Sourcen sind im Release dabei: > http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/ Oh, kein Versionskontrollsystem (git, hg, svn, cvs, ...) dafür? Nicht dass ich da gross mitmischen könnte, aber momentan scheint halt alles an Hayo zu hängen. Hat der keine Böcke mehr, wird's duster... Schlagt mich nicht, wenn's irgendwo steht: FPGA-Sourcen (VHDL, Verilog) sind gar nicht verfügbar? Oder gibt's zumindest ein Grundgerüst ohne IP-Cores?
Johann Wackener schrieb: > Kannst Du mal bitte kurz sagen: > 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem > Anstand verwenden zu können)? Da gibt es viele Verbesserungen. Weiter oben hat ein freundlicher Threadleser diesen Archivlink zur Verfügung gestellt: http://web.archive.org/web/20130326014650/http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement Die wichtigste Doku ist in SFN zu finden: http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/ Aber in Kürze: - anständige Belüftung durch diverse Änderungen am Lüfter. Hierzu gibt es von mir die Doku "Optimizing Thermal Design" in drei Ausbaustufen. - der externe Triggereingang kann etwas Überarbeitung gebrauchen. Hier gibt es einen Optimierungsvorschlag den Jörg mal gemacht hat und den ich dann mit einigen Bildern dokumentiert habe - die analoge Eingangsstufe hat im originalen Zustand mit einigen Unzulänglichkeiten zu kämpfen. Da wäre der nichtlineare Amplitudengang, der schlecht gewählte Aussteuerbereich der zu starkem Rauschen führt, schlechter kapazitiver Abgleich von Werk aus (Trimmer unter der Abschirmung), einige ungünstige Bauteildimensionierungen. Optimierungen gibt es da einige. Ein Ansatz geht soweit, eine komplette Platine mit eigener Eingangsstufe für jeden Kanal einzubauen. Der Aufbau der Platine und der Einbau ins Gerät ist nicht ganz einfach. Die firmwareseitige Unterstützung steckt auch in den Kinderschuhen da nur einige Wenige den Umbau gemacht haben. Deutlich einfacher und günstiger sind die Low Budget Mod und die OPA653 Mod, die in letzter Zeit einige erfolgreich ausprobiert haben. Löten an SMD-Bauteilen solltest Du auf jeden Fall können. Noch ein Hinweis zu der Bestückung der originalen Eingangsschaltung: Der Eingangsverstärker OPA656 ist maßgeblich für Frequenzgang und Bandbreite des DSO verantwortlich. Der Unterschied zwischen den 200MHz Versionen und den 100MHz Versionen besteht darin, dass in den 100MHz Versionen ein Fake verbaut wird welches deutlich geringere Bandbreite hat! Zu erkennen an einem grünen Lackpunkt auf dem Gehäuse. Es besteht weiterhin der Verdacht, dass in späteren 200MHz Geräten ebenfalls diese Bauteile verwendet wurden um Geld zu sparen bzw. mehr Geld nehmen zu können als für die 100MHz Geräte. Die wenigsten Besitzer solcher Geräte bemerken das. > 2. Wo sind die jeweils aktuellen Firmware-Sourcen zu finden Ich veröffentliche die hier. Du findest sie auch auf SFN. Es gab auch ein svn mit allen aktuellen Entwicklungszweigen. Durch die SFN-Umstellung ist das etwas in der Versenkung verschwunden. Ich weiß jetzt nicht ob Jörg das evtl. schon wieder aktualisiert hat. Ziel ist es jedenfalls irgendwann diese NIOS 1 Firmware abzulösen durch eine Firmware die auf dem von Jörg selbst entworfenen NIOS 2 Core aufsetzt. Das kann aber noch etwas dauern, daher gibt es zwischendurch immer noch Erweiterungen an der aktuellen Firmware. Gruß Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
Persistent.jpg
140 KB
Wie angekündigt hier die neue Version mit neuer Display-Funktion. Bei anderen DSOs habe ich gesehen, dass diese bei der persistenten Display-Funktion die Möglichkeit bieten einstellbar das nicht mehr gültige Signal auszublenden. Unser W20xxA konnte bisher nur Persistenz an/aus. Das konnte ich natürlich so nicht stehen lassen! Die neue Firmware kann jetzt Lebenszyklen (Lifecycles) von 5s/10s/25s/50s und Unendlich darstellen. Am besten kann man das testen wenn man die Fade Out Time auf 5s einstellt und dann das Testsignal in Amplitude oder Frequenz verstellt (siehe Bild). Der kleinere Bug im Triggermenü ist auch behoben - danke für den Hinweis. Viel Spaß Hayo
Hi Hayo, I tested the new functions,working and useful,only the memory 1 save/recall function fails from 1.2.BF6.9 onward.For example saving sinewave, recall is different,appear dc voltage.Downgrade solve it,may you check this little bug? Thank you Sandro
Hi Sandro, I checked it but I can't find the problem. All seems to work correct. Please describe in detail under which conditions and parameters the problem occured. Hayo
Johann Wackener schrieb: > Kannst Du mal bitte kurz sagen: > 1. Welche Hardware-Modifikationen sind nötig (um das DSO mit einigem > Anstand verwenden zu können)? Da fällt mir noch ein, es gibt einen Umbau für den Akkubetrieb von Markus, den sollte man auf jeden Fall auch erwähnen. Ist zwar nicht nötig, aber unter gewissen Bedingungen hilfreich: Beitrag "Wittig(welec) DSO W20xxA Umbau Akku-Betrieb" Ach und was unter die gleiche Kategorie fällt mir aber entfallen ist, weil das für mich an meinen Geräten so selbstverständlich ist - die Trigger LEDs: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" -> möchte ich nicht mehr missen! Gruß Hayo
Gibt es den Inhalt von http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI noch irgendwo?
Angehängte Dateien:
-
screen-0002.jpg
64 KB -
screen-0003.jpg
62 KB
Hi Hayo, setting is :default,input 1 kHz calibrator,CH1,500mVdiv, 500KSa,500 uS/,but also with other settings. Save to Memory 1,disconnect the probe,then recall ,the waveform is only a line and trigger setting go also itself from combi to normal . This bug is random,pls see the enclosed diagrams. Thank you, Sandro
I tried hard, but the problem does not occure on my DSOs. I have the suspicion that the "Auto" trigger might be the guilty one. Can you try it once more with the "Normal" trigger? @all Has anyone else the same problem? Hat noch jemand Probleme beim Speichern und Wiederholen der Signale aus dem Speicher? Hayo
Hayo W. schrieb: > I tried hard, but the problem does not occure on my DSOs. I have the > suspicion that the "Auto" trigger might be the guilty one. Can you try > it once more with the "Normal" trigger? I can confirm, that the trigger mode, if set to combi, is somehow set to normal. I don't know how save/recall should work. Should I be able to view stored traces 1 and 2 at the same time? Should I be able to overlay a saved trace on the live signal?
keinGast schrieb: > I can confirm, that the trigger mode, if set to combi, is somehow set to > normal. Yes I know the bug. It is solved in the next version. > I don't know how save/recall should work - go to Save/Recall - choose a memory place - push "Save Trace" -> signal will be stored into flash - switch off the signal input - push "Recall Trace" -> signal should be displayed as before - or push "Overlay Trace" -> old signal and actual signal will be displayed Hayo
:
Bearbeitet durch User
Ok hier die neue Version mit einigen Verbesserungen, Bugfixes und einer neuen versteckten Funktion zum Umlabeln der Modelversion. Details stehen in der Datei Special Functions.txt Hayo
Hallo Hayo, noch mal ein kleiner Bug, wieder bzgl. dem Popup-Timeout: - im Trigger-Menu das Mode-Popup öffnen - dann an der Timebasis drehen - das Popup bleibt offen, so die Timebasis verändert wird. Ist das ein Architekturproblem?
keinGast schrieb: > Ist das ein Architekturproblem? Nicht direkt! Es handelt sich vielmehr um konkurierende Interrupts. Der Timer-Interrupt des Popup Timeouts (schönes Denglisch) konkuriert hier mit dem Interrupt des Rotary Interface (Drehgeber-Interrupt). Letzterer unterbricht die Bildausgabe und damit auch die Möglichkeit das Popup zu schließen, obwohl der Timeout schon längst zugeschlagen hat. Damit kann man aber wohl ganz gut leben denke ich. Wenn wesentlich mehr Rechenleistung zur Verfügung stünde könnte man das sicherlich auch geschmeidiger lösen. Für 12MHz aber wohl ganz akzeptabel. Gruß Hayo
:
Bearbeitet durch User
Johann Wackener schrieb: > Oh, kein Versionskontrollsystem (git, hg, svn, cvs, ...) dafür? ... doch schon immer ... nun auch mit all den Versionen vom Hayo. http://sourceforge.net/p/welecw2000a/code/HEAD/tree/ Grüße Andiiiy
Hi Hayo, I confirm that the bug comes from auto and combi settings,with normal trigger save/recall are correct. Ciao Sandro
Hi Andiiiy, hab schon gesehen, dass Email von SFN im Postfach war wegen des Checkin. Ich wusste gar nicht mehr, dass da noch ein Repository eingerichtet ist. Muss ich mir mal wieder alles richtig einstellen. Bin jetzt aber erst mal weg ....muss in Griechenland segeln :-) Hayo
unser Hayo iss schon ein armer Tropf, wir werden dich bedauern wenn du in Griechenlan in der Sonne schmorst und unsern schoenen Regen hier verpasst :p vlG Charly
Hayo: nice job with persistence that now is settable. This remind me about the interpolation matter because in that way it improve the waveforms on the screen even if trigger instability worsens the drawn. So any news for sin(x)/x interpolation or whatever that can improve the drawn of the waveforms on the screen that is very crude until now. I think it was discussed in the past. So long, 400
~ ~ The hidden functions can be reached by using a serial terminal and special keys on the pc keyboard. ~ ~ ~ - Shift + O ~ Renaming function to change the model label for modified devices. Depending on the hardware ~ settings (hardware menu -> Gain) the label will be changed and written into the protected flash. ~ This label has no influence to the hardware functions. It is only for display. ~ ~ ~ Gain Label ~ ----------------------------------------- ~ Factory W20xxA (no change) ~ LB-Mod W202xA / OPA656 Mod ~ OPA653 W203xA / OPA653 Mod ~ 24.5Ohm W202xA (W2022A or W2024A) ~ Add On W203xA / LMH6518 Mod ~ ~ ~ ~ !!!! Be carefeful, some changes can't be set back !!!! ~ Hayo: We can put them there but we can't rewrite or overwrite them again. Why can't be some changes set back? So long, 400
김사백 schrieb: > Why can't be some changes set back? If your DSO is a W2012A or a W2014A and you change the Label to LB-Mod your DSO will become a W2022A or a W2024A. There is no possibility for the firmware to see if the DSO is really a W2022/W2024 because the hardware is the same (only the OPA656 is different). So it can't be set back to W2012/W2014 in the moment (only mnually with a separate function I could write). All this is only for display and has no influence to the function. Greetings from the Ionian Sea Hayo
:
Bearbeitet durch User
Hayo thanks. That's the same thing that I thought. If it's possible to change it then it's even possible to set it back. Have a nice travel. 400
Angehängte Dateien:
Ab der BF.5.8XE bis zur aktuellen BF.7.1 (ab hier wird übrigens auch die trigonometric Tabelle ins Flash geschrieben), wird der Sinus, bei drücken der Test-Signaltaste, nicht mehr korrekt dargestellt! Ich habe mir mal die Mühe gemacht, ab welcher Firmware-Version das der Fall ist. Angefangen hatte ich bei BF.5.6, da war noch alles ok. Jetzt ist die Tabelle mit der 5.8XE fertig geschrieben, komischer Weise wird nun auf dem 2.Kanal kein Testsignal ausgegeben, hmm... Ok, nach dem aus u. wieder Einschalten, wird der Sinus auf Kanal2 angezeigt, allerdings, (wie oben schon beschrieben)auch mit einer viel zu kleinen Amplitude. Ich wollte das nur mal so erwähnen ;-) Ein Pic anbei. Achso...wem beim schreiben der trigonometric Tabelle ins Flash, ein Fehler passiert ist, braucht nur auf die BF.5.7 downgraden, dann wird ab der BF5.8XE diese wieder neu geschrieben(ich habe es ja gerade getestet) Gruß Michael
Hmm, schau ich mir mal an wenn ich zurück bin. Für das Schreiben der Trigo-Tabellen könnte ich auch noch eine Hidden Function einbauen, dann kann man das jederzeit refreshen. Hayo
Mir ist aufgefallen, dass die Triggerschwelle nicht mit skaliert, wenn man die vertikale Auflösung V/div umschaltet. BTW: Kann das Firmware-Projekt (also das von Hayo massgeblich betreute) vielleicht nach Github umziehen? Dann könnte man da wird das Wiki etablieren, ausserdem ist der Bugtracker dort ziemlich knorke. SF.net nervt, ist so unübersichtlich - wra früher mal toll, aber mittlerweile ist es nicht mehr oldscool, sondern einfach nur noch oll. Github bietet auch einen Downloadbereich für Releases (https://help.github.com/articles/creating-releases/).
One thing I always wonder is what is the purpose of that function, what the test signal meaning is? What does it do? 400
Welecverbastler schrieb: > Mir ist aufgefallen, dass die Triggerschwelle nicht mit skaliert, wenn > man die vertikale Auflösung V/div umschaltet. Ja, das ist aber kein Fehler, sondern so gewollt. Hintergrund ist der Umstand, dass der Trigger auch nur im Anzeigebereich des Grids arbeitet. Größere Triggerlevel sind unwirksam (Signal und Triggerlevel liegen dann außerhalb des ADC-Aussteuerbereichs). Daher ist es in diesem Fall praktikabler den Level am Grid zu orientieren, d.h. den Level in Relation zum Grid konstant zu halten. So hält man den Trigger immer im Aussteuerbereich. Ziel bei der Wahl des Spannungsbereiches ist es ja im Normalfall, das Signal im Gridbereich komplett darzustellen. > Kann das Firmware-Projekt (also das von Hayo massgeblich betreute) > vielleicht nach Github umziehen? Das müsste man sich mal ansehen. Grundsätzlich spricht nichts dagegen. SFN gefällt mir auch nicht so besonders. 김사백 schrieb: > what > the test signal meaning is? > What does it do? It is a software generated signal which is loaded into the signal buffer instead of the ADC value register. It can be used to test some of the firmeware functions like "Quick Measure", "Noise Filter", "Math" etc. . It does not work with functions which are operating on hardware layer level (driver level) like "Average". It is only a simple signal simulating routine. I'm thinking about improving it... Hayo
Hi, bin gerade erst zurück und hatte einige Ideen. Zum Einen habe ich das Rotary Interface nochmals genauer unter die Lupe genommen. Leider ist es die Hardware- (FPGA) Implementierung die hier für das schlechte Ansprechverhalten verantwortlich ist (etliche Impulse werden einfach verschluckt). Um das Ganze erträglicher zu machen habe ich für die Zerolevel-Verstellung den Code nochmals überarbeitet. Der Zerolevel lässt sich jetzt etwas flüssiger verstellen und springt nicht mehr ganz so heftig. Wichtig ist, dass man nicht allzu schnell am Drehgeber kurbelt, da dann das Interface die Impulse schlichtweg verschluckt (quasi ein Null Device). Weiterhin habe ich den Ansatz mit dem skalierenden Triggerlevel von Welecverbastler aufgegriffen und eine mögliche Umsetzung eingebaut. Beides betrifft nur Kanal 1, dadurch kann man direkt mit Kanal 2 vergleichen, der komplett unverändert arbeitet. Ich bitte um Rückmeldung ob die beiden Änderungen eine Verbesserung sind. Short version in english: Please test the new implemented scaling triggerlevel and the new rotary handler for zerolevel adjustment. both available only on channel 1 to be able to compare with the originally working channel 2. Hayo
Hi Hayo, I tested the level and rotary, it's good but unfortunately the memory recall waveform is buggy,still different to the memory save waveform,both in channel 1 and 2,auto and combi.Could be a trigger problem,I agree with you. Anyway the persistence function works well ,together with the main functions. Regards Sandro
Hi Sandro, thanks for reporting, I will test the memory saving once more. Regards Hayo
Die Reaktion auf meine letzte Anfrage war ja recht verhalten. Ich habe die Neuerungen jetzt einfach mal eingebaut, da sie mir ganz gut gefielen. Vielleicht kommen ja jetzt einige Reaktionen dazu. In der Zwischenzeit war ich recht aktiv und habe an diversen Baustellen gearbeitet (siehe readme). @Sandro Save/Recall problem should be solved now. It was not the trigger, but the activated filter which changed the pointer to the signal memory. In consequence the wrong memory area has been saved to flash. Please test out and be so kind to report any problem. @Andii Wärst Du noch mal so nett die Sourcen in SVN einzuchecken? Gruß Hayo
Hayo W. schrieb: > Wärst Du noch mal so nett die Sourcen in SVN einzuchecken? Gern ... soeben erledigt! Es ist schon beindruckend wie sich die Software entwickelt hat. Ich hoffe ich kann Dich weiter für das neue FPGA Design begeistern? Jeder der es nur Testweise mal auf dem Gerät hatte, wird es bestätigen können. Im Hintergrund haben wir mit Jörg etwas über das Thema "Gradient - displaying the Data" gesprochen, d.h. was sich an einen farbigen persistence Mode anlehnt. Mit dem aktuellen Design ist das aber nicht mehr möglich, da eine Plane nur eine Farbe haben kann. Grüße Andiiiy
Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der Absolutwert konstant bleibt. Das kann der LeCroy auch, ich finde das sehr praktisch.
Andiiiy schrieb: > Ich hoffe ich kann Dich weiter für das neue FPGA Design begeistern? Aber ja! Damit haben wir so viele neue Möglichkeiten... Ich warte nur (wie eigentlich alle) darauf, dass Jörg sein Design für alle vier Kanäle stabil hinbekommt. Das ist natürlich leichter gesagt als getan. Ich bin da jedoch voller Zuversicht und glaube auch nicht, dass das Projekt wegen kleiner kreativer Pausen tot ist. Die Updates an der BF-Firmware werde ich aber erst einstellen, wenn wir einen halbwegs vollwertigen Ersatz auf der neuen Plattform anbieten können. eProfi schrieb: > Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü > einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der > Absolutwert konstant bleibt Hatte ich auch vorgehabt. Leider habe ich im Menübaum keinen (sinnvollen) freien Platz mehr gefunden. Das Triggermenü (bzw. Submenü) ist schon voll. Vorschläge nehme ich gern entgegen.
Hello Jörg, Good idea but IMHO it's a mere exercise in style if what we'll get on the screen is the same of today. Make no sense the effort to upgrade from a DSO to a DPO if then the waveforms on the screen will be crude (drawn rappresentation) and not stable (poor hardware trigger) like it is right now My two cents. Victor
Hallo Hayo, now the memory save/recall and trigger works and the new functions also.Please check the cal standard menu isn't available. it's a little jewel! @Victor Some features (USTB,digital edge trigger,10 FFT filters and many more)and continuos technical support all together are only available on our Welec project, despite a limited hardware.May be the colour persistence is useful too. Regards, Sandro
eProfi schrieb: > Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü > einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der > Absolutwert konstant bleibt Ok, ich habe den Rücksprung aus dem Triggersubmenü geopfert und da ein Popupmenü eingesetzt um das Triggerlevelverhalten einzustellen. Den Rücksprung kann stattdessen mit dem Mode/Coupling Button machen. Sandro schrieb: > Please check the cal standard menu isn't available. it's a little > jewel! Thanks for the hint! Bug is fixed now. Next version is coming soon.
Die neue Version ist da! Neben einigen Verbesserungen und Bugfixes habe ich den Testsignalgenerator noch mal überarbeitet. Die Testsignale skalieren jetzt mit den Spannungsbereichen und sind DC/AC/Inverted sensitiv. Da öfters mal gefragt wurde, wozu das Testsignal gut ist, habe ich mal eine kurze Beschreibung in der Datei Special Functions hinterlegt. Hayo
Thank you Hayo. Not less reading special functions document have arisen in to my head some doubts. How many is the memory depth for each channel? I knew Welec is 16kBytes memory depth for each channel independently from the time base but in your documents it's stated even 32kBytes somewhere. And then another more trivial question which I don't know. During acquisitions how much is it the maximun time which is possible to take recording of the waveforms on the screen? I guess it depend on the time base and numbers of sample. So when it using 1000s/div in USTB how much is the maximum time it is possible to browse the memorized waveforms? Is it possible to calculate it? Nice job. 400
김사백 schrieb: > How many is the memory depth for each channel? > I knew Welec is 16kBytes memory depth for each channel independently > from the time base but in your documents it's stated even 32kBytes > somewhere. Memory depth is changing due to the sample rate. In fast sampling modes all 4 ADC are working interleaved. The result register is 32 bit long and every ADC has one byte in this register for its values. The readout length is alway 4096 samples long. So we get 4 * 4096 bytes. Well that are our 16Kbyte. In slower sampling modes (25MS and slower) only one of the four ADCs is working. So we get only one byte in the 32 bit register every readout cycle. That results in 4096 * 1 byte = 4Kbyte. In ultra slow timebases (USTB) the acquisition works completely different. The number of ADCs which are working is no longer important. The limiting factor is the internal RAM size. Some modes need more RAM space as others. So you can choose for some modes 32Kbyte buffer size. 김사백 schrieb: > So when it using 1000s/div in USTB how much is the maximum time it is > possible to browse the memorized waveforms? > Is it possible to calculate it? Indeed it is! One Div are 50 samples. that are 12*1000s = 12000s on the screen (3.3 hours). 1000s/Div are 20s/sample. 16K * 20 = 327680s (ca. 91 hours) that you can browse in the 16Kbyte buffer (more than 3 days!!!). Hayo
:
Bearbeitet durch User
Hayo jjang! 327680s, daebak! Terrific lasting time acquiring waveforms! I didn't knew it. I don't understand some things though. Ok in USTB there are 50Sa/s (why 50?) setting time base for 1000s/div, so 12000s (3h 20m) for the whole screen because graticule is 12 divisions. But why is 20s/Sa in 1000s/div? Welec is a real 1Gsa/s, starting by this I don't understand the other numbers you wrote where they come from. Sorry I'm babo. So long, 400
김사백 schrieb: > Ok in USTB there are 50Sa/s (why 50?) Not 50Sa/s - 50Sa/Div. That is always in every TB the screen resolution. So you get 50 samples in one Div. One sample every 20s. That are 20s * 50Sa = 1000s/Div. 12 Div on the screen are 12 * 1000s = 12000s Hayo
Angehängte Dateien:
-
01_Testsignal.jpeg
57 KB -
02_Linear_20ns.jpeg
51 KB -
03_Linear_10ns.jpeg
49 KB -
04_Linear_5ns.jpeg
48 KB -
05_Linear_2ns.jpeg
48 KB
Ok, weiter gehts. Ich hatte mich ja schon vor einiger Zeit mit der Sin(x)/x (auch bekannt als Sinc) Interpolation beschäftigt. Ich hatte da viel Zeit und Gehirnschmalz reingesteckt um das zu implementieren. Leider musste ich feststellen, dass unser veralteter NIOS Prozessor mit seiner langsamen Taktrate mit der Berechnung total überfordert war. Ich hatte die weitere Implementierung daher eingestellt. Aber - nach der letzten kreativen Pause hatte ich wieder neue Ideen und habe mich noch mal drangesetzt. Zum Testen des FIR Algorithmus eignet sich das generierte Testsignal auf Kanal 1 besser als jedes echte Signal. Das ideale Rechteck hat eine Anstiegszeit gegen 0ns, was bei unserer Auflösung (Abtastung) einer Risetime < 1ns entspricht. Das Signal ist absolut rauschfrei. Folgerichtig habe ich also alles mit dem Testsignal überprüft. Man kann auf den Bildern schön die Schräge und die Ecken der linearen Interpolation sehen. So sieht natürlich kein echtes Signal aus. jetzt kommt unsere Sinc Interpolation ins Spiel...
:
Bearbeitet durch User
Angehängte Dateien:
-
06_Sinc_20ns.jpeg
54 KB -
07_Sinc_10ns.jpeg
52 KB -
08_Sinc_5ns.jpeg
50 KB -
09_Sinc_2ns.jpeg
51 KB
Ich habe den FIR Algorithmus soweit reduziert und mit einigen Tricks angepasst, dass die Sinc Interpolation mit einer noch akzeptablen Framerate läuft. Wenn alle 4 Kanäle gleichzeitig an sind, bricht die Framerate natürlich total ein, aber das DSO bleibt wenigstens nicht ganz stehen. Man kann hier schön sehen, dass die Sinc Interpolation aus dem idealen Rechteck ein reales Rechteck simuliert wie es ein Pulsgenerator erzeugen würde. Bei größeren ADC-Werten (150 - 255, unterer Screenbereich) kommt ein leichtes Rauschen hinzu, welches durch Rundungsfehler der auf 8bit reduzierten 16bit Berechnung entsteht. Zur Zeit mache ich noch etwas Feinschliff, aber mit der nächsten Version steht die Sinc Interpolation zur Verfügung. Hayo
Hmm Aber das sinc interpolierte Signal zeigt Überschwinger die es in der Abtastung nicht gibt. Oder verstehe ich da was falsch? Das könnte mich leicht auf die falsche Fährte führen wenn ich es an einer gut angepasster Leitung sehe. Da kann man gar nicht mehr unterscheiden was echt ist und was das Oszi macht. Bitte um Aufklärung. Gruß, Kruno
Thank you Hayo, I get it now... ...I hope. I guess it's related with the screen resolution of the graticule on the screen that should be 600pixels horizontally (TFT of the Welec is 640x480pixels as resolution). Each TB is 50Sa/div and so 600 samples for the whole screen being 12 divisions (50Sa/div * 12div = 600Sa) then it is 1 sample for each pixel of the screen (600 pixels). Now for USTB and 1000s/div it is 12000s on the whole screen, so doing the division (12000s) / (600Sa) it is 20s which is 1 sample every 20s (20s/Sa) or 1 pixel every 20s which is the same thing. Am I wrong? Sorry I'm babo. So long, 400 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ ~Zur Zeit mache ich noch etwas Feinschliff, aber mit der nächsten Version steht die Sinc Interpolation zur Verfügung. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Just saw. Daebak! Are those from the original hardware rather than LB/OPA mods?
Kruno schrieb: > Da kann man gar nicht mehr unterscheiden was echt ist und was das Oszi > macht. Jain! Du hast nicht ganz unrecht. Grundsätzlich ist es so dass in den interpolierten Zwischenräumen nicht das angezeigt wird was das Oszi misst, sondern das was man (man ist in diesem Fall die Interpolations- routine) an Signalverlauf vermutet. Bei der linearen Interpolation geht man davon aus, dass zwischen Punkt A und Punkt B der Signalverlauf in der Zwischenzeit linear weitergeht. Man verbindet die beiden Punkte also auf dem kürzesten Weg. In der Realität ist aber, wie wir wissen, nix linear. Steile Anstiegszeiten von Signalen sind immer verbunden mit Einschwingvorgängen. Beim Rechteck kann man das schön in einer mathematischen Reihenentwicklung aus der Überlagerung der einzelnen Frequenzkomponenten zeigen. Bei der Sinc-Interpolation macht man jetzt nichts anderes als lauter Sinc-Signale zu überlagern und erhält dadurch eine Simulation die ganz dicht an der Realität ist. http://de.wikipedia.org/wiki/Sinc-Funktion Um zu sehen was echt ist und was nicht empfiehlt es sich zwischen linearer und Sinc Interpolation hin und her zu schalten. dann sieht man sehr deutlich was da Fake ist und was nicht. Hayo
:
Bearbeitet durch User
김사백 schrieb: > Am I wrong? You are right. 김사백 schrieb: > Are those from the original hardware rather than LB/OPA mods? Interpolation is completely independent from Hardware Mods. Hayo
Angehängte Dateien:
-
Delayed_Linear.jpeg
61 KB -
Delayed_Sinc.jpeg
62 KB
> Um zu sehen was echt ist und was nicht empfiehlt es sich zwischen > linearer und Sinc Interpolation hin und her zu schalten. Besonders gut sieht man das im Delayed Mode. Hayo
Danke für die Aufklärung. Danke auch für die gute Arbeit an der FW. Kruno
So, gerade rechtzeitig vor dem Abendbrot noch fertig geworden. Viel Spaß beim Ausprobieren. Jetzt werde ich mal die beste aller Ehefrauen bekochen :-) Hayo
Ciao Hayo. Grazie for new software! @Hayo Indeed it is! One Div are 50 samples. that are 12*1000s = 12000s on the screen (3.3 hours). 1000s/Div are 20s/sample. 16K * 20 = 327680s (ca. 91 hours) that you can browse in the 16Kbyte buffer (more than 3 days!!!). Is possible take picture on PC of that big time? If the answer is yes, how? I am only capable to pour a single picture of the screen and I never see anybody do the entire area of memory. Sorry for my english, I am from Italy.
CB schrieb: > Is possible take picture on PC of that big time? Ciao, the screenshot program delivered with the firmware can receive raw data from the DSO which can be edited with excel. Unfortunately the USTB-Mode is not supported at this time. May be it is possible to download parts of the USTB-Signal but that is not guaranteed. The good news are - I'm working on that. I hope to get it ready in the next time. Buona notte Hayo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Interpolation is completely independent from Hardware Mods. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hayo: that's good! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~The good news are - I'm working on that. I hope to get it ready in the next time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hayo: even that is good. I had never thought. So long, 400
Grazie Hayo! My Welec have again original hardware. I want do modify but again I have not the component. For start I want use 24,9Ω and 150Ω (better 174Ω or 180Ω) that perhaps I have in old printed circuit. For now I have open the oscilloscope and try adjust input but nothing happen. I must upgrade the hardware before adjust or it is functional only with LB and OPA modification? I like very much black/red theme you use, also I want use this. ;-) Buona Domenica. Carlo
CB schrieb: > I must upgrade the hardware before adjust or it is functional only with > LB and OPA modification? Ciao Carlo, adjusting the input stage is always a good idea due to the fact that the factory adjustment is mostly poore. That is independent from any modification. It is just the same as adjusting a probe before you can use it for serious measuring. By the way, I checked the coding for transfering raw data to the PC. Actually there are transferred the first 4096 samples of every channel in USTB mode. The rest is cut off. I'm working on that... Hayo
Ciao Hayo. Well, but trimmer don't function in my oscilloscope. I see with a lens and trimmer are broken. Big new for PC transfer, tank you for the help! Buona sera. Carlo
CB schrieb: > Well, but trimmer don't function in my oscilloscope. Maybe the soldering is bad. If so, you have to desolder the metal covers and resolder the pads. On my DSO some of the pads are also bad soldered.
Ciao Hayo. No, unlucky soldering is well are trimmer that are broken chipped. I must substitute. Grazie! Carlo
Hallo Hayo Bei der letzter FW habe ich einen komischen Offset am Display bemerkt. Auf der Mittellinie ist alles OK, aber je mehr man die Nulllinie nach oben oder unten verschiebt, wird ein Offset dazu addiert, unten positiv, oben negativ (siehe Bild). Der Betrag ist unabhängig vom Bereich und kommt bei beiden Kanälen (W2022A) gleichermaßen vor. Vorher habe ich die Offsets kalibriert (vielleicht hat es was damit zu tun). Gruß, Kruno
Hallo Kruno, bin wieder gerade erst vom Griechen zurück (Montags ist immer Grieche). Das Bild ist wohl irgendwie verloren gegangen. Aber ich weiß schon was Du meinst. Da stimmen die Faktoren für die Verstärkung (Gain) nicht so richtig. Die Einstellung dafür findest Du im Hardwaremenü. Die Grundeinstellung macht man mit Pre Gain. Wenn Deine Kiste noch original ist "Factory" nehmen. Sonst je nach Modifikation einstellen. Die Feineinstellung macht man mit Gain. Bei 1,000 passiert nix (1 x irgendwas ist immer noch irgendwas). Je nach Bedarf den Wert nach oben oder unten verstellen - dann sollte es passen.
Ja, das war's. Dort war LB-Mod eingestellt (nicht von mir). Danke Hayo
Hi Folks, hier die neue Version. Diesmal habe ich vor allem an den Tools gearbeitet. Die Screenshot-Version ist jetzt bei 1.0 und bietet USTB Support. Die Version ist nicht abwärtskompatibel und braucht mindestens die aktuelle FW 7.5, da der Trace-Header erweitert wurde. Weiterhin habe ich die Parametertexte angepasst (es waren noch uralte Menütexte drin) und die Trennzeichen für ASCII und CSV korrigiert. Die Anzahl der Übertragenen Samples ist abhängig von der eingestellten Timebase bzw. der eingestellten Buffergröße und kann bis zu 32K pro Kanal betragen. Bei 20s pro Sample sind das 640000s = 177h = 7,4 Tage = 1 Woche! Da in der Vergangenheit immer mal wieder bei Einsteigern Schwierigkeiten bei der Installation von Perl und WIN32 Serial Port auftraten habe ich einen einfachen Firmware Updater als Konsolenprogram geschrieben, der statt des Perlscripts verwendet werden kann. Er ist genauso schnell (180s = 3min), kann aber weder gepackte UCL-Dateien laden noch Backups erstellen. Es können aber Backupdateien vom WELEC-Updater oder vom Perlscript geladen werden. Das Tool soll in erster Linie eine Vereinfachung für Einsteiger und Gelegenheits-Flasher sein. Poweruser und Programmierer wechseln wie gehabt in das UCL Verzeichnis und benutzen das Perlscript mit 18s Uploadzeit. Gruß Hayo
by the Way. Habe heute auch Perl installiert erst die 64bit Version damit funktioniert aber Serialport nicht, also deinstalliert und die 32bit Version installiert. Für Serialport (aktuell V0.22) ist es wichtig im Gerätemanager erst auf 9600 bps umzustellen um das Makefile... auszuführen. Bei der Firmware dann später aber wieder auf 115200 bps einstellen. Was mir bei der 7.4 aufgefallen ist. Gridcolor Gray und With sind identisch beides grau
Hatte vergessen eine kurze Anleitung beizufügen. Als alter Hase denkt man nicht immer daran, dass ein Neuling oft nicht so genau weiß wie man das macht. Ist dann bei der nächsten Version mit im doc Verzeichnis. @Thomas Die beiden Gridfarben sind nicht ganz identisch. In der 66% Einstellung unterscheidet sich die Farbe etwas. Hayo p.s. wer den easyloader als Windows 64 bit Version braucht möge sich melden, dann stelle ich das zur Verfügung
:
Bearbeitet durch User
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Hatte vergessen eine kurze Anleitung beizufügen. Als alter Hase ~denkt man nicht immer daran, dass ein Neuling oft nicht so genau ~weiß wie man das macht. Ist dann bei der nächsten Version mit im ~doc Verzeichnis. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thank you Hayo, I have some trouble though. This time for the upgrade I have used your easyloader. I have setted the batch file for my COM number and tried it. I got this: D:\>"D:\\easyloader.exe" -c 3 -f TomCat.flash ************************************************************************ * * * * Easy Loader v1.0 * * * * RS232 serial port firmware update tool for WELEC DSO W20xxA. * * Update the flash memory with a new firmware using TomCat.flash. * * The firmware can also be loaded temporarily into RAM for tests using * * the TomCat.ram file. Please keep in mind, that the new firmware may * * overwrite settings of the previous firmware. Therefore it may be * * a good idea to make a complete backup of the flash memory before * * changing anything. Don't switch off the DSO while flashing!!! * * * * This program is distributed with absolutely no warranty. Problems or * * damages that may arise out of the use of this program are completely * * on your own risk! * * * * * * 2014 by BlueFlash * * * ************************************************************************ * open file TomCat.flash file size is 1668964 bytes communicatition test - ok starting transmission... setting address offset register erasing flash sector 00040000 command not recognized - retry command not recognized - retry Error: transmission error - aborting firmware update , exiting. (OS was Windows7 Starter) Since then my Welec show black screen and doesn't work anymore. Switch off/on or reset do anything. Connecting the DSO through a serial cable to a computer running TERATERM I'm able to only get this: ++C CPU048 "h" doesn't work but it change HEX numbers on the serial terminal output. I guess flash in my DSO was erased so now it doesn't work. All this don't worry me because I know my Welec only need to be reflashed using the good old Perl Script. Later I'll do that and I'll post the result. Repeat not worry at all, actually not any trouble. Please chill out, nothing happened. So long, 400
Hi, try to load the firmware once more. If this don't work -> use perl script. Do you have installed Perl and WIN32 Serial Port? If so, you can use the perl script which can be found in the UCL directory. Change the flasloader.bat according to your com port settings and start it. Upload should be done after 18s. Hayo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ try to load the firmware once more. If this don't work -> use perl ~ script. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hayo: I know, I know. I have tried several times with easyloader but no joy. I had to use the Perl Script. I had to use the Perl Script. That solved the issue and now the DSO is functioning like before. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Do you have installed Perl and WIN32 Serial Port? ~ If so, you can use the perl script which can be found in the UCL ~ directory. Change the flasloader.bat according to your com port ~ settings and start it. Upload should be done after 18s. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hayo: I have it, don't worry. Nothing happened, my Welec is live better than before with your new firmware. Thank you. So long, 400
That's good to hear. Unfortunately I only have an old WinXP / Linux PC for developing. So I don't know how the program works under Vista or Win 7. I will try to solve that problem. Is it possible, that your system is a 64 bit system? That might be a reason. So long Hayo
Hayo: no it's Windows 7 Starter Edition 32bit. Microprocessor inside the netbook is a N450 64bit but the operating system is only 32bit. Anyway nothing happened except I now enjoy the new firmware. Thanks. So long, 400
Now I set up a second PC for testing and on this PC the easyloader has the same problem as on yours, while on my main system it is running without problems. Strange! I will try to solve the problem. Hayo
Hi 김사백 try this, i use it also, maybe its works on your system vlG Charly
Hi Charly, hat der easyloader bei Dir auch Probleme gemacht? Bis jetzt habe ich dazu keine weiteren Rückmeldungen. Hayo
moinmoin Hayo, hab i noch nicht versucht, bin z.Z. im Stress, hab seit ~2 Monaten nix mehr gemacht, werde ihn aber event. am WE mal ausprobieren. I flashe schon seit Jahren mit dem obigen Prg., z.Z. unter win7/64U vlG Charly
OK,was ist das für ein Programm? Gibt es den Code dafür? Bin gerade mit dem Tablet in der Bahn und hab nur eingeschränkte Möglichkeiten (bin beruflich in Frankfurt). Hayo
keine Ahnung, hab es irgendwann im netz gefunden weil bei mir dieser 'pearl loader' damals nicht wollte und der original loader mehr als 15 Minuten brauchte (wenn i mich richtig erriner) Bei dem Prg steht auch nicht dabei von wem es ist ;( aber es funktioniert, ich dachte auch es sei hier auch bekannt, es gibt auch keine Rueckmeldungen ob es funktioiert o. nicht........ vlG Charly
Charly: thanks. Isn't it the original upgrade software from Welec? I know it's slow compared to Perl Script so normally I use the latter. I didn't know it worked using new Windows versions (Win7/8/8.1) and 32/64bit too. For what I know WelecUpdate is especially good in order to get a safety backup of the original firmware. It's slow but safe and never fails while Perl Script isn't so suitable for that kind of operations. ~ Hayo: one question about Test-Signal. I see amplitude of the test signals depends on the gain set in the hardware menu. So would not be possible to use it to calibrate the level of the input channels? Thanks. ~ So long, 400
Hi 김사백 its not the Original Wellec, i found the Prg long long time ago on the Net, its work on my system w. W7/64U and need ~ 180s for flashing vlG Charly
Charly: thanks. Aish!~ Indeed it isn't at all, sorry! You are right though, it works on my netbook. IMHO it's very useful, I didn't know that program. At first glance it seems to be something from Wittig/Welec. Though there is any copyright. So long, 400
Charly B. schrieb: > Bei dem Prg steht auch nicht dabei von wem es ist ;( > aber es funktioniert, ich dachte auch es sei hier auch bekannt, > es gibt auch keine Rueckmeldungen ob es funktioiert o. nicht........ So bin wieder zurück und habe mir das Programm mal angesehen. Es läuft bei mir auf allen PCs problemlos. Ich kannte das bisher überhaupt nicht. Bevor ich jetzt noch Zeit investiere um herauszufinden, warum beim easyloader das bescheuerte Windows API den Com-Port nicht richtig ansteuert werde ich einfach mal dieses kleine aber feine Programm meinen Paketen hinzufügen. Ich hoffe das ist im Sinne des unbekannten Programmierers. Die Linux-Version des Easyloaders wird auch weiterhin dabei sein, da diese auf allen bisher getesteten PCs problemlos lief. Danke für den Tip Hayo
:
Bearbeitet durch User
~W2012A/OPA653 ~BF.7.5 Hayo: overlay function doesn't works as supposed to do. Channel 2 became 10:1 probe and persistence switch on even if it isn't selected. Thank you. So long, 400
~W2012A/OPA653 ~BF.7.5 Hayo: OSS switched on, then IP label is always Off even though actually Linear or sin(x)/x are selected. Something like this: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Turn off then on or reset doesn't fix, IP label is always Off. ~ Some times parameters in the hardware menu are changed. Setting for OPA653 but it find 24/180ohm without do anything. ~ Some times sine wave for the Test Signal is a sawtooth. ~ Often position of the trigger in the time (browser) doesn't match with the slope. Something like this: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks. So long, 400
Angehängte Dateien:
-
screen-0000.JPG
190 KB -
screen-0002.JPG
140 KB
Hi Hayo, I tested the last firmware with two IC OPA653 installed works well up to 230 MHz. Used reference HP3325A / TDS540A and with gain 1.00 accuracy is so good. Just a a minor bug the test signal is triangular. Thank you and Regards, Sandro
~W2012A/OPA653 ~BF.7.5 Hayo: the amount of the delay between the channels depend on the V/div setting. Range 1 and range 2 have a their unique value while range 5 has its other one which is different. So the delay set in hardware menu doesn't match in all the situations. ~ Sandro: I also reported the bug in the Test Signal. In my case it isn't always a triangle. Indeed it's a sine wave until the moment in which touching something it becomes triangular. ~ Sandro: nice pictures. I have also a W2012A modified with OPA653 and it works great. In my case I have to set gain under 1 to obtain correct levels. I used leveled voltage reference so I'm pretty sure all is 100% matching. I compared my Welec against Tektronix 500MHz DPO using a square wave generator and finding it can reach about 200MHz, no more. With the gain I have setted adjusting it using the leveled voltage reference the Vpeak-peak and the shape of the reference square wave is the same I see on the DPO using sin(x)/x interpolation otherwise using the linear one Vpeak-peak is lower even if the shape of the waveform isn't very different (only less overshoot). HP3325A is a 21MHz function generator, how could you get 230MHz? Thanks. So long, 400
Hi 400, I use also a 8GHz Wiltron generator , 0.1 dB accuracy in the full range ,compared with a Anritsu microwave signal gen.same accuracy,then a calibrated power meter up to 30GHz and 4 GHz spectrum analyzer to be sure about the level and harmonics.You can read it in this forum. 3325A is suitable to adjust the square wave response and also have enough accuracy. So,for daily use I trust our W2022 and appreciate the software. Sandro
Sandro: thanks, you are lucky to have all those instruments. I didn't know it, sorry. Do you mind some questions? I'd like to have your opinion on some things here and in the "Hardware (Teil 2)" (Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"), because I see you have the necessary tools to dig the matter. ~ Are setting for delay in the hardware menu good for all 1/2/5 range? (In my case the amount of the delay between the channels depend on the V/div setting) ~ By applying a leveled square wave signal matched for 50Ω is the Vpeak-peak amplitude correct compared to the generator while using linear or the sin(x)/x interpolation? (In my case the correct value is while using sin(x)/x after adjustment performed with a DC leveled voltage reference while Welec was set for linear interpolation) ~ Is the overlay function functioning? (In my case it doesn't works) ~ What rule have you used for set the gain in hardware menu? (In my case I used a DC leveled voltage reference while Welec was set for linear interpolation but I had to set gain under 1 to obtain correct values) ~ Sandro: when you wrote 230MHz were you mean like bandwidth? (In my case last year at school I have measured 165MHz after the OPA653 modification, starting by a W2012A with 33/150Ω) Other questions follow here: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks. So long, 400
Angehängte Dateien:
-
screen-0004.JPG
180 KB
Yes, max frequency is typical as the enclosed screenshot,but 200 MHz is enough. Input 1 V pp square to the dso and adjust gain and input capacitors. Overlay is working but : Let's wait Hayo reply. Sandro
Sandro: thanks for the help. Nice your picture. You mean the trigger ability while I mean the bandwidth. Starting from 1Vpeak-peak the bandwidth is supposed to be within the limit of -30% and 148mVpeak-peak is much less than -30%, it is -85%. Anyway the shape of that 250MHz sine wave looks quite good using sin(x)/x, it surprise me. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Input 1 V pp square to the dso and adjust gain and input capacitors. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandro: ok for the 1Vpeak-peak (Hayo wrote between 1kHz and 1MHz) square wave. My doubt is if I must adjust for the overshoot peak at the same level of the flat top/bottom of the square wave or in order to get the flat top/bottom side as long as possible and overshoot peak over the level of that. That's why I asked you a picture with the details of the overshoot taken with filter off and reduced time base. Moreover when I adjusted mine Welec there wasn't sin(x)/x support and I have used Linear interpolation. Today sin(x)/x is supported so what should I use for the best result? Thanks. So long, 400
Angehängte Dateien:
-
settling_time_measurements.png
42 KB -
Rect_signal.gif
12 KB -
Clock_signal.gif
9 KB
김사백 schrieb: > My doubt is if I must adjust for the overshoot peak at the same level of > the flat top/bottom of the square wave or in order to get the flat > top/bottom side as long as possible and overshoot peak over the level of > that. Overshoot - the name is the meaning! So the overshooting has to be a little bit higher than the flat top of the rect signal (see pictures). The persistence setting in Save/Recall/Overlay is not longer saved with the signal (coming with BF.7.6). I changed it today. Hayo p.s. added bigger picture
:
Bearbeitet durch User
Die neue Version mit einigen Bugfixes und kleinen Änderungen bzw. Optimierungen. Das kleine Uploadprogramm das Charly hier geposted hat ist jetzt auch mit an Bord. Gruß Hayo
:
Bearbeitet durch User
Hayo: jjang! Pictures daebak! Thanks, that's what I was looking for! Now I know what I must do. Of course thanks also for new release and bug fix. So long, 400
@ 400 Square wave is for adjustment only.Then start auto offset calibration and check the frequency response. I mean -3dB bandwidth is 230 MHz: use a sine generator and terminate the dso with a 50 ohm load for testing.Input level between 0 (220 mVrms) and -10 dBm. Enjoy it Sandro
Sandro: honestly I don't understand what you mean. Sorry, aish!~~~ OK, square wave is for adjustment only. I know because Hayo explained it very well. I don't understand the meaning of the phrase ~ start auto offset calibration and check the frequency response and especially of this ~ I mean -3dB bandwidth is 230 MHz: use a sine generator and terminate ~ the dso with a 50 ohm load for testing.Input level between 0 (220 mVrms) ~ and -10 dBm. Aish!~ Anyway, last Monday I too have measured a 250MHz sine wave in very pretty good shape like the your. Starting by a 50Ω matched 1Vpeak-peak 250 MHz sine wave I have got 250mVpeak-peak ond the screen. Really good but 250mVpeak-peak starting from 1Vpeak-peak is -75%, not -30%. I rather have got -30% (-3dB) at 165MHz: 700mVpeak-peak. A weird thing I noticed is the behaviour of my Welec with sine waves over 200MHz. 250MHz sine wave have good shape but going down in frequency for instance 230MHz isn't so good. It seem to be overimposed to a low frequency sine wave and it has not a stable amplitude. Under 200MHz all is good like amplitude even if seems to me trigger position very often doesn't match with the trigger level. Thanks. So long, 400
김사백 schrieb: > I rather have got -30% (-3dB) at 165MHz: 700mVpeak-peak. That could be the wrong adjustment of the input stage. If the input stage is adjusted in that way you wrote above (overshooting is flat), higher frequencies will be attenuated. To get a correct result of your bandwidth measuring you first have to adjust the input stage. Hayo
Hallo Hayo, schön das du wieder dabei bist, ich denke auch über einen Wiedereintritt nach. Ich habe zugegeben nicht in den Code geguckt und die Firmware auch nicht ausprobiert, frage trotzdem: Kannst du dich zu deiner sinc-Interpolation noch etwas auslassen, wie man die praktisch realisiert? Ich hatte verstanden, sinc ist ein idealer Tiefpaß und daher leider unenlich lang, nicht praktikabel. Zweite Frage, wie hast du die variable Persistenz gelöst? Dazu müßte man ja eigentlich alle Wellen speichern und immer alle neu zeichnen, nachdem man hinten eine weggenommen hat. Ich vermute du löscht periodisch komplett, oder gibt es was raffinierteres? Grüße, Jörg
:
Bearbeitet durch User
Hayo: this time before starting with measures I tuned inputs in the right way as you explained. Actually bandwidth doesn't matter to me because mine it's the 100MHz version so 150MHz it's fine for me. What I'm talking about is for things I learned at school in the recent past which now are stated in different way from what I know. That's spirit. Moreover I see my measurements very alike with those to others, Sandro for instance. I got same results so I'm pretty sure all it's good. Surely I'm missing something but I get -30% at roughly about 165MHz. Going over there the amplitude decreases more and more, no way. May be a problem only if others can document a different behavior. Next Monday I'll take some picture and I'll post them here, I hope. Only thing that really worry me is the weird behaviour I get between 200MHz and 250MHz because it's crazy that 250MHz are better and more easily shown on the screen than 230MHz or less. May be a resonance. Wonder if it's only with my Welec. Thanks. So long, 400
김사백 schrieb: > actually bandwidth doesn't matter to me because mine it's the 100MHz > version so 150MHz it's fine for me. You are right! And we should keep in mind, that a 200 MHz DSO is made for measuring real signals with main frequency of max. 40 - 50 MHz to get convincing results. In real live we rarely measure pure sinus signals, so this is more theoretical. Especially in digital circuits we find signals that are a kind of rectangle which contain multuple other (higher) frequency components than the main frequency. Hayo
Jörg H. schrieb: > schön das du wieder dabei bist, ich denke auch über einen Wiedereintritt > nach. Das sind bei mir nur kreative Pausen. Speziell im Sommer bin ich meist so im Freizeitstress, dass ich kaum weiß was ich bei gutem Wetter zuerst machen soll. Da fallen dann alle Bastel und Programmiersachen hinten raus. Im Winter wendet sich dann das Blatt... :-) Ich hoffe ja inständig auf Deine FPGA Implementierung. > Kannst du dich zu deiner sinc-Interpolation noch etwas auslassen, wie > man die praktisch realisiert? Ich hatte verstanden, sinc ist ein idealer > Tiefpaß und daher leider unenlich lang, nicht praktikabel. Ja, das ist ein leidiges Thema. Wenn man es mathematisch korrekt machen will, dann muss man eigentlich filtern bis das Universum aufhört zu existieren. Praktisch macht man es wie bei der FFT, man benutzt Fensterfunktionen die den Filter endlich begrenzen. Man findet hier die üblichen Versdächtigen, nämlich alle möglichen Arten von Cosinusartigen Fenstern (Hamming, Hanning, Blackman etc.). Des weiteren sind die Anforderungen an die Rechenleistung nicht unerheblich. Signalprozessoren haben hier den Vorteil, dass sie die typische Berechnung mit nur einem MAC Befehl (multiply and accumulate) abfackeln können. Bei unserer Gurke muss man da tief in die Trickkiste greifen, damit das Ding nicht ganz stehen bleibt. Da wäre zum einen die Verwendung von Lookup-Tabellen. Die Werte werden beim Start des DSO schon berechnet und in einer Tabelle abgelegt. Zum Anderen gibt es für die Berechnung in digitalen Systemen hochoptimierte Algorithmen. Da wäre in unserem Fall die Implementierung als Polyphase Filter. Das bedeutet im Prinzip, statt eines langen Filters mehrere kurze Filter die eine gegeneinander verschobene Mittenfrequenzen haben. Die Implementierung ist so gemacht, dass immer nacheinander jeweils ein Filterwert auf den Ausgang geschaltet wird. Im Programm macht man das mit Arrays und ineinander verschachtelten Schleifen. > Zweite Frage, wie hast du die variable Persistenz gelöst? Dazu müßte man > ja eigentlich alle Wellen speichern und immer alle neu zeichnen, nachdem > man hinten eine weggenommen hat. Ich vermute du löscht periodisch > komplett, oder gibt es was raffinierteres? Das ist eigentlich relativ einfach gelöst. Die Persistenz wird dadurch erreicht, dass die Signalebene nicht gelöscht wird bevor neu reingezeichnet wird. Das entspricht dann der Einstellung "Unendlich". Bei den ander Einstellungen (5s, 10s, 25s, 50s) gehe ich mittels Schleife durch den Speicher und schreibe in bestimmten Abständen Nullen(schwarz) in den Grafikspeicher. Wenn man das zyklisch wiederholt und dabei die Abstände verändert ist irgendwann der ganze Speicher gelöscht. Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
Wrong_Byte_Order_01.jpeg
79 KB -
Wrong_Byte_Order_02.jpeg
67 KB -
Corrected_Byte_Order_01.jpeg
66 KB
Ach ja, aktuell bin ich dabei ein altes Problem wieder herauszuzerren und endlich mal eine Lösung dafür zu bauen. Viele haben es vermutlich schon wieder vergessen, aber vor längerer Zeit wurde schon durch Exportieren der ADC-Werte festgestellt, dass unter bestimmten Umständen die ADC-Werte nicht in der richtigen Reihenfolge ausgelesen werden und daher auf Signalflanken üble Zacken zu beobachten sind (ich glaube Falk hatte das festgestellt). Meine jetzigen Messungen haben ergeben, dass bei der Hardwareversion 8C7.xx die Zeitbasen 2µs und 5µs (500MSa/250MSa) betroffen sind - siehe Bilder. War gar nicht so einfach herauszubekommen was da schiefläuft. Die Werte werden ja immer als 32 Bit Wert aus dem FPGA-Register gelesen und dann in 4 Bytes zerlegt. Ich habe dann versucht die Bytes in der Reihenfolge zu ändern aber das machte die Sache nur schlimmer. Bis ich dann drauf gekommen bin, dass es immer zwei 32 Bit Werte sind die zusammenhängen (also 8 Byte). Die Bytes sind immer paarweise falsch angeordnet. Statt 01|23|45|67 kommen die Bytes in der Reihenfolge 45|01|67|23. Ich habe daraufhin einen Assemblertreiber geschrieben der die Reihenfolge korrigiert. Allerdings funktionierte das erst, nachdem ich den Triggeroffset vor dem Buffer Readout auf eine gerade Addresse gesetzt hatte. Ergebnis seihe drittes Bild. Die endgültige Implementierung ist noch in Arbeit. Hayo
Hayo: exactly, I agree. Plus I'm sure nothing is wrong in my Welec. My doubts are only for some things that teachers have told me in different way and now I don't understand who is wrong and who is right. All this even keeping in mind that one teacher of mine explained at me the wrong way to make compensation of the inputs immediately after OPA mod. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Die Bytes sind immer paarweise falsch angeordnet. ~ Statt 01|23|45|67 kommen die Bytes in der Reihenfolge 45|01|67|23. ~ Ich habe daraufhin einen Assemblertreiber geschrieben der die ~ Reihenfolge korrigiert. ~ Allerdings funktionierte das erst, nachdem ich den Triggeroffset vor ~ dem Buffer Readout auf eine gerade Addresse gesetzt hatte. ~ Ergebnis seihe drittes Bild. Die endgültige Implementierung ist noch ~ in Arbeit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's daebak! Hayo: I could be wrong but I guess you have just found the culprit for the weird behaviour that I wrote! You are jjang! Thanks. So long, 400
김사백 schrieb: > Hayo: exactly, I agree. > Plus I'm sure nothing is wrong in my Welec. > My doubts are only for some things that teachers have told me in > different way and now I don't understand who is wrong and who is right. > All this even keeping in mind that one teacher of mine explained at me > the wrong way to make compensation of the inputs immediately after OPA > mod. No teacher can know every thing! And teachers are also learning every day. So we have to be critical and have to verify things we have learned in school :-) Hayo
Kurzer Zwischenstand meiner Nachforschungen: Anders als bisher angenommen (und auch in der Firmware implementiert), gibt es nicht nur eine Betriebsart mit 16K Speichertiefe (Highspeed) und eine Betriebsart mit 4K Speichertiefe (Lowspeed), sondern noch ein Zwischending. In den Timebases 5µs und 2µs (250MS und 500MS) sind nämlich immer zwei Byte (nahezu) identisch wenn man das FPGA im 16K Modus ausliest. D.h diese TB laufen real mit 8K Speichertiefe. Da muss ich wohl noch etwas mehr umbauen als den Treiber... Hayo
Hallo Hayo, Von einem 8k Modus weiß ich nichts, aber was mir gerade wieder einfällt, ich habe schon mal versucht dich drauf zu stubsen: Du könntest auch mal in meinem Sourcecode von Osoz forschen, der kann auch die bei dir "fehlenden" Sample Rates zwischen 25 und 250 MSa/s. Guck' mal in den Treiber für die alte Hardware, in platform/nios/src/capture.c, Funktion CaptureSetTimebase(). Jörg
:
Bearbeitet durch User
Jörg H. schrieb: > Von einem 8k Modus weiß ich nichts Ist ja auch kein offizieller 8K Modus sondern eigentlich in beiden Fällen ein 16K Modus. Da aber immer zwei Werte als Pärchen identisch sind (da werden offensichtlich immer zwei ADC zur gleichen Zeit ausgelesen) sind es effektiv nur 8K echte Werte. Es fällt nur im Normalbetrieb nicht auf, da in der entsprechenden Screendarstellung immer nur jeder 20ste bzw. 25ste Wert ausgegeben wird. Auffallen tut es nur wenn man die Daten als ASCII Datei downloadet oder im Delayed Modus. Mir ist es aufgefallen als ich mir die FFT noch mal genauer angesehen habe, da hier alle Werte verwendet werden. Jörg H. schrieb: > Du könntest auch mal in meinem Sourcecode von Osoz forschen, der kann > auch die bei dir "fehlenden" Sample Rates zwischen 25 und 250 MSa/s. Ja ich erinnere mich, eigentlich brauche ich nur die Registerwerte, dann könnte ich das mal einbauen. Da sehe ich noch mal nach. Hayo
Ok, hab den Treiber extrahiert und in die BF-Firmware eingebaut. Nach einigen Tests hat sich Folgendes ergeben: - Wir reden hier von unterschiedlichen Dingen. Die Sampleraten von 125MS und 62,5MS die der Treiber einstellt sind keine echten Sammpleraten sondern nur dezimierte Sampleraten. Die kann ich auch jederzeit erzeugen. Es geht hier um die echten Taktraten mit denen die ADC getaktet werden bzw. die dazugehörigen Registerwerte. - Der Treiber ist sehr schön aufgebaut vom Funktionsprinzip her, wurde aber wohl nicht so richtig getestet. Der Subsampling-Wert 32 (Registerwert 0xFFFFFFFC) soll einer Abrtastrate von 31.5 MSa entsprechen. Tatsächlich ist die Abtastrate aber identisch mit Subsampling-Wert 40 (Registerwert 0xFFFFFFFB) = 25MSa. Das Gleiche gilt für Subsampling-Wert 48 (Registerwert 0xFFFFFFFA) der ebenfalls 25MSa entspricht. - Und wie von mir jetzt entdeckt -> 250MSa und 500MSa sind eigentlich 8K Betriebsmodi. Der 500MSa Modus lässt sich durch Tauschen der Bytereihenfolge wieder geradebiegen, der 250MSa Modus leider nicht, da sich die Bytereihenfolge hier willkürlich von Mal zu Mal ändert. Diese Zeitbasis ist also eigentlich überhaupt nicht verwendbar, da hier die zeitliche und die quantitative Zuordnung nicht reproduzierbar ist. Das trotzdem so etwas wie eine Signalform entsteht ist der Tatsache geschuldet, dass im normalen Betrieb nur jeder 25ste Wert verwendet wird. Wenn man aber im Delayed-Modus aufzoomt, dann sieht man was ich meine. Ich hatte schon vor längerer Zeit alle möglichen Registerwerte ausprobiert und dabei die funktionierenden Registerwerte extrahiert. Es hätte mich jetzt sehr gewundert wenn ihr da auf einmal neue Betriebsmodi entdeckt hättet. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, es ist lange her daß ich den Code geschrieben habe, die Details habe ich nicht mehr parat. Wo du davon schreibst erinnere mich mich aber an die wirre Sample-Reihenfolge. Daran war ich glaube ich auch verzweifelt. Ich hatte mal eine Kalibrierroutine geschrieben oder angefangen, die die Sortierung austestete, aber dann gemerkt das jedes Mal neu gewürfelt wird. Das mit der Dezimierung stimmt glaube ich, im Übergangsbereich ist es reine Ansichtssache, ob man den Speicher 1-, 2- oder 4-zügig betrachtet. Jörg
Ich hatte ja auf eine echte Abtastrate unterhalb von 250MSa gehofft um diese TB dadurch zu ersetzen. Naja, spes saepe fallit wie der Lateiner sagt. Dafür habe ich jetzt einen handoptimierten interpolierenden Assemblertreiber für die 500MSa TB gebaut. Was heißt das? Also erst einmal wird die Bytereihenfolge in Ordnung gebracht, was etwas tricky ist wenn man gleichzeitig schnell sein will (und er ist schnell - schneller als der normale Treiber). Zusätzlich habe ich den Lesezugriff auf jedes zweite Byte rausgenommen, da ja hier immer der gleiche Wert wie vorher gelesen wurde. Ist also redundant. Stattdessen habe ich den Mittelwert zwischen dem vorhergehenden und dem folgenden Wert gebildet. Dadurch bekommen wir jetzt statt 16KB lang Treppchen aus 8KB Werten tatsächlich 16KB sinnvolle Werte die zwar nicht alle echt aber zumindest schlüssig sind. In der 250MSa TB kann dieser Treiber zwar das eigentliche Problem nicht lösen, sorgt aber für eine gewisse Schadensbegrenzung. Das man nach all den Jahren immer noch auf solche Überraschungen stößt... Ich schreibe zur Zeit noch die invertierende Version des Treibers, dann gibt es die neue FW Version und Ihr könnt Euch selbst ein Bild machen. Schönes WE Hayo
:
Bearbeitet durch User
Moin Hayo, Hayo W. schrieb: > - Wir reden hier von unterschiedlichen Dingen. Die Sampleraten von 125MS > und 62,5MS die der Treiber einstellt sind keine echten Sammpleraten > sondern nur dezimierte Sampleraten. Die kann ich auch jederzeit > erzeugen. Es geht hier um die echten Taktraten mit denen die ADC > getaktet werden bzw. die dazugehörigen Registerwerte. Dann erzeuge *125MS und 62,5MS* bitte, das wäre echt Klasse! Gruß Jürgen
Jürgen schrieb: > Dann erzeuge *125MS und 62,5MS* bitte, das wäre echt Klasse! Wozu? Das ergäbe eine Zeitbasis von 400ns bzw. von 800ns bei einer Dezimierung von 8 bzw. 16 ausgehend von 1GSa. Das wäre eher unüblich. Wir benutzen die Dezimierungsfaktoren 4, 10, 20 für die Zeitbasen 200ns, 500ns, 1µs was einer Samplingrate von 250MSa, 100MSa und 50MSa entspricht ausgehend von 1GSa true sampling rate. Nett wäre es halt gewesen, wenn es noch bei 100MSa oder 125MSa eine true sampling rate gegeben hätte. Dann hätte man da die Dezimierungsfaktoren noch anders verteilen können. Gruß Hayo
Da an der true sampling rate nichts geändert werden kann, geht es doch nur darum bei der Darstellung die Lücke zwischen 250 MS/s und 25 MS/s mit zwei weiteren Darstellungen zu füllen. Deshalb wäre die zusatzliche Darstellung mit 100 MS/s und 50MS/s genau so willkommen. Gruß Jürgen
Ja richtig, zusätzlich würde ich gerne die total vergurkten 250MSa ersetzen, was aber leider nicht geht, da die 25MSa von unten nicht weit genug nach oben reichen und die 500MSa von oben nicht weit genug dezimiert werden können da sie sonst nur noch mit 400 Punkten Breite (statt 600) auf dem Bildschirm dargestellt kann. Tja da kann nur noch Jörgs FPGA-Design helfen :-) Hayo
Ok, hier das Ergebnis meiner Bemühungen. Folgende Einschränkungen: - für 250MSa funktioniert das Neusortieren nicht richtig, aber durch die Interpolation wird die Verzerrung etwas vermindert. - für 500MSa funktioniert der neue Assemblertreiber nur für Kanal 1 + 2. Auf Kanal 3 + 4 (FPGA 2) ist die Bytereihenfolge so verwurstet, dass ich keine Lösung gefunden habe, die vom Aufwand her zu rechtfertigen wäre. Um sich das Ganze anzusehen schaltet man am Besten in die Zeitbasis 2µS (500MSa) mit einem Sinus oder Rampensignal mit ausreichender Steigung. Dann in den Delayed Mode wechseln und ganz aufzoomen. Mit dem C-Codierten "Standard" Treiber sieht man wie das Signal verzerrt wird. Schaltet man im Hardwaremenü auf den Assembler-Treiber um sieht man den Unterschied. Gruß Hayo
Angehängte Dateien:
-
10MHz.jpg
52 KB -
50MHz.jpg
53 KB -
100MHz.jpg
58 KB -
150MHz.jpg
53 KB -
160MHz.jpg
51 KB -
185MHz.jpg
51 KB -
200MHz.jpg
50 KB -
SQUARE.jpg
46 KB -
TUNE.jpg
46 KB
~ W2012A/OPA653 ~ BF.7.6 ~ 50Ω feed-through termination Hayo: this is what I got. It isn't the new release though. Anyway that's the sequence that I have captured: ~ 10MHz ~ ~ 50MHz ~ ~ 100MHz ~ ~ 150MHz ~ ~ 160MHz ~ ~ 185MHz ~ ~ 200MHz ~ The last two pictures are the square wave I used in order to check good tune. Thanks. So long, 400
Angehängte Dateien:
-
0_OPA653-122mHz__left__W2022A24_-150_-122mHz__right_.gif
27 KB -
1_OPA653-1_22Hz__left__W2022A24_-150_-1_22Hz__right_.gif
30 KB -
2_OPA653-122Hz__left__W2022A24_-150_-122Hz__right_.gif
30 KB -
3_OPA653-250Hz__left__W2022A24_-150_-250Hz__right_.gif
29 KB -
4_OPA653-350Hz__left__W2022A24_-150_-350Hz__right_.gif
29 KB -
5_OPA653-500Hz__left__W2022A24_-150_-500Hz__right_.gif
29 KB -
6_OPA653-1kHz__left__W2022A24_-150_-1kHz__right_.gif
29 KB -
7_OPA653-25kHz__left__W2022A24_-150_-25kHz__right_.gif
29 KB -
8_OPA653-100kHz__left__W2022A24_-150_-100kHz__right_.gif
29 KB -
9_OPA653-10MHz__left__W2022A24_-150_-10MHz__right_.gif
28 KB -
10_OPA653-50MHz__left__W2022A24_-150_-50MHz__right_.gif
27 KB -
11_OPA653-100MHz__left__W2022A24_-150_-100MHz__right_.gif
30 KB -
12_OPA653-150MHz__left__W2022A24_-150_-150MHz__right_.gif
32 KB -
13_OPA653-200MHz__left__W2022A24_-150_-200MHz__right_.gif
30 KB -
14_OPA653-250MHz_LINEAR__left__W2022A24_-150_-250MHz_LINEAR__right_.gif
29 KB -
15_OPA653-250MHz_SINC__left__W2022A24_-150_-250MHz_SINC__right_.gif
30 KB -
16_OPA653-122Hz_CH1_probe_x10__left__W2022A24_-150_-122Hz_CH1_probe_x10__right_.gif
29 KB -
17_OPA653-122Hz_CH2_probe_x10__left__W2022A24_-150_-122Hz_CH2_probe_x10__right_.gif
29 KB -
18_OPA653-122Hz_CH2__left__W2022A24_-150_-122Hz_CH2__right_.gif
30 KB
~ W2012A/OPA653 and W2022A/24Ω-150Ω ~ BF.7.7 ~ 50Ω feed-through termination Hayo: DAC calibration doesn't work on factory device with the standard 24Ω-150Ω modification. A classmate of mine has a W2022A. Long time ago he has modified his Welec with 24Ω and 150Ω resistors. Now installing on it the latest version of the firmware then DAC calibration doesn't work. The same revision on my W2012A/OPA653 exhibits a weird behaviour while performing the DAC calibration. Indeed DAC calibration works but not better as before because it isn't so precise and the calibration depends on the position where the tracks are on the screen. The offset changes depending on the position of the tracks on the screen. So in order to get a good calibration we need to put the tracks where the offset is null and then perform DAC calibration. Doing so after the calibration become super perfect all over the whole screen, everywhere. Hence actually on W2012A/OPA653 it works but you need to act in a way different from the usual For both W2012A/OPA653 and W2022A/24Ω-150Ω performing default setup then time for the trigger position is in a weird position which doesn't match grid nor anything. Not real problem but it's weird. ~ Hayo: maybe a failure in my W2012A/OPA653, but I have noticed something of wrong. Until roughly 350Hz the square waves are distorted, then up of there all is good. Seems like the OPA653 modification isn't so good in low frequencies. Generator was good, no fault. We have compared its output using other oscilloscopes and the W2022A/24Ω-150Ω. In very low frequencies range (hundred of mHz) even W2022A/24Ω-150Ω show some distortion. Though we can't know if it is by wrong tuning because we have retuned the compensators losing the factory calibration performed by Welec. I'm pretty sure that behaviour on W2022A/24Ω-150Ω is normal because we accurately tune-up our devices, unless actually Welec performed tune-up in a different way. Everyone who have Welec in factory condition or modified are requested to verify and write their impressions. Thanks. ~ Hayo: sometimes appears a ghost rotatory switch. Thanks. So long, 400 ~~~ It's still me 김사백 but away. ~~~ Sorry
Easyloader funktioniert bei mir nicht, mit strace sehe ich, dass er eine Datei ohne Namen öffnen will: ./easyloader -c /dev/ttyUSB0 TomCat.flash > open("/dev/ttyUSB0", O_RDWR) = 3 > open file > open("", O_RDONLY) = -1 ENOENT (No such file or directory) > flash file: Unable to open > +++ exited with 1 +++
> open("/dev/ttyUSB0", O_RDWR)
Du bist an der falschen Schnittstelle zugange! Es ist TTYS0 bis 10.
Also seriell, nicht USB.
Hayo
Hayo W. schrieb: >> open("/dev/ttyUSB0", O_RDWR) > > Du bist an der falschen Schnittstelle zugange! Es ist TTYS0 bis 10. > Also seriell, nicht USB. ttyUSB0 ist seriell über USB. Sorry, ich hatte das so verstanden, dass easyloader eine Alternative zu germsloader.pl sei.
nichtGast schrieb: > Sorry, ich hatte das so verstanden, dass easyloader eine Alternative zu > germsloader.pl sei. Ja war auch so gedacht. Soll nur ohne Perl laufen. Geht aber auch über RS232, also mit dem String `dirname $0`/easyloader -c /dev/ttyS0 -f TomCat.flash $* sprichst Du Com Port 1 an. Hayo
Bei mir werden die ausgewählten Quick-Measure-Sachen nicht gespeichert. Im Grunde kein Problem, nur sehe ich bei jedem Druck Quick-Measure erstmal zwei "alte" Messdinger, die ich meist nicht brauche.
Ja stimmt, ich schau mal ob ich da was machen kann. In letzter Zeit war ich in anderer Mission unterwegs :-) aber ich könnte mich mal wieder dransetzen und eine neue Version auflegen. Gruß Hayo
Gesagt - getan. Die neue Version hat einige unsichtbare Änderungen unter der Haube und jetzt das persistente QM-Menü. Beim Neustart sollte alle so sein wie beim Abschalten. Nur wenn vor dem Abschalten alle QM-Slots gelöscht wurden (Clear Measure) werden danach Default-Werte gezogen. Gruß Hayo
Ciao Hayo, with last FW 7.8 there's something wrong with the memory save/recall: I tried to save CH1 waveform one channell, but recall result is different and shows 2 channels.Installed back 7.6 and works properly. Persistence now is fine. Regards Sandro
Ciao Sandro, thanks for reporting. I changed the internal channel numbering. So there might be a bug. I will check it. Hayo
Hallo Hayo, mir ist ein kleiner Schönheitsfehler aufgefallen (1.2.BF.7.8): Benutze ich den Assembler ADC-Driver, so startet bei Average (flat oder deep) die Average-Berechnung nicht neu, wenn ich Zeitbasis oder Y-Verstärkung umschalte. Sieht dann einen Moment etwas komisch aus. Das tritt beim Standard-Treiber nicht auf. Ricardo
Hmmm, das muss ich mir mal ansehen. Danke für den Tip. Leider bin ich die nächsten zwei Wochen viel unterwegs und komme da nicht zu. Ist aber notiert. Hayo
Da ich nun auch stolzer Besitzer eines Wellec W2024As (aktuell BF 7.7 installiert, 7.8 kommt sobald ich einen gescheiten USB-RS232 Adapter gefunden habe) bin, wollte ich mich hier auch mal melden :). Und wo ich schonmal dabei bin, hätte ich auch direkt mal zwei Fragen: 1) Ist das hochfrequente vom Oszi ausgehende Piepsen/Pfeifen normal oder bin ich der einzige dem das auffällt? 2) Bei mir ist es so, dass das Oszi nach direktem Anschalten fehlerhaft misst. So werden aus 5V plötzlich 0V oder auch mal -2,5 V. Ein Dreiecksignal, das eigentlich von 0V bis 5V geht wurde von -2,5 bis 2,5V angezeigt. Nach einigen Malen Offsetkalibrierung läuft das Gerät nach ca. 5 Minuten wieder normal. Ist das ein Softwareproblem? Jemand einen Lösungsvorschlag? Danke für schon einmal im voraus, Benedikt
Hi Benedikt, Glückwunsch zu Deinem W2024A. Zum Pfeifen - das ist eigentlich nicht normal und stammt höchstwahrscheinlich aus dem Netzteil. Schaltnetzteile arbeiten mit Hochfrequenztransformatoren. Manchmal schwingt da was mit und verursacht dann dieses unangenehme Geräusch. Muss aber nichts Schlimmes sein. Das Oszi hat eine kurze Warmlaufphase, in der auch die Nullpunkte etwas driften. So große Abweichungen wie bei Dir sind allerdings ungewöhnlich. Die Software ist da nicht die Ursache. Normalerweise sollte nach einer Offsetkalibrierung in warmem Zustand die nächsten Male keine Kalibrierung mehr nötig sein. Wenn doch, ist da irgndetwas nicht in Ordnung. Hast Du das Gerät neu erworben oder war es ein Gebrauchtkauf? In letzterem Falle ist die Frage ob der Vorbesitzer daran herumgebastelt hat. Ich weiß nicht wie tief Du schon eingestiegen bist - es gibt da zwischen den Geräteversionen 100MHz/200MHz und auch zwischen den Hardware- (sprich FPGA) Versionen bestimmte Unterschiede. Manche 200MHz Geräte sind auch keine, sondern wurden mit den billigeren Bauteilen bestückt, die in den 100MHz Geräten drin sind. Gruß Hayo
Angehängte Dateien:
-
2015-04-09_17.16.42.jpg
230 KB -
2015-04-09_17.20.27.jpg
240 KB
Danke für die schnelle Antwort! Hayo W. schrieb: > Manchmal schwingt da was mit > und verursacht dann dieses unangenehme Geräusch Interessant ist aber vielleicht, dass das Geräusch nur bei bestimmten Signalen oder Time-Base Einstellungen auftritt. Hat das vielleicht auch mit irgendwelchen Modifikationen zu tun? Hayo W. schrieb: > Hast Du das Gerät neu erworben oder war es ein Gebrauchtkauf Das Gerät ist gebraucht. So wie es von innen aussieht ist auch einiges modifiziert, was genau kann ich aber nicht sagen. Jedenfalls ist bei Pre-Gain der LB-Mod eingestellt. Anbei ein Foto vom innenleben, ich denke du kennst dich da drin besser aus als ich ;)
Ok, das wird etwas offtopic hier - lass uns mal umziehen in den Hardwarethread, den findest Du hier: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Weitere Dateien und Infos findest Du hier: http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/ Hayo
Angehängte Dateien:
-
R13_01.jpg
43 KB -
R13_02.jpg
49 KB
Hello Mark, I'm still working on our problem - and I found a solution. Resistor R13 (390KOhm, in original 908KOhm) is dimensioned a little bit too big. Using 300KOhm I got much better results. The remaining discharge error on the signal is minimal, but I will try to find the optimal value. On the screenshots channel 1 is equiped with 300KOhm and channel 2 with 390KOhm. The correction factors in the firmware need to be updated also. A new fw version and an update of the OP653 Mod manual will be available after that. Hayo
Got the wrong thread - sorry. Should be in the hardwarethread...
:
Bearbeitet durch User
Hello Hayo, that's fine! I agree that the result could be further improved being sure it doesn't come to unintentionally create other problems before releasing the final version. Maybe it isn't relevant but looking at the schematic R19 (9080ohm) is 1/100 of the size of the original R13 (908kohm). Is it a chance? I know nothing about the mathematical which is behind that circuit but perhaps there is a link. Anyway was your screenshot obtained with the original value for C11 (22nF)? If the better value for R13 is roughly 300kohm, then putting a resistor of roughly 1,3Mohm on the already welded 390kohm the result will be precisely +/-300kohm. I understand the zerolevel side but what would happen by putting a more common 270kohm resistor instead of a 300kohm? Thanks. mark
Coming in late today from sports, so answer is coming in the hardware thread tomorrow. Good night Hayo
Hi Hayo, I own a 2024 and I cycle recur in my many hobbies, now is time for electronic. I still haven't do upgrades, altoght I have all components (opa 653 also), I wanna be sure before. Playng and checking I found a bug in BF.7.8. IN TB 20uS frequency measure reports value is greather than real and also display is affected. Congratulation for good job. luigi P.S. I don't succeed to find complete schematic, could you give me a link? Thanks
Ciao Luigi, > Playng and checking I found a bug in BF.7.8. > IN TB 20uS frequency measure reports value is greather than real and > also display is affected. please would you be so kind to make some screenshots and describe signal form, levels frequency etc. That makes it more easy for me to find the failure. > I still haven't do upgrades, altoght I have all components (opa 653 > also), I wanna be sure before. yes I can understand that. The OPA653 Mod is working stable in higher frequency ranges but Mark found a little problem at lower frequencies caused by the DC input circuit after my modifications. But this will be fixed in the next days. > I don't succeed to find complete schematic, could you give me a link? complete schematic is not available. There are only some schematics of single parts like input circuits, external trigger circuit and some digital parts. Hayo
:
Bearbeitet durch User
Ciao Hayo 'please would you be so kind to make some screenshots and describe signal form, levels frequency etc. That makes it more easy for me to find the failure. Sorry I can't do that, home logistic problems but if necessary I shall try after, I tried 20uS/div 10KHz to 100 KHz Sine, Square, Pulse, with Rigol 1022A and against also a Tek 2445B for validate. I hope information is adeguate for replicate measures. have a nice day, luigi
Hi, Hayo it's visible at a glance in the display viewing 3-4 waveforms. luigi
Ok, thanks I will try it. At the moment I'm a little bit busy with the correction for the OPA653 Mod. Hayo
Angehängte Dateien:
-
Sin_20KHz_20uS.JPG
160 KB -
Sin_20KHz_10uS.jpg
150 KB -
Square_20KHz_10uS.JPG
150 KB -
Square_20KHz_20uS.JPG
150 KB -
Pulse_.5uS_20KHz_10uS.JPG
150 KB -
Pulse_.5uS_20KHz_20uS.JPG
150 KB
Ciao Hayo, here screenshots. luigi
Hello Luigi. From my own experience nothing is bad in what you have noticed. I have also noticed the same thing with other oscilloscopes than Welec, I think there is any issue at all. You must take note of the effect of overshoots that you can easily spotting expecially on the square waves and which is more or less visible depending on how the time base is set. mark
'Hi Mark, 'sorry I don't agree, it was so for old scopes not for digital TB. Ciao Hayo, I checked from 200S to 5nS and only 20uS is affected in high frequencies, while 1S and 2S are slightly affected. luigi
luigi schrieb: > Playng and checking I found a bug in BF.7.8. > IN TB 20uS frequency measure reports value is greather than real and > also display is affected. Ok, I checked it - and it is no bug. The accuracy of the measurement is depending on the number of samples in one signal period. Best accuracy you will get when only one period is displayed on the screen. The more periods are displayed the worse is the accuracy. So you have to choose a higher timebase for a better result. Hayo
Ok, die neue Version ist fertig. Wichtigste Änderung sind die neuen DAC-Offsetfaktoren, die zum neuen R13 = 305K passen. Der alte Wert (390K) wird nicht mehr unterstützt. Wer erst mal nicht dazu kommt sein OPA653 Mod anzupassen sollte FW 7.6 verwenden. Diese Version ist noch ohne Save/Recall Bug. Die Mod-Doku wird noch aktualisiert. Ok, new version is released. Main change are the new DAC-offset factors for matching the new R13 = 305K. The old value (390K) will not be supported any longer. For those Who want to use the old value longer fw version 7.6 is recommended because there is no Save/Recall bug. OPA653 Mod docu will be updated soon. Hayo
Hello Luigi. No problem, that's my experience. Anyway carefully observing 20kHz square waves into your screenshots it's quite clear that to make a difference in amplitude is mainly the initial overshoot. I think Hayo is righy and his explanation fits perfectly. If I can afford I would suggest at you to take a look to the document "Peak Detect_en.pdf" inside the "doc" folder of 1.2.BF.7.9.zip archive. On the other hands there must be a reason because Hayo wrote the function in that way, I think. mark
Hello Hayo, thank you for having fix the problem that was serious for me cause I use the oscilloscope in my daily job. The issue was severe expecially for me. Now I have to find the right resistor but that isn't a problem. Thanks. mark
Hi Mark, I agree about amplitude effects of overshhots, but what I mean is all TB settings, for the same signal, are very good but 20uS, and aince Hayo says no bug I think the question is hardware. (also amplitude of same pulse signal decrease a lot decreasing TB settings, but this is another story). I haven't still open my 2024 and don't know hardware condition, but now is time to do upgrades as soon as I have 2 free days. There is around a TB sketch ? Hayo is tyreless with the new mod and related firmware. Thanks Hayo. luigi
Ciao Luigi, if you are opening your DSO the first time - there is a detailed description how to remove the knobs on the frontside in the document W20xxA - External Trigger Mod.pdf Hayo
Ciao Hayo, downloaded with other docs. I hope next week to do all upgrades. I teporarily tried trigger leds on Ch3 and Ch4 (of course disabled), is possible to limit flickering as Tek? luigi
When triggered led is on it should last on till next transisition off/on if it happens in the next period of TB, (while trigger wait should last off). I hope to have well explained what I mean.
Hallo Alle, habe ein W2022 un die 6.5 Firmware. Habe noch keine Hardware Optimierungen gemacht. Mein derzeitiges Ziel: Ich muss meine Junsi 4010 Lader kalibrieren. Ein 2x10 Zellen Lader mit 2000W Ladeleistung, welches ich per Werte bis auf 5mV kalibireren kann in der SW. Eignet sich mein W2022 dazu? Wie gehe ich vor? Genau: Lipospannung 4,2V DC schwanken je nach Pack zwi. 3,8 und 4,2V. Ich habe mal mit 1:10 Probe und 20ms Abtastung mittels Cursur gemessen, ist aber ungenauer als mein Voltcraft VC250 DMM. Wie kann ich kalibrieren, bzw. gibt es eine Art Sefkalibration in der SW?
Hallo Martin, zunächst zwei Dinge, - Du solltest auf die aktuelle FW 7.9 updaten - ein DSO/Oszi ist immer ungenauer als ein DMM da die ADC weniger Auflösung haben Was genau willst Du denn messen? Welche Frequenz und welche Signalform erwartest Du denn?
Da ich wie gesagt "nur" auf hohe Messgenauigkeit aus bin, kann ich Abtastung und Waveform quasi vernachlässigen. Es geht eigentlich nur darum eine Niedervolt Gleichspannung zu messen, wie ich es praktisch mit einem DMM machen würde. Üblich haben DMM eine Messtoleranz von 0,5% (wie mein VC250). Bei 4,2V DC ergäbe das +/-0,0882V. plus ein paar Digits (Leider bei mir nur 2 Stellen hinterm Komma) D.h. bei 4,200V kann das sein 4,2084 --> Mein DMM zeigt dann 4,21 Mein W2022 hat 4,35 gemessen, wieso das? Wie messe ich das mit möglichst hoher Auflösung, was muss ich da einstellen??
Hallo Martin, für genaue Gleichspannungsmessung ist ein DSO völlig ungeeignet. Dieses ist optimiert auf schnelle Signalabtastung und nicht auf Genauigkeit was die Pegel angeht. Es geht da eher um die Signalform und alle möglichen Parameter im Zeit und Frequenzbereich. Natürlich hängt das auch noch vom gewählten Messbereich ab. Nimm für Deine Anwendung lieber ein Multimeter, damit bist Du deutlich besser bedient. Als Beispiel: Im Messbereich 1V hast Du ca 30 Werte pro Div (ca 240 Werte Fullscreen / 8 Div). Das sind 0,033V Genauigkeit. Dann rechne noch Bauteiltoleranzen und einen gewissen Abstimmfehler hinzu, dann bist Du bei höchstens 0,05V bis 0,1V Genauigkeit wenn es gut läuft. Das kann jedes DMM vom Discounter besser - aber dafür kann es keine Signalformen anzeigen.
Ach ja, den zusätzlichen Messfehler Deines 1:10 Tastkopfes habe ich dabei noch nicht einmal berücksichtigt...
Ok Super Hayo, genau diese Info hab ich benötigt, DANKE !! Muss ich mir doch ein Solartron 7150plus besorgen und etwas "modden" :-)
Ich habe zwar auch ein sehr genaues Tischmultimeter, aber eigentlich ist mein Handmultimeter von Voltkraft (Metex) mit vier Anzeigestellen schon genauer als ich es bisher gebraucht habe. Sowas sollte bei Dir eigentlich auch locker hinhauen. Die haben dann intern minimum 14 Bit Auflösung, was schon alles erschlägt was nicht hochpräzisen wissenschaftlichen Laboransprüchen genügen muss. Mehr als 30 - 40 Euro muss man dafür wirklich nicht ausgeben.
:
Bearbeitet durch User
Sorry Hayo, da muss ich jetzt mal Dir widersprechen. Für 40-50 Euro bekommt man keine sehr genauen DMMs das mehr als 0,5% gesamt Tol. hat. Selbst die besten Handgeräte sind da meist nicht besser als 0,1 bis 0,05%. Das fast über 40 Jahre alte und ev. neu kalibrierte Solartron 7150plus hat üblicherweise unkalibriert 0,05%. Kalibriert kann es bestimmt 0,002% ! Bei 6 1/2 Display. Wer kennt ein DMM für unter 100Euro das extrem genau ist wie das Solartron. ....upss, tut mir Leid, ist sehr Offtopic ;-|
Ach soo nochmal zum Thema, das Welec DSO kann leider tatsächlich keine Toleranzenn von denen ich sie brauche Messen. Selbst wenn ich auf 0,5V Auflösung oder noch mehr gehe und dann mit viiieeel Offset arbeite. (Abtastung ist meist 50ms) Meine Lipos dürfen beim Laden und Balancen nicht mehr als 2mv Delta haben. Um das hinzubekommen, MUSS der Lader sehr genau kalibriert sein. Also z.B. 6 Zellen in Reihe geschaltet: 1. 4,189 V 2. 4,191 V 3. 4,201 V 4. 4,188 V 5. 4,199 V 6. 4,202 V Delta wäre hier 13mV, was für Lipos auf Dauer grenzwertig wäre, da ich beim Entladen bis 250A raushole (in Peaks).
Martin Haßlöcher schrieb: > Für 40-50 Euro bekommt man keine sehr genauen DMMs das mehr als 0,5% > gesamt Tol. hat. Ja korrekt. Das sind bei Deinen Spannungen ca. 25mV. Genauer brauchte ich das bisher jedenfalls noch nie. Bei Dir scheint es ja extrem zu sein. Das sind dann tatsächlich schon Laboranforderungen - sowas wird nicht billig. Und nicht vergessen, wenn man mit diesen Ansprüchen messen will nützt einem ein gutes Gerät wenig, wenn es nicht regelmäßig kalibriert wird.
du könntest aber auch ein paar Spannungsreferenzen hernehmen um festzustellen wie genau dein DMM über einen kleinen Bereich ist. In einer Tabelle kannst du dir das dann interpolieren lassen. Angenommen DMM Messbereich auf 20V und du möchtest etwas um die 4V messen. Dann nimmst du einen Spannungsreferens von 3V und 5V und schreibst dir die Werte auf setzt sie in deine Tabelle ein misst dann z.B. 4,18V und siehst in der Tabelle nach wo du dann liegst.
Hast Du eine so genaue Spannungsreferenz? Ich nicht. Sonst könnte ich mein Tischmulti auch selbst kalibrieren.
Ja, das ist klar, sobald ich eine Spannungsreferenz oder Messreferenz habe, kann ich das alles "relativ" hinbekommen. Sogar durch interpolation seeeehr genau. Leider kosten solche "Referenzen" auch nicht wenige Euro. Ich habe einen Lipo Checker genommen, der brutal genau war, aber leider nur 3 Digits hat )-: Da musste ich selbst schätzen, er rundet dann mal bei 0,004 und dann wieder auf 0,005 auf. Das ist genau die Messtol. die ich überwinden muss.
Ach übrigens, wenn ich bald ein DMM mit 0,002% habe (kalibriert für ein Hunni), wie kann ich dann mein Welec 2022 kalibrieren, (nachdem ich auf 7.9 "geupdated" und den 390KOhm eingelötet habe) ? Geht das per SW Setup?
Ja, zur genaueren Kalibrierung gibt es im Hardwaremenü eine "Gain" Einstellung. Die steht normalerweise auf 1,000 da kannst Du dran drehen bis es passt. Das gilt dann aber für alle 3 Bereiche (5er, 2er, 1er). Also am besten den "Lieblingsbereich" kalibrieren, und dann prüfen ob die anderen noch akzeptabel sind. Evtl. für spezielle Messaufgaben den benötigten Bereich nachkalibrieren. Damit kann man dann für Oszi-Verhältnisse schon recht genau messen. Der empfehlenswerteste Bereich ist der 5er Bereich, da hier am wenigsten Rauschen auf dem Signal ist welches ja auch zur Ungenauigkeit beiträgt. Übrigens wird in der Bucht gerade ein Schlumberger für 175,- Ocken angeboten
Ach ja, noch ein Tip wenn es auf genaue Pegelmessungen ankommt. Wenn man mit Quick Measure (also automatisch) misst, dann wird der Rauschpegel mitgemessen. Das sorgt natürlich für eine zusätzliche Ungeauigkeit in höhe des Rauschpegels. Wenn man es genau braucht ist die manuelle Cursormessung besser, da man hier den Cursor ungeachtet des Rauschens direkt auf das Signal legen kann.
Hi Hayo, ja genau auf das Schlumberger in der eBucht ziele ich. Ist auch eins dabei das derzeit günstiger steht vom Preis. Alle aus UK. Plus eben Zoll, Kalibrierung etc. komme ich trotzdem auf über 200 Euro. Dafür bekomme ich schon ein Voltcraft VC950 nach ISO zertifiziert und mit 0,05% auch schon recht gut. Achso, danke für den Kalibrier Tipp. Hatte ja schon geschrieben, dass ich mittels Cursor Messung gemessen habe, bzw. mit RMS Einstellung. Aber wie gesagt, bei 0,5V Teiler hatte ich anstatt 4,200V schon 4,35V gemessen, da hab ich das ganze abgebrochen und bin auf den LipoChecker gegangen. Schlussendlich werde ich mir eine CellPro 8 kaufen, der misst extrem genau und ist schon kalibriert (auf 0,005V bei den Lipo typischen 4,2V) Für unter 20 Euro zu bekommen. Damit wäre schon so ganz grob mein Ziel erreicht.
Hello Martin,you have to pay attention at the fact that generally DVM have 10-11Mohm like input impedance while oscilloscope is 1Mohm. Welec also is 1Mohm input impedance and this makes a difference. DVM is better than oscilloscope basically due its great input impedence. Going over surely you can tune your W2022 availing of a leveled voltage generator by adjusting the gain in the hardware menu. I did do it so and it works. Anyway the instrument still is a 1Mohm input impedance. mark
Martin Haßlöcher schrieb: > Ach übrigens, wenn ich bald ein DMM mit 0,002% habe (kalibriert für ein > Hunni), welches DMM ist das denn und wer kalibriert das denn auf die genaugikeit? mein UT804 zeigt bei 0.4V 0.3997V das sind ~0,075% abweichung bei 4V siehts genauso aus vlG Charly
Hi Charly, das hatten wir doch mehrfach erwähnt, es ist das Schlumberger Solartron 7150plus. Ein Gerä aus den 80er, rein entwickelt für's Millitär. Es sind in den 2000ern einige Geräte in den Handel gekommen, die immer wieder in Ebay auftauchen. Kalibrieren kann man das Gerät in der SW direkt. Und ja man kann das Gerät fast wieder auf Werksgenauigkeit kalibrieren, mit entsprechendem Werkzeug. Jeder gute Kalibrier Service macht das für 80-150 Euro, je nachdem. Das sind dann Normen die über Iso oder DAkkS gehen. Nur die PPms/C° sind eben nicht ganz so gut, da die Kondis etc. halt meist über 40 Jahre alt sind. Referenz ist eine hochselektierte / Diode mit ca. 6,2V, was ja egal ist, da das im ACD gewandelt wird und kalibriert. PPm/C° ist ca. 5 der Diode!
luigi schrieb: > When triggered led is on it should last on till next transisition > off/on > if it happens in the next period of TB, (while trigger wait should last > off). > I hope to have well explained what I mean. Hello Luigi. Sorry I didn't understand what do you mean but have a look at this document here: http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/W20xxA%20-%20LED%20Mod.pdf/download Maybe actually Welec works in opposite way to other oscilloscopes. mark
Hi Mark, I have read this doc but what I mean is when the signal is triggered and led is on it stay on for a short time so before time expires (time out) and a new signal is detected it it's still on and continous on/off is avoided. luigi
I think I understood. So in case of stable trigger, the red LED (trigger indicator) is always on, correct? What about the green led (trigger armed)? Hayo
Correct. The same, till Red Led is on the Green couldn't go on, (I think a aimple xor instruction) I prefer yellow for armed trigger and green for triggered. luigi P.S. I think next info could be useful forn many people. In the various flashing I had Model, HW and serial resetted, I could restore them reflashing original firmware with your WalecUpdate not with WalecUpdater.
Ehi Hayo, whath do you think about Display Persistence values lower than 5 sec.? luigi
Ok, I added 1s and 2.5s - Is that ok? Hayo
Wonderful, this does a better display of some modulated waveform. You surely noticed aliasing and colliding display problems (sampling rate and memory depth) in sweeped wf. Do you think can just do something ? Yes I know it's hard but sw often can do miracles. Off topic: Playing with R19 (reducing) and C11 (increasing) a bit can we improve HF BW linearity ? luigi P.S. When you thing I go too far tell me and I shall stop.
luigi schrieb: > When you thing I go too far tell me and I shall stop. No problem - thinking and discussing about improvements are always welcome. I try my best to make it possible. Unfortunately there are some limits due to bad hardware/FPGA design which can't be solved without changing the FPGA-core. Jörg made some good attempts which showed us what could be possible with a NIOS 2 core. At the moment the development sticks a little bit but we hope that Jörg will go one. Hayo
luigi schrieb: > Off topic: > Playing with R19 (reducing) and C11 (increasing) a bit can we improve HF > BW linearity ? No, that is the wrong step. The OP1177 and the back coupling with C11/R19 is only responsible for the DC part of the signal. To change HF linearity we have to play with the back coupling of the OPA656 (R22/C12) as I have done in the LB-Mod. Changing the values can raise or bring down the higher frequency range of the characteristic. In original design the upper range of the amplitude characteristic (80 - 180MHz)is much to high - this results in a greater 3dB bandwidth but with completey distorted signals. So it is better to have less bandwidth but more linearity. And that is what I made in the LB-mod. Hayo
Ok Folks, the new firmware version for all WELEC "A" models with or without modifications. Die neue Firmwareversion für alle WELEC "A" Modelle mit oder ohne Modifikationen. Gruß Hayo edit: please use the second compilation. I added the new LED option for Peak Detect also
:
Bearbeitet durch User
Hi, Danke Hayo. DSO wird mit jedem kleinen Fix besser, perfekt so! Übrigens hab ich mir so ein China DMM geholt. Damit wird dann auch mal das Welec kalibriert. Das DMM hat bei DC 0,003% Genauigkeit :-)
Hello Hayo. OK, thanks for the upgrade. So 1.2.BF.7.10C2 is better cause it has the new LED option for Peak Detect that 1.2.BF.7.10 hasn't yet, correct? Martin Haßlöcher schrieb: > Übrigens hab ich mir so ein China DMM geholt. Damit wird dann auch mal > das Welec kalibriert. > Das DMM hat bei DC 0,003% Genauigkeit :-) Hello Martin. Am I pushy asking exactly which DMM model it is? Thanks mark
@mark That's correct, I was a little bit in hurry because of preparing holidays beginning next week and so I forgot it in the first compilation. @Martin Welches Modell und bitte einen kurzen Erfahrungsbericht ob das Gerät empfehlenswert ist.
Hi All, It's from Digitek the model DT 80000. Precision in DC is genius. I calibrated my Charger with 3mv tolarance, the values are fully reproducible. Next step is the firmware update to the welec and then the calibration. The AC tolerance is not the best at all, but DC is more my usage. Quality is not the best, but also not bad. Background light is blue, nice :-) The best is the Frequenz Generator, precise and great to check the welec ! Further will follow.
Hi All, unlängst brauchte ich mal wieder den Pulsewidth Trigger. Der funktonierte leider nicht in der aktuellen BF7.10C2. Ursache war eine im Edge Trigger eingestellte Holdoff Zeit. Irgendwann hatte ich mal herausgefunden, daß für den Pulsewidth Trigger Holdoff = 0 sein muss. Also habe ich das mal am Ende der Funktion Hardware::CaptureTrigSetPulse als CaptureTrigSetHoldoff(0) nachgetragen: Pulsewidth Trigger funktioniert wieder! Zum Ausprobieren im Anhang die zwei geänderten Files. Vielleicht kann das Hayo nun mal endgültig für das alte FPGA-Design übernehmen?! Gruß Jürgen
Hi Jürgen, ja klar, ich baue das ein. Manche Sachen brauchen halt länger bis sie den Weg in die Firmware finden ;-) Hatte ich wohl irgendwann mal aus den Augen verloren. Da bei mir Holdoff immer auf Null steht ist mir das nie aufgefallen (Anderen wohl auch nicht...). Gruß Hayo
Hello Jürgen.
Jürgen schrieb:
TomCat_flash.ucl TomCat_ram.uc
Are those intended like a recognized legit fix?
Thanks
mark
mark schrieb: > Hello Jürgen. > > Jürgen schrieb: > TomCat_flash.ucl TomCat_ram.uc > > Are those intended like a recognized legit fix? > Thanks > > mark Hello Mark, this is a fix for me and this fix is running for me. If you are not happy with it, please use the the standard version from Hayo. You can flash it forward or flash back the standard version. No problem. Regards, Jürgen
PS: Hi Mark, Hayo will use this fix in his next version: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Jürgen
Hi there folks, a was a little bit busy the last time. So I had no chance to build a new version. But don't worry, I will bring it out soon. If anyone needs to use the pulsewidth trigger I would recommend to use Jürgens fix. Otherwise there is no need to do anything. I will be back... Hayo
Ach ja - @Jürgen - ich weiß auch warum Deine Änderung wieder fehlt. Die ist bei der Umstellung auf das OSOZ API verlorengegangen. Da musste ich so viele kleine Einstellungen übernehmen bzw. anpassen, dass dieser Punkt wohl einfach untergegangen ist. Hayo
Hello Jürgen. Maybe I explained bad, sorry. I'm happy with your fix and I'm grateful to you for it. The only thing I wanted to know is if that is 1.2.BF.7.10C2 fixed by you or instead a different one. Please take in mind I'm not saying different firmware like for instance one completely wrote by you or anybody else isn't good as the Hayo release. What I want to say is that because I use my Welec for job I need stable and tested firmware in order to avoid errors. My fear is that your firmware have differents hidden features which can create problems in my application field. Hoping to be clear now. I repeat it, for me your firmware is good for what is related the Pulsewidth Trigger. Rarely I use Holdoff and Pulsewidth Trigger and therefore very likely I would not have noticed the problem, so thank you for having fix it! mark
mark schrieb: > Hello Jürgen. > Maybe I explained bad, sorry. > I'm happy with your fix and I'm grateful to you for it. > The only thing I wanted to know is if that is 1.2.BF.7.10C2 fixed by you > or instead a different one. Hello Mark, no, it's only one additional line of source code in Hayo's 1.2.BF7.10C2 firmware. Jürgen
So, hatte jetzt mal so zwischen Firma, Raspberry Pi Projekt und diversen anderen häuslichen Verpfichtungen mal Zeit die Korrektur von Jürgen einzubauen. Damit sollte das ein für alle Mal erledigt sein :-) Hi folks, this is the correction for the pulse width trigger. Also available on SFN
OK, well done. But what about adding a kind of alert while persistence is on? I understand that's a silly question but after I lately upgraded I have had trouble just because 1s/2.5s persistence was activated and it took a little time and some reset before I understood that the problem was there. Likely I have activated and forgot it, surely it's my bad, but perhaps I'm not alone.
Hi Stefano, sorry for the late answer, I was a little bit busy last time. Yes maybe I can add a message in the (optional) On Screen Message System. The status bar is a little bit crowded with other things. Any own ideas how to solve this? Hayo
Hi Hayo, no problem. If status bar is too crowded On Screen Message System would be the better choice but I can tell how. That I don't know, I guess exists many way. I'm sure you are in the zone most than me and I trust you. Maybe putting some indication in the channel labels just like for AC/DC indication would does the job. It does not need something complex then any way will be fine. Another thing related to the issue I met. Is it possible that using Tek option for trigger LEDs introduce delays on trigger's acquisitions?
Angehängte Dateien:
-
FW6.4_Trace_Middle.png
3,3 KB -
FW7.11_Trace_Middle_50ns.png
3,8 KB -
FW7.11_Trace_Middle_100ns.png
3,6 KB
Nach langer Pause und nach dem Low Budged Umbau, der mein Welec ausser Bertieb setzte, durch eigens verschuldete Lötkünste... jetzt mit gefixten W2022 (es rennt wieder), habe ich mal die aktuelle FW7.11 geflasht. Im "Edge"-Menu auf "Trace Middle" habe ich einen Spike auf beiden Kanälen, bis ins unendliche, bei 50 u. 100ns. Das Verhalten geht zurück bis zur FW6.4 ! An der Low Budged Option kann es nicht liegen, da die FW6.4 diese noch nicht hat. Ich bin mal zurück, bis zur FW6.0, da tritt der Fehler nicht auf. Anbei 3 Screenshots Gruß Michael
Hi Michael, bin gerade zurück vom Portugiesen (nicht Griechen!). Ich werde mir das mal morgen ansehen wenn die berufliche Lage das zulässt. Hört sich ja merkwürdig an. Mal schaun... Hayo
Angehängte Dateien:
-
Factory_Setup.jpg
43 KB -
HF1_Setup.jpg
43 KB -
HF2_Setup.jpg
44 KB
Hi Michael, die Lösung liegt so nahe! Schau mal in Dein Hardwaremenü, ich wette Dein ADC-Setup steht auf High Frequency 2. Diese Einstellung ist nur für besondere Messungen gedacht, wenn es mit dem Factory oder HF 1 Setup nicht so gut klappt. Also eher experimentell. Für alles Andere lieber das Factory-Setup benutzen. Also alles wird bzw. ist gut! Gruß Hayo p.s. aber schön rauschfrei das Signal, oder?
:
Bearbeitet durch User
Nein, stand auf "Factory"! Und wie gesagt, tritt nur bei "Trace Middle" auf. Aber gut, das du es erwähnst. Ich habe mal von "Factory" auf HF 1 geschaltet, plötzlich waren die Spikes weg!? Weiter auf HF 2, sind sie wieder da. Also muss ich auf HF 1 stehen lassen, da ist dann alles hübsch! Wie kommt das denn? Bzw. was ist bei HF 1 anders? Hat es jetzt auch was mit meinem LB Umbau zutun? Und ja, das Rauschen ist so minimalistisch, das sogar die 1V, 2V Div's brauchbar geworden sind. Normaler Weise fehlt ja noch der Tausch von Bauteilen u. Abgleich unter den Schirmblechen. Trotzdem stimmt der Gainfaktor, also die Spannungsangabe bei DC-Messungen ist realistisch. Gruß Michael
Michael D. schrieb: > Also muss ich auf HF 1 stehen lassen, da ist dann alles hübsch! Wie > kommt das denn? Also bei dieser Einstellung wird ein bestimmter Wert in eines dieser ominösen nicht dokumentierten Register des FPGA geschrieben. In der Einstellung "Factory" wird der von WELEC vorgegebene (bzw. mit dem Gerät ausgelieferte) und im Protected Flash abgelegte Wert verwendet. In den anderen Einstellungen werden experimentell ermittelte Werte (die sind hart codiert in der Firmware hinterlegt) hinengeschrieben. Wie wir ja festgestellt haben, wirkt sich das je nach Hardware- (bzw. FPGA) Version unterschiedlich aus und es sind auch unterschiedliche Factory-Werte hinterlegt. Welche Werte da aktuell verwendet werden, kannst Du über ein Terminal mit der Kommataste herausfinden. Das Register heißt adc_change12_reg und wir haben im Hardwarethread/Firmewarethread damals recht ausgiebig damit herumexperimentiert. Gruß Hayo
Hallo Hayo, leider mal wieder eine sehr schlechte Nachricht :-( Die Version BF7.10C2 triggert nicht in der einfachsten Triggerart EDGE im NORMAL Mode! Bei 500kSa/s läuft das noch, bei 250kSa/s und darunter erfolgt keine Triggerung mehr. Test war die Darstellung einer seriellen Ausgabe ca. im Sekundenabstand auf 3,3V Niveau. Der Fehler muss in der BF7.10 hereingekommen sein, da in der BF7.9 noch sauber bis hinunter zur USTB getriggert wird. Ja, ich weiß, das Warten beim Testen ist hier schon langweilig! :-) Bitte, wenn Du mal Zeit hast.... Viele Grüße Jürgen
Uuups! Das muss ich mir mal ansehen. Ist das sonst noch keinem aufgefallen? Ich schau mal... Gruß Hayo p.s. ok, ich kann das bestätigen. Die Triggerung reißt unterhalb von 250KS ab. Da muss ich wohl mal abgleichen was ich da geändert habe und auf Fehlersuche gehen. Danke für den Hinweis.
:
Bearbeitet durch User
Jürgen schrieb: > Hallo Hayo, > > leider mal wieder eine sehr schlechte Nachricht :-( > Die Version BF7.10C2 triggert nicht in der einfachsten Triggerart EDGE > im NORMAL Mode! > Bei 500kSa/s läuft das noch, bei 250kSa/s und darunter erfolgt keine > Triggerung mehr. > Test war die Darstellung einer seriellen Ausgabe ca. im Sekundenabstand > auf 3,3V Niveau. > Der Fehler muss in der BF7.10 hereingekommen sein, da in der BF7.9 noch > sauber bis hinunter zur USTB getriggert wird. > Ja, ich weiß, das Warten beim Testen ist hier schon langweilig! :-) Actually that's the problem I was talking about. In reality it's trigger lack, don't a persistence problem.
Hi, I'm sorry but I'm a little bit busy last time - new project at work. But I'll keep it in mind. The correction will come... Hayo
No problem for that. It's me who want underline how my previous statement was wrong.
Werte Welec-Oszi Freunde, ich hatte etwas Zeit und habe versucht die mich am meisten störenden Fehlfunktionen in der Firmware zu finden und zu beheben. Folgende Dinge sind mir bei der Review der aktuellen Firmware BF7.11 und in der Funktion unseres Scopes aufgefallen: 1. wie schon gemeldet, kein Edge-Triggern unterhalb 500kSa/s im Normal Mode 2. FFT aktualisiert nicht im Normal - Mode 3. PW-Triggerung funktioniert immer noch nicht zuverlässig, da teilweise falsche Anzeige der eingestellten Werte 4. PreTrigger entspricht nicht der üblichen Funktion 5. ein Workaround für den Normal - Mode ist normalerweise ein K.O. Kriterium :-( 6. tolles Geflimmer einiger Trigger-LED's trägt nicht unbedingt zur Übersichtlichkeit in der Firmware bei :-) Mittlerweile ist der Test nach Änderungen in der Firmware die zeitraubendste Tätigkeit. Jetzt etwas "Fachchinesich": Überarbeitet habe ich zunächst die Ablaufsteuerung des Oszis etwas. Aus der Erinnerung funktionierten doch einige Funktionen in vorhergehenden Versionen zuverlässig. Deshalb als These eine althergebrachte Ablaufsteuerung: Sampling KOMPLETT einstellen - Starten - Ergebnis abwarten - Sampling Stoppen - Ergebnisse anzeigen - und von vorn :-) Allerdings muss ich einschränkend sagen, das es mir in den letzen drei Tagen wegen der inzwischen doch recht hohen Komplexität der Firmware nicht gelungen ist, alle Zweige zu testen und zu durchschauen. Ich habe mich nur auf die Grundfunktion beschränkt. zu 1. mit der Umstellung der Ablaufsteuerung funktioniert das jetzt zu 2. dieser Fehler resultiert irgendwie aus der (notwendigen?) Verstellung des Nullpunktes für XY-Betrieb. Dies ist für FFT nicht notwendig(?). Dort habe ich die Nullpunktverstellung FFT erstmal stillgelegt. Ist noch nicht perfekt. Das könnte sich unser Experte nochmal ansehen :-) zu 3. Die PW-Triggerung hat tatsächlich nur 16 bit breite Register mit einer Auflösung von 8 ns :-( Dadurch ist der im Handbuch vorgegebene Einstellbereich der Parameter bis 100 ms vollkommen illusorisch. Habe versucht die als "ungenutzt" bezeichneten Bits im trigger_width zu nutzen - leider kein Erfolg :-( Daraufhin habe ich die zwei Tastenfunktionen F4 und F5 und die Funktion des Drehknopfes komplett überarbeitet und die Begrenzung der Einstellbarkeit der Zeiten auf 524 us eingearbeitet. Damit stimmt wenigsten die Anzeige mit der Einstellung im Hardwareregister überein (vorher Zahlenbereichsüberlauf und auch bei * ms teilweise Funktion, falls der Rest im Register gerade gepasst hat). Da die "SM" Smaller Funktion nicht so sicher funktionierte und als Workaround mit "Range" ersetzt wurde, habe ich hier für den kleineren Teil einfach 1/32-tel des grossen Parameters gesetzt. Dies erscheint mir klein genug, da man ja auch den grossen Parameter recht klein einstellen kann. Jedenfalls funktioniert das besser als 16ns ... für den kleinen Parameter. zu 4. der Pretrigger nutzt nur maximal die Breite des Bildschirmes in der aktuellen Samplerate aus. Da geht normalerweise besser, falls man ein komplizierteres Signal hat, bei dem das Triggerereignis erst nach weiteren Samples erfolgt. Maximal sollte hier die Länge des Samplepuffers einstellbar sein. -> Habe hier Keine Änderung in der Firmware gemacht. zu 5. Workaround in Handle_ADC komplett entfernt zu 6. unverändert :-) Anbei die geänderte Firmware als *.flash und *.ucl zum ausprobieren und testen. Bitte wirklich testen und Rückmeldung geben, auch wenn ich selber weiss: Ein Oszi braucht man unbedingt. Aber wenn es denn da ist, braucht man es doch relativ selten :-) Einzelheiten werde ich besser gern mit Hayo per PN diskutieren, falls und wenn er wieder Zeit und Lust dazu hat. Schliesslich entsteht das alles in unserer Freizeit! Also viel Spass beim Testen. Viele Grüße Jürgen
Hallo zusammen, mir ist gestern noch eine Kleinigkeit aufgefallen: Die Anzeige der Triggerschwelle bei externer Triggerung skalierte nicht mit dem eingestellten Probefaktor. Das ist jetzt korrigiert. Die Dateien ersetzen direkt die gestern von mir hochgeladenen Dateien. Gruß Jürgen
Hallo, mir ist gerade aufgefallen, dass die Trigger Betriebsart "Free Run" mit der neuen my7.11-Firmware nicht mehr funktioniert, die Kurve steht. Habe es gleich mit der älteren 1.2.BF.7.11 (von Hayo) gegengeprüft, da läuft es noch. Gruß Ricardo
Hallo Ricardo, ja das ist wohl so. Habe da nicht so darauf geachtet. Ich kann mir auch beim besten Willen nicht vorstellen, wozu diese Betriebsart im Gegensatz zur Betriebsart Auto gut sein soll!? Da könnte man nochmal das Menü aufräumen und diesen Betriebsmodus entsorgen. Soweit bin ich aber noch nicht vorgedrungen :-( Gruß Jürgen
Ok, hier wie versprochen die neue Version mit den Korrekturen der von Jürgen gemeldeten Bugs. ----------------------------------------------------------------- Ok folks, here the new version with latest bugfixes -> thanks to Jürgen for reporting Hayo
Hi Hayo, Hayo W. schrieb: > Ok, hier wie versprochen die neue Version mit den Korrekturen der von > Jürgen gemeldeten Bugs. da bin ich ja gespannt, wie Du das gemacht hast ohne meine Source gesehen zu haben :-) Ich werde noch einmal vergleichen... Gruß Jürgen
Hallo Jürgen, cool das du auch etwas beisteuerst! Magst du deine Quelle bzw. Patches veröffentlichen? Viele Grüße
Jürgen K. schrieb: > da bin ich ja gespannt, wie Du das gemacht hast ohne meine Source > gesehen zu haben :-) Naja, die Source ist ja mittlerweile mein zweites Zuhause. Da kennt man ja schon fast die Zeilennummer aus dem Kopf wenn man mal was reparieren muss ;-) Da ich etwas kanpp an Zeit war konnte ich nur die beiden wesentlichsten Punkte auf die Schnelle korrigieren. Zu Punkt 4. z.B. habe ich nicht ganz verstanden wie Du das gemeint hast. Denn eigentlich nutzt der Pretrigger schon den gesamten Bufferbereich. Gruß Hayo
Vielen Dank für die neue Version! Ich habe auch noch nicht wirklich getestet - aaaber das Testsignal auf Kanal 3 (blau) hat jetzt eine wesentlich geringere Frquenz als die anderen....soll das so? Auch werden die im Autoscale nicht mehr so schön scaliert. Könnt ihr das reproduzieren? Grüße, Egberto
Also am Testsignal und auch an der Skalierung habe ich nichts geändert. Eigentlich sollte das alles so sein wie vorher. Dass das blaue Testsignal eine geringere Frequenz hat war doch auch schon vorher - oder irre ich mich da? Die Skalierung des Testsignals mit Autoscale ist übrigens nicht ganz repräsentativ, da es sich nicht exakt wie ein natürliches Signal verhält. Hier also nicht zu viel hineininterpretieren. Autoscale am Besten immer mit einem echten Signal testen.
:
Bearbeitet durch User
Hallo nichtGast, nichtGast schrieb: > Hallo Jürgen, > > cool das du auch etwas beisteuerst! > Magst du deine Quelle bzw. Patches veröffentlichen? > > Viele Grüße natürlich mache ich das wie bisher auch schon VG
Hallo Hayo, leider ist in der neuen Woche wieder viel zu wenig Zeit für's Hobby und zum ernsthaften Testen ist offenbar auch nur wenig Zeit oder Lust in der Community vorhanden :-( Anbei die kompletten Quellen meiner Fixes der Version BF7.11. Ich würde Dich bitten alle Dateien mit Datum 5.9.2015 komplett zu übernehmen, damit nicht wieder etwas verloren geht und nicht mehr funktioniert.(Teilweise hab ich auch nur für mein Verständnis Kommentare eingefügt. Deshalb die größere Anzahl Dateien.) Erläuterung folgend: Ich habe ebenfalls die BF7.12 nochmal den gleichen Tests unterzogen, die ich für die Fixes my7.11+ durchgeführt hatte. Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung, weder im Edge-Trigger noch im PW-Trigger. Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig. Die Einschränkung in der Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls noch und läßt hier eine Fehlerquelle in der Bedienung zu. Mit der geänderten Signalerfassung in der 7.11+ erfolgt stabil eine Triggerung unter allen Umständen. Es wäre eben schön gewesen, wenn dies von Anderen ebenfalls getestet und bestätigt würde! Hayo W. schrieb: > Zu Punkt 4. z.B. habe ich nicht ganz verstanden wie Du das gemeint hast. > Denn eigentlich nutzt der Pretrigger schon den gesamten Bufferbereich. Das muss ich mir nochmal ansehen, was ich mir dazu überlegt hatte. Ist aber im Moment keine Zeit dazu. Wie schon geschrieben, habe ich mich extra hier angemeldet. Einzelheiten der Software habe ich aber nicht vor hier zu diskutieren. Das können wir jetzt auch anders tun :-) Viele Grüße Jürgen
Jürgen K. schrieb: > Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung, > weder im Edge-Trigger noch im PW-Trigger. Hast Du hier ein Beispielsignal an dem ich mir das mal ansehen kann? Signalform, Frequenz, Amplitude. Dann kann ich das direkt vergleichen mit Deiner Version. > Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig. Was fehlt noch? Habe ich was übersehen? > Die Einschränkung in der > Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls > noch und läßt hier eine Fehlerquelle in der Bedienung zu. Da bin ich auf die Schnelle nicht mehr zu gekommen, muss ich dann noch nachrüsten. Guats Nächtle Hayo
Hi Hayo, Hayo W. schrieb: > Jürgen K. schrieb: >> Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung, >> weder im Edge-Trigger noch im PW-Trigger. > > Hast Du hier ein Beispielsignal an dem ich mir das mal ansehen kann? > Signalform, Frequenz, Amplitude. Dann kann ich das direkt vergleichen > mit Deiner Version. > Ja, habe ich: Edge-Trigger: einfach ein Signal (hier 3,3V) von irgendeiner Comm-Software via seriellen Port, welches im Abstand von >= 1sec (!) z.B. Anfragen an ein Gerät sendet. PW-Trigger: Siehe Ausdruck. Das ist natürlich nur nachzuvollziehen, wenn ein entsprechender Funktionsgenerator vorhanden ist. Das Signal besteht aus 4000 Werten, die mit ca. 900Hz wiederholt werden. Sync-Signal wird selbstredend hier nicht benutzt. Dabei setzt die Triggerung eben auch beim Durchkurbeln und Zurückstellen der Ausgabefrequenz sicher aus und wieder ein. >> Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig. > Was fehlt noch? Habe ich was übersehen? > Der wird verstellt mittels Triggerlevel, Mainwheel und mittels F5-Button. >> Die Einschränkung in der >> Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls >> noch und läßt hier eine Fehlerquelle in der Bedienung zu. > > Da bin ich auf die Schnelle nicht mehr zu gekommen, muss ich dann noch > nachrüsten. Ist eben alles in meiner 7.11+ eingebaut. Gruß Jürgen
Ok danke, ich schau mir das mal an. Gruß Hayo
Aktueller Zwischenstand, - Du hast Recht Jürgen, die Einstellroutinen für den Pulsweitentrigger sind zum Teil noch auf dem alten Stand von Wittigs ursprünglicher FW. Ich habe das jetzt mal gründlich überarbeitet. Jürgen K. schrieb: >>> Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig. >> Was fehlt noch? Habe ich was übersehen? > > Der wird verstellt mittels Triggerlevel, Mainwheel und mittels > F5-Button. Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen Einstellung/Kombination hat es denn bei Dir nicht funktioniert? Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so reproduzieren können, habe aber mit etlichen verschiedenen "normalen" Signalen getestet und konnte keine Probleme beim Triggerr feststellen. Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der vermurksten Hardwareimplementierung doch recht gut funktioniert. Gruß Hayo
Hallo Hayo, Hayo W. schrieb: >> Der wird verstellt mittels Triggerlevel, Mainwheel und mittels >> F5-Button. > > Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der > Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen > Einstellung/Kombination hat es denn bei Dir nicht funktioniert? > Ich habe das eben nochmal versucht durchzuspielen. Es scheint doch so zu funktionieren. Kann sein, ich hatte nur die Quellen verglichen. Aber bekanntlich führen viele Wege nach Rom :-) > Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so > reproduzieren können, habe aber mit etlichen verschiedenen "normalen" > Signalen getestet und konnte keine Probleme beim Triggerr feststellen. > Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der > vermurksten Hardwareimplementierung doch recht gut funktioniert. Na ich bin gespannt und wir werden sehen... Grüße
Und hier ist die neue Version. Auch verfügbar auf SFN - wie immer. Die Drucktastensteuerung der Pulseweitenwerte hat jetzt neue Steps und eine Begrenzung auf 524µs, ebenso die Mainwheelsteuerung. Ich habe noch mal alles geprüft und es lief bei mir alles schön stabil. Der Teufel steckt aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler jederzeit willkommen. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, Hayo W. schrieb: > Der Teufel steckt > aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler > jederzeit willkommen. also los geht's: Ich komme zuerst mal auf den Pretrigger zurück. Mit dem oben genannten Edge Trigger Signal mit ca. 1s Abstand sieht man in der 1.2BF.7.13: Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt. Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal angezeigt. Dabei sieht es so aus, als ob zweimal ein Signal angezeigt wird. Zum Schluss aber der falsche Ausschnitt. Wenn man auf Single umschaltet, stimmt dann die Anzeige wieder nach dem Triggern. Als Referenz nehme ich jetzt mal die V1.4 :-) Dort funktioniert die Anzeige mit dem richtigen Triggerzeitpunkt (z.B. triggern auf fallende Flanke) in allen Timebase. Dazwischen habe ich weitere Versionen daraufhin getestet: BF6.3 und BF6.4C6 OK - ab BF6.5 falsche Darstellung Gruß Jürgen
Hallo zusammen, auf meinem W2024A war noch eine sehr alte Software. Jetzt habe ich die 7.13 eingespielt und habe folgendes Problem: In Y Richtung wird die Spannung falsch angezeigt. Statt 5V wird nur 4V angezeigt (Sprich: 0,8*Wert). Ich habe bereits gesucht wo ich die Kalibrierung verändern könnte aber habe nichts richtiges gefunden. Ich hoffe jemand kann mir hier weiter helfen. Danke. Gruß Stefan
Hi Stefan, erstmal die Frage ob Dein Gerät irgendwie modifiziert ist oder die originale Factory-Bestückung hat? Die entsprechende Einstellung nimmst Du im Hardwaremenü vor: Utility -> More -> Hardware - ADC Setup erstmal auf Factory - Pre Gain je nach Modifikation oder wenn nicht modifiziert dann Factory - Gain kann zur Feinabstimmung benutzt werden (default 1.000) - ADC-Driver würde ich Assembler nehmen, Standard geht aber auch Dann wieder zurück und Default Setup machen. Danach kalibrieren wenn das Gerät etwas warm geworden ist. Dann sollten die Amplituden eigentlich stimmen. Gruß Hayo
Angehängte Dateien:
-
W2024A_ADC.jpg
96 KB
Hi Hayo, Danke für die schnelle Antwort. Mein Gerät ist Factory. Habe versucht ADC Setup auf Factory zu stellen und jetzt ist das Oszi eingeschlafen. Bildschirm leicht grün und keine Taste geht mehr. Aus- und einschalten bringt nichts ebenso reset (F2 + F1) es landet immer wieder an dieser Stelle. Gruß Stefan PS: Habe die alte FW eingespielt und anschließend wieder auf 7.13. -> Oszi läuft. Habe nur preGain auf Factory gesetzt und die Volt Kalibrierung stimmt. Danke. -> Das mit dem ADC Setup müsste ein Bug in der FW sein.
:
Bearbeitet durch User
Hi Stefan, nein ein FW-Bug in dem Sinne ist es nicht. Aber wenn Du von einer sehr frühen Version upgradest kann es vorkommen, dass noch alte Werte im Flash an Stellen stehen, die jetzt eine andere Funktion haben. Daher wie in der Anleitung beschrieben immer ein Default Setup machen nach dem Flashen wenn man größere Versionssprünge macht. Wenn das erst mal in Betrieb ist sollte man keine Probleme mehr haben. Wenn Du da jetzt was verstellst müsste das ohne Probleme auch wieder zurückzustellen sein. Wenn nicht, dann bitte noch mal Bescheid sagen. Gruß Hayo
Jürgen K. schrieb: > Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt. > Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal > angezeigt. Hi Jürgen, ich habe versucht das nachzustellen. Versuchsaufbau mit drei Oszis - Owon SDS8102 - WELEC W2022A mit OPA653 Mod und FW 7.13 - WELEC W2014A mit LowBudget Mod und FW 6.3 Am Signalgenerator habe ich Pulse eingestellt und den Start manuell getriggert um eine gewisse Ähnlichkeit zu Deinen Signalen zu erreichen. Spannungsbereich am Oszi war auf 2V/Div 90% ausgesteuert (also ca. 12V). Ich konnte keine Unterschiede zwischen den Oszis feststellen. Es wurde bei allen korrekt getriggert. Dein Signal scheint ja sehr speziell zu sein wenn es da Probleme gibt. Gruß Hayo
Hi, Hayo W. schrieb: > Dein Signal scheint ja sehr speziell zu > sein wenn es da Probleme gibt. da ist aber überhaupt nichts spezielles an dem Signal. Ist einfach ein Stück serielle Comm (9600,8,N,1 oder so) im ca. 1 s Abstand gesendet und aufgezeichnet. Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus. Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst angezeigt wird und danach im RUN gleich überschrieben wird. Ich habe mal drei Screenshots angehängt. Vielleicht wird es damit besser sichtbar. Gesamt.bmp zeigt das gesamte Signal :-) Die zwei anderen eben Richtig und Falsch. Die Bilder hab ich wegen der Größe besser gezipt. Die Screenshots sind vom W2024A, 8C7.0H, BF7.13 und was auf den Bildern für Einstellungen zu sehen sind. Falls Du unter Windows unterwegs bist, kann ich Dir gern das kleine Progrämmchen zusenden, was die Signale ausgibt. Gruß Jürgen
Jürgen K. schrieb: > Die Bilder hab ich wegen der Größe besser gezipt. Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-) http://cetus.sakura.ne.jp/softlab/b2p-home/
Wolfgang A. schrieb: > Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-) Danke für den Hinweis!
Oho, da hab ich mich wohl geirrt :-( Ich habe wahrscheinlich die Antwort schon in der Frage mitgeschrieben: >> Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus. >> Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst >> angezeigt wird und danach im RUN gleich überschrieben wird. Das wäre ja auch das beabsichtigte Verhalten: Im RUN so viel wie möglich Frames anzeigen, damit man kein Signal verpasst. Eben blos schlecht, wenn weitere Triggerereignisse im zu untersuchenden Signal folgen. Damit können durchaus je nach Länge des Signales verschiedene Darstellungen angezeigt werden. Je schneller die Anzeige ist und um so kürzer der Puffer im Verhältnis der Signallänge ist, umso mehr verschiedene Darstellungen des Signales können angezeigt werden. Nur war das eben nicht das von mir erwartete Signal "Triggern auf die ERSTE negative Flanke und Anzeige des ersten Teiles des Signals". Beim Single wird deshalb auch das erwartete Signal angezeigt, da nach dem Füllen des Samplespeichers nicht auf ein neues Triggerereignis getriggert wird. >> Die zwei anderen eben Richtig und Falsch. Das sollte also besser "Erwartet" und "Nicht erwartet" heissen. Bei langsamen Sampleraten dauert es eben länger bis der Samplebuffer gefüllt ist und eventuell passt das gesamte Signal in den Samplespeicher. Dadurch ergibt sich nicht die Möglichkeit einer erneuten Triggerung (hier bei 1s Impulsabstand und ca. 22,2ms Impulsfolgedauer). Also muss man hier besser SINGLE einstellen, um genau das Erwartete zu sehen. Sorry, man lernt eben nie aus :-) Beste Grüße und ein schönes WE Jürgen
Hallo Jürgen, ja das ist allgemein ein Systembedingtes Problem bei Oszilloskopen. Auch bei den alten analogen Geräten. Man hat immer eine gewisse Zeit in der das Gerät "blind" ist. Wenn es ungünstig läuft kommt das nächste Triggerereignis (Signalanfang) ausgerechnet in dieser Zeit. Da die Konstrukteure von Oszis dieses Problem auch schon recht früh erkannt haben gibt es die Holdoff-Time. Die kann man so einstellen, dass die "blinde Zeit" etwas länger wird, nämlich idealerweise so lang, dass der Trigger erst wieder nach dem letzten Signalteil scharf wird. So kann er dann wieder auf den nächsten echten Signalanfang triggern. Ob das bei unserem DSO so gut funktioniert wäre zu testen. Vielleicht kannst Du uns dazu Infos liefern? Dein Signal wäre ja der ideale Testprobant. Gruß Hayo
Hallo Hayo, genau in diese Richtung hatte ich gedacht. Ich werde die Holdoff Funktion etwas genauer mit dem Signal untersuchen. Gruß Jürgen
Hallo Hayo, die Holdoff Geschichte funktioniert bei unserem DSO so wie es sein soll! Du kannst nur in der Hardware Beschreibung mal korrigieren, daß das Holdoff Register doch nur 24 bit breit ist. Da ist es noch 32 bit breit. Damit ergibt sich bei 8ns Increment eine maximale Holdoff Zeit von 134,217 ms. Diese Begrenzung ist ja auch im User Interface so eingebaut (134,000 ms). Da gibts noch eine kleine Reserve :-) Der Pretrigger und die Anzeige ist ebenfalls ok. Schön wäre, wenn auch die Triggerpositionsauswahl "Fixed" oder "Constant" gespeichert würde und nach dem Einschalten entsprechend gesetzt wird. Gruß Jürgen
Ah ja, danke. Ich schau mir das mal an und korrigiere das. Gruß Hayo
Merry Christmas and happy 2016 to all Hayo and the dso team Let's hope that the new year will bring all the best and a new firmware! Sandro
And from me also a happy new year 2016 to all. The support for the hardware-mods and the BF-Firmware is still alive! If there are any questions or problems or maybe new ideas - post it here... Kind regards Hayo
Hallo liebe Freunde des Welec! Ich bin Besitzer eines W2024 und bis jetzt sehr zufrieden und finde euer Engagement bezüglich FW Erweiterungen bemerkenswert! Ich dachte nun, dass ich nach langem mal meine FW aktualisiere und bin von 1.2.BF.2.7 direkt auf die neueste 1.2.BF.7.13 umgestiegen. Folgendes Problem ist aufgetreten, die Nullpunkte stimmen nicht mehr, bzw. nur mehr auf der Null-Linie. Also verschiebe ich einen Kanal, dann verschiebt sich der Nullpunkt (wie wenn eine Skalierung nicht stimmen würde) - Kalibrieren hilft nichts. Habe dann verschiedene FW Versionen ausprobiert und bin da zu stehen gekommen, dass es bei meinem Gerät bis 1.2.BF.6.5 funktioniert, ab der Version 1.2.BF.6.6 aber nicht mehr. Ist das ev. wegen meiner HW-Version (8C7.0F), oder mach ich was falsch. Danke im Voraus für alle Antworten. LG Alfons
Nochmal Alfons! Vergesst bitte den obigen Beitrag, Hayo hats bereits oben beantwortet. Bin durch die vielen Beiträge erst jetzt drauf gestoßen. Pre Gain -> Factory war bei mir das Schlüsselwort. Danke
:
Bearbeitet durch User
Hi Alfons, ja das ist dem Einen oder Anderen auch schon passiert. Im erstem Moment nach dem Update denkt man nicht an die Hardwareeinstellungen... :-) Aber Du hast es ja selbst gefunden. Noch viel Spass Hayo
Hi, i have one question about sampling memory. Is there any way for using other memory on board like SDRAM to extend sampling memory buffer for slow speed (like 1MSps) or direct usb continuos reading to PC. Thanks a lot for best work firmware :)
Hi Sladjan, unfortunately the fast memory is limited to 4K for each ADC. This memory is directly coupled to the ADC (inside the FPGA). In Fast sampling Mode all four ADC are used in interleave mode - so there are 16K memory available. In slow sampling mode only one ADC is used, so there are only 4K memory available. Only in very slow sampling mode (USTB - ultra slow time bases) the samples are stored in the main memory and so there is a little bit more space. Without new FPGA-design there is no possibility to change this :-( Haye a nice week Hayo
Hayo W. schrieb: > Der Teufel steckt > aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler > jederzeit willkommen. Moinmoin Hayo & CO. hab seit laengerem nun wieder in Hardware zu tun und hab die 7.13 aufgespielt weil die 7.1 massive Probleme im Single mode hat, leider sind die geblieben nur geht der Quick Mess jetzt auch nicht mehr (Freq. messung) die Cursors haengen links am 'Anschlag'; (oder hab i die bedienung vergessen), vllcht kann das auch noch jemand hier mit der 7.13 testen, danke Hayo koenntest du bitte zumindest nach dem Single mode schauen, ist f. mich sehr wichtig vlG Charly *EDIT*: hab eben die FW nochmal geflascht, def.setup und jetzt geht die Freq. messung im Quickmess, was da vorher war, KA...... der Single mode ist aber immer noch nicht OK, was genau kann i noch nicht genau beschreiben, ein Problem ist zb. falls trigger auf auto steht u. man aktiviert den Single dann Triggert er wenn man die TB aendert.... nochmals vlG Charly
:
Bearbeitet durch User
Hi Charly, also aktueller Stand bei Dir ist, dass der Single Mode irgendwie Probleme bereitet - korrekt? Du weißt aber noch, dass es ein Submenü gibt in dem Du einige Einstellungen zum Trigger vornehmen kannst? Hast Du die Einstellungen mal gecheckt? Gruß Hayo
Nice to heard you again, Hayo!! :-) Have you some good surprise for us, about new version of firmware? Thanks again for your great work... Regards, Paolo
Hi Paolo, at the moment there is no active development of the firmware from my side. This is because the actual version is running fairly stable and as second reason I'm deeply committed in some Raspberry Pi projects - for example RPi as ADS-B flight radar or RPi as media player build in a JVC boom blaster and so on. But nevertheless I'm giving support for bugs or problems in the firmware or hardware. So if you have trouble with one of these - don't hesitate to report your problems here. I will try to help you with a new FW version or some new hardware hints. Kind regards to you and all WELEC owners Hayo
Hello guys,
for me it's time for a dumb question:
how is it possible to forecast the sample rate at a given time base?
For Welec's DSO the related formula should be
sample rate = memory depth/(time per division*12)
that doesn't match though.
On my W2012A I read
sample rate | time base
50Sa/s | 1s/div
1kSa/s | 200ms/div
100kSa/s | 2ms/div
250kSa/s | 1ms/div
500kSa/s | 500us/div
1MSa/s | 200us/div
25MSa/s | 10us/div
500MSa/s | 2us/div
1GSa/s | 20ns/div
1GSa/s | 5ns/div
and so on which doesen't fit.
What's the trick?
Thanks,
Pico
Hi Pico, the trick is to use oversampling. That means, that we read more samples than we need - except 50ns (which is 1:1) and 20ns/10ns/5ns/2ns (which is undersampling with interpolation). For example when we have 4 x oversampling - we are only using every fourth sample in the memory to display it on the screen. That gives us the possibility to "zoom in" in Stop-Mode or in Delay-Mode. Also this is the only possibility to get all needed timebases in spite of the very poor implemented ADC controlling unit in the FPGA. Hope that helps Hayo
Hello Hayo,
honestly I don't understand.
I meant the sample rate shown on the top of the screen.
I thought it was related to something calculated by the firmware.
For instance there is:
sample rate | time base
50Sa/s | 1s/div
1kSa/s | 200ms/div
100kSa/s | 2ms/div
250kSa/s | 1ms/div
500kSa/s | 500us/div
1MSa/s | 200us/div
25MSa/s | 10us/div
500MSa/s | 2us/div
1GSa/s | 20ns/div
1GSa/s | 5ns/div
Why by setting the time base for 200ms/div is shown 1kSa/s like sample
rate on the top of the screen?
Why 250kSa/s with 1ms/div?
Why is 1GSa/s by setting for 5ns/div and still with 20ns/div?
I guess that the firmware derives the sample rate from a formula, but I
don't know what formula.
Thanks,
Pico
The Sample rate gives the number of samples per second, while the time base gives the horizontal scaling of the waveform on the screen. These are different things. If you activate the "Delayed" presentation of the signal, you even can have two different time bases for a signale aquired with an identical sample rate. Tom
Hello Tom, I agree. But i think in the firmware have to be a formula that ties sample rate with the setting of the time base, that is what I'm talking about. I set the time base for 200us/div and so on the top of the screen it's shown 1MSa/s, I set for 20ns/div and it's 1GSa/s, still the same value for 5ns/div, while by setting time base for 1s/div it's instead 50Sa/s and so on. How the firmware choose the sample rate shown on the top of the screen? For me by a formula that I don't know. Thanks, Pico
Hello guys, just another question. I know it's already been discussed but I'm not sure of the right answer because it has been provided differently from time to time. About the FPGA revision in some occasions have been told that 8C7 is better than 1C9, in other ones that 1C9 is better than 8C7. Which of the two is more resistant to spurious spikes? Thanks, Pico
Hi Pico,
there is no formula inside of the firmware. This is controlled by table
entries. Here a piece of the code:
- the register values
const unsigned long tb_value[36] =
{
/*-------16Kb--------*/
0xFFFFFFFF, // 0 -> 2 ns
0xFFFFFFFF, // 1 -> 5 ns
0xFFFFFFFF, // 2 -> 10 ns
0xFFFFFFFF, // 3 -> 20 ns
0xFFFFFFFF, // 4 -> 50 ns
0xFFFFFFFF, // 5 -> 100 ns
0xFFFFFFFF, // 6 -> 200 ns
0xFFFFFFFF, // 7 -> 500 ns
0xFFFFFFFF, // 8 -> 1 µs
0xFFFFFFFE, // 9 -> 2 µs (500MSa/S)
0xFFFFFFFD, // 10 -> 5 µs (250MSa/S)
/*-------4Kb--------*/
0xFFFFFFFB, // 11 -> 10 µs (25MSa/S)
0xFFFFFFF3, // 12 -> 20 µs
0xFFFFFFE7, // 13 -> 50 µs
0xFFFFFFCE, // 14 -> 100 µs
0xFFFFFF83, // 15 -> 200 µs
0xFFFFFF06, // 16 -> 500 µs
0xFFFFFE0C, // 17 -> 1 ms
0xFFFFFB1E, // 18 -> 2 ms
0xFFFFF63C, // 19 -> 5 ms
0xFFFFEC78, // 20 -> 10 ms
0xFFFFCF2C, // 21 -> 20 ms
0xFFFF9E58, // 22 -> 50 ms
0xFFFF3CB0, // 23 -> 100 ms
0xFFFE17B8, // 24 -> 200 ms
0xFFFC2F70, // 25 -> 500 ms
/*------- USTB -----*/
0xFFFFFFFF, // 26 -> 1 s [USTB]
0xFFFFFFFF, // 27 -> 2 s [USTB]
0xFFFFFFFF, // 28 -> 5 s [USTB]
0xFFFFFFFF, // 29 -> 10 s [USTB]
0xFFFFFFFF, // 30 -> 20 s [USTB]
0xFFFFFFFF, // 31 -> 50 s [USTB]
0xFFFFFFFF, // 32 -> 100 s [USTB]
0xFFFFFFFF, // 33 -> 200 s [USTB]
0xFFFFFFFF, // 34 -> 500 s [USTB]
0xFFFFFFFF // 35 -> 1000 s [USTB]
};
- and the text output
unsigned char SampleRateData[36][11] =
{{"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "},
{"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, //interpolated / normal
{"1 GSa/s "}, {"500 MSa/s "}, {"250 MSa/s "}, {"25 MSa/s "}, {"10 MSa/s
"}, {"5 MSa/s "}, {"2.5 MSa/s "}, {"1 MSa/s "}, //normal
{"500 kSa/s "}, {"250 kSa/s "}, {"100 kSa/s "}, {"50 kSa/s "}, {"25
kSa/s "}, {"10 kSa/s "}, {"5 kSa/s "}, {"2.5 kSa/s "}, //normal
{"1 kSa/s "}, {"500 Sa/s "}, {"50 Sa/s "}, {"25 Sa/s "}, {"10 Sa/s "},
{"5 Sa/s "}, {"2.5 Sa/s "}, {"1 Sa/s "}, {"1 Sa/2s "},//USTB
{"1 Sa/4s "}, {"1 Sa/10s "}, {"1 Sa/20s "}};
And to your question about the FPGA version - 8C7 is the better choice. If someone have problems with his 1C9, there is the possibilty to change the version to 8C7. All you need is an Altera byte blaster clone (for < 10€) and the Altera programming software. Hayo
Hello Hayo, thanks, finally I get it! So ultimately it's a parameter taken from a table that decides the label on the top of the screen for the sample rate versus the time base. For me it's a useful thing to know. Thanks also for your reply about the better anti-spikes FPGA design. Honestly by reading the forum sometimes it's said that 1C9 is better than 8C7 and other times the reverse. Your post clarifies the issue once and for all, even if actually it isn't exactly what I was hoping for because my oscilloscope has the 8C7 and it isn't so resistant to the spikes. Pico
Yes the 8C7 also can have some problems with spikes. This seems to be a thermal problem. The 2 channel version has less problems than the 4 channel version. Optimizing the thermal design (like in my mod guides) can help to minimize these problems. The original build in fan has nearly no cooling effect. So it is recommended to change it against a better one. Doku and all other stuff can be found here: https://sourceforge.net/projects/welecw2000a/files/ Hayo
Hallo Hayo, bezüglich Sampleraten ist die alte Hardware meine ich noch nicht ausgereizt. In meinen Experimenten mit OSOZ auf dem alten FPGA habe ich keinen solchen Sprung von 250 MSa/s auf 25 MSa/s beobachtet. Die Werte dazwischen sind zugegeben aber recht krumm. Siehe CaptureSetTimebase() in osoz/platform/nios/capture.c Die Hardware hat erstmal einen "exponentiellen" Einstellbereich, wo sich bei jedem Registerschritt die Abtastrate halbiert. Ergibt 1GSa, 500MSa, 250MSa, 125MSa, 62.5MSa/s. Alle 4 ADCs und die volle Speichertiefe gibt es nur bei den beiden schnellsten Raten. Dann kommt ein schier endloser "linearer" Einstellbereich wo sich der Teiler mit jedem Registerschritt um 8 erhöht. Das ergibt Abtastraten von 31,25MSa, 25MSa, 20,83MSa, 17,86MSa, 15,625MSa, 13,89MSa, 12,5MSa, ... Mit dem neuen FPGA wird das besser. Vor allem steht immer die volle Speichertiefe zur Verfügung, bei Nichtbenutzung des anderen Kanals kriegt man dessen Speicher sogar noch hinzu. Für die Abtastraten siehe die Schwesterdatei osoz/platform/nios2/capture.c, gleichnamige Funktion, sowie die Tabelle gDecimations[]. Grüße Jörg
Hello Hayo, my DSO already has the thermal improvements described in the forum but spikes are a pain in the back because you never can know if they are real or artifacts. Pico
Hello Jörg, this means that somewhere there is an alternative design? Where? Thanks, Pico
I shoudn't advertise it, since it's kind of abandoned. I haven't worked on it since almost 3 years (just checked), no free time in sight. This is the thread about it: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Originally started as just a new software, then on mid 2012 it turned into a new FPGA design, too. Some coverage in the hardware thread, too: Beitrag "Wittig(welec) DSO W20xxA Hardware (Teil 2)" Jörg
Hi Jörg, ja das Thema mit der Samplerate hatten wir schon mal vor einiger Zeit. Ich hatte daraufhin das OSOZ-Coding geprüft und festgestellt, dass die 125 und 62,5 nur softwaremässig implementiert waren. Für diese Samplingraten gibt es aber (meines Wissens) keine Registerwerte die die ADC auf diese Rate einstellen. Falls ich mich da täuschen sollte bitte ich unbedingt um Hinweise. Dann würde ich da nochmal was nachrüsten. Aber - wo Du das alternative Design ansprichst - wie ist den der Stand der Dinge? Bist Du da noch dran? Oder ist das in Dauerparkposition? Ohh, sehe gerade dass sich das mit Deiner Antwort überschneidet. Du warst ja schon mal an einem sehr vielversprechenden Punkt... Schon dieser Stand wäre mit etwas zusätzlicher Peripherie um Lichtjahre weiter als das derzeitige Factory-Design. Hayo
:
Bearbeitet durch User
Hi Pico, did you adjust the settings in the hardware setup? There are factory and highspeed settings that may cause different behavior. Do you own a 4 channel version? Hayo
Hi Hayo, I did but still the problem is there. As suggested in the forum I have to put time for trigger out of the viewable area of the screen even if me I don't like it much. It's known that most likely spikes are near trigger event. Pico
Hi Pico, can you upload a screenshot with an example? That may help to identify the problem. Preferred a typical situation of measuring with this spikes. Hayo
Angehängte Dateien:
-
ATR_SLE4442_digital.jpg
51 KB -
ATR_SLE4442_analog.jpg
46 KB -
MSO.jpg
160 KB -
CORRUPTED_1.jpg
88 KB -
CORRUPTED_2.jpg
90 KB
Hello folks. It is a long time that I didn't set foot here. Lately I'm debugging a device for a friend of mine so I want to show how a Welec DSO can be used as MSO oscilloscope. So here you go a couple of pictures showing my W2012A_OPA653_MOD when compared with a logic analyzer while it's acquired the ATR response of a 4442 chip card using digital and analog trigger on Welec. As it's possible to see it works great. I did notice a little problem though. In my W2012A is installed the latest firmware 1.2.BF.7.13C2 and when using zoom by DELAYED button with some time base's values I get garbage on the screen. It seems that something is wrong with the memory used for the captured waveforms. Hardware is good, any fault, being that the problem only emerges using DELAYED feature. Could it be a firmware issue? Thanks! mark
Hi Mark, yes indeed I think you are right and this is a firmware issue. The digital mode function seems to be tested not so good as the other parts. I think it is used not so often - especially the delayed function. Due to that this failure has not been detected yet. If I find some time for that I will try to fix it. Thanks for reporting Hayo
Hello Hayo, thanks! In my opinion digital mode function works great, the only problem is in DELAYED function, in fact the garbage appears with both digital and analog representation. I don't want to abuse your time but I have some questions that I'd like to have an answer from you as soon as the time will allow it to you. 1) Are EXT Trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. 2) Are SINGLE mode trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. I guess due the well known issue of noise that plagues the Welec DSO's I have many random trigger acquisitions even when real one isn't present. 3)Would be possible add a new DIGITAL function that allows for the same rappresentation on the screen as the usual ones togheter with the chance to adjust the thresholds of the triggering action? I understand that make no sense because DIGITAL trigger have their own levels. I mean rappresntation of the waveforms on the screen though, something like FILTERS in AQUIRE menu, don't a real DIGITAL trigger as those already allowed in the firmware. Course I'm not in a hurry either for this questions than for the fix of the issue I have written, answers well when you have the time and mood, I repeat there is no rush. Thanks. mark
Angehängte Dateien:
-
screen-0001.JPG
150 KB
Hi to all , I confirm that the last firmware is good for spike triggering with CAN automotive signal, as enclosed image, but that improvements for digital may help. Let's wait for Hayo and the team amazing news. Best 2017 to all of you. Sandro
Hallo, ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. Wegen der bekannten Probleme stand es bei mir jahrelang nahezu ungenutzt herum. Nun bin ich endlich dazu gekommen, die neueste BlueFlash Firmware 1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank an alle Beteiligten für die große Mühe! Leider zeigen sich zuweilen immer noch die lästigen Spikes. Eine Einstellung im ADC Setup auf HighFreq 1 bringt schon einiges. Im Forum habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo das benötigte File für diese Version. Könnte mir jemand einen Link benennen? Vielen Dank! Dietmar
Hallo Dietmar, das File kann sicher einer unserer FPGA Spezialisten hier zur Verfügung stellen. Notfalls müsste ich mal meine Archive durchstöbern oder von meinen Geräten eine Kopie runterziehen. Evtl. die Anfrage nochmal im Hardware- Thread wiederholen. Wenn keiner der Anderen helfen kann, sag noch mal Bescheid, dann muss ich mich mit dem Altera-Programm noch mal beschäftigen - ist schon etwas her, dass ich das benutzt habe. Gruß Hayo
Ich habe die Version, kann ich einem "Gast" aber nicht schicken. Bitte anmelden/einloggen. Ist ein ByteBlaster vorhanden? Man kann auch den USB-Chip mit einer entsprechende Firmware ausstatten. Jörg
Hi, auf die Schnelle habe ich folgendes File für den EP2C35 gefunden. Das könnte es sein, soweit ich mich erinnere. Im Hardwarethread hatte glaube ich auch mal jemand etwas hochgeladen. edit: Oh hallo Jörg, Du warst schneller als ich...
:
Bearbeitet durch User
Hallo Jörg, vielen Dank für dein Angebot. Ich habe mich gerade am Forum angemeldet und es wäre nett, wenn du mir das File zur Verfügung stellen könntest. Ein Altera USB-Blaster incl. Quartus-Software ist vorhanden. Grüße Dietmar
Hallo Hayo, auch dir vielen Dank! Ich werde von meinen Versuchen berichten. Grüße Dietmar
Hallo Hayo, darf ich mich anschließen, mit den Files. Ich besitze aus einem Nachlass auch jetzt auch noch ein W20xx ohne A. Nach den ersten Test war die Freude dann schnell am Ende. Ich fand dann den Thread hier, leider sind viele Links doch schon offline. Hast du noch die Files local bei dir ? Ich muss ja erstmal ein A aus dem DSO machen. Würde mich sehr über Hilfe freuen. VG Chris
Hi Chris, bin gerade aus dem Urlaub zurück und muss mich hier erstmal etwas sortieren. Aber ich schau mal was ich für Dich tun kann. Wegen der Files am Besten noch mal bei Jörg anfragen, seine Files sind auf jeden Fall die richtigen und er kann Dir auch in Sachen FPGA-Programmierung am Besten weiterhelfen wenn Du da Fragen haben solltest. @Jörg vielleicht kannst Du die Files ja im SF-Repository unter https://sourceforge.net/projects/welecw2000a/files/ ablegen? Dann hätten wir die an einer zentralen Stelle verfügbar. Gruß Hayo
:
Bearbeitet durch User
Vielen Dank, ja ich bin ein blutiger Anfänger. Habe nur soviel verstanden das man den Treiber bei Windows irgendwie trauschen muss. Dann tut der Wittig so als wäre er ein Programmer und dann dann sollte man das FPGA Programmieren können. Alles andere geht ja dann über den GERM und dem Welecupdater. Habe ich das soweit richtig verstanden? Chris
Ja ist soweit korrekt. Für die FPGA-Programmierung hab ich mir für unter 10,- einen Blasternachbau in der E-Bucht gekauft da der Treiber bei meinem Windows einfach nicht funktionieren wollte. Damit geht es auf jeden Fall - auch unter Linux. Dann brauchst Du eine Altera Installation um das FPGA (bzw. den Speicher) zu programmieren. Kann man kostenfrei runterladen. Die Anleitung zum Upgrade auf den A Typ muss ich noch mal raussuchen. Bist Du wirklich sicher, dass Dein Teil kein A ist? Auf dem Gehäuse steht das nämlich nirgends drauf - da steht immer nur W20xx ohne A. Gruß Hayo
Vielen Dank, den Blasternachbau habe ich mir jetzt für 3€ gekauft. Weil ich die treiber auch auf teufel komm raus weder unter Windows XP noch unter Windows 7 schaffe zu wechseln. Ja es ist eines ohne A, W2012 Software 1.00.08 / Hardware 3C7.0H Wird wohl eines der ersten sein. Chris
Ok, ich habe auf SF hochgeladen was ich so in Kürze finden konnte: https://sourceforge.net/projects/welecw2000a/files/Hardware/ Hier findest Du im Verzeichnis "Original" einiges an Doku und darin im Verzeichnis "FPGA" auch einige Altera Source Files. Auch dokumentiert ist die JTAG Steckleiste (es sind nämlich zwei identisch aussehende Steckleiseten vorhanden. Weiterhin ein Bild mit der Überbrückung am JTAG - wobei ich mir nicht mehr sicher bin ob man das für den Hardwareblaster auch braucht oder nur für den Softwareblaster. Vielleicht weiß das noch jemand. Notfalls schau ich bei mir noch mal rein. Im "Modification" Verzeichnis habe ich die Anleitung zum Upgrade auf "A" hinzugefügt. Ansonsten einfach hier nachfragen. Hayo
Vielen Dank, nun muss ich noch warten bis er aus China bei mir ankommt. Dann kann ich starten :-)
Morgen Hayo, demnach lade ich dann die W2022A.jic datei in den 2012 und danach mit dem welecupdater die Firmware ? Habe ich das so richtig verstanden ?
Ja, nach dem Umschießen des FPGA sollte der GERMSloader funktionieren und Du kannst dann mit dem beiligenden WelecUpdate.exe die Firmware reinladen. Die Prozedur mit den beiden F-Buttons kennst Du? Die ist ansonsten auch im Doku-Verzeichnis der Firmware beschrieben. Hast Du in der Anleitung zum Update auf "A" gesehen, dass Du auch noch einige Kleinigkeiten auf dem Mainboard umlöten musst? Ansonsten gibt es einige kleine ungefährliche Fehlfunktionen. Du kannst aber trotzdem erst das Firmwareupdate machen bevor Du da was umlötest. Dann kannst Du das Ergebnis besser checken - der nutzbare Screenbereich ist nämlich in der BF-Firmware größer. Hayo
Ja, das mit dem Löten habe ich in der Anleitung das ist ja wirklich sehr entspannt. Warte jetzt auf den Flashe und wenn es noch Probleme gibt melde ich mich, kann ich den Wittig eigentlich bricken oder ist es mit dem Blaster nicht möglich ?
Meines Wissens kein Problem, natürlich erstmal eine Sicherung vom Original ziehen bevor man loslegt - aber eigentlich kann man nix kaputt machen. Wenn das neue Build nicht läuft - einfach das Backup wieder einspielen, dann ist man wieder am Anfang. Allerdings muss man sagen, dass der Originalzustand nicht allzuweit von "kaputt" entfernt ist... Daher ist alles was einen irgendwie davon weg bringt ein Fortschritt :-) Hayo
:
Bearbeitet durch User
Ja Hayo, da gebe ich dir recht, schlimmer kann es nicht sein. Dann warte ich jetzt auf den Blaster und hoffe das es nicht zu lange dauert, jucken tun schon die Finger.
Sitze noch ein bisschen am Wittig, hat jemand ein tip wie man die Treiber wechseln vom Wittig. Es wird immer nur der HID Installiert ein aktualsieren endet mit der Meldung das der beste Treiber schon Installiert ist.
Das ist ja ein nicht ganz neues Problem... Schau mal im Hardware Thread im ersten oder zweiten Teil nach. Hier geht es z.B. auch um das Thema Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Vielen Dank, bevor ich alles zerlege wollte ich noch wissen wo ich U21 bzw. U23 finde. Ich habe keine Beschriftung auf der Platine finden können. Grüße Chris
Hi Chris, lade Dir das Dokument - Analog-Input-Part_assignment_V3_4.pdf - aus dem Sourceforge Verzeichnis herunter. Dort ist sowohl der Schaltplan als auch ein Bild mit der Position enthalten. Du musst dazu die Hauptplatine ausbauen, da die Teile auf der Rückseite liegen. Anleitungen zum Zerlegen gibt es in einer der Modifikations-Anleitungen - ebenfalls im SF-Verzeichnis. Gruß Hayo
:
Bearbeitet durch User
Ich wollte noch wissen, wenn ich den Blaster an den JTAG Port vom Wittig hänge, muss das Wittig dann eingeschaltet werden oder versorgt der Blaster den FPGA mit dem entsprechenden Strom? Als Treiber für den Blaster nutze ich dann den "USB_Blaster_for_W2000_v1.1" oder habe ich das falsch verstanden ? Chris P.S. den Treiber habe ich bisher weder unter Windows XP noch unter Windows 7 geschafft zu tauschen. Warte jetzt auf den Blaster.
Hi Chris, die FPGA müssen über die eigene Stromversorgung versorgt werden - also einschalten. Wenn Du einen Hardware-Blasternachbau verwendest brauchst Du diesen Treiber nicht, der emuliert nur den Altera-Blaster über die USB-Schnittstelle. Wenn Du den Blasternachbau verwendest, musst Du den Treiber für den Blaster in der Altera Software auswählen. Die Software steuert den Blaster dann direkt an. Gruß Hayo
Danke, aber heute habe ich nun geschafft den Treiber in WIndows XP zu wechseln so das der Wittig jetzt als Altera USB-Blaster erkannt. Soweit so gut nun suche ich den Altera Programmer, auf der Altera Seite habe habe mehre Versionen vom Quartus Programmer gefunden, leider laufen die nicht auf Windows XP. Gibt es ein Link oder hat jemand noch eine Version welche unter XP läuft. Grüße Chris
Bin jetzt weitergekommen, den Quartus II 10.1 Web Edition habe ich im Programmer kann ich auch den Nios II Ev. Board an USB-0 auswählen. Wobei im Geräte Manager steht ja Altera USB-Blaster. Ich habe auch ein Backup versucht aber es kommt "Error : Can't access JTAG chain". Habe ich da jetzt noch etwas übersehen ? Grüße Chris
Angehängte Dateien:
-
Altera_Blaster.jpg
210 KB -
JTAG.jpg
210 KB -
JTAG_Bruecke.JPG
73 KB
Hallo Chris, hast Du an die 0 Ohm Brücke am JTAG gedacht? Hayo
Nein, dachte das brauch ich nur wenn ich den Blaster nutze. Habe es jetzt per USB direkt am Wittig probiert, also USB Kabel am Wittig, Treiber Installiert und dann mit dem Quartus II probiert. Der USB-Blaster wird ja leider noch dauern bis er auch China da ist.
Beim Stöbern bin ich auf den Originalbeitrag getstoßen - da sind die Details noch etwas besser nachvollziehbar: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Hayo
Danke für den Link, leider könnte ich da nichts finden was mein Problem beschreibt :-( oder ich stehe da noch mächtig auf dem Schlauch. Dann werde ich wohl noch einige Wochen warten müssen bis der USB Blaster kommt :-( oder hast du da noche in Tip. Denke soweit bin ich vom Ziel noch nicht entfernt.
Hallo Hayo, jetzt hab ich es geschafft das es geht, lag am USB Switch. Direkt läuft das flaschen gut. Habe dein File "W2022A.jic"was du hochgeladen hast rein geflasht. Sollte beom booten jetzt nicht 2012a stehen? chris
Entscheidend ist die angezeigte Hardwareversion - hier sollte optimalerweise 8C7.xx erscheinen. Nicht so gut wäre 1C9.xx - aber beides sind W2000A Versionen. Wenn beim Booten weiterhin Deine alte Hardwareversion angezeigt wird, ist was schiefgelaufen. Gruß Hayo
Hallo Hayo, wollte gerade rückmeldung machen, alles gekappt jetzt läuft die neue Firmware. Danke für deine Hilfe.
Aber immer gerne :-) Viel Spass mit der neuen Firmware - da gibt es viel zu entdecken... Hayo
Da hast du recht, schon einiges gesehen und sehr überrascht. Kann man eigentlich auch daa DSO mit dem Computer bedienen bzw. ist dieses geplant ? Chris
Aber klar doch! Du brauchst dazu ein Terminalprogramm (so wie Teraterm oder Hyperterminal) das sich über die RS232 seriell mit einem anderen Gerät unterhalten kann. Näheres zu den Einstellungen findest Du im Doc Verzeichnis der Firmware. Beim Starten des DSO siehst Du dann schon die Textausgaben. Mit den entsprechenden Tastendrücken lässt sich alles Mögliche an und abschalten. Es gibt auch ein Screenshotprogramm, das den Screeninhalt auf den PC überträgt. Alles natürlich über RS232. Hayo
Hallo zusammen, wie hier Beitrag "Oszilloskop Wittig/Welec W2024A vs. Rigol DS1054Z" schon erwähnt, habe ich mir jetzt auch die aktuelle Firmware auf mein W2024A geflasht. Das ganze habe ich am Mac unter OS X (10.11) durchgeführt, deshalb hier etwas ausführlicher was dazu nötig ist - vielleicht hilft es jemand anderem auch. Benötigt wird ein USB-Seriell Interface; ich hatte noch ein Keyspan USA-19HS und musste lediglich die Treibersoftware installieren. Das Keyspan hat direkt eine Male DB9 Buchse und könnte damit direkt angesteckt werden, klappt aber wegen den versenkten Buchsen nicht. Habe dann mit zwei hintereinander gesteckten Gender-Changern verlängert. Für einen ersten Kommunikationstest noch mit der Original Firmware habe ich CoolTerm verwendet. Gibt's als Freeware. Passenden Seriellen Port ausgewählt, Parameter auf 115200, 8 N 1 - connect und hoffnungsvoll ein 'h' gedrückt. Erfolg, die Kommunikation klappt. Dann kann ja die Firmwareinstallation auch nicht mehr so schwer sein. Das Terminal gestartet, und erst mal mit # sudo cpan Device::SerialPort das fehlende Perl Modul nachinstalliert. (Muss als root gemacht werden) Dann alle erforderlichen Files - GERMSloader.pl - TomCat.flash - TomCat.ram in ein Verzeichnis kopiert und mit cd dorthin wechseln. # ls /dev/{tty,cu}.* zeigt an, auf welchem Device das serielle Interface hängt, bei mir /dev/tty.KeySerial1. Als Angsthase habe ich dann erst mal die Original Firmware gesichert: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -r ./Backup_Welec2024A_Orginal Script läuft los und zeigt an, dass es wohl einige tausend Sekunden dauern wird. - Also, frischen Kaffee machen und abwarten. - Zum Schluss dann diese Meldung: * --- Backing up firmware from 00040000 to 007fffff... * Successfully read out firmware in 2473.1 seconds! * Writing firmware to ./Backup_Welec2024A_Orginal... und im Verzeichnis das File mit 4,7 MB Größe. Na wenn das klappt, könnte ich ja mal die neue Firmware wenigstens in den RAM schreiben: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -w ./TomCat.ram * --- Writing GERMS firmware... * Writing line 029946 of 029946: S8 detected, end of GERMS transmission. * Successfully wrote GERMS firmware in 210.6 seconds! * Please reboot DSO if it didn't restart automatically. * * READY! * Thanks for all the fish. Ohne Reboot des Welec wurde nach kurzen Flackern ein Laufbalken angezeigt, das verschiedene Werte neu geschrieben werden müssen. Hat rund 10 Minuten gedauert und danach konnte ich die neue Firmware ausprobieren. Macht einen wesentlich besseren und bedienbareren Eindruck; die Kommunikation per seriellem Interface und Terminalprogramm klappt auch. Nachdem bis hier keine Probleme aufgetreten sind dann gleich Nägel mit Köpfen gemacht: # perl ./GERMSloader.pl -d /dev/tty.KeySerial1 -w ./TomCat.flash Ging auch gut und nach einem Reboot habe ich jetzt die aktuellste Firmware am Start. Vielen Dank an Hayo und alle anderen die das alles ermöglicht haben. Ein schönes Ostergeschenk! :-) Werde mich dann mal intensiver mit dem „neuen“ Oszilloskop befassen und bei auftretenden Fragen zurückmelden. Viele Grüße aus Franken NormalZeit
:
Bearbeitet durch User
Vielen Dank für die Info. PS: Nach dem Firmwareupdate hatte ich Probleme mit einen scheinbaren GND-Offset. Check mal ob Utility -> More -> Hardware -> Pre Gain Factory auf Factory steht. das steht bei einigen fälschlicherweise auf OPA653 o.ä.. Auch so lohnt es sich mal die Setups nach dem Firmware zu erkunden.
Ja, der Ground Offset hat mich zuerst auch irritiert. Nach dem Check aller Setups hat sich das aber schnell geklärt. Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran.
Gerhard J. schrieb: > Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das > Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, > Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem > Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran. Zum Screenshot kann ich leider nichts sagen, ich bin inzwischen dazu übergangen den Screen mit dem Smartphone abzufotogtafieren und dank Dropbox etc ist der Ausdruck 1-2-3 auf dem PC und wo ich ihn sonst brauche. Da geht mir einfache von der Hand als mit USB-Stick etc.. Allerdings muss das Bild nach nachgearbeitet (beschnitten) werden.
Nicht, wenn Du es mit der App CamScanner mit dem Smartphone abfotografierst. Die App schneidet es automatisch auf den Bildschirm! Anschließend kannst es als jpg abspeichern und mit Share auf die Dropbox laden. Mach ich seit langem so, geht genial einfach, nur so als Tipp.
Gerhard J. schrieb: > Ja, der Ground Offset hat mich zuerst auch irritiert. Nach dem Check > aller Setups hat sich das aber schnell geklärt. Hallo Gerhard, wie Du schon herausgefunden hast, müssen die Einstellungen im Hardwaresetup erst korrekt eingestellt werden und dann eine Kalibrierung durchgeführt werden. > Aktuell versuche ich noch vernünftig einen Screenshot hinzubekommen. Das > Unix Programm im entsprechenden Verzeichnis läuft unter OS X nicht, > Fehlermeldung "cannot execute binary file" und neu kompilieren mit dem > Makefile klappt auch nicht. Da muss ich am Wochenende nochmal ran. Das Screenshotprogramm ist aktuell nur für Windows und Linux ausgelegt. Ich vermute, dass es aber auch ohne viel Aufwand auch für den Apple angepasst werden kann. Falls es Dir gelingt, wäre es nett wenn Du es hier zur Verfügung stellst. Gruß aus Südamerika Hayo
Hello folks. Simply as reference, I spotted that the 20MHz bandwidth limit function doesn't works into the latest firmware 1.2.BF.7.13C2. My DSO is a W2012A_OPA653_MOD and I tested the thing by measuring a sine wave signal of about 90MHz with and without inserting 20MHz bandwidth limit. When 20MHz bandwith limit is selected I espect some attenuaton on the signal drawn on the screen because of the 20MHz reduced bandwidth while measuring a 90MHz signal, but the signal drawn on the screen doesn't change not even a bit, it's the same as for full bandwidth. No any filters applied in "Aquire" menu. Thanks! mark
Hi Mark, thank you for reporting. Did you check this on an older firmware version also? I will try to find out if this is an original WELEC hardwarebug or if the switch is not working correctly due to firmware changes. Regards Hayo
Hi Hayo and Mark, I checked with firmware 1.2BF7.10 C2 and works properly. But some bugs with this version, changing the probe settings from 1:1 to 10:1 doesn't effect the level reading. Also, the deltaY cursors readings are always zero. Regards, Sandro
Angehängte Dateien:
-
20MHz_Full.jpg
51 KB -
20MHz_BW_Limit.jpg
49 KB -
100MHz_Full.jpg
63 KB -
100MHz_BW_Limit.jpg
51 KB
mark schrieb: > Hello folks. > Simply as reference, I spotted that the 20MHz bandwidth limit function > doesn't works into the latest firmware 1.2.BF.7.13C2. Hi Mark, I found some minutes time to check your reported problem today. I checked with 2 channels 653-Mod and 4 channel LB-Mod both with latest firmware. I measured on channel 1 only. Frequencies are 20MHz (as reference) and 100MHz with a Leader 3216 signal generator as source. Hardware setting is on "High Frequency 1". Find attached the screenshots I made. As you can see it works as it should and there is only a little attenuation at 20MHZ. At 100MHz there is a great attenuation - as it should be. So the question is what's going wrong with your DSO? Maybe something with your mod? Regards Hayo
Hello Hayo. Thanks for having spent some of your free time on it. Maybe it's really the OPA653_MOD I did, even if it would be weird since all is good with it, unless some garbage on the screen while using DELAYED function and ZOOM, but the 20MHz bandwidth limit function doesn't works. I spotted the issue by measuring an about 90MHz signal a bit dirty, so I thought to clean up inserting the 20MHz bandwidth. I'll dig the matter and if I'll find something wrong I'll post Thank you very much. mark
Angehängte Dateien:
-
Ricev._rc_003.jpg
220 KB
Hi Mark, if the noise you may want to reduce,like a modulation, is within 20 MHz BW inserting the filter don't effect the signal quality. Please see the enclosed photo using a spectrum analyzer. I made the OPA mod and works good up to 250 MHz, also tried others ic's OPA from TI , but this is the hardware limit. So I'm thinking another HW improvement, meanwhile may be Hayo like to update the firmware. Regards, Sandro
Hello Sandro. Thank you for your hint. I had the need to attenuate some high frequency spurious signals while measuring low speed enable signal. As reference something like measuring a 100 kHz square wave which turn on/off continuously a 100MHz sine wave, insertion of the 20MHz bandwidth limit doesn't works there. I have to dig further because could be even possible that in some circumstances it does works correctly just like Hayo wrote. Me too I made the OPA653_MOD. Interesting what you wrote, from my side i can't exceed 180MHz within 3dB bandwidth. Surely I can reach 250MHz like you wrote but in my case attenuation is much more than 3dB. With OPA653_MOD I have a 3dB bandwidth limit up 180MHz, going up the attenuation increases fast over 3dB. Where you wrote 250MHz do you mean the 3dB flatness limit or simply triggered signals shown on the screen without regards the bandwidth within 3dB? What hardware improvement are you thinking about? Thanks! mark
Hi Sandro, hi Mark, if there is the need of firmeware adjustment due to a hardware improvement I will do it! So if you have any idea to make things better - let's see how we can work together. Hayo
Hello Hayo. Thank you for the support. Hardware side I don't know. In my opinion Low budget mod and better OPA653_MOD are good enough and very simple to do without any need for something else. Of course if something new will be provided it will be carefully evaluated as always it has been, so any new idea there it's wellcome. Still for the hardware side I think that rather than work for improving bandwidth it would be better put the eyes on the trigger stability and steady waveforms shown on the screen. It's useless reach high value for the megahertz bandwidth if then trigger ability doesn't allow to acquire correctly the waveforms under measure. The 150MHz bandwidth offered by Low budget Mod and OPA653_MOD (actually about 180MHz as I measured with OPA653_MOD) are enough based on the weakness of the trigger and the instability of the waveforms displayed on the video which sadly are always dancing over the screen. It's even to consider that anyway on the screen the waveforms representation is rather crude compared to other DSO of the same kind especially for high frequencies and hence by using fast time bases. By the software side as first step it might be useful to try to correct the memory problem where some garbage appears on the screen while using zoom in DELAYED mode with some ranges of time base. Then, being dreaming I would suggest some things already asked by others in the past: 1) Maybe simple to do, put a warning on the screen in order to signaling when persistence is on. 2) Maybe hard to do, allow for uncalibrated VOLTS/DIV knob in order to fine scale waveforms on the screen instead of the only normal coarse scale. Since into hardware menu it's possible to adjust the gain of the input stage the matter would be to put the same function in the VOLTS/DIV management. 3) Perhaps even harder to do, set overlay function so that it acts just like the pass/fail mask testing from LeCroy. An easy way or better a simplified version of it could be allow for fine vertical and horizontal positioning of the overlay waveform so that it's possible overimposed it exactly anywhere on the screen that anyway it would be very hard to reach. That's all, but I'm just dreaming. mark
Hi Mark, unfortunately I have restricted access to internet until end of next week. I will answer in detail later. Hayo
Angehängte Dateien:
-
250_MHz.bmp
900 KB -
250_MHz.jpg
56 KB
Hi Hayo and Mark, yes I confirm the level is correct -3dB and trigger stable at 250 MHz,picture enclosed.But 180 is also good. I tested the trigger from 50 MHz to 250 and sometimes could be better as Mark reports.Hayo can say if is plan. I'm glad to partecipate to HW improvements,now is early will discuss later. Frequency flatness is tested with 50 ohms termination and synth. generator. Regards, Sandro
Hello Sandro. Thank you for the pictures. I agree 180MHz is good but your 250MHz @-3dB is terrific. It means the starting signal from the output of the leveled sine wave generator was -10dBm (0,20Vpp) while your Welec captured it as -13dBm (0,14Vpp). Really excellent result, congratulations Sandro. No, mine isn't so good. Me too at job I have a leveled sine wave generator and 50ohm terminations but I reach only about 180MHz within 3dB bandwidth flatness. Anyway I confirm that 250MHz are possible for sure with OPA653_MOD because with my Welec I could capture signals similar to yours, of course with greater attenuation though. Next days I'll take some picture and I'll put it here. @Hayo OK, thanks. I'll waiting for your answers mark
Hello Sandro. Sandro schrieb: > I checked with firmware 1.2BF7.10 C2 and works properly. > But some bugs with this version, changing the probe settings from 1:1 to > 10:1 doesn't effect the level reading. Maybe the latest 1.2.BF.7.13 already has the fix for the issues you wrote, cause I don't see them. @Hayo Anyway about what I wrote about the 20MHz reduced bandwidth feature, I'm totally wrong, my fault, sorry. The fact is that I expected roughly 100MHz sine wave when actually due an hardware failure there were only roughly 20MHz! This explain because the button for 20MHz bandwidth limit apparently doesn't work while actually it does!!! I'm really very, very sorry expecially for Hayo. mark
Hello folks. Today I spent the afternoon doing measures in order to document the bandwidth of my Welec and some other things. Well, or it should be better write bad, I had took a bunch of pictures directly storing them into the DSO but now I noticed that none of them has been correcly stored, it isn't possible recall not even one of them all. On my Welec there is the latest firmware 1.2.BF.7.13C2 and seems that memory function doesn't works as expected. I had also noticed that the label for linear interpolation or sin (x)/x in some case doesn't appears so that it's difficult know which of the two options is selected. By using the leveled signal generator I evaluated precise bandwidth of my W2012A_OPA653_MOD which it's resulted to be about 220MHz rather than 180MHz. The fact is that the representation of the signals on the screen it's very crude so that isn't simple evaluate their amplitude, honestly it's even much difficult understand their real shape even knowing that on the output of the leveled signals generator there are only sinusoidal waveforms. I also could see a 250MHz sine wave even if it was quite attenuated. Anyway strangely enough 230MHz sine wave was much easy than 240MHz, 230MHz and so on. The shape of the 250MHz sine wave was pretty good ,while going down to 245MHz or less it worsened it becoming very hard to recognize. Shape of the waveforms is however barely recognizable unless they are quite low frequencies and in any case always they are dancing on the screen. Thing are better by inserting filters in aquire menu but still not firm enough. one important thing I wanted to check it out is the right value of the Vrms quick measure but sadly all my pictures have gone missing. Quick measure on the screen were frequency, Vpeak-peak and Vrms, the leveled sine waves generator was set for -10dBm (0,20Vpek-peak, 71mVrms). Maybe next time. 20MHz bandwidth limit works fine as expected, no issue there. mark
Hi mark, what do you expect sampling a 250-MHz-Signal with 1 GS/s, as long as the Welecs sampling is far from perfect? So, what you see is ok.
Hello Guido. I'm expecting nothing, in fact I wrote my W2012A_OPA653_MOD stops very soon than 250MHz. Talking about -3dB flatness bandwidth my unit reach 220MHz but actually the usable limit is about 160-180MHz due poor trigger and crude rappresentations of the acquired waveforms and their stability. When the actual shape of waveforms are barely recognizable then bandwidth limit is the last of the problems, flying over the trigger's weakness, and I was already aware of all that, nothing new. That isn't the point. Since Sandro's statements I thought my DSO has some faults, perhaps something is wrong with how I made OPA653_MOD, so I wanted to compare it with Sandro's pictures. I'm pretty sure nothing is bad with how I made the modify and I already knew that my device wouldn't have reached same performances like that of Sandro, but in any case I wanted to try. Despite its many limitations I'm happy with my Welec that I even use for my daily work, however if it's possible to improve it well come. Even considering that there will also be a reason why my unit behaves in one way and as example that of Sandro in a different one. Here is because as reference I used -10dBm sine wave at 250MHz same as Sandro who I have to consider he enjoys the same performance throughout the whole bandwidth range without any gaps, doesn't matter if 250MHz, 245MHz, 217MHz, 83MHz, 1MHz, 11kHz, 34Hz or something else. Why normally does Sandro's DSO do that and my no? This is the question. Actually I think the real performances are those described and documented by Hayo in the manuals he wrote. I'm not doubting any of the other's claims, I just think that performance by somebody's devices, that of Sandro for example, falls in extraordinary cases, that anyway it would be useful to investigate. Surely there are some tolerances to take into account but this gap seems weird to me. It would be useful to have many more users able to do measures and sharing them, but I'm aware of how only very few of them they have the right equipments needed in order to do it. However for me the most important thing was to evaluate how much it was the accuracy of some readouts, precisely Vpeak-peak and Vrms. That was my primary goal but sadly all my photos are gone missed. I'll try to repeat it by saving pictures directly into a PC. To avoid misunderstanding I'm not saying that I think Vpeak-peak and Vrms don't work as they should, I'm just trying to exclude the possibility that my Welec actually has problems. I use it for work and I'm trying to be sure all it's ok with it. mark
Angehängte Dateien:
-
250MHz.png
5,3 KB -
50MHz.png
5,7 KB
Hello folks.
This afternoon I had to do extra work, so in meanwhile I collected some
pictures.
DSO was Welec 2012A_OPA653_MOD using latest firmware 1.2.BF.7.13C2, the
leveled sine wave generator was set for -10dBm (200mVpeak-peak /
71mVrms).
Vrms and Vpeak-peak are right and consistent.
I didn't manage to save and recall the acquired waveforms, I just
managed to use the OVERLAY feature.
In order to deeper the matter I did reset the DSO and via terminal
program I did rewrite the trigonometric's tables without joy though.
Next time I'll try reflashing the whole firmware.
By playing with the terminal I spot this errors but I don't know what it
means:
**********************************************
BlueFlash firmware starting!
**********************************************
- Hardware initialization - done
- Display initialization - done
QM -> draw_factor = 0 -> divide by zero exception will occur!
QM -> draw_factor = 0 -> divide by zero exception will occur!
- Starting up - done
----------------------------------------------
Version : 1.2.BF.7.13 C2
mark
Ok marc, your pics look like i remember the situation. Afair the problems are due to the samples not beeing stored in the correct order. I think only Jörg's new FPGA-design could help, but sadly he stopped working on that. Lets wait until Hayo is back again, he knows it better than i do.
Hello Guido. OK, thanks. Waiting for Hayo I would like to retake some of my questions and requests that have gone unnoticed, in the case him or somebody else being able to give an answer. Are EXT Trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. Are SINGLE mode trigger working while using DIGITAL mode function? I'm not able to use it even by setting the trigger to NORMAL. I guess due the well known issue of noise that plagues the Welec DSO's I have many random trigger acquisitions even when real one isn't present. Would be possible add a new DIGITAL function that allows for the same rappresentation on the screen as the usual ones togheter with the chance to adjust the thresholds of the triggering action? I understand that make no sense because DIGITAL trigger have their own levels. I mean rappresntation of the waveforms on the screen though, something like FILTERS in AQUIRE menu, don't a real DIGITAL trigger as those already allowed in the firmware. mark
Hi guys, I'm sorry but I'm just a bit in hurry due to business reasons. So don't be angry for waiting for some answers. I will try to take some time on weekend to make things a little bit clearer. regards Hayo
Ohoh, Hayo ist to busy. mark schrieb: > ********************************************** > BlueFlash firmware starting! > ********************************************** > > - Hardware initialization - done > - Display initialization - done > QM -> draw_factor = 0 -> divide by zero exception will occur! > QM -> draw_factor = 0 -> divide by zero exception will occur! > - Starting up - done > > ---------------------------------------------- > Version : 1.2.BF.7.13 C2 QM means QuickMath afair. Some parameters in Setup are not set correctly, so something horrible could happen showing the measuring values on screen.
:
Bearbeitet durch User
QM is the Quick Measure function. This seems to be only a message thrown out by the intializing routine. I think using the QM function will let this message disapear. mark schrieb: > Are EXT Trigger working while using DIGITAL mode function? > I'm not able to use it even by setting the trigger to NORMAL. I have no access to the code in this moment but if I remember right, there is no EXT trigger possible. > Are SINGLE mode trigger working while using DIGITAL mode function? > I'm not able to use it even by setting the trigger to NORMAL. > I guess due the well known issue of noise that plagues the Welec DSO's I > have many random trigger acquisitions even when real one isn't present. I'm not shure - I have to check it. > Would be possible add a new DIGITAL function that allows for the same > rappresentation on the screen as the usual ones togheter with the chance > to adjust the thresholds of the triggering action? > I understand that make no sense because DIGITAL trigger have their own > levels. At this time the triggerlevels are fixed due to the logic type. But indeed it would be possible to add a variable trigger for that. Also it would be possible to add a variable amplification for the voltage range. We discussed this some times in the past. Both are not so easy to implement and I decided to wait for Jörgs new FPGA design and the OSOZ firmware to implement those functions there. Nowadays it seems to be very unlikely that the new design will be finished anytime. So I will think about the possibility to implement those functions in the BF firmware (and maybe some other functions too). I did not realy understand what you meant with the overlay feature. Did anything go wrong? If there might be an issue - please make some additional screenshots to make things clearer. Kind regards Hayo
:
Bearbeitet durch User
Ok, found the issue with the message and fixed it. It occures only if the QM mode is active while startup. The new compilation C3 is available here... https://sourceforge.net/projects/welecw2000a/files/?source=navbar The message should not appear anymore. Kind regards Hayo
Thank you Hayo and sorry to annoying. Hayo W. wrote: > I have no access to the code in this moment but if I remember right, > there is no EXT trigger possible. OK, thanks! Hayo W. wrote: > I'm not shure - I have to check it. OK, thanks! Hayo W. wrote: > But indeed it would be possible to add a variable trigger for that. ... > I will think about the possibility to implement those functions in > the BF firmware (and maybe some other functions too). OK, nice to know. It 's really a good news, thanks! Hayo W. wrote: > I did not realy understand what you meant with the overlay feature. > Did anything go wrong? > If there might be an issue - please make some additional screenshots > to make things clearer. Simply I can only recall stored waveforms as overlay and not alway as memories. As you can see from the colour of the waveforms into the pictures I sent, almost the whole time are shown overlay. There may be a problem with my Welec or that I remember bad but for example acquiring a square wave and storing it with [Save Trace] as memory 1, a triangular as 2 and a sine as 3, then using [Recall Trace] should be possible show each of them on the screen. In my case [Recall Trace] has the only effect to RUN-STOP the oscilloscope by showing something waveforms which aren't related with the actual content of the given memory location. In order to show the actual shape of the stored waveforms in a given memory location I need to use the button [Overlay Trace] so that then it appears on the screen as an overlay with its expected color and sometimes as the real one with its expected color green and/or yellow depending on channels. I repeat, maybe something is wrong with firmware or it could be my Welec, anyway there is something weird. I have to go deeper, even because am I wrong or was there an alarm bell while acquiring screenshots on the computer? Honestly I'm a kinda confused, maybe it's just my fault. Hayo W. wrote: > 1.2.BF.7.13C3 I just upgraded my Welec with your new firmware 1.2.BF.7.13C3 and the error is gone. It does not show up anymore, thanks!: ********************************************** BlueFlash firmware starting! ********************************************** - Hardware initialization - done - Display initialization - done - Starting up - done ---------------------------------------------- Version : 1.2.BF.7.13 C3 mark
Angehängte Dateien:
-
spurious_spike.jpg
53 KB -
overimposed_spike.jpg
47 KB -
Wrong__Pre_Trig_.jpg
45 KB -
Left_Edge-First_Div-Grid_Middle.jpg
46 KB -
Correct__Pre_Trig_.jpg
44 KB
Hello Hayo. Some new details. I don't know if it's only a random case or not, but with the new firmware 1.2.BF.7.13 C3 the memories management behave better on my Welec, even if something weird still happens. I found that pushing the [Recall Trace] button then RUN-STOP is activated and the stored waveforms are shown on the screen but for something I think it's tied with the settings of the Time Base at the moment of memory recall only sometimes it's possible to see its right representation. With some range of the Time Base it's possible, with other ones it isn't and what is put on the screen it's meaningless although the recalled range of the Time Base is the correct one for that given memory location. So by turning the knob of the Time Base often it's possible to trigger the right visualization of the waveform that it's whished to see. In some cases, in my opinion depending on the range of the Time Base set at the moment of pushing the [Recall Trace] button, there is no need to operate the knob of the Time Base that the picture is shown already correctly without doing anything. In some other situations by changing the range of the Time Base doesn't do the trick and despite the memory location being the right one, then on the screen is shown the contents of a different stored memory location. Sometimes pushing [Clear Display] and/or [Restore Setting] does the same trick. Documentation explain what the meaning of [Restore Setting] is, but what about [Clear Display]? Talking about something else, seems that setting for Trace Middle, Keep Value or Keep+Follow a spurious spike is drawn on the screen. The same spurious signal is too overimposed on the waveform under measure. In that case [Pre Trig] is set wrong, it doesn't match the range of the Time Base based on its trigger position on the graticule, not even using [Adjust Window]. Instead by setting for Left Edge, First Div or Grid Middle, then the spurious spike doesn't show up on the screen and [Pre Trig] is set rigth, matching the range of the Time Base based on its trigger position on the graticule. This issue I think could be related with the worst shape sometimes drawn in the start or in the end of the waveforms on the screen depending on where the trigger is put on the horizontal axis (time for the trigger event). mark
Hallo, Habe ein WS2022A geschenkt bekommen. Es ist noch nichts modifiziert und auch die originale Software am arbeiten. Was soll ich da jetzt am besten machen? Ich habe keinen JTAG daheim, darum kann ich den FPGA nicht flashen. Was ist die letztbekannteste Version, die mit dem originalen FPGA zusammenarbeitet? Leider ist der Beitrag schon sehr unübersichtlich geworden.
Hier findest du alles, vom flashen der neuen FW bis zum modden und umbauen inkl. Dokumentationen, mußt eben ein "wenig" lesen! https://sourceforge.net/projects/welecw2000a/files/?source=navbar EDIT: neue Firmware kann über RS232, erst mal ohne "öffnen", geflasht werden Gruß Michael
:
Bearbeitet durch User
Hello Fred Ram. For unmodified DSO the latest supported firmware free is 1.2.BF.7.6 because it hasn't Save/Recall bug. Starting from 1.2.BF.7.9 there are new DAC-offset factors in order to matching the new R13 = 305Kohm instead of the old factory value (390Kohm) that will not be supported any longer. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" mark
Fred R. schrieb: > Was soll ich da jetzt am besten machen? Hallo Fred, nach den schon gegebenen Antworten auch noch mal ein Statement von mir. Also grundsätzlich - mit der originalen Firmware ist das Gerät nutzlos wie ein Kropf. Du hast jetzt diverse Optionen aus diesem Gerät etwas Brauchbares zu machen. Wie weit Du da gehen möchtest hängt letztlich von Dir ab. 1. Um das Gerät erstmal in einen benutzbaren Zustand zu versetzen solltest Du die aktuelle BF-Firmware flashen (1.2.BF.7.13 C3) die Du von Source Forge herunterladen kannst. Das Flashen geht dabei nur über RS232!!! Das USB-Kabel kannst Du gleich weglegen. An Deinem FPGA musst Du nichts machen. Wie man das macht und die benötigten Tools sind in dem Download-Package enthalten. Natürlich helfen wir auch gerne hier weiter wenn Du Fragen hast. 2. Es gibt 2 FPGA (Hardware) Versionen. Das Gerät meldet sich beim Hochfahren mit dieser Version. 1C9.xx und 8C7.xx. Bei der 1C9 wurde berichtet, dass hier vermehrt Probleme mit Spikes auftreten. Hier kann man jetzt das FPGA auf 8C7 umschießen wenn man möchte. 3. Es gibt diverse Hardwaremods die das Gerät verbessern. Dazu gehört eine bessere Belüftung oder auch Modifikationen an den analogen Eingängen oder am externen Trigger. Viel Erfolg Hayo
Hi Hayo, do you know this free program to analyze the analog/digital signals? https://sigrok.org/wiki/FAQ I'm doing hardware development of input stage for preamp and perhaps MSO inputs, may you evaluate W2000 FW mods to emulate one the listed instruments? Our DSO transformed to MSO oscilloscope is very useful! Sandro
Hi Sandro, no I don't know this software, but it seems to be very interesting. Also it seems to be a good idea to support an interface to this software. I will check this option in the next weeks and if it is possible I will add this feature. Thanks for the hint Hayo
Hi again, I checked some supported Hardware for SIGROK and my first Idea is to try a support for DSO/MSO with RS232 connection. This may be easier than to write an USB firmwaremodule and a system driver. Interesting are GW Instek GDS-800 and may be Hameg HMO or Rigol DS1000. I will check further options Hayo
Hi Hayo, thank you for your reply and new idea. I am registered at sigrok-devel@lists.sourceforge.net , they reply fastly and collaborate for development of new instruments with sigrok,the owner of the website came from city Braunschweig Germany,may be helps. Regards, Sandro
Hello Sandro, yes that may help. I just try to install and get familiar with the Software. If I understood right we have two main Options for using Sigrok. 1. we can create a file with our DSO which can be processed by Sigrok 2. we can connect Sigrok and the DSO directly via interface Both sounds interesting. I will check the possibilities. Hayo
Mal eine Frage am Rande - ich habe gestern ein bisschen mit den Cursors rumgespielt, wenn ich dann an der Zeitbasis drehe, werden die Werte des Cursors nicht automatisch angepasst, zeigen also die alten, falschen Werte. Soll das so? Meine SW Version ist relativ neu. Grüsse, Egberto
Du meinst die Werte, die auf den F-Tasten eingeblendet werden X1, X2, Y1, Y2 - richtig? Um ehrlich zu sein, ist mir das noch nicht aufgefallen und ich glaube es hat auch noch niemand sonst erwähnt. Aber Du hast natürlich Recht. Die Werte sollten aktualisiert werden. Ist in Arbeit... Gruß Hayo
New version out now - neue Version ist verfügbar! Die neue Version zeigt jetzt bei Änderung der Timebase und auch bei Änderung des Spannungsbereiches die aktuellen Cursorwerte an. Download hier: https://sourceforge.net/projects/welecw2000a/ Danke an Egberto für den Hinweis. Gruß Hayo
Der Dank geht an dich!! Ohne deine Arbeit hätten wir alle hier nur ein Stück Elektroschrott zu stehen. Und Fehlerkorrekturen/Updates so lange nach Projektende sind auch etwas besonderes. Viele Grüsse, Egberto
Danke für die Blumen... @Andiiy Wärst Du wieder so nett, die Änderungen ins Repo einzupflegen? Betroffen ist im Wesentlichen der Code in userif.cpp. Ansonsten nur das Changelog und tc_vars.cpp wegen der Versionsnummer. Gruß Hayo
natürlich ... wie immer (wird aber erst morgen)! PS: Ich fand die Idee mit sigrok auch ziemlich gut! Wobei NIOS2 immer noch ein schöner Gedanke wäre ... wo sind nur die ganzen FPGA Programmierer!
Supie! Ja ein neues FPGA-Image wäre sicherlich ein Sprung um Lichtjahre. Ich weiß gar nicht warum ich bisher nicht auf Sigrok aufmerksam geworden bin. Sehr vielversprechend. Ich analysiere derzeit die Treiberdateien für die GW Instek 800 Serie um eine Möglichkeit zu finden das W2000a auf das Protokoll zu synchronisieren. Das würde dann zumindest im 2 Kanalbetrieb einige Möglichkeiten eröffnen. Mehr als 2 Kanäle gibt der Treiber leider nicht her. Ein eigener Treiber für das WELEC wäre dann aber ziemlich einfach aus der vorhandenen Source zu erstellen. Für alle die an diesem neuen Projekt Interesse haben stelle ich mal die entsprechenden Sourcen hier bereit und hoffe, dass ich damit nicht gegen irgendwelche Lizenzbestimmungen verstoße. Gruß Hayo
:
Bearbeitet durch User
Andiiiy schrieb: > Wobei NIOS2 immer noch ein schöner Gedanke wäre ... wo sind nur die > ganzen FPGA Programmierer! Die ganzen... Also ich bin immer noch hier, auf der Welt. Wenn auch sehr mit anderen Dingen beschäftigt. Oszi-mäßig habe ich mir vor knapp einem Jahr "was ordentliches" gekauft, ein Keysight DSOX3014A, und zum Äqivalent eines MSOX3054A mit allen Optionen aufgerüstet, außer das meines sogar mit 5 GSa arbeitet. Es gibt da interessante Tuningmöglichkeiten. Macht viel Spaß damit zu arbeiten, ist superschnell und fühlt sich "analog" an. Leider zeigt es auch, daß man das Welec nie zu einem ordentlichen Werkzeug kriegen würde. Hardware-Rendering ist klasse. (60 mal in der Sekunde das Ergebnis von allen mittlerweile aufgelaufenen Triggervorgängen anzeigen, Häufung als Helligkeitsstufen, statt nur eine Welle.) Dafür ist der Speicher im FPGA viel zu knapp. Dazu noch alle erdenklichen Dekoder und Meßwertbildung in Hardware... Für den "normalen" und erschwinglichen Hobbybedarf bietet auch ein Rigol aus der 1000Z-Serie ein vielfaches. Die lassen sich ja bekanntlich leicht hochrüsten. Habe zugegeben noch nicht selbst damit gearbeitet. Zurück zum Thema, prima daß Hayo noch so tapfer dabei ist, Hut ab. Sorry daß ich mein Projekt nicht fertig genug bekommen habe. Viele Grüße Jörg
:
Bearbeitet durch User
Hallo Jörg, Glückwunsch zu Deinem tollen Neuzugang. Sowas hätte sicherlich jeder hier gerne. Aber ein Vergleich mit dem ehrwürdigen Welec ist auch etwas unfair :-) Das Keysight (bzw. ex-Agilent) ist ja Profiausstattung und mit 4,5K€ etwas außerhalb des normalen Hobbybudgets. Für den Hobby-Elektroniker oder auch Studenten mit schmalem Budget ist das Welec trotz aller Schwächen ein interessantes Gerät. Gerade deshalb wäre sicherlich die Unterstützung von Sigrok eine echte Bereicherung. Und wo hat man schon die Möglichkeit seinem Oszi eigene Funktionen beizubringen? Gruß Hayo
Nios2 ist aber nicht offener Quellcode? Mal OpenRisc angeguckt?
Andreas R. schrieb: > Mal OpenRisc angeguckt? Nein, noch nicht genauer. Wäre aber sicherlich auch eine Option. Die Lizenz für den NIOS2 wäre aber nicht das Problem. Jörg hatte da was am Start. Was wir brauchen, ist jemand, der sich mit dem Design von FPGAs auskennt und ein funktionierendes Design erstellt. Jörg hat sich ja schon relativ weit eingearbeitet. Das hörte sich zwischendurch schon echt gut an, bis dann die weitere Entwicklung abbrach. Ich hatte auch schon überlegt, ob ich da einsteige, aber mir fehlt etwas die Zeit um in das Thema wieder komplett neu einzusteigen (meine letzten Vorlesungen zu dem Thema waren in den 90iger Jahren). Denkbar wäre auch das Ganze als Studienarbeit oder so zu nutzen. Sowas hatten wir hier ja auch schon. Da lag der Schwerpunkt aber auf der Entwicklung von Filterbänken im FPGA und das Ganze auch nur für zwei Kanäle. So war das dann für uns nicht direkt nutzbar.
Hi, Ich habe mal das Screenshot-Tool etwas komfortabler gestaltet. Hier: Beitrag "Welec DSO Screenshot-Tool" falls Interesse besteht, kann ich das mit eurer Unterstützung noch etwas ausbauen. Gruß Michael
Hello Hayo. OK, thanks for the new 1.2.BF.7.14! This new one firmware corrects the problem wrote by Egberto, what about these others? Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Is there hope that also them can be adjusted too? Very good also for the intention to support the usage of SIGROK on the Welec's DSOs. About the bandwidth matter developed in some past posts and also in the intent of making calibrations of the DSO input stages I saw this: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=124&products_id=295&zenid=82e2d98b8484f6fc53e13c392a4c3c47 http://www.eevblog.com/forum/projects/yet-another-fast-edge-pulse-generator/ I purchased it and with that device I have evaluated the bandwidth -3dB of my W2012A_OPA653_MOD equal to about 150MHz. Unlike other oscilloscopes, the measurement is quite difficult to do on Welec as the signal is rather unstable as it is drawn on the screen, anyway 150MHz is the most realistic value: rise and fall time equal to about 2,4ns (the fast pulser in question is rated 33ps rise time and 31ps fall time). Meanwhile for cheap I purchased a second hand W2022A too. The only change it has is the input resistors 33/150 ohm. By using the same fast pulser I wrote above I have evaluate its -3dB bandwidth equal to about 150MHz. I'm pretty sure my OPA653_MOD was done correctly but since I have now a new one Welec I changed its channel 1 input stage with OPA653_MOD as I done on my W2012A and still the -3dB bandwidth evaluated with the test device is about 150MHz. As I already wrote I'm happy with 150 MHz bandwidth, it's no problem. The thing is rather weird though. I wonder why somebody in bandwidth draws great benefits from OPA_653_MOD (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)") and me no. Next step will be to change channel 2 with Low Budget Mod in order to check what happens.
@Michael sorry für die späte Antwort. Hört sich gut an. Bin aber momentan etwas unter Strom (passt zum Forum...) und konnte mir da noch nix ansehen. Hole ich aber schnellstmöglich nach. @mark > Is there hope that also them can be adjusted too? Yes - it just got out of my scope. Thanks for remembering. I will try to fix it after my holidays. > I wonder why somebody in bandwidth draws great benefits from OPA_653_MOD Please keep in mind, that the main idea behind this mod is not to increase the bandwidth, but to make the frequency response as linear as possible. It is easy to increase the bandwidth without linearity - but it is very useless because the signal shape you see on the screen is far away from reality. And that is what the original input stage does - it amplifies the higher part of the frequency range more than the lower part.
Hello Hayo. OK thanks. For bugfix it wasn't my intention to hurry. Sorry. About bandwidth improvement with OPA653_MOD I totally agree. As I already wrote I'm happy with it, that isn't the point. What I'm trying to understand is why of the behavior described by someone compared to others. Maybe OPA653 I purchased were fakes, maybe it's some other component inside the Welec, maybe I was wrong to make the change, maybe... I think the performance of some devices, that of Sandro for instance, falls in extraordinary case. The expected ones are those described and documented by you into the instructions you wrote. I'm pretty sure nothing is bad with how I made the modify as well as the performance I detect in my two specimens are what is normal to expect. Indeed what I get is roughly the same value you measured with your TR-0307 pulse generator which is 2,5ns rise/fall time: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" As it's possible to see in your documentation the frequency response evaluated with your Leader 3216, which stop at 140MHz max, from around that frequency value begins to get worse quickly. @ Michael D. Well done, thanks. mark
mark schrieb: > from around > that frequency value begins to get worse quickly. But that's no problem, if the frequency response is linear in this range. The sample rate of 1 GHz combined with about 150 to 200 MHz bandwidth is good for signals in the range of 20 to 50MHz. In the real live that are not sinus waves. That means, the signals contain frequencies which are factor 5 higher than the main frequency. Measuring signals with higher main frequencies will result in signal distortion and less measuring quality. So - to repeat what I said before - we can be happy if the modification leads to an accurate signal shape on our screen. Don't worry about some MHz more or less bandwidth, in practice that makes no difference. p.s. I will make some additional measurings with my DSOs after holiday to have some more value to compare with. I don't think you got fakes of the OPA653. The only fakes I know are the original parts of the W2012/W2014 and also some of the W2022/W2024 (with green dots). But parts directly from the manufacturer are beyond any doubt I think.
:
Bearbeitet durch User
Hayo W. schrieb : > @Michael > > sorry für die späte Antwort. Hört sich gut an. Bin aber momentan etwas > unter Strom (passt zum Forum...) und konnte mir da noch nix ansehen. > Hole ich aber schnellstmöglich nach. Kein Problem, eilt ja nicht! ;-) Bei Gelegenheit könntest du mir mal die Schalter für das abspeichern von CSV und ASCII mitteilen, ich kann die nirgends finden. Am besten hier rein: Beitrag "Welec DSO Screenshot-Tool" oder per PN Gruß Michael
:
Bearbeitet durch User
Hi mark, I tried to get the same failure as You - but I wasn't able to reconstruct the issue. I used the same settings and same signal. Can you give me a hint how to bring this on the screen? Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Hayo
:
Bearbeitet durch User
Hello Alles, I have a W2012A dso, and I have flashed BlueFlashFirmware since many years. I have flashed last version (1.2.BF.7.14) few minutes ago. I have an issue related to channel offset and amplitude. Offset: Input disconnected = 0V input. When the channel is centered, Trace is centered. Moving the channel (vertical position) the trace moves far from the arrows indicating "zero". The more the channel is away from center of the screen, the more the trace is away from the arrows. Amplitude Scaling: With 12.0V DC input connected, channel centered in screen, I read 9.0V. Moving the channel toward the bottom of the screen, the reading is correct (12.0V) when the trace is at center of screen (and the arrows are "-12V"). As the problem is there since many version of firmware, I was wondering if this is a software issue (firmware or calibration) or it could be hardware issue. Many thanks.
@Alessandro Mauro Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
Hi Alessandro, there are new hardware settings since the last firmware releases. So you have to go to your hardware menu and choose the correct settings. If you havn't modified your DSO, the factory setting is the best choice. Otherwise you have to choose the setting matching to your mod. If you are not shure how to setup your DSO, I will help you in detail. Regards Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
Hardware_01.jpg
40 KB -
Hardware_02.jpg
41 KB
Hi again, here a screenshot of my W2022A. The first setup is for the OPA653 Mod and the second for an unmodified DSO. The ADC-Setup can be changed for different signals and frequencies to avoid spikes and other crap. Regards Hayo
Hayo W. schrieb: > So you > have to go to your hardware menu and choose the correct settings. Thank you Hayo, it was that! Changed to Factory now it is okay!
Hallo, erst einmal recht großen Dank und Anerkennung an alle, die an diesen Projekt die vielen Jahre gearbeitet haben. Habe jetzt erst von 1.2.BF.2.x auf 1.2.BF.7.14 geflasht. Da ich derzeit einen Tastkopf 500:1 verwende ist mir noch ein Fehler in tc_vars.cpp aufgefallen.
1 | //Voltage ratio
|
2 | const float VoltFactor[19] = { 0.001, // 1mV |
3 | 0.002, // 2mV |
4 | 0.005, // 5mV |
5 | 0.01, // 10mV |
6 | 0.02, // 20mV |
7 | 0.05, // 50mV |
8 | 0.1, //100mV |
9 | 0.2, //200mV |
10 | 0.5, //500mV |
11 | 1.0, // 1V |
12 | 2.0, // 2V |
13 | 5.0, // 5V |
14 | 10.0, // 10V |
15 | 20.0, // 20V |
16 | 50.0, // 50V |
17 | 100.0, //100V |
18 | 200.0, //200V |
19 | 300.0, //500V sollte '500.0' sein. |
20 | 1000.0}; //1000V |
vielleicht kann das jemand noch bereinigen. Grüße jofri
Oh oh... wie konnte das passieren und so lange unbemerkt bleiben? Korrigiere ich natürlich umgehend. Danke für den Hinweis. Gruß Hayo
Hi Folks! Second compilation (C2) of 7.14 firmware with corrected divider table is available now on sf-net: https://sourceforge.net/projects/welecw2000a/ regards Hayo
Hallo Hayo, Danke für deine rasche Korrektur. Beim Utiliy-Menü sind mir die Punkte Defaut-Setup - was geschieht da genau? Calibration-Standard - was ist Set3 / Set4 nicht ganz Klar. Gibt es irgendwo eine zusammenfassende Beschreibung der Menü. Danke Josef
Hi Josef, eine kurze Beschreibung aller nicht Standard Funktionen findest Du in der Datei Special Functions im Doc Verzeichnis. Aber wo ich gerade dabei bin: Man kann verschiedene Kalibrierungen speichern. Wenn man z.B. einen aktiven Tastkopf hat, so weicht dessen Kalibrierung von der normalen Kalibrierung ab. Damit man nicht immer einen neuen Durchlauf starten muss, kann man sich für verschiedene Tastköpfe je ein Kalibrierungsset speichern. Wenn Du normalerweise nur selten mit anderen Tastköpfen arbeitest kannst Du auch einfach auf Standard bleiben und vor der Messung eine Kalibrierung machen. Das Ganze war eine Anforderung von einigen Spezialisten, die häufig mit unterschiedlichen Eingängen arbeiten. Gruß Hayo
Da mir meine liebe Frau ein neues Oszi geschenkt hat, gebe ich mein Welec 4-Kanal 200 Mhz mit (fast) aktueller Blueflash Firmware gegen Porto ab (keine Garantie, keine Tastköpfe und sonstige Kabel!!) Ich hatte damals den Lüfter gegen einen größeren, leiseren ersetzt, ein Abschirmblech eingebaut und die 2 Trigger LEDs in die Frontplatte gebaut. Das Gerät ist soweit funktionsfähig, hat aber die bekannten Welec Designschwächen. Ziel dieser Aktion sind Bastler, die dieses Gerät aktiv weiter entwickeln wollen bzw. Schüler/Studenten mit Ambitionen, die Entwicklung hier weiter zu treiben. Kontakt bitter per PM. Mirko
Hi guys, I've been away for a long time, is there still someone here? I hope so. I own a W2012A upgraded OPA653 with the latest firmware 1.2.BF.7.14C2. Based on the document "Spektralanalyse mit dem WELECW 20xxA" (https://www.mikrocontroller.net/attachment/53555/W20xxA_Spectrum_Analysis_de.pdf) it would be possible to switch from linear to logarithmic and reverse but I can't find anymore the MODE button which is used to switch among V and dB. Is it only me or the button has been removed? Regards, Antony
Angehängte Dateien:
-
Linear_Mag01.jpg
47 KB -
Log_Mag_wrong_display.jpg
48 KB -
Log_Mag_correct_display.jpg
47 KB
Hi Antony, sorry for the late reply. There is no button in your menu? It is correct, that the appearence of the menu changed. There are new modes available. The logarithmic mode is called Power Spectrum now - and that's what it is. But I found a little bug. When switching the modes, the type of magnitude in the display on the rigth side is not correct. You have to switch to x-y or main and back to get the correct display. I will try to correct this in the next time. Hayo
Angehängte Dateien:
-
dB.gif
98 KB
Hello Hayo, thanks and no worry. There is no hurry, one answers when he can and wants. OK, many thanks for the explain, I'll follow your advice. One more thing, if it's possible. I'm dumb for sure, but is it that with the new firmware it's no longer possible to display the values in dB overimposed on the graticule? OK, I had have the experienced the bug you wrote. Doing what you wrote in the end I have Mag:log(dBm). I don't know if this could be useful, but I managed to achieve the same result also with a reset. Much better your method though. Regards, Antony
Hi, I shifted the grid to the left, to get space for the display on the right side. So the values had to disapear. I found the display more useful than the dB values so I decided to sacrifice them for the new display. I hope this is useful for you too. I will try to solve the switching problem as soon as possible. I will let you know when a new version is available. Kind regards Hayo
Hi all - I corrected the bug yesterday night, so you can download the new release 7.15 here: https://sourceforge.net/projects/welecw2000a/ wish you all a nice week Hayo
Hello Hayo, OK, many thanks for the explain, now I understand. Surely what you wrote is very useful to me, thank you. I understand that even if not explicitly specified the 0dBm (1Vrms) are at the top exactly as in the screenshot I posted. Thanks a lot also for the new firmware that fix the issue by switching among V and dBm and reverse. I'm happy the thread isn't dead, even if I sense that the hard work is always only your since you alone dedicate your time to fix the problems of us users of the awesome Welec. We are really lucky to have you on our side Regards, Antony
Nabend, bin auf der Suche nach dem Wiki das sich unter:http://sourceforge.net/apps/trac/welecw2000a/ befand, in der Waybackmachine fehlt das meiste. Eigentlich suche ich das RS232 Protokoll.
Hi, das Wiki ist leider nicht mehr aktiv. Die Reste sind hier zu finden: http://web.archive.org/web/20120115071202/http://sourceforge.net/apps/trac/welecw2000a/wiki Ansonsten sind die meisten Sachen aber auch in den Dokumenten auf SF zu finden: https://sourceforge.net/projects/welecw2000a/files/ Ich kann Dir sonst im Coding auch gerne die Stellen nennen wo Du was dazu findest. Es ist da ja Verschiedenes zur RS232 programmiert worden. Da ist einmal das Firmwareupdate(komprimierte Firmwareupdates), dann die Fernsteuerung/Sonderfunktionen, dann die Screenshot- und Datenexportfunktion, was davon brauchst Du? Wenn Du sonst noch Fragen hast einfach direkt drauf los... Gruß Hayo
Angehängte Dateien:
-
2019110414115100.jpg
93 KB
Hallo, mein Oszi hat sich gestern, nachdem ich ADC Setup Factory aufgerufen habe, aufgehangen. Aus/Ein sowie ein Reset bringt es nicht mehr zum Laufen. Hat jemand eine Idee wie ich es wieder zum Laufen bringe. Danke Stefan
Hi Stefan, erstmal sicherstellen, das die Firmware ok ist - d.h. die aktuellste Firmware noch mal neu laden und dann das Oszi neu starten. Wenn das vorher schon die letzte Version war, sollte das recht schnell gehen. Wenn eine sehr alte Version drauf war braucht es etwas Zeit bis sich das Gerät initialisiert hat. Danach noch mal ins Hardware-Menü und alles richtig einstellen. Wenn es dann nicht läuft, ist irgendwas nicht in Ordnung und wir müssen etwas mehr ins Detail gehen. Das würde ich aber eher nicht vermuten. Gruß Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
W2024A-startscreen.jpg
250 KB
Hallo Hayo, vielen Dank für die Unterstützung. Das Upload der Firmware (1.2BF.6.xx -> 1.2BF.7.15) ging ohne Probleme, hat aber nichts gebracht. Leider ist das Fehlerbild immer noch das gleiche. Zu Deiner Frage wie es zu dem Fehler gekommen ist: 1.) Ich habe das Hardware Menü aufgerufen. 2.) ADC Setup --> Der Bildschirm wurde grün und seitdem hängt das Oszi. Aber bitte mache Dir nicht zu viel Aufwand. Da das Ding ist schon etwas in die Jahre gekommen und ich möchte ungern an der HW noch was tun (bin da auch nicht so fit). Würde mir für meine Hobby Zwecke (IoT, Ardino, ESP, also bis ca. 10MHz) dann wahrscheinlich ein Rigol DS1054Z (oder Vergleichbares) zulegen. Im Voraus schon mal vielen Dank. Gruß Stefan
Hi Stefan, das sieht für mich bei näherer Betrachtung so aus, als wenn da der Zugriff auf das FPGA nicht richtig funktioniert. Normalerweise sollte der Bildschirm so aussehen: Model: W2024A Hardware Version: 8C7.0L Serial Number: 04063846C8 Flash ID: 0193 Die Werte werden aus dem FPGA gelesen - und bei Dir steht da leider Schrott drin. Was kann das sein? - Das FPGA hat irgendwo "kalte Füße", was ja bei den WELECS durchaus nichts Neues ist. - Das FPGA hat intern eine Macke (glaube ich eigentlich nicht so recht) - einer der Speicherchips hat "kalte Füße" - kommt öfter mal vor, äußert sich allerdings normalerweise durch Displayprobleme Man könnte also mal vorsichtig Beinchen nachlöten um hier weiterzukommen. Hat sonst hier in der Runde jemand eine Idee? Gruß Hayo
Angehängte Dateien:
-
2019110718205100.jpg
350 KB
Danke Hayo, Habe das Oszi gerade zerlegt (leider mit leichten Schaden an einem Drehknopf) . Beide RAM'S nachgelötet. Alle Lötstellen sehen eigentlich gut aus. An den FPGA kann man ja wohl nichts machen Füße wärmen) . Wenn keine andere Idee vorhanden ist gebe ich die Reparatur auf. Gruß Stefan PS: kann dann gerne das Oszi gegen Porto als Ersatzteile zur Verfügung stellen.
Hi, Du bist ja schnell... Nein am FPGA lässt sich schlecht was machen. Ich würde auch am ehesten auf das RAM tippen, da hier öfter schon mal ein Problem war. Bin ja mal gespannt, ob Dein Nachlöten Abhilfe geschaffen hat. Gruß und viel Erfolg Hayo
Hallo Hayo, das Löten der RAMs (auf beiden Seiten und mit viel Flux) hat nix gebracht. Wie gesagt, ich gebe es auf. Es gibt jetzt ein vorgezogenes Weihnachtsgeschänk ;-). Noch mal vielen Dank. Gruß Stefan. PS: Wenn jemand das Oszi als Ersatzteile haben möchte gebe ich es gern ab. (gegen Porto).
Wenn es noch was anzeigt ist es gut genug für einen Trade-in bei Keysight. Es gibt da immer mal wieder so 30% Rabatt Aktionen. Wenn ich recht erinnere muß das Altgerät um qualifiziert zu sein mindestens halb so viel Bandbreite oder Kanäle haben wie das neue. So kam ich zu meinem DSOX3014 (OT, was jetzt eher ein MSOX3054 ist...)
Happy 2020 to all of you! I hope that Hayo, Jorg will devolope new features with our dso, may be serial decode with some basic information I provided time ago. Greetings, Sandro
Hi Sandro, happy new year to you and all others here. Unfortunately (for you) I bought a sailing yacht and now spend all my time to work on the boat. For this reason I will not develop new functionality in the next time but nevertheless I will support you with bug fixes if needed. Maybe anyone else here has the motivation and time to develop new functions - support from my side is guaranteed! Regards Hayo
Angehängte Dateien:
-
QM_ch1-CH2.jpg
240 KB
Hallo Hayo, have a nice job with your boat. Just a little W2022A bug, in quick measure mode dual trace, switching the qm from Ch1 to Ch2 no changing, the measure remains to ch1. Regards, Sandro
Hello Sandro, this is not a bug. You can add a new measurement on CH2, so that you can measure both channels for example. There is no change of the choosen types of measurement in the channel number, if you switch between CH1 and CH2 - this is absolutely normal and also the solution on other oscilloscopes. Regards, Sven.
Hello Sven, I have also a Tektronix TDS 500MHz 4 channel updated to 800MHz and new LCD colour display, quick measure works different from our Welec, there it's very easy to change qm between channels. May be improved for sure, this is only a kind observation. Regards, Sandro
Ich grüße als Neuling in diesem Forum alle Experten! Ich habe da ein Problem mit meinem älterem W2012A, der vorgestern seinen Dienst quittiert hat. Es wäre schade, dieses tolle Gerät zu verschrotten ohne einen Reparaturversuch unternommen zu haben. Dazu bräuchte ich aber Euere Hilfe! Fehlerbeschreibung: Nach dem Einschalten und normaler Anzeige erschien nach etwa 2 Minuten ein vertikales Raster, ähnlich einem Gartenzaun, über den ganzen Bildschirm. Nach dem Aus- und Wiedereinschalten blieb der Bildschirm - bis auf einen leichten Schimmer - ohne Inhalt. Ausserdem blieben alle Bedientasten, ausser RUN/STOP, dunkel und funktionslos. Ohne Schaltplan ist es für mich ziemlich schwierig eine Reparatur durchzuführen. Kann mir da jemand weiterhelfen? Grüße, Reinhard
Hallo Reinhard, ja das ist kein Beinbruch, sondern eher ein abgelöstes Beinchen :-) Das Problem ist altbekannt und hat schon viele Besitzer ereilt. Ich habe jetzt auf die Schnelle nur diese Beiträge dazu gefunden: Beitrag "Ausfall W2024A" Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Es gibt aber noch mehr dazu. Letzterer mit Foto, das Dir bekannt vorkommen sollte... In allen mir bekannten Fällen war es der RAM-Baustein auf der Außenseite, also der leichter zugängliche Baustein. Wenn man etwas Lötgeschick hat ist das kein Problem. Der Lötkolben sollte eine feine Spitze haben und man muss auch nur kurz auf die SMD-Beinchen tippen. Starkes Drücken, kann die Beinchen auf dem Pad verschieben und Kurzschlüsse verursachen. So gesehen bei einem Gerät, bei dem mit einem etwas zu großen Lötkolben gearbeitet wurde und welches dann bei mir landete als nix mehr ging. Wenn Du noch Hinweise brauchst, welcher SMD-Chip das ist... ...oder wenn Du noch Infos brauchst um das Gerät zu zerlegen - es gibt schriftliche Anleitungen beim SF-Download, aber ich helfe auch gerne direkt. Gruß Hayo
Guten Abend Hayo, habe mich heute mal an die Nachlöterei aller Beinchen der beiden RAM's gemacht: leider kein Erfolg. Hast Du noch weitere Vorschläge? Gruß, Reinhard
Hi Reinhard, kein Erfolg bedeutet, es ist noch alles so wie vorher? Hast Du mal ein Foto vom Bildschirm? Ist eine aktuelle Firmware drauf? Neu flashen kann manchmal auch schon helfen. Gruß Hayo
Danke für die schnelle Antwort, Hayo. Der Zustand ist wie vorher. Ich denke, dass ein Foto von einem dunklen Bildschirm keinen großen Informationswert hat. Wie kann ich das Gerät ohne Bidschirmanzeige neu flashen? Außerdem habe ich an meinem PC nur USB-Anschlüsse. Grüße, Reinhard
Hallo Reinhard, als ich vor Jahren mein mein W2012 von Wittig bekommen habe, zeigte es ähnliche Symptome. Der Display-Stecker war nicht ganz eingerastet. Grüße,Josef
Angehängte Dateien:
-
USB_zu_RS232_Converter.jpg
270 KB
Aahh - ok, ich dachte es würde noch was auf dem Display angezeigt. Wie Josef hier schon andeutet, kann es helfen das Gerät einmal ganz zu zerlegen und wieder zusammen zu bauen. Evtl. sind Kontaktschwierigkeiten irgendwo vorhanden. Wenn die Probleme erst nach dem Auseinandernehmen auftreten, kann es sein, dass man die Pfostenleiste zwischen den Platinen nicht richtig getroffen hat (um einen Pin verrutscht). Du solltest aber für weitere Diagnosen unbedingt einen Computer mit RS232 Anschluss haben. Für reine USB-Geräte habe ich einen USB/RS232 Converter im Einsatz (für's Lappy). Aber wie auch schon hier in den Foren berichtet scheinen nicht alle gleich gut zu funktionieren (musst mal hier oder im Hardwarethread suchen). Meiner meldet sich im Gerätemanager mit "Prolific USB to Serial Comm Port" (siehe Bild). Damit kann man dann die Debug-Ausgaben des Gerätes beim Start über ein Terminal mitverfolgen und auch eine neue Firmware aufspielen. Hast Du denn noch die Wittig-Firmware drauf (eigentlich unvorstellbar)? Gruß Hayo
Ich Frage mal nur aus Interesse: Ist der FPGA Teil dokumentiert so dass man da selber Code für schreiben kann? Bei kaufbaren Oszis kann man sich zwar die Samples nach einem Trigger geben lassen und damit Auswertungen machen, aber das ist oft sehr langsam und man hat viel Totzeit. Zu Messzwecken im Labor wäre das super zu diesem Preis. Die Auflösung würde mir auch locker genügen mit den 8 Bits. Wichtig sind mir das Erkennen von kurzen Impulsen zu denen ich dann jeweils einen Zeitstempel mit ausgeben. Da genügt locker die serielle Schnittstelle. Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt?
Gustl B. schrieb: > Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um > das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht > dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt? Moin Gustl, in dem Bereich wäre Jörg der richtige Ansprechpartner und Du wirst im Hardwarethread https://www.mikrocontroller.net/topic/goto_post/3068213 sicher einiges dazu finden. Nur kurz - die Konfiguration wird im Flash abgelegt. Am JTAG hängt ein ALTERA Klone (USB Blaster) für ca. 10€ vom freundlichen Chinesen. Eigene Designs wurden schon in Angriff genommen und waren aber bisher noch nicht verwendbar. Dennoch haben sie klar aufgezeigt, dass das Potential des Gerätes mit der Wittig-Programmierung maximal zu 10% ausgeschöpft wurde. Es geht deutlich mehr Geschwindigkeit und bessere (fehlerfreiere) Funktionen. Wenn Du da was auf die Beine stellen willst sei Dir noch der Thread "made from the scratch" (von Jörg) empfohlen: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Gruß Hayo
Gustl B. schrieb: > Ist der FPGA Teil dokumentiert so dass man da selber Code für schreiben > kann? Gustl B. schrieb: > Wie ist denn der Aufbau grob, muss man zwingend eine CPU verwenden um > das FPGA zu konfigurieren und den ADC und UART zu verwenden oder reicht > dafür eine FPGA Konfiguration die man über JTAG in einem Flash ablegt? Das Board ist gut bis sehr gut dokumentiert, beim FPGA fehlen (mir zumind.) ein paar Pins, die lasse ich aber als Input mit WeakPullup. Damit lassen sich dann RAM/ROM, LCD, UART, das Eingabeboard und die ADC-Stufen komplett ansteuern. Überflieg einfach mal hier die verschiedenen Forenthemen, da müssten alle notwendigen Links zu finden sein.
Hallo Leute, Ich habe gestern die Firmware meines W2024 auf 7.15 geflasht. Hat soweit auch alles super funktioniert nur leider wird jetzt die Amplitude eines Signals auf allen Kanälen ca. 1 V zu niedrig angezeigt. Da ich das Gerät nur selten brauche und noch seltener mit Frequenzen über 100Mhz zu tun habe, habe ich die Hardware bis jetzt nicht angefasst. gibt es eine möglichkeit die Y-Verstärker neu zu kalibrieren oder muss ich jetzt auch das Hardwareupdate durchführen ?? lg Rudi
Angehängte Dateien:
-
Setup01.jpg
59 KB -
Setup02.jpg
54 KB -
HardwareSetup.jpg
58 KB
Hi Rudi, nein - keine Sorge, Du musst nichts an der Hardware ändern. Du musst lediglich einmal durch das Setup gehen und alles richtig einstellen. Das machst Du so: 1. Taste Utility -> Du bist im Setup 2. Default Setup -> alles wird erstmal auf Defaultwerte gesetzt 3. Calibrate Offsets -> das machst Du nachdem das Gerät warm ist (5 Min) 4. More -> Hardware -> Jetzt bist Du im Hardware Setup 5. ADC Setup -> Hab ich bei mir auf HighFreq1 stehen - probier es aus! 6. Pre Gain -> muss bei Dir auf Factory stehen, sonst falscher Pegel!!! 7. Gain -> dient zur Feinkorrektur - default ist 1.000 8. ADC Driver -> solltest Du Assembler wählen, ist schneller Das war's! Wichtig ist vor allem Pre Gain, das wird bei Dir vermutlich falsch eingestellt sein, aber geh einfach alle Schritte der Reihe nach durch, und dann ist alles korrekt eingestellt. Punkt 3 kannst Du beliebig oft wiederholen, aber wenn Du das im kalten Zustand machst stimmen die Nullpunkte später nicht mehr. Gruß Hayo
:
Bearbeitet durch User
Hallo, mein W2024 aus Ebay mit BF 1.5x Firmware funktioniert gut, ich will erst mal nichts ändern. Ich finde nirgendwo die originale W2000 PC Application mit welcher man die Screenshots vom DSO wohl per USB Bus am PC visualisieren konnte . Screenshot via RS232 ist natürlich möglich, USB wäre aber unkomplizierter . Grüsse Dietrich
Hallo Dietrich, ich hänge die Software hier mal an, da keine Copyright-Verweise drin sind. Mit der BF-Firmware arbeitet das Programm aber nur begrenzt zusammen. Einige Remotebefehle gehen, aber es werden keine Daten angezeigt (zumindest bei mir nicht). Das liegt daran, dass die zugrunde liegende Originalfirmware der Version 1.2 schon nicht funktioniert hat. Aktuell muss man dafür wohl die Version 1.3 oder 1.4 verwenden. Die USB-Funktion erkauft man sich dabei allerdings mit dem Verlust fast aller Funktionalität des DSO! Denn die originale Firmware kann eigentlich fast nichts. Nebenbei würde ich Dir auf jeden Fall empfehlen von BF 1.5x auf die letzte 7.15 aufzurüsten - da hat sich doch Einiges getan. Zu der Welec Software habe ich (glaube ich) auch noch die originalen Delphi-Sourcen, falls da jemand noch dran programmieren möchte. Es wäre wohl auch möglich die BF-Firmware so anzupassen, dass man das Programm wieder benutzen kann. Wäre aber wohl schon noch etwas Gefummel bis das läuft. Gruß Hayo
Hallo Hayo, Vielen dank für die schnelle Hilfe. Ich habe alles so gemacht wie du beschrieben hast, jetzt läuft es wieder so wie es soll :-) . P.S. Ist das Projekt eigentlich abgeschlossen oder wird noch weiter daran gearbeitet? Ich habe es über die Jahre mehr oder weniger sporadisch verfolgt. Leider besitze ich weder die Zeit noch das Fachwissen um aktiv daran mitzuwirken !! Gruß Rudi.
Prima, freut mich, dass ich helfen konnte. Sowas ist ja eigentlich nie abgeschlossen. Es gibt immer etwas was man da einbauen oder erweitern könnte - wie z.B. im Beitrag einen weiter oben die USB-Unterstützung für das Welec Programm. Aber aktuell habe ich auch nicht mehr soviel Zeit dafür. Schuld daran sind andere Projekte (mit dem RasPI z.B.) und diverse Outdoor-Freizeitaktivitäten. Aber laufenden Support mache ich noch so nebenbei (Fragen beantworten oder kleinere Bugs beheben etc.). Gruß Hayo
Angehängte Dateien:
-
IMG_5179.JPG
210 KB
Hallo Hayo , vielen Dank, die W2000PC Software funktioniert wie von dir angekündigt nur teilweise. Daten-Anzeige OK, steuern teilweise möglich,Screenhots werden nicht übertragen und die Scopeanzeige wird nicht am PC angezeigt . Ich hatte bzgl meiner Version Unsinn geschrieben, habe tatsächlich 1.2BF .7.13 C2. Welche Version des Screenshot Progr. müsste mit der Version funktionieren , Die neueren -bisher gefundenen- Screenshot ab Version BF Package 1.2- 0.96 scheinen mit dem DSO aktuell via Prolific/ RS232 nicht zusammenzuarbeiten ? Baudrate 9600 ist ok ? Ich bin zwar mit meiner Umschulung zum EGS fast fertig, Programme umschreiben ist mir aber noch zu viel, ich bin froh, wenn ich Arduino Programme einigermassen verstehe .. Gleiches gilt für das Risiko, dass ein Firmwareupdate schief geht, dann müsste man sicher im schlimmsten Fall den uC ausbauen , um ihn extern neu bespielen . Sofern ich nerve, kannst du meine Fragen gerne ignorieren.. Grüsse Dietrich
:
Bearbeitet durch User
Dietrich H. schrieb: > Screenhots werden nicht übertragen und die Scopeanzeige wird nicht > am PC angezeigt . Ja die Printroutine wurde komplett neu geschrieben und geht auf die RS232. Ich müsste mir mal die alte Routine ansehen, ob man die zusätzlich wieder einbaut. Ich glaube aber, dass das im Original etwas anders arbeitet als bei uns - da wird (so vermute ich) der Screenshot vom PC-Bildschirm erzeugt und nicht vom DSO-Bildschirm (so wie in der BF-Firmware). Aber wie gesagt sehe ich mir mal an... > Welche Version des Screenshot Progr. müsste mit der Version > funktionieren , Die neueren -bisher gefundenen- Screenshot ab Version BF > Package 1.2- 0.96 scheinen mit dem DSO aktuell via Prolific/ RS232 > nicht zusammenzuarbeiten ? Baudrate 9600 ist ok ? Also der Prolific-Adapter funktioniert bei mir einwandfrei. Die Screenshot-Versionen nicht durcheinanderwürfeln!!! Die gehören immer genau zu der Firmwareversion mit der sie ausgeliefert werden. Deshalb sind diese im Firmwarepaket auch immer mit enthalten. Nimm also das Programm aus Deinem Firmwarepaket. Die Baudrate musst Du nicht einstellen, das macht das Programm selbst. Du musst nur die Batch-Datei anpassen auf Deinen COM-Port. Bei mir ist das 1, weil ich noch einen echten Port habe. Die Adapter haben meist eine höhere Nummer (findest Du im Hardware Manager). Ich hänge mal meine Batchdatei hier an. > .. Gleiches gilt für das Risiko, dass ein Firmwareupdate schief geht, > dann müsste man sicher im schlimmsten Fall den uC ausbauen , um ihn > extern neu bespielen . Nein - keine Angst, da kann nichts schiefgehe! Das ist der Vorteil am RS232 Firmwareupdate. Da werden die internen Updateroutinen des Prozessors genutzt. Wenn das Update schiefgeht macht man es einfach noch mal :-) Anders ist das beim USB-Update. Da sind die Updateroutinen Bestandteil der Firmware. Wenn da was schiefgeht kann man danach nur noch die RS232 benutzen. Also nur keine Hemmungen. Ich habe auch noch originale Welec 1.3 und 1.4 Versionen im RS232 Updateformat falls jemand die alte Firmware (zum abgewöhnen) noch mal ausprobieren möchte. > Sofern ich nerve, kannst du meine Fragen gerne ignorieren.. :-) Keine Sorge, ich mache das gerne. Gruß Hayo
Hallo Hayo,danke, ich habe nun auf 7.15 geflasht , es ging mit dem USB/ RS232 wesentlich flotter als erwartet. Habe mich ein bisschen in das Gerät vertieft, man kann damit schon zielführend messen. Die Übertragung von Screenshots ist auch flüssiger als bei einem Tek , welches in der Schule benutzt wird. Die Befehle um das DSO per cmd zu steuern, haben bei mir noch nicht geklappt. scrsh.sh mit notepad geöffnet und daraus cmd Befehle senden, sollte zielführend sein ? Die Technik des Teils ist sicher sehr komplex, hoch auflösende D/A und alles schnell getakted um 200Mhz sauber auflösen zu können . Grüsse Dietrich
Hallo und frohe Ostern allerseits! Aktuell bin ich dabei die Kommunikation über USB mit der PC-Software zu überarbeiten. Das klappt auch schon ganz gut. Leider ist die Software genau wie die originale Firmware ziemlich buggy und hat etliche Macken. Da die Software keine Versionshinweise ausgibt, weiß ich nicht ob das die aktuellste Version ist. Meine ist vom 7.11.2007 - gibt es noch neuere Versionen ? Wenn ja, bitte Bescheid geben. Ich habe mal Delphi 7 installiert und mir die Sourcen angesehen, die ich hier noch rumliegen habe. Leider gehören die Delphi-Sourcen, die ich hier vorliegen habe, nicht zu dieser Software/Oszi Kombination, sondern zu einem anderen, einfacheren, Oszi, das die Firma Wittig wohl auch mal im Angebot hatte (Pencil-Oszi). Korrekturen an der PC-Software sind somit leider nicht möglich. Man müsste das komplett neu aufsetzen, was aber meine zeitlichen Möglichkeiten etwas sprengt. Die neue Firmwareversion und eine kleine Doku zur PC-Software folgt in Kürze... Gruß Hayo
New BF 8.0 out now! https://sourceforge.net/projects/welecw2000a/ Ok, dank Corona hatte ich etwas Zeit und habe mich - angeregt durch die Posts weiter oben - mit der USB Anbindung beschäftigt. Die neue Firmware arbeitet jetzt mit der WELEC PC-Software ganz gut zusammen. Leider sind noch sehr viele Fehler drin (in der PC-Software). Da zur Software bisher keine Anleitung existiert, habe ich mal eine Kurzanleitung in Deutsch und Englisch geschrieben. Da sind auch die Fehler und Grenzen der Software aufgeführt. PC-Software und Anleitung findet ihr hier: https://sourceforge.net/projects/welecw2000a/files/PC%20software/WELEC%20PC%20Software/ Vom Konzept her eigentlich ganz gut gemacht, hapert es leider an der Sorgfalt bei der Programmierung. Ich werde noch mal versuchen ob ich von den Wittigs die Sourcen bekomme, aber ich bin da eher wenig zuversichtlich. Rückmeldungen sind - wie immer - willkommen Viel Spaß beim Ausprobieren Hayo
:
Bearbeitet durch User
Hallo, da es Welec offenbar nicht mehr gibt (website down) frage ich ob man ein alternatives Osziloskop kaufen kann bei dem die Firmware funktioniert, das Oszi aber noch neu erhältlich ist.
Ja als Alternative für private Anwender kann ich die Geräte von OWON empfehlen. Ich selbst habe ein DS8102. Zu dem Thema habe ich hier im Forum auch schon Einiges geschrieben - such mal danach. Gruß Hayo
Hello Hayo, I downloaded the latest 1.2bf.8.0, thank you. But, with the quick measure doesn't switch source 1 or 2 in dual trace mode, remains in the last channel used.I have to switch off one channel to use it. As mentioned is very different from HP and Tekronix (just one button and the reading goes from 1 to 2 and viceversa)in my laboratory. Daily I use the W2022A , if it's not too difficult may be helpful for the users to have an easier function to select which channel QM. Let me know and thank you for your development. Kind regards, Sandro
Angehängte Dateien:
-
QM_01.jpg
57 KB
Sandro schrieb: > But, with the quick measure doesn't switch source 1 or 2 in dual trace > mode, remains in the last channel used. Hi Sandro - this is not a bug but a feature! It works exactly as designed. The idea behind this is to be able to quick measure on more than one channel at the same time, This gives you the ability to compare two signals. For better understanding I will give you an example: You have a signal which has to be amplified by an OPA. One measure point is on the input side (channel 1) and one measure point is on the output side (channel 2). Choose channel 1 as source and add measure peak-peak. Change the source to channel two and add measure peak-peak again. Now you can directly compare the signal levels (see screenshot). > I have to switch off one channel to use it. No - you don't have to switch off one channel. Simply clear the measure and add new ones with matching sources. > if it's not too difficult may be helpful for the users to have an easier > function to select which channel QM. This would disable the above described functionality. I think most users would be unhappy with this... :-) Kind regards Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
QM_01_ORIGINAL.jpg
58 KB -
QM_01_LB_MOD.jpg
57 KB -
QM_01_OPA656.jpg
57 KB
Just for information - for the adjustment of the USB signal factors a friend gave me his unmodified W2020A and I had the opportunity to compare my two modified devices with the original hardware version - amazing! I didn't remember that it was so bad. Here the quick measure scenario from above on the three different versions (Original, LB-Mod and OPA656). german: Ein Freund und ehemaliger Studienkollege hat mir freundlicherweise sein unmodifiziertes W2020A zur Verfügung gestellt. Der Vergleich der Geräte war ziemlich ernüchternd. So stark hatte ich das Rauschen nicht mehr in Erinnerung. Wenn das keine Motivation zur Umrüstung ist... Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
QM_01_OWON.jpg
81 KB
And to show you that the WELEC oscilloscope is not so bad as sometimes said -here the same measurement with the OWON SDS8102. There is also much noise on the signal (more than on the modified WELECs) and the menu handling is not so good as with the W2000A. @Sandro - by the way - the quick measure works in the same way as in the W2000A. The source is always constantly assigned to one measurement and can't be changed. You have to remove a measurement first - then you can add a new one with new source. german: Also im Vergleich hier mal das OWON mit den gleichen Signalen. Hier ist auch ein ziemliches Rauschen drauf. Die modifizierten WELECs schneiden hier deutliche besser ab. Auch das Menu-Handling ist deutlich angenehmer als beim OWON. Da musste ich ziemlich rumfummeln bis ich dann die mikroskopisch kleinen Messergebnisse unten am Schirm eingeblendet bekam. So schlecht sind diese W2000A Büchsen bei durchschnittlichen Anwendungen also gar nicht. Für mich jedenfalls angenehmer zu bedienen als die Konkurenz aus China. Gruß Hayo
:
Bearbeitet durch User
Hello Hayo, I see, will use in that way the dso,connected to a frequency counter I built. I hope you don't abandon the seral decoding project with the W2022, may be you remember we exchanged some informations about. Thank you, Sandro
Da es anscheinend einige gibt, die das Kommandozeilenprogramm zum Erzeugen von Screenshots (und mehr!) in Zeiten des Mausklicks nicht so gerne benutzen, hier noch mal eine kurze Anleitung und Tips. Wer, wie ich, seinen seriellen Anschluss auf COM1 liegen hat, kann einfach das Programm w2000a-screenshot.exe starten und am Oszi durch Doppeldrücken der Quick Print Taste den Screenshot starten. Wer einen anderen Port nutzt muss dies als Argument übergeben: w2000a-screenshot.exe -c 4 Bei diesem Aufruf sucht das Programm auf COM4 nach dem Oszi. Bei Verwendung eines Prolific USB zu RS232 Adapters kann es manchmal zu Problemen mit dem Treiber kommen. Die Folge ist, dass der COM-Port nicht erkannt wird bzw. nicht geöffnet werden kann. Hier hat bei mir die Installation eines älteren Treibers geholfen. Anleitung und Download findet man hier: https://itler.net/prolific-usb-to-serial-comm-port-error-code-10/ Bildformat konvertieren: Das Programm erzeugt PPM-Dateien. Das ist ein einfaches unkomprimiertes Bitmap Format. Dieses Format kann man mit einem Grafikprogramm (z.B. IrfanView in JPG umwandeln). Ich benutze dafür das Kommandozeilenprogramm mogrify von ImageMagick welches ich in das Screenshotverzeichnis kopiert habe. Der Aufruf mogrify.exe -format jpg *.ppm wandelt alle PPM-Bilder im Verzeichnis in JPG um (die Originale bleiben bestehen). Das habe ich in eine Batchdatei geschrieben und auf den Desktop gelegt. Wie kommt man an das Programm? Auf der Homepage von ImageMagick einfach die Programmsammlung als ZIP-Archiv herunterladen und auspacken. ftp://ftp.imagemagick.org/pub/ImageMagick/binaries/ImageMagick-7.0.10-10 -portable-Q16-x86.zip oder https://imagemagick.org/download/binaries/ImageMagick-7.0.10-10-portable-Q16-x86.zip Das Programm mogrify kopiert man dann einfach ins Screenshotverzeichnis. Schönen Start in den Mai Hayo
:
Bearbeitet durch User
Hallo Leute, ich versuche seit fast ner halben Stunde mein Welec W2014A mit der aktuellen FW zu flashen. Ich benutze den W202X-Firmware Updater. Leider bekomme ich an unterschiedlichsten stellen, mal bei 1/3, mal bei der Hälfte, mal etwas mehr als die Hälfte einen TimeOut. Kennt jemand die Ursache bzw. eine Lösung? Das Oszi funktioniert jetzt natürlich nicht mehr. Da ja nur ein Teil geflasht worden ist. Nachtrag: Mit dem Kommandozeilentool hat es funktioniert. Danke und Gruß.
:
Bearbeitet durch User
Angehängte Dateien:
-
Upload.jpg
14 KB
Hallo Georg, das Problem kenne ich noch nicht. Gerade habe ich eines meiner Geräte mit dem Windows Updater geflasht - keine Probleme. Interessant wäre zu wissen, welche Konstellation Du genau verwendet hast. Bei mir sieht das so aus: Programm: WelecUpdate.exe (beiliegendes Windowsprogramm) Port: COM1 (echter RS232 COM-Port, kein Konverter) OS: Windows 7 (32 Bit) Dauer: 160s Gruß Hayo
Beitrag #6266968 wurde von einem Moderator gelöscht.
Hi Hayo, Das Tool ist aus deinem download. Mein System : Windows 7 pro 64Bit Echte rs232 an der HP dockingstatio Gruß Georg
Hallo, ich habe gerade IR Fernbedienungscodes untersucht, und dazu das Oszilloskop bei "Aquire" auf "TTL-5V" gestellt, mit timebase 20ms. Geht wunderbar, aber ich kann die Timebase nur Richtung kleiner stellen, also 10ms, 5ms, 2ms usw. Wenn ich wieder größer stellen will, geht es nur bis 10ms. Um auf Werte auf länger als 10ms zu stellen, muss erst der Digital Logic Mode auf "OFF" gestellt werden, dann kan man auch auf längere Werte stellen. Wird zurück auf (irgendeinen) Digital Logic gestellt, dann kann man zwar mit z.B. 100ms messen, aber nur auf kleinere Werte stellen. 10ms scheint eine harte Grenze zu sein. Ist mir aufgefallen mit Version 7.13, ist aber bei der aktuellen 8.0 immer noch so. Habe ich da ein Feature übersehen, oder ist das ein Fehler? Gruß, Bernhard
Oha! Da bin ich auf die Schnelle überfragt. Muss ich mir mal ansehen. Ich kann mir eigentlich nicht vorstellen, dass es als Feature gedacht war, hört sich eher an wie ein Bug der aber mangels Tests nicht bemerkt wurde. Ich muss mal sehen wann ich dazu komme, hier geht gerade die Segelsaison zu ende und ich bin ziemlich eingespannt alles winterfertig zu machen. Gruß Hayo
So, Boot ist auf dem Trockenen und ich bin inzwischen dazu gekommen mir das Problem anzusehen. Tatsächlich ist das von Bernhard berichtete Verhalten so gewollt gewesen und es ist ein Limit eingebaut worden - warum weiß ich allerdings nicht mehr. Ich vermute, dass das irgendwie mit dem USTB-Modus zusammenhing. Leider war das Ganze auch nicht 100%ig implementiert, so dass man mit höheren Timebases einspringen konnte, aber das Hochschalten dann blockiert wurde. Ich habe das jetzt geändert und es stehen alle realen Timebases zur Verfügung. Maximum Tb ist jetzt 500ms. Langsamer geht nicht, da jenseits davon die USTB Roll- und Shiftmodes anfangen. Ein Quereinspringen mit langsameren Tb ist auch nicht mehr möglich, da der USTB Modus den Logic-Modus blockiert. Falls noch Unregelmäßigkeiten auftreten, bitte hier posten. Die neue Version 8.1 gibt es hier: New bugfix version 1.2.BF.8.1 https://sourceforge.net/projects/welecw2000a/files/ Ansonsten hoffe ich, dass alle gesund sind und auch bleiben. Gruß Hayo
:
Bearbeitet durch User
Hallo zusammen, ich habe folgende Oszi-Version: Modell: W2012A HW: 3C7.0E SW: 1.3 Ich habe das Oszi mal von der Firma vor ein paar Jahren bekommen da es nicht richtig funktionierte. Inzwischen habe ich mich noch mal mit dem Thema beschäftigt und habe hier die Möglichkeit einer Open Source FW gefunden. Leider tut sich inzwischem am Oszi gar nichts mehr, d.h. es startet zwar normal, ich bekomme aber kein Signal angezeigt. Weder an CH1, noch an CH2 kann ich das 1kHz Rechtecksignal des Oszis sehen. Das dort noch etwas heraus kommt, habe ich mit einem billigst Selbstbau-China-Oszi erfolgreich prüfen können. Außerdem fällt auf, dass die Amplitude sowie Zeitbasis nicht mehr richtig eingestellt werden können. Es scheint nur noch 10mV und 5V sowie 10ns/ und 200s/ zu geben. Sind diese Fehler bekannt? Ist das reparabel? Oder leigt das vielleicht direkt an der tollen Original-FW? Außerdem wollte ich die aktuelle Firmware sichern und dem Germs-Monitor starten. Das drücken der linken beiden Tasten (erst die Linke, danach kurz die Zweite) funktioniert nicht. Die Tasten selbst funktionieren aber. Ist hier evtl noch mehr defekt? Gruß osbln
:
Bearbeitet durch User
Hallo Oliver, die von Dir beschriebenen Symptome lassen nicht direkt auf einen der bekannten Fehler schließen. Generell hört sich das aber erstmal nicht unbedingt so schlimm an. Da sich in der Vergangenheit immer wieder Kontaktprobleme als Ursache herausstellten, wäre mein Vorgehen wie folgt: 1. Gerät komplett zerlegen (also alle Boards ausbauen) - ist nicht schwer. Anleitungen findest Du im Hardwarethread (Wittig(welec) DSO W20xxA Hardware) oder hier in der Doku zur LB-Mod: https://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/ Eine detailierte Beschreibung zum Abziehen der wirklich festsitzenden Drehknöpfe findest Du in der Doku Ext_Trigg_Mod. Du kannst aber sonst das Board mit den Drehreglern erstmal drin lassen und nur das darüberliegende Board ausbauen. 2. dann alles wieder zusammenbauen und dabei an den Steckverbindungen etwas herumwackeln (insbesondere am Displaystecker, den Du schon beim Abnehmen der Rückwand siehst) 3. Wenn das Teil wieder komplett ist, versuch mal die neue Firmware aufzuspielen. Achtung, das geht nur mit dem seriellen RS232 Kabel - nicht über USB! Die Firmware gibt es hier: https://sourceforge.net/projects/welecw2000a/files/latest/download Geflasht wird mit dem beigelegten Updateprogramm. Anleitungen dazu sind ebenfalls im Paket enthalten. Das Flashen ist völlig unkritisch und kann bei Abbruch jederzeit wiederholt werden. Das Sichern der alten Firmware kannst Du Dir eigentlich sparen, denn: 1. Kannst Du hier die Versionen 1.2 bis 1.4 jederzeit bekommen 2. Taugt die Firmware leider zu gar nichts und ist eigentlich nicht benutzbar. Bei weiteren Fragen stehe ich gerne zur Verfügung. Gruß Hayo
Hallo Hayo, vielen Dank für dein Feedback. Was ich allerdings merkwürdig finde und daher nicht auf ein mechanisches bzw. Kontaktproblem eingrenzen würde ist, dass die Drehregler bei einer Rastung scheinbar immer das Maximum in die entsprechende Richtung auslösen. Beide Kanäle und selbst bei der Timebase. Über Autoscale konnte ich dann wenigstens noch das 1kHz Signal sehen, welches nun auch nicht mehr erscheint. Ich werde die kommenden Tage mal das von dir genannte durchführen. Sollte mir nicht so schwer fallen da ich beruflich schon mehrere Oszis von Keysight und Hameg zerlegt habe um aus 2 Defekten wieder ein funktionierendes herzustellen ;) Danke und Gruß
:
Bearbeitet durch User
Hallo zusammen Erstens, bitte vergib mir mit Google Übersetzer, ich bin Engländer, es kann nicht geheilt werden! (Ich habe das Original Englisch am Ende aufgenommen). Zweitens, Entschuldigung, wenn dies bereits beantwortet wurde, das Forum ist sehr lang und Google übersetzt nur Schnipsel für mich! O.K., zum Geschäft! Ich habe ein großes Problem mit meinem 2-Kanal-W2022A mit der Autoscale-Funktion in ALLEN Firmware-Versionen nach 2.15 (März 2011!). Wenn Sie die automatische Skalierung aktivieren, wird die Zeit- UND Spannungsskala in 90% der Fälle nicht korrekt eingestellt (und wenn das Eingangssignal zu empfangen scheint, ist es wahrscheinlich zufällig, da es jedes Mal leicht unterschiedliche Einstellungen aufweist). Meistens endet es nur bei 5 V Div und ein paar nS Div. Die manuelle Suche findet das Signal, das vorhanden ist, sodass die automatische Skalensuche fehlschlägt und nicht die Signaleingabe. Die automatische Skalierung versucht (friert nicht ein), ... es gibt verschiedene Klicks und das Popup "Autoscale TB 2ms 2ns" (so ähnlich!) Wird angezeigt. Dieser Fehler tritt bei allen Signalen auf, die ich darauf geworfen habe. niedrige und hohe Frequenzen (1 kHz - 1 MHz), niedrige bis hohe Spannungen (100 mV - 5 V), Sonden mit mehreren Oszilloskopen, mehrere Signalquellen. Und um es zu wiederholen, ich habe Firmware von jeder Hauptversion installiert (OS-0.92; BF-1.11; BF-2.15 BF-3.0c6; BF-4.9c2; l BF-5.10; BF-6.10; BF-7.15). Alle Versionen NACH 2.15 verhalten sich gleich. Ich habe mich auch tief in die Menüs eingegraben und alles versucht, was ich sehen kann, ohne Wirkung. Da ich mir nicht vorstellen kann, dass alle guten Leute seit März 2011 so hart daran arbeiten und einen so schwerwiegenden Fehler hinterlassen, glaube ich, dass MEIN Problem entweder eine einfache Einrichtung sein muss, die mir fehlt, etwas Besonderes für mein Gerät oder mein Modell (2-Kanal W2022A) ). Alle Ideen, die Sie anbieten können, wären sehr dankbar. Dies ist nicht kritisch, aber es scheint eine Schande zu sein, von den vielen vielen Korrekturen und Verbesserungen ausgeschlossen zu sein, an denen Sie seit 2.15 im März 2011 hart gearbeitet haben! Modell: W2022A HW: 8C7.0L FW: Alles NACH 1.2.BF.2.15 (09.03.2011) Danke schön Paul ########## ENGLISH ########## Hello Everybody Firstly please forgive me using google translate, I'm English, it cannot be cured! (I've included the original English at end). Secondly, apologies if this has already been answered, the forum is very long and google will only translate snippets for me! O.K., To Business! I'm having a big problem with my 2 channel W2022A with the Autoscale function in ALL firmware versions after 2.15 (March 2011!). Basically, hitting autoscale fails to correctly set the time AND voltage scales 90% of the time (and when it does seem to catch the input signal, it's likely random as it's at slightly different settings every time). Most often it just ends up at 5v/div and a few nS/div. Manual search finds whatever signal is there so it's the autoscale search that is failing not the signal input. The autoscale tries (doesn't freeze),...there are various clicks and the "Autoscale TB 2ms 2ns" (something like that!) popup is given. This failure happens for all signals I've thrown at it; low and high Frequencies (1Khz-1MHz), low-high Voltages (100mv-5v), multiple scope probes, multiple signal sources. And to repeat, I've installed firmware from every major release (OS-0.92; BF-1.11; BF-2.15 BF-3.0c6; BF-4.9c2;l BF-5.10; BF-6.10; BF-7.15). All versions AFTER 2.15 behave the same. I've also dug deep into the menus and tried everything I can see, to no effect. As I cannot imagine all you good people working so hard on this since March 2011 and leaving such a serious flaw, I believe MY problem MUST either be some simple setup I'm missing be something peculiar to my device or my model (2 channel W2022A). Any ideas that you can offer would be much appreciated. This is not critical but it seems a shame to be locked out of the many many fixes and improvements you have worked hard on since 2.15 in March 2011! Model: W2022A HW: 8C7.0L FW: Everything AFTER 1.2.BF.2.15 (2011-03-09) Many Thanks Paul
Just checked on my W2022A 1.2.BF.7.13 | 8C7.C9: Autoscales doesnt work
At least I'm not alone! (sorry for your troubles!) Try v2.15 or before. Like I said, I tried the final version of every major release (the final "Y" of every "X" in "1.2.BF.X.Y"). Every single one failed until I got back to 2.15, then the autoscale worked properly in everything I tried (BF.1.11, OS.0.92a and original Wittig FW14/13) ####### Zumindest bin ich nicht alleine! (Entschuldigung für Ihre Probleme!) Versuchen Sie v2.15 oder früher. Wie gesagt, ich habe die endgültige Version jeder Hauptversion ausprobiert (das endgültige "Y" jedes "X" in "1.2.BF.X.Y"). Jeder einzelne schlug fehl, bis ich wieder auf 2.15 zurückkam, dann funktionierte die automatische Skalierung bei allem, was ich versuchte, ordnungsgemäß (BF.1.11, OS.0.92a und Original Wittig FW14/13).
Hi Paul, nice try to translate with google - and it's not so bad. But there is no need for translation. Most people here speak english too (if it is not to hard for you to read our school english...) and there are some other people from english speaking countries too. So let's come back to your problem. You are right - shame on me - the Autoscale function ist not working reliably. I spent a lot of time with optimizing this part of the firmware. But due to other problems that had a higher priority I decided to leave it half-done (to finish it later). After a long time solving other problems I really forgot this issue. Mea Culpa... So I will try now to give you a better working solution in the next time. I'll keep you informed. Regards Hayo
Hello Hayo Thanks for your response, the dedication of you guys to this project is really inspiring! I hate the waste of trashing old but functional equipment and your efforts to keep this device useable are admirable. Please don't sweat putting this issue aside you've produced an amazing amount of fixes and upgrades. I probably rely on autoscale too much from bad engineering habits but for debugging failing HW it seems useful! If there's anything I can do to help I'll try my best. Maybe I can verify changes on the 2022A if you guys don't have a lowly 2-channel model available! If you need me to test/characterize any older versions I'm happy to do so. Thanks again and stay well! Sincerely Paul P.S. Your "School English" is near perfect, and better than many natives where I was born (Essex, UK). Regrettably I really tried to learn German as a youngster but failed. I can actually understand most of what Google produced but creating new stuff is beyond me.
Ok folks - good news! The Autoscale function (which hasn't functioned correctly at any time) is now working reliably under every circumstances. That means I didn't find any signal that couldn't be detected by the Autoscale. I tested with all signals that my signal generator can produce - with positive and negative offset and so on. Detailed specs and limits can be read in the Special Functions.txt in the Doc directory or as download above. I tested on my 4 channel device with LB-mod and on my 2 channel device with OPA653 mod. What I couldn't test is an original unmodified W2000A. So please can anyone test it and report the result? The new firmware 8.2 can be downloaded here: https://sourceforge.net/projects/welecw2000a/ Thanks for reporting any problems Hayo
Meanwhile I found an issue with inverted signals. I'm working on a solution... Hayo
Angehängte Dateien:
-
LevelStep8thDiv.jpg
230 KB -
LevelStep8thDiv.jpg
230 KB -
LevelStep8thDiv.jpg
230 KB
That's fantastic Hayo. Thanks for your efforts! I can confirm that on my UNMODIFIED (at the moment!) W2022A, your fix has made the autoscale much better. I've only performed some quick tests so far but I have some HW debug to do in the next day or so so I should have more data soon. The only oddity I've seen so far (unrelated to autoscale) is a peculiar small step down on ALL signal traces at the 8th screen division (i.e. unrelated to timebase, always after the 8th horizontal division) . It's a small step, maybe about 5% of full scale. I'll try to upload a picture with this post. This happens for all horizontal and vertical settings, for both channels and for both probes I have. It IS much less pronounced when using the probe in x1 mode so, whether it's HW or FW related, the absolute input voltage does seem affect it (a x10 probe applied to the same input signal will send a much smaller voltage for the HW/FW to operate on). I saw this on earlier FW revisions as well so this isn't related to your 8.2 fixes. I haven't categorized which versions exhibit this behavior but IF anyone is interested, I'm happy to do so. I'll also set some time aside to see if I can mitigate it with some deep menu settings) This could just be a problem with MY hardware but I'd be interested if anyone else has ever seen this strange behavior.
SORRY for triple identical picture attachments! The blog was rejecting my IP (I use a VPN) and seemed to want me to re-attach picture on each attempt.
I suspect that the offset step is definitely somewhere in the FW - for analog/HW problems the step onset time would scale with the timebase (not be fixed at a % of visible window) - analog/HW problems would also likely not be such a discrete step - I don't recall this issue in early firmware My best guess on the cause is that a DC offset correction is not being applied to the full visible window. Perhaps an array buffer used in the processing of the window is too short or array pointer ranges are being mis-calculated
Just checked on my W2022A 1.2.BF.8.2 | 8C7.C9: I am not able to reproduce your latest problem. Can you provide a short guide how to reproduce?
Hello If you're talking to me about the step offset,... Well, I just power cycled the scope (which DID do before!) and at this moment I cannot reproduce it! Please everyone ignore (and forgive) me just for the moment. I'll devote some proper time to attempting to reproduce and categorize it. (I swear it was consistently there earlier, and has been in the past) Apologies!
Hi, may be your step down has to do something with the pretrigger. If this occurs again try to scroll through your sample memory (timeline) but I can't produce it as well. But something different. I found some more issues and fixed some of them. I 'm working on the new version, which will be available during the next week. Also I changed the Autoscale again and made it work as my other oscillopes. That concerns the DC offset and inverted signal detection. Also I changed the complete inverted signal processing for I was unhappy with it. Hayo
:
Bearbeitet durch User
Hello again! As promised the new version 8.3 is out now. I made the most extensive changes since 7 years! In my tests all functions performed stable. But as you know - a little bug can always remain. So don't hesitate to report it here. ----------------------------------------------------------------- Hi Leute! wie versprochen ist die neue Version 8.3 jetzt verfügbar. Es sind die umfangreichsten Änderungen seit 7 Jahren! In meinen Tests lief alles stabil. Aber - kleine Fehler schleichen sich immer mal ein. Also nicht zögern Selbige hier zu berichten. Download link as always: https://sourceforge.net/projects/welecw2000a/ regards/Grüße Hayo
Ok folks, I had a run and spent a lot of time the last days with testing, debugging, fixing and optimizing. The result is the new version 8.4, which is (naturally) the best version ever... :-) Download is available now on SourceForge. ----------------------------------------------------------------- Hi Leute, ich hatte einen Lauf und habe viel Zeit in den letzten Tagen mit testen, debuggen, Fehlerkorrektur und optimieren verbracht. Das Ergebnis ist die neue Version 8.4, die (natürlich) die beste Version von allen ist... :-) Download auf SourceForge. @Andi Danke für's Einchecken! Ich habe keine Ahnung mehr wie das geht - und auch irgendwie keine Zeit mehr mich da neu rein zu fummeln. https://sourceforge.net/projects/welecw2000a/ regards/Grüße Hayo
Angehängte Dateien:
-
FFT_QM_Testsignal.jpg
52 KB -
FFT_QM_01.jpg
49 KB -
FFT_QM_02.jpg
50 KB -
FFT_OWON.jpg
58 KB
Hi there, I enjoyed the last weeks to work on the project again and so I decided to create the traditional Easter Edition with a new "nice to have" feature - the QM (Quick Measure) for FFT. I saw it - years ago - on a very expensive professional spectrum analyser and immediatly I wanted it for us too. But always other issues took my time and I forgot it. But now - I did it. The yellow screenshot was made with the internal test signal (Utility -> Test Signal) - the green ones with a real square wave signal at 200KHz and 300KHz. Hope you enjoy it and it makes spectrum analysis a bit more comfortable. As comparison the FFT of a commercial device (OWON) with the same 300KHz signal. _________________________________________________________ Moin, die letzten Wochen habe ich es ziemlich genossen mal wieder an unserem Projekt zu arbeiten und habe mich daher entscieden unsere traditionelle "Easter Edition" rauszubringen. Diesmal mit einem neuen "nice to have" feature - Quick Measure für die FFT. Hab ich mal vor Jahren bei einem echt teuren Spektrum Analysator gesehen und fand es so cool, dass ich das auch für uns implementieren wollte. Irgendwie kam aber immer was dazwischen und ich hab's irgendwann vergessen. Aber jetzt habe ich es einfach mal umgesetzt. Der gelbe Screenshot wurde mit dem internen Testsignal (Utility -> Testsignal) erzeugt, die grünen mit einen echten Rechtecksignal bei 200KHz und 300KHz. Ich hoffe ihr mögt es (braucht man ja eigentlich nicht so oft...) und es erleichtert die Spektrumanalyse etwas. Als Vergleich mal die FFT eines kommerziellen Gerätes (OWON) mit dem gleichen 300KHz Signal. @Andi Bist Du wieder so nett, die neue Version einzuchecken? Frohe Ostern Hayo p.s. ach ja - die neue Version 8.5 gibt es natürlich auf SF-Net zum Download
:
Bearbeitet durch User
Angehängte Dateien:
-
P_20210409_213018_3_p.jpg
330 KB -
P_20210409_213049_p.jpg
310 KB
Hallo Hayo, I tested the last fw , really nice improvements,autoset works up to 250 MHz. I found only a bug in the save function for FFT, as photo attached I saved the memory but the recall is empty. Thanks for your help. Regards Sandro
Hi Sandro, thank you for testing and reporting. That is no bug - what you found out, is that I didn't implement this function yet :-) (and I also forgot to block the button in FFT-mode) But that is a good hint, I will try to make it available in the next version. Regards Hayo
Danke schön Hayo für Deine Arbeit. Toll das Du das Projekt am Leben hältst. cheers oscar
Danke für das Lob, hier kommt auch schon die neue Version 8.6. Ich mach mal auf Englisch weiter für unsere Freunde aus dem nichtdeutschen Sprachraum. Hi there, and thanks to Sandro for the hint with the Save/Recall function for FFT. The new version 8.6 is available now: https://sourceforge.net/projects/welecw2000a/ What is new? Of course the Save/Recall for FFT. Due to the fact that the signal is stored in the memory as time signal I implemented the possibility to switch between time (main) mode XY mode FFT mode after recall from memory. This affects the normal Stop mode also as it is identical to the system status of Trace Recall. Also new is the possibility to change FFT parameters while the FFT is in Stop mode or Recall mode. Changes will take effect immediatly. The new QM value display is switchable in Stop mode as well now. So it is not important if you store your signal in time (main) mode or FFT mode, as you can switch around after recall as you like. Hope you like the new functions - and don't forget to report any inconsistency. regards Hayo
Hallo ich habe ein defektes Welec W2014 A? in die Finger bekommen. Der Infobildschirm zeigt seltsames an: Modell W0000A HW 8C7. SW 1.10.00 SN 0000000000 Es scheint ein A zu sein der Text ist wie auf den Bildern der russischen Seite auch auf meinem Layout zu sehen Das IC ist auch gleich. Die beiden Kondensatoren kann ich nicht sehen weil 4-Kanal. Der GERMS Monitor lässt sich nicht starten. Über serielle Kommunikation kann ich zugreifen Shift-Y und Shift-X bekomme ich einen dunklen Screen mit einen gelben Rechteck. Aber kein Upload möglich. Ich nehme an, dass mein Vorgänger den ECPS16-Konfig-Flash getötet hat und ich ihn wieder flashen muss. Ich will erst einmal die Software auf einen besseren Stand bringen um dann zu sehen ob noch mehr im Argen liegt. Gruß Jürgen
Oha! Das hört sich interessant an. Ich denke auch, dass man da wohl erstmal mit dem Altera Blaster ran muss. Denn wenn der Germs-Monitor nicht startet kommt man nicht weiter. Die Frage ist natürlich, ob evtl. Bauteile defekt, oder kalte Füße Mitverursacher sind. Halte uns mal auf dem Laufenden... Gruß Hayo
Hallo Hayo, euch allen die ihr schon seid Jahren am Ball seid zollt mein höchster Respekt. Hab das Teil einmal vollständig zerlegt sieht alles recht ordentlich aus. Es sind keine Auffälligkeiten zu bemerken. Die Kontakte der RAM und Rom Bausteine sehen gut verlötet aus. Wurde auch zum Glück nicht verbastelt das ist jetzt mein Part :-). Nun warte ich auf den USB Blaster. Die JTAG Brücke, nehme ich einmal an, muss gelötet werden? Muss es ein 0 Ohm Widerstand sein oder geht auch eine Drahtbrücke. So kleine SMD Widerstände habe ich nicht. Muss die Brücke wieder entfernt werden? Hat eigentlich jemand den Original EPCS16 Flash für das W2014A? Oder macht es nichts wenn ich die "Original_EPCS16_for_W2022A" flashe? Oder ist es die "W2022-EPCS16"? Viele Fragen ich weiß. Gruß Jürgen
Angehängte Dateien:
-
USB_Blaster_connected.jpg
200 KB -
JTAG.jpg
210 KB
Hi Jürgen, die meisten der alten Garde haben inzwischen neue Projekte, verfolgen aber den Thread weiterhin. Ich selbst mache ja auch nur hin und wieder mal was Neues und sonst eher Bugfixing. Ja - die Brücke musst Du löten. Draht reicht völlig. Die Brücke kann drin bleiben. Ich habe meinen Blaster immer auf dem Board stecken und lege ihn dann lose ins Gerät, damit der Deckel zugeht. Dann muss ich nicht lange überlegen wo ich das Ding rumliegen habe, oder wie rum ich den Stecker draufstecken muss. Zum Programmieren kann man ihn dann rauslegen und den Deckel nicht allzufest wieder draufschrauben. Ich habe das Flachbandkabel an der Stelle wo es eingeklemmt wird einfach mit Tesa umwickelt. Wenn Du mit dem "Original_EPCS16_for_W2022A" nicht weiter kommst (einfach mal probieren im temporären Modus), kann ich das sonst bei mir auslesen, der Blaster steckt bei mir auf dem Vierkanalgerät. Ich müsste nur die Altera Software wieder auf meinem Rechner installieren und mal kurz überlegen wie das Ganze funktioniert. Hab ich schon länger nicht mehr gemacht. Einige hier sind da aber viel besser mit vertraut als ich und können da bestimmt auch weiterhelfen. Gruß Hayo
Hallo, ich habe jetzt versucht den FPGA zu flashen. Quartus II Programmer Version 13.0.1 Windows XP, Altera USB Blaster mit Treiber usb_blaster_q16.1. Datei W2022-EPCS16-Bak.jic Jetzt habe ich auf dem Display nur noch bunte senkrechte Streifen und sonst ist alles tot. Sichern des Flashs hat leider nicht geklappt.:-( Ich denke ich brauche den originalen W2014 Flash oder auch dem vom W2024 wenn ich es richtig verstanden habe unterscheiden beide sich nur durch die Auswahl der Eingangsverstärker. Bei der Anleitung "Upgrade W2012 auf W2012A" habe ich nicht verstanden wieso man das braucht "USB-Blaster v.1.1 installiert". Bin für Rat und Flasch dankbar. Gruß Jürgen
Hi Jürgen, erst mal zum USB Blaster. Es gibt eine Möglichkeit direkt über USB auf das FPGA zuzugreifen. Der USB-Blastertreiber (V1.1) simuliert dabei einen Hardware Blaster. Hat bei mir damals nicht funktioniert, weil ich den Treiber irgendwie nicht so richtig installiert bekommen habe. Daraufhin habe ich mir den besagten Hardware Blaster besorgt. Der dazugehörige Treiber ist in der Altera Software enthalten. Den kann man da auswählen. Im Quartus müsstest Du dann nach dem Anschließen beide FPGAs sehen können. Ich habe das jetzt nicht mehr so genau in Erinnerung, was da noch angezeigt wird. Das Flash meine ich wird auch angezeigt. Wenn Du die W2022-EPCS16 Datei flashst müsstest Du anschließend zumindest auf jeden Fall ein Zweikanalgerät haben. Beim Vierkanalgerät ist aber das zweite FPGA meines Wissens identisch. Was die Bezeichnung W2014A oder W2024A angeht, mach Dir keinen Kopf. Da ist wirklich nur der Eingangsverstärker unterschiedlich, das FPGA und auch die restliche Hardware ist gleich. Ist nur ein winzig kleines Bauteil... Was Du da jetzt erzählst, hört sich ein wenig danach an, als wenn Du ein W2000 ohne A hast. Dann solltest Du die Anleitung zum Umrüsten mal durchgehen. Dazu passt auch die Aussage, dass der GERMS Monitor nicht startet. Das geht nämlich beim W2000 ohne A nicht. Auch die Streifen hatte schon jemand als er ein W2000 mit neuem FPGA beglücken wollte. Die Umrüstung hat mehrfach funktioniert soweit ich weiß. Danach das Teil flashen und Du hast ein echtes W2000A. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, Danke für die Zeit. Komme momentan nicht weiter. Blue F. schrieb: > Im Quartus müsstest Du dann nach dem Anschließen beide > FPGAs sehen können. Bei mir ist nach autodetect nur ein FPGA zu sehen sonst nichts. Wenn ich die Datei W2022-EPCS16-Bak.jic ins Programm lade sind es 1 FPGA und das FEPCS16. Blue F. schrieb: > Was Du da jetzt erzählst, hört sich ein wenig danach an, als wenn Du ein > W2000 ohne A hast. Dann solltest Du die Anleitung zum Umrüsten mal > durchgehen. Meinst du die Anleitung "Upgrade_W2012_auf_W2012A_de.pdf" ECPS16-Konfig-Flash per JTAG über USB ausgelesen und gesichert hat nicht geklappt. -den ECPS16-Inhalt von slog2's W2022A per JTAG aufgespielt und neugestartet. Nach der Anleitung sollte zumindest der Startbildschirm erscheinen. Habe ich es versucht mit dem Ergebnis Streifen, oder gibt es noch eine andere Anleitung. Blue F. schrieb: > Auch die Streifen > hatte schon jemand als er ein W2000 mit neuem FPGA beglücken wollte. Die Einträge habe ich leider nicht gefunden. Stehe momentan auf den Schlauch. Gruß Jürgen
> Blue F. schrieb: >> Im Quartus müsstest Du dann nach dem Anschließen beide >> FPGAs sehen können. > Bei mir ist nach autodetect nur ein FPGA zu sehen sonst nichts. > Wenn ich die Datei W2022-EPCS16-Bak.jic ins Programm lade sind es 1 FPGA > und das FEPCS16. Ok, das müsste ich mal bei mir gegenchecken. > Meinst du die Anleitung "Upgrade_W2012_auf_W2012A_de.pdf" Ja genau die... > ECPS16-Konfig-Flash per JTAG über USB ausgelesen und gesichert hat nicht > geklappt. Die Beschreibung bezieht sich auf den Software-Blaster. Aber das Auslesen mittels Hardware-Blaster sollte schon klappen. Allerdings musst Du eigentlich keine Sicherung machen. Was da jetzt drauf ist, ist eh nicht lauffähig. > Stehe momentan auf den Schlauch. Ok, dann muss ich wohl mal den Quartuskram installieren und noch mal sehen wie es dann bei mir aussieht - es sei denn einer der Anderen hier hat noch seine Installation parat und kann da weiter helfen. Jörg ist da ja einer der Experten. Ich weiß aber nicht ob er das hier noch verfolgt. Gruß Hayo
Hallo Hayo, ist echt cool von dir dich noch einmal rein zuhängen. Ich werde das Ozi noch einmal zerlegen und den Aufbau insbesondere die nachträglich verlegten Drahtbrücken kontrollieren eventuell gibt es da Unterschiede zum A Modell. Ich forste auch die Hardware Beiträge durch. Leider gehen so manche Links ins leere. Gerade diese währen sehr interessant z.B. https://sourceforge.net/apps/trac/welecw2000a/wiki/..... Werde mir auch noch die beiden Rams auf der Oberseite vornehmen wobei ich kalte Lötstellen nicht als die Ursache sehe. Heute aber nicht mehr Morgen geht es dann weiter. Hast du Bilder von der Hauptplatine des W2024A? Meinst du diesen Jörg von Jörg H. (idc-dragon) Dann werde ich ihn einmal eine PN schicken eventuell kann ich ihn aktivieren :-) Gruß Jürgen
Jürgen R. schrieb: > Hallo Hayo, > ist echt cool von dir dich noch einmal rein zuhängen. Ja gerne, sowas kann einem ja auch selbst passieren, dann ist man froh über jede Unterstützung. > Werde mir auch noch die beiden Rams auf der Oberseite vornehmen wobei > ich kalte Lötstellen nicht als die Ursache sehe. Allerdings ist bei den RAMs ein bekannter Nebeneffekt der kalten Lötstellen, dass man bunte Streifen auf dem Bildschirm bekommt... Es ist also nicht auszuschließen. Und die kalten Lötstellen sind mit bloßem Auge nicht zu erkennen > Heute aber nicht mehr Morgen geht es dann weiter. Ja, bin morgen auch etwas busy und kriege auch noch Besuch (einzelne Person - alles ok). Werde also frühestens Sonntag weiter machen können oder auch erst Montag. Bei Fragen melde ich mich aber auf jeden Fall. > Hast du Bilder von der Hauptplatine des W2024A? Da müssten etliche in den Anleitungen zu den Hardwaremodifikationen drin sein (im Downloadverzeichnis von SF). Ich such Dir sonst aber gerne noch welche raus oder mache neue. > Meinst du diesen Jörg > von Jörg H. (idc-dragon) Ja genau, er hat vor einiger Zeit versucht ein komplett neues Design aufzusetzen. Sah auch sehr vielversprechend aus. Aber natürlich hat er auch noch ein Privatleben. Der Aufwand war wohl einfach zu hoch. Kannst gerne von mir Grüße ausrichten. Falls noch nicht bekannt ist hier der Link zu dem Thema: Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Gruß Hayo
Angehängte Dateien:
-
EPC16-Backup.png
35 KB -
SYN_W2000A.sof.png
60 KB -
Untitled.jic.png
52 KB
Hi, ich hatte hier doch mal mal eine Anleitung dazu geschrieben!?! War das 2013? Kann mich erinnern, das ich von dem EPC16 ein Backup erstellen konnte. Das NIOS II vom Jörg konnte ich auch damit flashen... EPC16 auslesen ging nicht? Waren die richtigen Häkchen gesetzt? Ich habe da jetzt nur noch ein paar Screenshots, wie das aussehen sollte Gruß Michael
Hi, der Email-Trigger funktioniert noch, ich sehe den Traffic hier. Die Welec-FPGA-Bastelei ist aber schon sehr lange her, viele andere Projekte seitdem. So freihändig erinnern tue ich mich nicht. Fühle mich wie Olaf Scholz. Mag sein, dass dieses Autodetect nicht funktioniert, man dem mit einer Konfigurationsdatei auf die Sprünge helfen muß. Wenn das Flashen vom FPGA-Flash geklappt hat sollte der Teil aber in Ordnung sein? Das Sorceforge-Wiki hatte ich mal aus einem Backup wieder in einen read-only Zustand unter anderer URL bekommen, aber auch der funktioniert mittlerweile nicht mehr. Sourceforge ist einfach furchtbar. Die Datenbank-Files von anno 2014 habe ich noch, falls jemand damit was anfangen kann. Die ehemaligen Attachments sind Dateien, der Wiki-Text ist in SQL-Dumps. Grüße Jörg
Angehängte Dateien:
-
s-l1600.jpg
230 KB -
s-l1601.jpg
190 KB -
s-l1603.jpg
230 KB
Hallo, danke für eure Antworten. @ Michael flashen konnte bei mir W2022A.jic und W2022-EPCS16-Bak.jic mit dem Ergebnis totes Oszi. Was bewirkt enable real-time ISP? wäre das der temporäre Modus. ( testen ohne zu flashen?) das habe ich nicht angehakt. Ich habe dann noch die Datei gefunden EPCS16_W2022A.pof beim öffnen gab die Fehlermeldung, dass ich den falschen Mode habe. Mal eine grundsätzliche Frage welche Datei muss ich ins FPGA flashen? Ich habe ja ein W2014. Ein paar Bilder wie es sich verhielt als ich es in die Hände bekommen habe. Grüße Jürgen
Angehängte Dateien:
-
DSCF4018.JPG
230 KB -
DSCF4019.JPG
240 KB
Hallo, ich hab das Oszi nochmal zerlegt und mit den Bildern von euren verglichen. Dabei ist mir aufgefallen, dass die gelbe Verbindung bei mir fehlt. Auch noch ein Bild von meinen Display. Gruß Jürgen
@Jürgen: vielleicht kannst du zur Hardwarediagnose mal was von meinen Test-Bitstreams zu OSOZ ausprobieren. Hier hatte ich einen Speichertest gebaut, eher um mein aggressives RAM-Timing zu testen: Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Woanders hatte ich auch einen, der nur ein Testpattern auf dem LCD ausgibt. War für mein kleines HiColor-Addon gedacht, finde ich gerade nicht. Aber, das Oszi hat vor deinen Update-Versuchen funktioniert? Dann muß ja was in der Prozedur noch fehlen. FPGA-Update, F1 beim Einschalten halten, Germs-Loader, Python-Script zum Flashen, ich erinnere nur grobe Eckpunkte. Grüße Jörg
Angehängte Dateien:
-
DSCF4020.JPG
220 KB -
DSCF4021.JPG
220 KB -
DSCF4022.JPG
230 KB -
DSCF4024.JPG
240 KB
@ Jörg das war die Ausgangssituation: Hallo ich habe ein defektes Welec W2014 A? in die Finger bekommen. Der Infobildschirm zeigt seltsames an: Modell W0000A HW 8C7. SW 1.10.00 SN 0000000000 Es scheint ein A zu sein der Text ist wie auf den Bildern der russischen Seite auch auf meinem Layout zu sehen Das IC ist auch gleich. Die beiden Kondensatoren kann ich nicht sehen weil 4-Kanal. Der GERMS Monitor lässt sich nicht starten. Über serielle Kommunikation kann ich zugreifen Shift-Y und Shift-X bekomme ich einen dunklen Screen mit einen gelben Rechteck. Aber kein Upload möglich. Ich nehme an, dass mein Vorgänger den ECPS16-Konfig-Flash getötet hat und ich ihn wieder flashen muss. Der nächste Schritt: ich habe jetzt versucht den FPGA zu flashen. Quartus II Programmer Version 13.0.1 Windows XP, Altera USB Blaster mit Treiber usb_blaster_q16.1. Datei W2022-EPCS16-Bak.jic Jetzt habe ich auf dem Display nur noch bunte senkrechte Streifen und sonst ist alles tot. Sichern des Flashs hat leider nicht geklappt.:-( Jörg H. schrieb: > vielleicht kannst du zur Hardwarediagnose mal was von meinen > Test-Bitstreams zu OSOZ ausprobieren. > Hier hatte ich einen Speichertest gebaut, eher um mein aggressives > RAM-Timing zu testen: > Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop > W20xxA" > Woanders hatte ich auch einen, der nur ein Testpattern auf dem LCD > ausgibt. War für mein kleines HiColor-Addon gedacht, finde ich gerade > nicht. Versucht das gleiche Ergebnis :-( Jörg H. schrieb: > Aber, das Oszi hat vor deinen Update-Versuchen funktioniert? Dann muß ja > was in der Prozedur noch fehlen. FPGA-Update, F1 beim Einschalten > halten, Germs-Loader, Python-Script zum Flashen, ich erinnere nur grobe > Eckpunkte. Das Flashen des FPGA's läuft fehlerfrei. F1 beim Einschalten ist mir neu, aber leider das gleiche Ergebniss. Germs-Loader soweit bin ich noch nicht. Das war ja auch das Anfangsproblem. Irgendetwas übersehen ich oder mache ich falsch Einstellung beim Programmer - Reset - ..... Das durch dem Upload die Hardware gestorben ist kann ich mit nicht vorstellen dann würde ja bein nächsten Mal eine Fehlermeldung kommen oder Verify eine Meldung bringen. Von jetzt auf nu kalte Lötstellen sehr unwahrscheinlich dann sollte doch zumindest irgend etwas geschehen Schalten von Relais LED zucken am Display.. Noch ein paar Bilder der Upload Prozedur. Grüße Jürgen
Jürgen R. schrieb: >> vielleicht kannst du zur Hardwarediagnose mal was von meinen >> Test-Bitstreams zu OSOZ ausprobieren. >> Hier hatte ich einen Speichertest gebaut, eher um mein aggressives >> RAM-Timing zu testen: >> Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop >> W20xxA" > > Versucht das gleiche Ergebnis :-( Wie, kann doch gar nicht? Das ist ein grundsätzlich anderes FPGA-Design. An der seriellen Schnittstelle sollten die Ausgaben des Speichertests kommen, zusätzlich zu dem Geblinke. Grüße Jörg
Hallo Jörg kein Geblinke keine serielle Ausgabe. Ich denke ich mache beim FPGA Flashen irgendetwas falsch Grundeinstellungen etc. Nehme den Altera US-Blaster zum Fashen liegt es eventuell daran.Aber die Übertragung funktioniert ja. Habe mit Quartus keine Erfahrung. Bin mit Atmega und C unterwegs. Ich weiß für euch ist es lang her. Grüße Jürgen
Hi bin leider wegen eines Notfalls im Freundeskreis etwas out of order. Habe aber trotzdem zwischendurch Quartus II 13.0.1 installiert. Scheint eine 30 Tage Testversion zu sein. Den coolen Speichertest hatte ich nicht mehr auf dem Radar, werde ich mal bei SF hochladen (wenn nicht schon vorhanden). Ließ sich sofort laden und produzierte mehrere Stunden lang rosafarbenes Geflimmer. Speicher ok! Melde mich morgen nochmal, dann können wir Details abgleichen. Gruß Hayo
Angehängte Dateien:
-
Autodetect.jpg
81 KB -
2_FPGA.jpg
93 KB -
W2024A_Readout.jpg
84 KB
So, hab mal den Vormittag mit ausprobieren und aktualisieren von SF verbracht (neben der echten Arbeit - versteht sich). Der Memtest von Jörg ist jetzt mit einer kleinen Anleitung auf SF. Zusätzlich habe ich den Memtest von Slava hochgeladen. Dieser arbeitet, anders als der Test von Jörg, extern via Windowsprogramm. Vielleicht hilft das ja. Hab ich selbst aber noch nicht getestet: https://sourceforge.net/projects/welecw2000a/files/Hardware/MemoryTest/ Ich habe auch einen Abzug meines EPCS16 hochgeladen, wir hatten ja bisher nur welche vom W2022A. Jetzt also auch vom W2024A. Ich weiß aber nicht, ob die wirklich unterschiedlich sind - sehen für mich beim internen Vergleich erstmal bis auf die Quartusversion gleich aus. https://sourceforge.net/projects/welecw2000a/files/Hardware/Original/FPGA/Original_EPCS16_for_W2024A.zip Zum Abgleich hier die Systemdaten: OS - Win7 32bit Quartus II 13.0.1 Altera USB Blaster an JTAG (Brücke gesetzt) - Beim Autodetect wird nur ein FPGA erkannt (Bild 1) - manuell hinzugefügtes FPGA führt zu einem Fehler beim Auslesen (Bild 2) - nur in der schon bekannten Konstellation (Bild 3), lässt sich das Flash auslesen Gruß Hayo
:
Bearbeitet durch User
Angehängte Dateien:
-
DSCF4025.JPG
240 KB -
DSCF4026.JPG
240 KB -
DSCF4027.JPG
220 KB
Hallo Hayo, Blue F. schrieb: > Ich habe auch einen Abzug meines EPCS16 hochgeladen, wir hatten ja > bisher nur welche vom W2022A. Jetzt also auch vom W2024A. Ich weiß aber > nicht, ob die wirklich unterschiedlich sind - sehen für mich beim > internen Vergleich erstmal bis auf die Quartusversion gleich aus. > > https://sourceforge.net/projects/welecw2000a/files/Hardware/Original/FPGA/Original_EPCS16_for_W2024A.zip Du wirst es nicht glauben aber damit hat es geklappt :-)))) Fragt mich aber nicht wieso ;-) Übrigens meldet er sich immer noch mit Modell W0000A HW 8C7. Den GERMS Monitor konnte ich jetzt starten. Spiele gerade die 1.2.BF.8.6 auf mal schauen was es dann sagt? Eventuell geht es dann an die Hardware. Kann mit jemand etwas über die bei mir fehlenden Drahtbrücke sagen. Das werde ich auch noch machen müssen: Gerät aufschrauben und Pins 15 und 16 an U21 oder U23 (ist egal) überbrücken (Zinnklumpen), bitte erst nach dem Update überbrücken, da ich nicht weiß, was mit dem Original-FPGA-Projekt sonst passieren kann. Was war noch sinnvoll und machbar. Die OPA656 scheinen bei mir keine Billigware zu sein. Kühlkörper an den ADC habe ich schon. Halte euch auf den Laufenden. Echt cool von euch. Grüße Jürgen Gruß Jürgen
Hi, das sind ja mal gute Nachrichten. Bevor Du aber Zinnklümpchen verlötest, prüf erst mal, ob die besagten Effekte auftreten wie sie in der Anleitung zum Umrüsten beschrieben sind. Bisher ist es ja nur eine Vermutung, dass es ein W2000 ohne A ist. Dabei weiß ich noch nicht einmal, ob es überhaupt Vierkanaler ohne A gab. Also vor irgendwelchen Hardwareeingriffen erstmal den Status Quo gründlich checken. Wenn Du ein serielles Terminal startest (z.B. Teraterm oder sowas) kannst Du diverse interne Variablen abfragen und Testprogramme starten. Bei Fragen helfe ich natürlich gerne weiter. Wie ich an Deinem Screenshot oben sehe hast Du die 8.6 ja schon drauf. Der Fortschrittsbalken zeigt die Berechnung der trigonometrischen Tabellen an. Das passiert aber nur dieses eine Mal. Danach liegen die im Flash. Gruß Hayo p.s. Als Erstes im Hardware Setup alles richtig einstellen (z.B dass Du kein modifiziertes Gerät hast etc.) sonst stimmen die Nulllinien und Skalierungen nicht!
:
Bearbeitet durch User
Hallo Hayo, werde mal die Dokumentation studieren. Fakt ist aber, dass die Relais nicht schalten wenn ich die Spanung um Faktor 10 erhöhe. Ich kann nur zwischen 1 - 2 - 5 wechseln, bei 10 habe ich das Signal wie bei 1. Die bei mir nicht vorhandene gelbe Drahtbrücke ist mir sehr suspekt. Laut Analogplan ist es ein 74HCT238 das würde dann ja mit Masse an Pin 6 deaktiviert. Vielleicht ist die Brücke auch nur bei der 2 Kanal Variante vorhanden weil das IC nur für Kanal 3 + benötigt wird. Sind eigentlich noch mehr Schaltpläne vorhanden? Gruß Jürgen
Beitrag #6679042 wurde vom Autor gelöscht.
Hallo Jürgen, ja das hört sich tatsächlich wie das Verhalten eines W2000 ohne A an. Was mir aber noch eingefallen ist - der Config-Bereich im Firmware Flash wird beim Firmwareupdate nicht überschrieben. Der Inhalt muss zu dem passen, was im FPGA ist (bei Dir jetzt die Version 8C7 Vierkanal). Aktuell dürfte da jetzt nix (Vernünftiges) drin stehen. Enthalten sind Informationen zum Gerät und Registerwerte für das ADC Readout-Timing. Da das meine FPGA Version ist, habe ich Dir mal ein Backup meines Config-Sektors gemacht. Das kannst Du wie ein Firmwareupdate über den GERMS-Loader einspielen. Danach sollte sich Dein Gerät auch mit korrekten Angaben melden. Gruß Hayo
Hallo Hayo, dann habe ich jetzt softwaremäßig in Clone von deinem ;-) Jetzt geht es ans Einstellen und hoffen, dass nicht noch mehr defekt ist. Wie gesagt schalten keine Relais beim verstellen der Spannung also ist das die erste Aufgabe. Habe die Lötbrücke gesetzt Spannungseinstellung funktioniert. Kanal 1 und 3 ok 2 und 4 machen seltsame Sachen.Habe den Verdacht, dass die Offsetspannung oder die negative Spannung fehlt. Gruß Jürgen
Jürgen R. schrieb: > dann habe ich jetzt softwaremäßig in Clone von deinem ;-) Idealerweise ja... Ich habe noch mal in meinen Bildern gekramt und einige davon bei SF hochgeladen: https://sourceforge.net/projects/welecw2000a/files/Hardware/Original/Mainboard/ Drei Bilder sind dabei, die von einem 2022 ohne A stammen könnten. Jedenfalls fehlt dort die typische Drahtbrücke durch das Lötauge (beim W2022A weiß und beim W2024A gelb). Die Platinenrevision ist aber die Gleiche. Nebenbei habe ich noch den Link zum Webarchiv unseres alten Wiki gefunden: http://web.archive.org/web/20120125231324/http://sourceforge.net/apps/trac/welecw2000a/wiki/WikiStart Und last but not least - anbei das Coding, welches die Schalter ansteuert. Vielleicht hilft das bei der Analyse. Gruß Hayo p.s. wenn sich Dein Gerät mit "W2024A / OPA656 Mod" meldet, kann man das mittels "Hidden Function" über ein serielles Terminal korrigieren. Details kann ich gerne noch erklären.
:
Bearbeitet durch User
Angehängte Dateien:
-
DSCF4030.JPG
220 KB -
DSCF4030.JPG
220 KB -
DSCF4029.JPG
240 KB -
DSCF4031.JPG
240 KB
Danke Hayo, bei meinen scheint es noch Hardware Probleme zu geben. Kanal 1 sieht gut aus. Kanal 2 Amplitude passt ob man das noch Spices nennen kann? Kanal 3 Wellenform ok Amplitude falsch. Kanal 4 Kombination aus 2 und 3. Meine Vermutung Amplitude fehlende oder falsche Spannung AD Wandler Kanal 3 und 4 prüfen mit U27 vergleichen. Spannung +-2,5V und 3,3V an den OP-Amps prüfen. Kanal 4 sieht fast so aus, als ob bei einen AD Wandler ein Dout Pin fehlt oder die Referenzspannung falsch ist. Bei Kanal 2 könnte es auch so sein. Es gibt viel zu tun warten wir es ab. Gruß Jürgen
:
Bearbeitet durch User
Fragen zum aktuellen Zustand: - hast Du im Hardware Setup alles eingestellt (ADC/Pregain -> Factory)? - hast Du den Protected Config Sektor eingespielt? Solche Signalverzerrungen können auftreten wenn die Einstellungen nicht stimmen! Hinweise zum Test: - TB 500µs arbeitet nur mit einem ADC und mit jedem 5. Sample - nur TB 50ns zeigt die Abtatstung aller vier ADC 1:1 an Die entsprechenden Infos findest Du im Doc-Verzeichnis in der Datei "Programmers Reference". Memory 16KB = 4 ADC und 4KB = 1 ADC. Gruß Hayo
Hallo Hayo, Danke für die Infos. Blue F. schrieb: > - hast Du im Hardware Setup alles eingestellt (ADC/Pregain -> Factory)? Ich denke ja. werde es zuhause noch einmal prüfen. Blue F. schrieb: > - hast Du den Protected Config Sektor eingespielt? Habe ich auch, aber erst zuletzt. Kann es sein, dass er vor dem SW File eingespielt werden muss? Gruß Jürgen
Reihenfolge sollte egal sein. Es wird gezielt nur der Sektor vorher und der Protected Sektor gelöscht und neu beschrieben. Die Firmware kannst Du aber bedenkenlos so oft wie Du magst neu einspielen. Die verwendeten Registerwerte aus dem Protected Sector kann man sich im seriellen Terminal ansehen. Wenn man dort "," in Worten - Komma - eingibt, werden die Werte angezeigt. FPGA1 channel_Adr = 5f0a FPGA2 channel_Adr = 5f5f FPGA1 adc_change = 2020f00 FPGA2 adc_change = 200000a
Hallo Hayo, Blue F. schrieb: > - hast Du im Hardware Setup alles eingestellt (ADC/Pregain -> Factory)? > - hast Du den Protected Config Sektor eingespielt? Ja habe ich die Verzerrungen sind geblieben. Habe einmal die Ausgabe vom Terminal gespeichert und in lesbare Form gebracht. Gruß Jürgen
Angehängte Dateien:
-
Hardware_Setup.jpg
41 KB
Ok, habe den Plot mal analysiert - die Registerwerte sind ok. Wie ich sehe hast Du die Hidden Function zur Umstellung des Modells ja schon gefunden. Was ich allerdings merkwürdig finde, sind die Kalibrierungswerte der ADC-Offsets. Die weichen normalerweise maximal um 5 Stufen voneinander ab. Kanal 2 + 3 sehen also normal aus. die Abweichung von 26 bei Kanal 1 und die Abweichung von 105 bei Kanal 4 sind nicht ok. Das ist halbe Bildschirmhöhe bei Kanal 4! Oder hattest Du ein Signal dran? Bei der Kalibrierung müssen die Eingänge kurzgeschlossen oder offen sein. Ich hab Dir mal den Plot von meinem Oszi drangehängt und auch noch einen Screenshot vom Hardware Setup wie es bei Dir aussehen sollte. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, Blue F. schrieb: > Oder hattest Du ein Signal dran? Bei der Kalibrierung müssen die > Eingänge kurzgeschlossen oder offen sein. > > Ich hab Dir mal den Plot von meinem Oszi drangehängt und auch noch einen > Screenshot vom Hardware Setup wie es bei Dir aussehen sollte. Alles so gemacht wie es sein sollte. Das Verhalten ist auch dem Zustand ähnlich wie ich es bekommen habe. Es kann meiner Meinung nicht am Betriebssystem oder Setup liegen. Da ist irgend etwas gestorben. Die Spannungen habe ich bis auf die -6V geprüft. 3,3V 2,5V und -2,5V sind vorhanden. Ich werde einmal die analog Signale prüfen. Ich hoffe nicht, das einer der DAC für den Offset defekt ist. Sehr schwer zu bekommen doof zu löten. Gruß Jürgen
Eine Möglichkeit gibt es noch - hoffe aber, dass es nicht zutrifft. Du sagtest ja, dass auf den ADC Kühlkörper drauf sind. Sind da pro ADC-Set 4 einzelne Kühlkörperchen drauf (also 16 Stk)? Oder hat der Kollege da einen großen Kühlkörper draufgemacht? In letzterem Fall können nämlich thermische Spannungen für kalte Lötstellen an den ADC sorgen (da hatte ich in der Anleitung auch drauf hingewiesen). Dann müsstest Du versuchen die irgendwie abzukriegen oder mit Heißluft die Lötstellen nachbearbeiten. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, die Kühlkörper habe ich montiert. Es sind 4 Stück, einer je Kanal, mit 1mm Wärmeleitpads. So etwas hatte ich schon einmal. Seitdem klebe ich sie nicht mehr mit Sekundenkleber fest.Es sollten keine Verspannungen aufgetreten sein. Die Fehler waren ja auch schon vorher da. Ich habe es ja als defekt bekommen und wollte erst einmal die Software ausschließen. Werde jetzt analogseitig Kanal für Kanal den Signalweg durch messen und sehen ab wann die Verzerrungen auftreten. Da freut sich mein gutes Philips PM3394, dass es wieder etwas zu tun hat. Schlecht ist nur, dass die meisten OP-Amps auf der Rückseite sind. Gruß Jürgen
> Es sind 4 Stück, einer je Kanal, mit 1mm Wärmeleitpads.
Ok, dann ist ja gut. Dann kommst Du ja auch noch an die Pins ran, falls
Du nachlöten musst.
Ich denke, dass es nicht im Analogteil liegt, sondern im digitalen
Signalweg. Ich habe hier übrigens auch noch ein Philips PM3215 rumstehen
- gute solide alte Analogtechnik.
Viel Erfolg
:
Bearbeitet durch User
Hallo Hayo, die zu geringe Amplitude von Kanal 3 und 4 lag an einer zu geringen Spannung an Pin 2 von "U12" für Kanal 3 + 4 das konnte ich beheben. Jetzt habe ich an Kanal 1 und 3 eine gute Darstellung. Der Rest liegt wie du schon sagtest am digitalem Signalkreis. Die Signale an den beiden 0-Ohm Widerständen zum ADC sehen alle gut unverzerrt aus. Also ein schönes Dreiecksignal anlegen und D0...D7 P und N durch messen ob digitale Signale ankommen.Ich hoffe nur, dass die kalten Lötstellen nicht am FPGA sind dann kann ich nach löten vergessen. Gruß Jürgen
Ok, Du kommst ja ganz gut voran. Wie hast Du denn die zu geringe Spannung behoben? War es eine kalte Lötstelle? Ja hoffen wir, dass es nicht unter dem FPGA liegt - das wäre übel. Es gibt aber auch noch genügend andere Kandidaten, die in Frage kommen. Ich bin gespannt... Hayo
Wäre es nicht möglich dünnes Flußmittel wie Flux oder ähnliches darunter laufen zu lassen und mit den Flowföhn das Lot kurz zum schmelzen zu bringen?
Versuchen könnte man das wohl, aber mir persönlich fehlt da jegliche Erfahrung. Vermutlich wäre das dann hopp oder top. Entweder es funktioniert, oder danach sind alle Pins kurzgeschlossen...
:
Bearbeitet durch User
Danke für euer Mitdenken, eventuelle kalte Lötstellen unter den FPGA zu löten wäre mir zu riskant denn es sind auch noch Bauteile auf der Unterseite. Habe die Datenverbindungen ADC FPGA durch gemessen konnte keinen offensichtlichen Fehler feststellen. Eventuell bin ich in die Falsche Richtung gegangen und der Fehler liegt auf der Timeline. Werde mal mit DC am Eingang schauen was das Signal am Display sagt. Gibt es noch Schaltpläne außer vom Analogteil, Frontpanel und Encoderschaltung? Gruß Jürgen
Schaltpläne gibt es meines Wissens nur die im Downloadbereich bei SF. Was genau brauchst Du denn? Ich kann sonst noch mal in meinen Dateien suchen. Die Leitungen vom FPGA zum ADC sind, glaube ich, nicht dokumentiert. Aber da das schon etwas länger her ist, kann ich da auch nichts Genaues sagen. Müsste auch erst mal wieder etwas rumstöbern...
Hallo Hayo, Fehler im Digitalteil sind wieder nicht mehr mein erster Gedanke. Habe soeben mit einen niederfrequenten Rechteck Signal langsam die Amplitude verändert es gab keine Sprünge die für eine unterbrochene Datenleitung gesprochen hätten. Mein zweiter Gedanke war ein RAM mit defekten Speicherzellen, dann müsste ich in der Timeline Einbrüche haben, es waren aber nur durchgehend Spices von ca 1/3 Raster. Was ich bemerkt habe ist als ich eine Batterie im DC Imput umgepolt habe, dass Kanal 2 kaum nach negativ und Kanal 4 kaum nach positiv ausschlägt. Also werde ich mir noch einmal die N-P Outputs der Analogkanäle anschauen ob sie symmetrisch sind. In-N und in-P kommen an den ADC's an. Und die Spannungen an den ADC testen. Dem Plan vom Analogteil habe ich ja. Es bleibt spannend. Wenn alle Stricke reisen habe ich ein 2 Kanal analog mit 4 Kanal Digital, die funktionieren. Diese Funktion einzubauen ist genial. :-) Gruß Jürgen
Hayo hatte recht :-) es waren die Datenverbindungen zwischen ADC und FPGA die Messung mit dem Ozi hat mich in die Irre geführt. Erst als ich Pärchen für Pärchen am ADC auf die 100 Ohm Abschlusswiderstand durchgemessen habe ( mit Nähmaschinennadel als Prüfspitze und Uhrmacherlupe ) konnte ich die Unterbrechungen feststellen. Kontakte nachgelötet (ich liebe das). Jetzt gehen 3 Kanäle beim 4. scheint dann doch noch ein analoges Problem zu sein. Das Signal ist unten abgeschnitten die Zentrierung geht nicht und der Triggerlevel ist verschoben. Der sonstige Signalverlauf ist gut. Hab die zwei LED's nachgerüstet und zwei defekte Rotarys ( Achse ist immer wieder heraus gefallen) gewechselt. Ich spiele mit dem Gedanken die Hintergrundbeleuchtung auf LED umzurüsten, dann ist der Inverter weg der ja auch Störungen verursacht. Gruß Jürgen
Hi, Du bist ja echt zäh :-) Ich hätte da noch einen Punkt, den Du checken könntest. Einige von uns haben mal (fast undokumentiert) die DACs getauscht. Das wurde irgendwo im Forum diskutiert und dann von einigen (z.B. von mir) durchgeführt (hab mal gesucht, aber auf die Schnelle nichts gefunden). Dabei geht es darum die originalen 14 Bit DACs gegen die pinkompatiblen 16 Bit Versionen auszutauschen (LTC26xx). Die Datasheets gibt's bei LINEAR TECHNOLOGY. Falls da jemand versucht hat dran rumzuspielen, ist vielleicht der Versuch daneben gegangen. Original ist der Chip (Dual-DAC) mit LTACZ gekennzeichnet. Die höher auflösende Version mit LTACX. Ich habe mal die Bilder meiner Umrüstung hochgeladen: https://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/DAC%20Upgrade/ Der Treiber in der Firmware kann beide Typen ansteuern. Man hat dadurch eine feinere Auflösung beim Scrollen. Prüf mal die Pins und die Leitungen dort. Deine Fehlerbeschreibung könnte dazu passen. Ein Chip ist für zwei Kanäle zuständig. Du hast bei Dir also zwei Chips drauf (siehe Fotos). Zum Durchmessen kannst Du alle Nullevel in die Mitte stellen (Center Channels). Dann müssten die Werte an den DACs bei allen Kanälen fast identsch sein. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, ja bei mir ist ein Gerät erst defekt wenn ich es sage oder Rauch aufsteigt :-) Die DAC scheinen ok die Spannungen sind ziemlich gleich. Hab noch ein Abgleich durchlaufen lassen und ist besser geworden. Habe das Display auf LED umgerüstet ( je 10 Stück) oben und unten sind durch die LED's leichte Schatten fällt aber durch die Schrift kaum auf. Habe auch das Display nach vorne gesetzt,die Kühlkörper nochmal gevierteilt und jeden ADC einen eigenen spendiert ;-). Den Lüfter habe ich auch vergrößert. Nun werde ich das Teil wieder zusammenschrauben und sehen was passiert. Gruß Jürgen
Hi Jürgen, von Deiner LED-Mod könntest Du mir ein paar Bilder schicken, dann lade ich die auf SF mit hoch. Vielleicht möchte das noch jemand umrüsten. Gruß Hayo
Angehängte Dateien:
-
DSCF4045.JPG
230 KB -
DSCF4047.JPG
240 KB -
DSCF4048.JPG
240 KB -
DSCF4051.JPG
220 KB
Hallo Hayo, ein paar Bilder vom vorläufigen Endergebnis :-) Wie gesagt das Display auf LED umgerüstet weil ich es wegen dem Umsetzten sowie so schon ausgebaut hatte. Die Röhren lassen sich einfach herausziehen. Ein Streifen Streifenrasterplatine zurecht gesägt in regelmäßigen Abständen unterbrochen und zwei mal 5 LED's in Reihe aufgelötet. Weil man einen Stepup-Wandler braucht kann man auch alle in Reihe schalten, oder die Abstände kleiner wählen. Bei mir sind leichte Schatten zu erkennen. Gruß Jürgen
Sieht ja echt gut aus! Die Drehknöpfe passen prima dazu - und wie ich sehe hast Du auch unsere LED-Mod bereits eingebaut. Ist manchmal wirklich ganz hilfreich finde ich. Läuft bei mir eigentlich immer mit. Manche mögen das Geblinke ja nicht... Hast Du evtl. noch ein bisschen mehr zu Deiner LED-Mod? Vielleicht eine kurze Anleitung oder so und noch ein paar Bilder, die ich direkt bei SF reinstellen kann? Gibt bestimmt einige, die das auch probieren wollen. Bei mir ist die Helligkeit nach all den Jahren auch schon nicht mehr so optimal. Gruß Hayo
Hi Hayo, werde ein paar mehr Fotos machen und eine Beschreibung wenn ich das Teil wieder zerlege um die etwas matten grünen LED's zu tauschen. Habe ein paar hellere bestellt. Wiest du wie die Trigger Position verarbeitet wird. Die DAC scheinen für den Offset zuständig zu sein. Wenn es rein digital wäre dann sollte es ja nicht verschoben sein. Bei mir ist im Kanal 4 noch eine Diskrepanz zwischen der angezeigten Trigger Linie und dem tatsächlichen Trigger. Kann man auch auf den Bildern sehen. Der Offset scheint zu stimmen wenn ich das Signal mit der Taste zentriere stimmen Nulllinie und Signal überein. Kann an R23...R25 etwas manipulieren und sehen ob sich etwas ändert. Gruß Jürgen
Hallo Hayo, hab noch nicht berichtet was der Fehler war. Jürgen R. schrieb: > die zu geringe Amplitude von Kanal 3 und 4 lag an einer zu geringen > Spannung > an Pin 2 von "U12" für Kanal 3 + 4 das konnte ich beheben. > Jetzt habe ich an Kanal 1 und 3 eine gute Darstellung. Zuerst habe ich einfach die alte Verdrahtung wieder hergestellt. Bei der haben die Spannungen gepasst. Nun bin ich dem falschen Spannungswert nachgegangen meine Hoffnung war die Differenz bei der Triggerung damit zu beheben. Sehr seltsam es lag an einen Widerstand mit falschem Wert bei Kanal 1+2 5V-1K-2,5V-1k-U12(2)-1k-GND.Bei Kanal 3+4 5V-1k-2,5V-10k-U12(2)-1k-GND. Sah aber nach original Bestückung aus. Aber leider keine Änderung bei der Triggerung. Ich sollte R23 - R25 nachmessen. Ein Welec und noch ein Montagsgerät das ist der Hammer. Gruß Jürgen
Hallo Jürgen,
das ist doch schon nicht übel. Die Triggerung geschieht, außer beim
externen Trigger, nicht über eine separate (analoge) Triggerschaltung,
sondern wird über die ADC und einige Register gesteuert. Da hast Du
hardwareseitig leider wenig Eingriffsmöglichkeiten.
> Ein Welec und noch ein Montagsgerät das ist der Hammer.
Tja da kann ich Dich trösten: alle WELECs sind Montagsgeräte!
Der Trigger war schon von Anfang an problematisch (nichtlinear). Wir
haben dann sowohl im Zeitbereich als auch in der Amplitude softwaremäßig
versucht das ein wenig auszubügeln (Korrekturkennlinie). Gerade bei
negativen Triggerleveln gibt es aber nach wie vor größere
Ungenauigkeiten. Auch beim Pulsweitentrigger wirst Du feststellen, dass
hier trotz Softwarekorrekturen nicht alles so funktioniert wie man es
erwarten würde.
Wenn Du die W2000A Hardware- und Softwareforen der Jahre 2008 - 2013
hier durchgehst, wirst Du da jede Menge zu finden.
Aber wir haben es zumindest geschafft, ein benutzbares Gerät aus dem
eigentlich unbenutzbaren Ursprungszustand zu machen. Zudem hat das Gerät
jetzt eine Menge Funktionen, die man nicht überall findet. Trotz
bekannter Schwächen benutze ich es lieber, als mein chinesisches OWON.
Gruß Hayo
Hi Leute, kann mir ev. einer sagen wie ich den Nullabgleich machen. Bei mir ist der erste und der 4 Kanal nicht ganz bei 0. Da ist ein Offset von ca. 1V zu sehen. Danke und Gruß.
Angehängte Dateien:
-
DSCF4085.JPG
220 KB
Hallo Hayo, anbei die Beschreibung für die LED Hintergrundbeleuchtung. Noch ein Bild mit der Diskrepanz zwischen Triggerlinie und realen Triggerpunkt. Hatte Heute keine Lust das Teil soweit zu zerlegen. Dafür habe ich die LED- Beleuchtung überarbeitet und die LEDs dichter gesetzt und kleinere LEDs genommen.Bei der Gelegenheit ein paar Bilder gemacht :-) Die LEDs recycle ich aus defekten LED Beleuchtungen :-). Gruß Jürgen Ich misch mich einfach einmal ein auch wenn ich im Forum nur ein Küken bin. Die Profis sind Hayo und Co :-) Hallo Georg, hast du schon die Open Source Firmware? Wenn Ja. Die Infos von Blue F. am 07.05.2021 12:14 beachten. Im Utility Menü gibt es den Funktions-Button Calibrate Offsets Alle Messleitungen entfernen oder mit Masse verbinden und den Prozess durchlaufen lassen. Gruß Jürgen
@Jürgen Heißt das, dass getriggert wird, obwohl der Level so weit unterhalb des Signals liegt? Das wäre in der Tat etwas komisch. Hab das bei mir mal genau so nachgestellt (gleiches Signal etc.). Bei mir reißt der Trigger sofort ab wenn ich unter die Spitze des Dreiecks komme. Übrigens eine sehr schöne Anleitung. Wird den Einen oder Anderen freuen. Lade ich mal bei SF hoch. @Georg Ganz wichtig - erst mal prüfen ob die Hardwareeinstellungen richtig sind! Wenn das kein modifiziertes Gerät ist, alles auf Factory und Gain auf 1.000. Gerät möglichst kurz warm laufen lassen. Es gibt eine kleine Temperaturdrift. Dann ins Utility-Menü wechseln und dort Calibration Standard einstellen. Anschließend -> Calibrate Offsets (natürlich kein Signal an den Eingängen, wie Jürgen schon schrieb). Wenn das nicht so richtig klappt, vor dem Kalibrieren mal alle Kanäle anschalten, alle auf DC, alle in die Mitte stellen und dann noch mal kalibrieren. Wenn dann immer noch nicht klappt ist entweder was in den Einstellungen falsch (Gerät doch modifiziert? Abschlusswiderstand gewechselt worden?) oder es ist was defekt. Berichte mal ob es klappt. Gruß Hayo
:
Bearbeitet durch User
Hallo Hayo, genau der Triggerpunkt sollte eigentlich auf der Nulllinie sein. Er ist in diesen Fall um 1.5V verschoben. Die Differenz ist in den anderen Bereichen ähnlich. Wie gesagt werde mal die Widerstände, Spannungsteiler nach dem DAC, kontrollieren. Wenn der eine schon falsch war eventuell sind es noch mehr. In einigen Forenbeiträgen wurde über eventuelle Modifikationen über die freien Tastenkontakte und Rotarys mit Tastfunktion diskutiert. Gibt es in dieser Richtung Erweiterungen ( z.B. Zentrierung Trigger...) ähnlich den beiden LEDs. Schön, dass dir die Anleitung gefällt. Lustig wäre eine kleine Bildergalerie in dem man sein Oszi zeigt und was man damit gemacht hat. Du bist ja schon von Anfang an dabei und hast wahnsinnig viel geleistet. Ich hab vor ein paar Monaten mal mit einen DSO138 herum-gespielt um zu sehen was geht und da hatte ich noch eine recht gute Ausgangssituation es war eine gute übersichtliche Open Source Firmware für zwei Kanäle in C vorhanden. Deswegen mein voller Respekt. Gruß Jürgen
Hallo Hayo, habe mal wieder einen Ausdruck meiner log Datei gemacht. Die markierten Werte finde ich etwas seltsam. Was sagst du dazu? Gruß Jürgen
Hi, bin gerade erst vom Boot zurück... Ja, Du hast Recht, die Offsets der ADC 1, 2 und 4 sind jenseits von Gut und Böse. Das weist entweder auf ein Problem beim analogen Input hin oder es werden nicht alle Bits der Datenleitungen korrekt an das FPGA geleitet. Die schrägen DAC-Werte sind aber vermutlich eher eine Folge davon. Übrigens ein Tip für die Screenshots - wenn Du Du den Onscreen-Status anschaltest (Display -> Submenü -> OSS) kann ich mehr Details zu Deinen Einstellungen sehen. Deine Fotos sind zwar recht gut, aber wenn Du die Screenshotfunktion des Oszis verwendest, sieht man unter Umständen noch mehr Details. Die LED-Ausleuchtung wird dabei natürlich nicht wiedergegeben, da macht ein externes Foto natürlich mehr Sinn... Gruß Hayo
Hi Hayo, Boot in welcher Gegend wohnst du? Hab gerade den Fehler gefunden es war noch ein Unterbrechung beim INN eines ADC's. Jetzt passen die Offset Werte und der Trigger ist auch wo er hin soll. :-) Gruß Jürgen und einen erholsamen Feiertag
Super, hat große Freude gemacht Euch "zuzuhören". War echt spannend. Ja, wo hat Hayo denn sein Boot ?? Ein Bildchen wäre schön. Ich plane nämlich auch in diese Richtung. Euch noch einen schönen Pfingstmontag cheers
Angehängte Dateien:
-
Blue_Pearl_Finkenwerder_01.jpg
310 KB -
Blue_Pearl_Finkenwerder_02.jpg
300 KB
Hi, das ist ja super cool! Du hast also ein W2014 ohne A mit diversen fiesen Mängeln (also eigentlich ein hoffnungsloser Fall) in ein funktionierendes W2014A mit LED Backgroundbeleuchtung verwandelt - einen Überflieger quasi. Keine schlechte Bilanz! Bei so viel Einsatzbereitschaft kann ich Dir die eine oder andere weitere Verbesserung am Garät nur empfehlen. Die dazu nötigen Fähigkeiten hast Du ja eindeutig. Die Anleitungen sind eigentlich ziemlich genau beschrieben, da kann eigentlich nichts schiefgehen. Insbesondere die Low Budget Mod oder die OPA653 Mod belohnt einen mit einem linearen Frequenzgang und einem deutlich geringeren Rauschen. Auch der externe Trigger, der im Original keine Funktion hat, kann durch einige einfache Korrekturen wieder zur Mitarbeit bewegt werden. Das Boot: Ja nee - ist natürlich völlig offtopic hier - aber seit einigen Jahren ist es eigentlich nach dem W2000A DAS neue Projekt und nimmt mich mindestens genauso in Beschlag. Derzeit noch in Finkenwerder (gleich neben Airbus) in der Halle, hoffen wir im Juni endlich wieder Wasser unter dem Kiel zu haben. Das Problem ist die weltweite Rohstoffverknappung. Wir sollen eigentlich ein (Flexi)Teakdeck kriegen, aber erst kann das Deck nicht geliefert werden und jetzt gibt es keinen Klebstoff - kein Witz. Und es ist natürlich doch nicht ganz offtopic, denn ich habe natürlich auch hier meiner Leidenschaft gefrönt und mit dem Raspberri Pi einige schöne Projekte für die Bordelektronik umgesetzt (Mediaplayer für die netten Abende in der Marina, einen AIS Receiver mit einem TV-Stick und GPS-Stick, der seine Daten an ein Laptop mit Open CPN schickt). Da wir ebenfalls ein aktives AIS an Bord haben, sind wir auch unter unserem Bootsnamen auf vesselfinder zu finden... Gruß vom Skipper
Hi Leute, danke für die Unterstützung. Jetzt passen die Offsets wieder. Das ich nicht selbst drauf gekommen bin. Hayo danke für deine Bemühungen. Durch deine Überarbeitung ist das Oszi mein täglicher Begleiter. Bei dem Preis muss ich nicht dauernd drauf aufpassen. Gruß.
Na prima - wieder ein glücklicher W2000A Besitzer! Da helfe ich doch gerne... Noch viel Spaß mit Deinem DSO
Jürgen R. schrieb: > Hab gerade den Fehler gefunden es war noch ein Unterbrechung beim INN > eines ADC's. Hallo Jürgen, ich lese hier aus Interesse mit. Ich habe momentan kein Wittig(welec). Rein aus Neugierde: Hast Du eine Vermutung für die Ursache der Unterbrechung? Gab es die vermutlich schon ab Werk oder ist die später, z.B. durch mechanische Belastung, entstanden? Oder war es eine fehlerhafte Lötstelle?
Glückwunsch, wunderschönes Boot !!! Werde Euch im Auge behalten ;-) cheers sieges
Angehängte Dateien:
-
DSCF4089.JPG
240 KB
Hallo Hayo, Cooles Boot. Wenn das in unserer Badepfütze schwimmt ist sie voll :-) Meine Boote sind so eher in dieser Größenordnung :-) Jetzt aber zurück zum Thema. Blue F. schrieb: > Insbesondere die Low Budget Mod oder die OPA653 Mod belohnt > einen mit einem linearen Frequenzgang und einem deutlich geringeren > Rauschen. Auch der externe Trigger, der im Original keine Funktion hat, > kann durch einige einfache Korrekturen wieder zur Mitarbeit bewegt > werden. Bin noch am überlegen. Ich bin meist im NF Bereich bis bis 20Mhz unterwegs und habe auch noch das Philips. Die OPA653 kosten ja ab 6,50€ je Stück. Deswegen frage ich mich ob sich der Aufwand für mich lohnt. Eventuell die Low Budget Mod. Habe aber wieder gelesen, dass es bei einem W2014 durch die Noname OPA656 die doch bei mir in den 4 Kanälen verbaut worden sind eher nachteilig ist. Oder sehe ich das falsch? Den Umbau des Ext, Triggers werde ich in Angriff nehmen. Alexander S. schrieb: > ich lese hier aus Interesse mit. Ich habe momentan kein Wittig(welec). > Rein aus Neugierde: Hast Du eine Vermutung für die Ursache der > Unterbrechung? Gab es die vermutlich schon ab Werk oder ist die später, > z.B. durch mechanische Belastung, entstanden? Oder war es eine > fehlerhafte Lötstelle? Das ist eine gute Frage. Ich habe das Teil als defekt bekommen. Die kalten Lötstellen an den ADCs könnten mit der Zeit aufgetreten sein. Der falsche Widerstand sicherlich nicht. Der Wertegang des Oszis würde mich auch interessieren. Eventuell kann die Wittig Gemeinde hier besser Auskunft geben was bei den Geräten "normale" Fehler sind. Gruß Jürgen
Hallo, I tested the OPA653 and several mmic's before installing on the dso and it worths.But also I use an external ERA amplifier from Minicircuit to boost below 10 mV in the range 10-300 MHz. The last firmware works very fine in the daily use, thanks Hayo. Regards, Sandro
Jürgen R. schrieb: > Habe aber wieder gelesen, dass es bei einem W2014 durch die Noname > OPA656 die doch bei mir in den 4 Kanälen verbaut worden sind eher > nachteilig ist. Oder sehe ich das falsch? Korrekt! Mit den gedrosselten OPA656 macht das keinen Sinn. Dann knickt der Amplitudengang schon bei 50 bis 60 MHZ ab. Das ist der Bereich in dem Du jetzt unmodifiziert eine um 25% zu hohe Amplitude angezeigt kriegst. Also wenn Du die Eingangsverstärker modifizieren willst brauchst Du auf jeden Fall neue OPA656 (4 für die Kanäle und 1 für den ext. Trigger). Den OPA653 würde ich generell bevorzugen, aber die Verfügbarkeit ist manchmal nicht so gut und Du brauchst immer noch einen OPA656 für den ext. Trigger... Das Rauschen nimmt wirklich drastisch ab, da der Aussteuerbereich viel besser genutzt wird. Kann gerne Vergleichsbilder posten - hab ich aber glaube ich auch schon mal früher gemacht. > Alexander S. schrieb: >> ich lese hier aus Interesse mit. Ich habe momentan kein Wittig(welec). >> Rein aus Neugierde: Hast Du eine Vermutung für die Ursache der >> Unterbrechung? Gab es die vermutlich schon ab Werk oder ist die später, >> z.B. durch mechanische Belastung, entstanden? Oder war es eine >> fehlerhafte Lötstelle? > Das ist eine gute Frage. Ich habe das Teil als defekt bekommen. > Die kalten Lötstellen an den ADCs könnten mit der Zeit aufgetreten sein. > Der falsche Widerstand sicherlich nicht. Der Wertegang des Oszis würde > mich auch interessieren. > Eventuell kann die Wittig Gemeinde hier besser Auskunft geben was bei > den Geräten "normale" Fehler sind. Dazu kann ich generell sagen, dass diese Geräte von Anfang an immer wieder Probleme mit kalten Lötstellen hatten. Sehr beliebt ist hier das RAM. Das wird aus irgendeinem Grund von der Maschine etwas schief auf dem PCB platziert und dann kommen manchmal die Füße an der einen Ecke nicht mehr ganz an die Lötpads. Bei mir waren z.B. die Justierkondensatoren unter den Abschirmblechen an einer Seite nicht richtig fest (Empfehlung: einfach noch mal nachlöten wenn man die Bleche eh runter hat - sicher ist sicher...). Aber es gibt wohl auch andere Stellen. Da wurde wohl nicht so sorgfältig gearbeitet. Gruß Hayo
Hallo Hayo, Hab nun den Trigger Mod durchgeführt die fake OPA's getauscht und den LB Mod durchgeführt. Da zahlt sich aus, dass ich in der Jugend Mikado gespielt habe :-). Hatte aber nachher noch in Kanal 1 + 2 ein sehr seltsames Verhalten das schlagartig ab 50ns auftrat. Bei aufsteigender Flanke hatte ich über den ganzen Bereich symmetrische Spitzen nach unten und in der fallenden Flanke nach oben. Es sah aus als ob das Signal mit einem Rechteck Signal moduliert wurde. Mit aktiviertem Smooth Filter konnte man sie zwar eliminieren, war aber nicht perfekt ;-). Bilder habe ich keine gemacht. Dout hatte ich ja schon geprüft daran konnte es nicht liegen. Die Übeltäter waren 2 x DCLKN/P und 2 x CLKDIV die hatten keinen Kontakt. Wieder Kühlkörper entfernt und nach-gelötet. Uns siehe da nun habe ich auch hier brauchbare Anzeigen und das ohne Filter. Übriges versucht jemand auf Kleinanzeigen ein Wittig W2022 für 300€ zu verkaufen. Weil ich etwas ungeduldig war habe ich nun 5 OPA656N übrig. Gruß Jürgen
Hallo Jürgen, bin gerade aus dem (Segel) Urlaub zurück und sehe Deinen Post hier. > Hab nun den Trigger Mod durchgeführt die fake OPA's getauscht und den LB > Mod durchgeführt. Supi! Da freue ich mich natürlich, dass ich mit der Anleitung wieder jemandem weiterhelfen konnte :-) > Die Übeltäter waren 2 x DCLKN/P und 2 x CLKDIV die hatten keinen > Kontakt. Mann - bei deinem Gerät ist das aber auch schon extrem mit den kalten Lötstellen. Allerdings meine ich mich zu erinnern, dass auch schon jemand anderes solche komischen Zacken im Signal hatte. Würde mich also nicht wundern, wenn das auch eine Stelle ist, die häufiger mal problematisch ist. > Übriges versucht jemand auf Kleinanzeigen ein Wittig W2022 für 300€ zu > verkaufen. Das ist allerdings deutlich zu viel. Mehr als 150€ würde ich da nicht investieren. Mit den Umbauten und Optimierungen hat man dann allerdings für relativ kleines Geld ein nettes Messgerät für die heimische Bastelbude. > Weil ich etwas ungeduldig war habe ich nun 5 OPA656N übrig. Vielleicht legst Du Dir ja noch eins zu ;-) Oder vielleicht gibt es hier jemanden der ebenfalls umrüsten möchte?? Gruß Hayo
Das Teil steht nun auf meinem Tisch und wird helfen Fehler zu finden und nicht anders herum. Mal sehen was ich als nächstes angreife wenn es mir wieder langweilig wird :-). In der Bucht wird ein defektes Philips PM3065 angeboten scheint aber nur das Netzteil defekt langweilig, obwohl mich so eine PSU schon einmal verarscht hat, aber ein dritter Oszi brauche ich nicht.Und ob kaufen - reparieren - verkaufen sich bei dem Oszi sich lohnt ist fraglich. Werde immer einmal vorbei schauen ob sich etwas neues ergeben hat. Euch allen und vor allem dir Hayo vielen Dank für die Hilfe. Bastelst du noch an updates für das Gerät? Das letzte ist ja nicht so lange her. Gruß Jürgen
Vielen Dank für die viele und hervorragende Arbeit die in die FW geflossen ist und - hoffe ich - weiterhin fließen wird ;-) Zwei Fragen zum Thema Schnittstelle/Anbindung an einen Rechner habe ich: - Bisher habe ich keine Informationen zur Verwendung des USB-Anschlusses gefunden. Gibt es dazu eine Doku oder einen Thread um sich entsprechend einzuarbeiten? - Im SourceCode der Screenshot Utility wird auf eine RemoteControlAPI verwiesen, allerdings finde ich keine Doku zu diesem Thema. Der Link im Code sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPIführt zu keiner und auch finde ich kein Wiki… Sind die Informationen zur seriellen Schnittstelle in den Sourcen der FirmWare zu finden? Vielen Dank
Hallo Thomas, also grundsätzlich erstmal Eines: aktuell gibt es nur die Anbindung über die RS232 Schnittstelle. Das gilt sowohl für das Screenshot Tool und die Remote API als auch für das Open Source Firmware Update. Das von WELEC mitgelieferte Update Tool, welches über USB arbeitet, ist nicht für die Open Source Firmware geeignet! Es gibt seit der Firmwareversion 1.2.BF.8.0 eine Unterstützung der WELEC PC-Software, die den USB Port nutzt. Die Software hat allerdings diverse Fehler und es gibt keinen Sourcecode dazu. Auf Oszi-Seite ist die Verwendung des USB-Ports kein Problem. Es fehlen nur auf PC-Seite Anwendungen, die den Port nutzen. Da hat sich irgendwie niemand gefunden, der das programmieren konnte oder wollte. Ich selbst habe mich da mal etwas eingearbeitet, bin aber kein Windowsprogrammierer und mir fehlte dann irgendwie die Zeit dafür (früher hatte ich Geld und Zeit - jetzt habe ich ein Segelboot). Man muss auch sagen, dass der Zugriff über die RS232 Schnittstelle wirklich gut funktioniert, und dank GERMS Monitor absolut sicher ist. Wenn mal ein Update schief läuft, macht man es einfach noch mal. Das geht so über USB nicht, da hier die Updateroutinen Bestandteil der Firmware sind. Wenn die FW nicht mehr startet, gibt es auch kein Flashen über USB mehr. Zudem ist, dank Kompression, das Update über RS232 um Quantensprünge schneller (18sek) als über USB (der originale WELEC Updater braucht 45 Minuten für das Update von 1.3 auf 1.4). Wenn Du in Sachen USB aktiv werden möchtest, unterstütze ich Dich gerne. Es braucht, wie gesagt, Kenntnisse auf PC-Seite um die USB Unterstützung zu implementieren. Auf FW-Seite kein Problem... Zum Remote Control API: Dieses wird vom Screenshot-Programm genutzt, um vom PC aus Screenshots und andere Funktionen auf dem Oszi zu starten. Das Wiki dazu ist längst offline, aber es gibt noch dieses Archiv: http://web.archive.org/web/20120125231324/http://sourceforge.net/apps/trac/welecw2000a/wiki/WikiStart Dort habe ich allerdings auf die Schnelle auch nichts dazu gefunden. Das API ist im Source Code allerdings recht übersichtlich programmiert (von Falk) - ich kann dir die Stelle im Code gerne raussuchen. Im Source Code des Screenshot-Tools kann man auch ganz gut sehen wie es funktioniert. Einfache Funktionen des Oszis lassen sich auch über Terminal per Tastendruck aktivieren (Kanäle an und aus, Spannungsbereich wechseln usw.) Was da geht, kriegt man im Terminal angezeigt wenn man "h" drückt. Das kann man natürlich auch via Programm ansteuern... Gruß Hayo
:
Bearbeitet durch User
Vielen Dank, ich bin auf dem aktuellsten Stand deiner FW und 'spiele' ein wenig mit dem Remote-Zugriff via Terminalprogramm. Parallel versuche ich die Screenshot-Utility für mich 'aufzudröseln'… Aus diesem Kontext heraus zwei Verständnisfragen: - Worin liegt der Unterschied zwischen Trace- und Measurement-Dump? - Die Remotefunktionen sind also auch die, die durch die ursprüngliche GUI-Software auch genutzt wird/wurde oder gab es im ursprünglichen USB-Stack hierfür weitere Funktionen. Gruß, Thomas
Thomas K. schrieb: > - Worin liegt der Unterschied zwischen Trace- und Measurement-Dump? Puuuhh... da erwischst Du mich etwas unvorbereitet. Hab ich schon länger nicht mehr benutzt und müsste erst im Code nachsehen bzw. einfach mal ausprobieren. Wenn ich mich recht entsinne, liegt der Unterschied in den Übertragenen Daten. Beim Trace glaube ich nur die Raw-Werte, beim Measurement die skalierten Werte. Aber nagel mich nicht darauf fest, ich benutze fast nur die Screenshot-Funktion. Für die Dokumentation von Testaufbauten und Prüfmessungen (z.b. im Studium) ist die Measurement bzw. Tracefunktion schon ganz prima. > - Die Remotefunktionen sind also auch die, die durch die ursprüngliche > GUI-Software auch genutzt wird/wurde oder gab es im ursprünglichen > USB-Stack hierfür weitere Funktionen. Nein! Nicht ganz. Es gibt Remotefunktionen im USB-Stack, die zum Teil schon vorher drin waren, aber auch zum Teil falsch implementiert waren. Diese habe ich komplett überarbeitet, damit die WELEC PC-Software zumindest teilweise benutzt werden kann. Die einfachen RS232 Remotefunktionen und das RS232 Remote API sind davon völlig getrennt und Open Source Entwicklung (werden ausschließlich von der Open Source Software genutzt). Und - grundsätzlich lässt sich sowohl bei RS232 als auch bei USB alles was benötigt wird nachrüsten. Das ist kein Hexenwerk. Wie schon gesagt müsste es auf der PC-Seite eine Anwendung geben... Wenn von bestehender PC-Software das Protokoll bekannt ist, kann man das auch in der Firmware einbauen - alles machbar. Gruß Hayo
:
Bearbeitet durch User
Gruß, ich habe ein Problem mit dem W2022 Oszilloskop - Wenn ich es einschalte, gibt es nur einen dunklen Bildschirm und es wird nichts angezeigt - Wenn ich es an RS232 anschließe, mache ein komplettes Update, aber beim Einschalten wird nichts angezeigt - wenn ich es über USB an Altera anschließe und das Hallo-Programm programmiere erscheint das Bild auf dem Bildschirm und alles funktioniert, bis ich es ausschalte Was kann ich tun, um das Programm zu starten und es auf dem Bildschirm zu sehen, wenn ich es einschalte? Dankeschön
Hi Stjepan, ist mit so wenigen Infos etwas schwer einzuschätzen. Du sagst ja, Du hast versucht ein Firmwareupdate zu machen. War es die aktuelle Version? Wurde das Update korrekt zu ende durchgeführt, oder gab es eine Fehlermeldung? So als Schnellschuss getippt hört sich das nach Deiner Beschreibung an, als wäre die FPGA-Programmierung nicht in Ordnung. Dann müsstest Du das neu laden. Die Files gibt es ja im Downloadbereich von SF. Musst nur sehen, dass Du die richtige Variante nimmst (2 Kanal / 4 Kanal). Ansonsten müssen wir das mal Schritt für Schritt durchgehen, was geht und was nicht. Die Hardware scheint aber ja grundsätzlich zu funktionen. Gruß Hayo
:
Bearbeitet durch User
Das Modell ist W2022 2 Kanäle der Fehler trat nach dem Laden einer neuen Software auf Ich habe die Software mit welec Update über RS232 Kabel geladen, aus- und eingeschaltet und nur der schwarze Bildschirm Wenn ich es über ein USB-Kabel an das Alter and Load Hello-Programm anschließe, erscheint das Bild und das Programm funktioniert bis Ich schalte es aus. Danach beim Einschalten nur noch der schwarze Bildschirm. Ich habe versucht, mehrere Versionen über RS232 zu laden und es lädt ok, aber wer schaltet den schwarzen Bildschirm wieder ein? Ich weiß nicht, welches Programm ich laden soll, damit das Bild beim Einschalten des Oszilloskops erscheint
Gibt es ein originales Basisprogramm, dass ich das ganze irgendwie laden kann und wo ich es finde Dankeschön
Also grundsätzlich besteht das Ganze aus drei Ebenen: - Hardware -> die Boards mit den Komponenten und dem(den) FPGA(s) - FPGA-Programmierung -> hier ist die NIOS-CPU implementiert nebst etwas Peripherie und ADC-Steuerregistern. Die Programmierung wird mit ALtera Quartus und einem JTAG-Adapter (Altera-Blaster) gemacht - Firmware -> Das ist das eigentliche Betriebssystem bzw. die Software, die auch Ausgaben auf den Bildschirm schreibt. Diese wird über RS232 mit einem Uploadprogramm geladen. Jetzt hört sich das für mich etwas danach an, als hättest Du die FPGA-Programmierung mit Deinem Hello Programm zerschrotet (übergeschrieben). Kann das sein? Hast Du mit Quartus da was rein programmiert? - ja -> Du musst den origalen FPGA-Core wieder reinladen - nein -> dann ist das wohl in Ordnung und Du musst die Firmware noch mal korrekt laden. Nach einem Neustart sollte dann alles gehen. Alle Downloads gibt es hier: https://sourceforge.net/projects/welecw2000a/ Den FPGA-Core gibt es hier: https://sourceforge.net/projects/welecw2000a/files/Hardware/Original/FPGA/Original_EPCS16_for_W2022A.zip/download Die aktuellste Firmware gibt es da natürlich auch. Wie du beim Laden der Firmware grundsätzlich vorgehen musst weißt du? (Germsmonitor an F1 und F2 Taste drücken dann Upload starten) Gruß Hayo
Sie haben mich nicht verstanden - das Laden funktioniert nur mit Altera USB und Perl rs232 Beim Starten des Geräts erscheint nur ein schwarzer Bildschirm - Ich lade von Altera problemlos über das USB-Programm Willkommen herunter und das Bild erscheint auf dem Gerät - kein Problem beim Laden mit welecupdate any tomcat.flash - das Problem ist, dass beim Starten des Geräts nichts angezeigt wird Also drücke ich den Startknopf und nur den schwarzen Bildschirm Ich weiß nicht, was ich brauche, um das Bild beim Start anzuzeigen
Für mich hört sich dass so an als ob nur der FPGA Selbs geladen wird aber im Bootflash wird nichts abgelegt.
Könnt ihr mir helfen welches Programm genau und wie man es im Bootflash speichert? Ich habe es mit Perl, Update, Altera versucht, aber es hat nicht funktioniert. Vielleicht lade ich falsch oder ich kenne die falsche Software nicht mehr. Danke für die ganze Hilfe
Hi - sorry! Bin gerade total busy und habe mich deshalb noch nicht gemeldet. Ich melde mich aber noch mal dazu. Das kiegen wir bestimmt wieder zum Laufen. Gruß Hayo
Hallo Stjepan, schau mal etwas weiter oben ab 25.04.21 hatte u.a. auch Probleme mit Display und FPGA flashen. Dort gibt es einige Tipps von Hayo. Eventuell hilft es dir auch. Gruß Jürgen
Moin - frohes neues Jahr an alle! Hatte zwischendurch nur wenig Zeit, daher die Funkpause. Nun zu unserem Problem: Stjepan M. schrieb: > Sie haben mich nicht verstanden - das Laden funktioniert nur mit Altera > USB und Perl rs232 Ja - korrekt. Ich verstehe das Problem tatsächlich nicht richtig. Daher versuche ich einzugrenzen, ob es ein Problem mit dem FPGA-Core ist, oder mit der Firmware. Die Hardware scheint ja nach Deiner Beschreibung unter bestimmten Umständen zu funktionieren. Nach dem, was ich so zwischen den Zeilen herausgehört habe, hast Du mit Altera den FPGA-Core zerschossen - so zumindest meine Vermutung. Ist aber kein Problem, falls es so sein sollte. Dann holst Du Dir per Download das File https://sourceforge.net/projects/welecw2000a/files/Hardware/Original/FPGA/Original_EPCS16_for_W2022A.zip/download und brennst es mit Altera wieder rein. Falls Du dafür eine Anleitung brauchst bitte nachfragen. Gruß Hayo
:
Bearbeitet durch User
Da ich alle tomcat.flash-Dateien und w2022.jic ausprobiert habe und obwohl es lädt, startet es das Oszilloskop nicht, also bitte auf diese Weise, wenn jemand die originale Werkssoftware hat, die w2022 hat. Obwohl ich mit Quartus w2022.jic lade und alle möglichen tomcat.flash-Dateien flashe - nur ein schwarzer Bildschirm, wenn Sie den Power-Knopf drücken. Danke
Hallo Stjepan, mal ne ganz dumme Frage. Wird das Display kurz hell und dann schwarz oder ist es von Anfang an dunkel. Nicht, dass das Problem auf der Hardware Seite liegt. Bei mir wird das Display kurz hell bevor es von der Firmware initialisiert wird und den Startbildschirm mit Version anzeigt. Es könnte eine defekte Hintergrundbeleuchtung sein. Leuchte mal im Betrieb mit einer Taschenlampe das Display an ist dann etwas zu erkennen? Gruß Jürgen
Ok, hört sich schon komisch an. Also machen wir mal weiter... Die originale Firmware kann ich Dir auch hier hochladen, muss ich nur raussuchen - wird aber nichts helfen, soviel kann ich Dir schon mal sagen, denn das ist kein Firmwareproblem. Da Du ja sagtest, dass der Bildschirm funktioniert, wenn Du im FPGA ein "Hallo" Programm lädst, sollten wir mal den RAM-Speicher testen. Jörg hat hierfür ein prima Programm geschrieben, das Du mit Altera in das FPGA laden musst. Die Anleitung ist mit dabei. https://sourceforge.net/projects/welecw2000a/files/Hardware/MemoryTest/memtest_100mhz.zip/download Wenn das ohne Beanstandung durchgelaufen ist, bitte mal die letzte BF-Firmware laden und über ein Terminal die Ausgaben auf der RS232 prüfen. Dort sollte sich das OSzi dann melden. Wenn es das tut, kannst Du mit Shift + C einen Graphiktest aufrufen. Berichte mal was geht und was nicht - ich suche mal die alte Firmware raus. Gruß Hayo
Hallo Stjepan, ich hatte vor 10 Jahre (hier im diesem Thread am 17.04.2012 zu lesen) auch ein Problem mit meinem W2022. Damals sah es immer so aus, als ob die FW aufgespielt wurde, danach wurde auf dem Bildschirm aber nichts angezeigt. Auch ein Perl-Skript für den RAM-Loader ist ohne Fehler durch gelaufen. Das Problem war damals, wie bei zwei anderen auch, eine kalte Lötstelle am RAM. Bei mir war es der RAM-Chip, bei dem man das Gerät komplett auseinander nehmen musste. Ohne Hayo hätte ich es nie gefunden. Ich hoffe das hilft Dir weiter. Gruß Timo
Hallo Hayo, nur eine kurze Frage: Ist es möglich deine aktuelle Firmware auf ein Welec W2022A aufzuspielen ohne an der Hardware etwas zu ändern? (Ich habe den/die ganzen Threads nicht komplett durchgelesen aber da waren immer Dinge bzgl. Hardwaremodifikationen zu lesen) Vielen, vielen Dank! LG
Hi, ja klar. Die Modifikationen sind nur optional. Die Firmware unterstützt natürlich auch völlig unmodifizierte Geräte. Damit das geht, gibt es im Hardwaresetup die Möglichkeit einzustellen, ob das Gerät modifiziert wurde oder nicht. Da solltest Du nach dem Aufspielen der Firmware auf jeden Fall nachsehen ob alles richtig eingestellt ist, sonst zeigt das Gerät komische Dinge an. Beim allerersten Start mit der neuen Firmware braucht das Gerät einige Zeit, weil es erstmal Tabellen für die trigonometrischen Funktionen berechnen muss. Das macht es aber nur dieses eine Mal. Du bekommst dazu eine Anzeige mit Fortschrittsbalken, damit Du weißt ob es sich noch lohnt einen Kaffee zu holen :-) Viel Erfolg - bei weiteren Fragen einfach kurz hier melden. Gruß Hayo
Blue F. schrieb: > Hi, > > ja klar. Die Modifikationen sind nur optional. Die Firmware unterstützt > natürlich auch völlig unmodifizierte Geräte. Damit das geht, gibt es im > Hardwaresetup die Möglichkeit einzustellen, ob das Gerät modifiziert > wurde oder nicht. Da solltest Du nach dem Aufspielen der Firmware auf > jeden Fall nachsehen ob alles richtig eingestellt ist, sonst zeigt das > Gerät komische Dinge an. Beim allerersten Start mit der neuen Firmware > braucht das Gerät einige Zeit, weil es erstmal Tabellen für die > trigonometrischen Funktionen berechnen muss. Das macht es aber nur > dieses eine Mal. Du bekommst dazu eine Anzeige mit Fortschrittsbalken, > damit Du weißt ob es sich noch lohnt einen Kaffee zu holen :-) > > Viel Erfolg - bei weiteren Fragen einfach kurz hier melden. > > Gruß Hayo Vielen Dank für deine schnelle Antwort! Nochwas: Laden sollte man die Firmware am besten über ein RS232 Kabel, richtig? (Ist die Belegegung irgendwo dokumentiert?) Als Ladetool sollte man welche Software verwenden: Den WelecUpdater?
> Nochwas: > Laden sollte man die Firmware am besten über ein RS232 Kabel, richtig? Korrekt - über USB funktioniert das nicht! Die RS232 hat mehrere Vorteile: - es geht viiiel schneller - es ist völlig sicher. Die Laderoutinen (GERMS) sind Bestandteil des FPGA-Kernels. Kaputtflashen geht daher im Gegensatz zum USB nicht. Wenn was schiefläuft kann man es beliebig oft wiederholen. - Das ist ein normales RS232 Standardkabel (nix gekreuztes oder so). Da sollte eigentlich auch eins beim Gerät dabei sein. - Es gibt mehrere Möglichkeiten die Firmware zu flashen. Am einfachsten ist es, das mitgelieferte Windowsprogramm WelecUpdate.exe zu verwenden. - am Oszi muss zuerst der GERMS-Modus gestartet werden (F1 + F2 drücken, in genau der Reihenfolge - Der Schirm leuchtet dann kurz weiß auf). - alle Infos dazu und noch mehr findest Du in der mitgelieferten Doku Gruß Hayo
Hallo nochmals. Vielen Dank für deine Infos. Ich muss mal schauen ob ich noch an irgendeinem PC eine (richtige) RS-232 Schnittstelle zur Verfügung habe. LG
Hallo. Das Update hat funktioniert, Vielen Dank! LG
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.