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
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.