Announcement: there is an English version of this forum on Hi, > Die hängen aber alle hintereinander, d.h. ein Widerstand wirkt auf > alle ADCs. Einzelwiderstände müssten schon in die Leiterbahnstummel > zu den QFP-Beinchen, direkt an den AD8131 zwei "4er Packs" Widerstände und von diesen weg mit verdrillten Leitungen zu den ADC Beinchen? Gruß, Günter
Damals (TM) habe ich das mal an einem DVD-Player gemacht - QFP-Bein angehoben und den R hochkant drunter gelötet.....
@Bruno: >Dieser THS kann z.B. von einem l (der wird original verwendet),einem >OPA657 (erst stabil bei einer gain von 7), einem OPA659 (wird derzeit nicht >im SOT23-5 Gehäuse gefertigt) oder einem OPA653 (Lieferzeit 20 >Wochen)angesteuert werden. Wegen der Verfügbarkeit geeigneter Bauteile >kommt eigentlich nur der OPA657 als Alternative in Betracht. ich hab mal nach pinkompatiblen Modell gesucht. Da wären zum Beispiel AD8009, AD8001 oder AD8014. Ich bin nicht der Analogspezi, aber habt ihr diese Modelle schon in Betracht gezogen? lg Robert
Hallo Robert, Es gibt in der Tat noch ein paar Alternativen, aber was z.B. den AD8009 ausschließt ist: Input Resistance: +Input 110 kΩ, –Input 8 Ω Damit ist der spezifizierte und für Oszis typische Eingangswiderstand von 1MOhm II 15pF nicht zu halten. D.h. der erste OP sollte eigentl. schon FET Eingänge haben. Gruß, brunowe
Danke für de Hinweis. National hat auch ein paar Interessante: zB LMH6702 (Rin=1.4MOhm, Cin=1.6pF) oder LMH6624. Die haben sicher noch adere Typen auch. Auch der AD8001 (Rin+ = 10MOhm, Cin=1.5pF) schaut gut aus. lg Robert
Hallo, ich hab' mir mal das Grundrauschen etwas näher angesehen und dazu mal mit einer entsprechend modifizierten Firmware mal etwas mit den diversen Verstärkungseinstellungen an den OPAs herum gespielt. Dabei fällt auf, das die relative Größe des Rauschens unabhängig von der Einstellung der Verstärkung immer gleich bleibt. Das heist das Rauschen kann eigentlich nur auf der Strecke vom letzten AD8131 zu den ADCs oder in den ADCs selbst entstehen. Ich kann mir da vier mögliche Ursachen vorstellen: a) die unglückliche Leiterbahnführung zw. AD8131 und den ADCs b) an Pin-3 der ADCs (REFIO) ist ein ungeeigneter C oder er fehlt komplett c) das Layout ist bzgl Trennung Analog- u. Digital-Ground vollkommen daneben d) das Exposed-Pad der ADCs liegt nicht sauber auf Analog-Ground Vermutlich ist es eine Kombination von allen Gründen. Aber zumindest gegen b) könnte man wohl leicht etwas tun, brunowe könntest Du bei Gelegenheit mal die Referenzspannung an PIN-3 der ADCs hinsichtlich des Rauschens überprüfen. Gruß, Günter
Hallo Günter, ja, deine Erkenntnisse decken sich mit meinen (schlimmsten) Befürchtungen. Aber es gäbe noch eine mögliche Ursache- die innerhalb der digitalen Signalverarbeitung. Klingt zwar seltsam, aber ich spiele mich derzeit mit einer aufs Minimum reduzierte VHDL- Version .... und da kommt mir das Rauschen bei Weitem nicht so tragisch vor. Das werde ich auf jeden Fall noch mal intensiver untersuchen. Derzeit bin ich primär am Erforschen der Ursache für diese Oszillation bei höheren Frequenzen- und Pegeln über ca. 1/3 TFT Anzeige. Dazu hat mir Crazor ein noch nicht perfektes, aber für diese Zwecke schon recht brauchbares VHDL gebastelt. Die Überraschende Erkenntnis- bei 80MHz Input Signal lässt sich der Aussteuerbereich der ADC komplett ohne Schwingung durchfahren- im krassen Gegensatz zum Welec Design! Auch dazu werde ich, evtl. noch heute wieder ein kurzes Video auf Youtube stellen. Die Messung bzgl. des Rauschen mach ich natürlich noch. Gruß, brunowe
So, hier mein versprochenes Video: http://www.youtube.com/watch?v=Ma7Yoz7AHhI Bin mal gespannt was unsere Programmierer dazu sagen! Meine Folgerung aus dem Video: Die Oszillationen welche ich in http://www.youtube.com/watch?v=wo5eUZIkU5w mit der Original Fw und der aktuellen Hayo Fw darstelle, tritt mit verändertem VHDL Design nicht auf. ==> Irgendwo steckt im VHDL Design von Welec bzw. evtl auch irgendwo in der Assembler- Verarbeitung (mindestens) ein ganz massiver BUG. Dieses Problem beruht NICHT auf Fehler im HW Design- Wenn wir nicht auf ein neues VHDL Design übergehen, weiß ich nicht ob wir dieses Probl. beseitigen können. Kommentare willkommen! Gruß, brunowe P.S.: demnächst will ich diesen Versuch nochmal mit anderen hohen Freq. durchführen.
Hi brunowe, das macht doch noch Hoffnung fürs Hardware-Design. Wobei ich im Moment keine rechte Idee hab' wie man das Signal im VHDL und/oder Assembler Bereich unbeabsichtigt so verhauen kann. Sieht fast so aus alsob da im VHDL Code versucht wurde so eine Art Rauschunterdrückung zu schaffen die dann komplett daneben ging. Da bekommt man fast Lust sich doch mal den aktuellen Stand des neuen VHDL Designs anzuschauen. Gruß, Günter
Ist ja'n Ding. Da fällt mir momentan keine Erklärung zu ein. Keine Ahnung ob das an der FW liegen könnte oder eher am Design. Auf jeden Fall müßte man wissen ob das nur selektiv für einzelne Frequenzen gilt oder allgemein für alle hohen Frequenzen.. Hayo
Hallo Günter, vielleicht noch ein paar Worte zur Richtigstellung. Ziel von Bruno's Bemühungen war es nachzuweisen, das zwischen den ADC und der Darstellung auf dem TFT irgendetwas seltsames mit den Signalen passiert. Deswegen ist die analoge Eingangsstufe vom Kanal weitestgehend abgeklemmt. Um genau zu sein hat der Bruno, ich hoffe ich geb das jetzt exakt wieder, ein 220MHz Filter vor den ADC's von Kanal 1, an dessen Eingang er mit seinem Testsignal geht. Der Vergleich mit dem originalen VHDL-Design+FW1.3 und dem VHDL-Design an dem Crazor arbeitet ist unter exakt diesen Bedingungen durchgeführt worden. Um so mehr zeigt sich, dass was Bruno erwähnt hat, nämlich das irgendwas im VHDL-Design von Welec oder aber in der Assemblerroutine daneben geht. Crazor ist dran das VHDL-Design um ein Umschalten auf den Kanal 2 zu erweitern, weil Kanal 2 bei Bruno noch im Originalzustand ist. So ist man dann in der Lage direkt den Einfluss der analogen Vorverarbeitung auf die Signale ebenfalls mit abzuschätzen. Ich hoffe ich hab das jetzt für jeden verständlich erklärt. Gruß, branadic
Hallo branadic, danke für die Klarstellung. Allerdings kann man an diesem Aufbau schon mal erkennen, das die von mir vermuteten Probleme im Bereich der ADCs (lange Leiterbahn, AGND und REFIO) so schlimm nicht sein können, denn ich gehe mal davon aus, das brunowe die ADCs direkt hinter dem AD8131 abgeklemmt hat. BTW wolltest Du nicht mal ein kleines DDS Board machen? Gruß, Günter
Schon recht Günter, allerdings hilf uns das an dieser Stelle nicht wirklich weiter. Bin aber noch dran. Gruß, branadic
Hallo, ok... hab nicht erwartet das dieses Video so viele Fragen offen lässt. Geht einfach mal davon aus das dieses Video auch für Jeden (der dieses Board nicht liest) alle notwendigen Informationen liefert. Was bleibt also? Ein Signal mit 75MHz ruft ab einem bestimmten Pegel (welche ca. 1/3 des TFT Vollausschlag entspricht), bei allen bisher veröffentlichten Firmware (Welec original und Hayo) ein, mit steigendem Signalpegel zunehmendes oszillieren hervor. Die große Frage war jetzt: WARUM? Nachdem ich bei meinen bisherigen Messungen an der HW alles mögliche entdeckt habe, aber keine Erklärung für dieses Oszillieren, wollte ich mit dem Test einfach prinzipiell klären ob die HW, oder evtl. doch vermurkste SW/ VHDL Design für dieses Phänomen verantwortlich ist. Mein Kanal 1 wurde mit einem Tiefpass (Grenzfreq. ca. 220MHz) ergänzt, weil ich noch höherfrequente Störungen, welche evtl. Aliasing hervorrufen, unter allen Umständen von den ADC fernhalten wollte. Dieses oszillieren mit der Original (und Hayo) FW tritt trotzdem auf. Mein Rückschluss- irgendetwas läuft da im original VHDL Design mächtig schief. Auch wenn das für das neue Video verwendete VHDL nicht perfekt ist- z.B. Triggerprobleme- so hat es mir doch gezeigt das sich der komplette Aussteuerbereich, sprich 256Bit, auch mit 80MHz komplett ansteuern lassen. Bei beiden Videos sind die kompletten Eingangsstufen aktiv, d.h. das Signal wird direkt über den BNC eingespeist. Bei meinen bisherigen Tests konnte ich zwar dieses oszillieren durch versch. HW Massnahmen etwas dämpfen aber das prinzipielle Problem blieb immer bestehen. Die von Crazor erstellte VHDL wertet also ein mit max. Signalpegel anliegendes Signal mit 80MHz noch sauber aus- d.h. die Störungen durch die vorherigen Analogstufen sind minimal (bis auf das Rauschen?!). Mit dem Original VHDL klappt das nicht! Gruß, brunowe
heißt also, Hardwaremodifikationen sind (bis auf absolutes Finetuning) überflüssig? Nur buggy Software (FPGA)? Viele Grüße, egberto
Hallo egberto, speziell für mich bedeutet das: 1.) HW Modifikationen mit dem Ziel diese Oszillation zu unterdrücken erstmal einstellen. 2.) VHDL Testdesign verbessern bis noch bessere Aussagen möglich sind. 3.) Nähere Untersuchung des Oszillierens bei höheren Frequenzen. 4.) Ähnliche VHDL- Tests für das Rauschen durchführen (erfordert ein Anpassung des derzeitigen VHDL Designs- ADC Kalibrierung notwendig) Gruß, brunowe
Hallo brunowe, solange die ADC Kalibrierung, verursacht durch das Rauschen > 1Bit, keine reprudozierbaren Ergebnisse liefert, macht es eventuell auch Sinn die 4 ADCs erstmal getrennt zu betrachten. Gruß, Günter
Jetzt mal für die nicht so Hardwarebegabten unter uns (mich zum Beispiel): ist als Quintessenz aus den bisherigen Erkenntnisses auch zu entnehmen, dass selbst das grausame Rauschen und die ab und zu auftretenden riesigen Spikes auf verschiedenen Kanälen u.U. "nur" ein Software/Firmware/VHDL-Problem sein könnten? /Hannes
Johannes Studt schrieb: > Jetzt mal für die nicht so Hardwarebegabten unter uns (mich zum > Beispiel): ist als Quintessenz aus den bisherigen Erkenntnisses auch zu > entnehmen, dass selbst das grausame Rauschen und die ab und zu > auftretenden riesigen Spikes auf verschiedenen Kanälen u.U. "nur" ein > Software/Firmware/VHDL-Problem sein könnten? Zum Teil, das Rauschen war nicht das primäre Ziel der Untersuchungen von brunowe, aber in dem Video ist das Rauschen anscheinend auch deutlich geringer. Primäres Ziel war die merkwürdige (virtuelle?) Oszillation bei hoher Amplitute bzw hohem V/s. Ob die Amplitute oder die Anstiegsgeschw. die Hauptursache sind lässt sich aus den bisherigen Tests nicht schliessen. Gruß, Günter
Günter Jung schrieb: > Zum Teil, das Rauschen war nicht das primäre Ziel der Untersuchungen Das hatte ich schon verstanden, aber... > von brunowe, aber in dem Video ist das Rauschen anscheinend auch > deutlich geringer. ... das eben nicht richtig einordnen können, weil ich den im Video verwendeten Messbereich nicht (er)kenne. Bei 5V sieht das hier auch so schön glatt aus, bei 1V dagegen rauscht es mit ca. einem halben DIV. /Hannes
Der Bruno hat hier denke ich mit einem 5V Signal gemessen. Signalquelle ist ein Oszillator mit Spannungsteiler um die Amplitude zu verstellen. Das keine Einstellungen zu erkennen sind liegt daran, dass diese im VHDL-Design noch nicht angezeigt werden, eben weil es sehr rudimentär ist. Beste Grüße, branadic
Die Frage die sich mir jetzt so spontan stellt ist folgende: Läßt sich das VHDL-Design so verändern, dass - die Originale FW bzw. Open Source FW noch läuft - und die Störungen nicht mehr auftreten? oder müssen die Änderungen am VHDL-Design so tiefgreifend sein, dass auch der Firmwareseitige Hardwarelayer komplett neu geschrieben werden muß???? Gruß Hayo
Hallo Hayo, dazu vielleicht ein paar Worte von mir... Das Problem am VHDL-Design ist, dass Wittig seinerzeit Lizenzen für den Nios gekauft hat. Das ist ein Softcore der zusätzlich zur Hardware im FPGA läuft, also eine Art µ-Controller, den man über die Firmware anspricht. Mit dem Open Source Projekt stellt sich nun das Lizenzproblem, weswegen es ja die verschiedenen Ansätze für einen anderen Softcore gibt, der ebenfalls Open Source und somit lizenzfrei ist. Um noch mal alle aufzuzählen: T51 ZPU Leon3 Die Problematik mit der FW sieht also so aus, dass mit einem anderen Softcore auch in gewissen Grenzen eine andere FW her muss. Die Änderungen hängen dann von den Schnittstellen des Softcores ab. Ich hoffe ich konnte zur allgemeinen Verwirrung beitragen. :) Beste Grüße, branadic
Hi branadic, nett erklärt. Das war mir allerdings schon soweit alles klar. Nur weiß ich nicht welcher Softcore jetzt diesem Versuch zugrunde liegt und ob evtl. kleinere Änderungen am VHDL-Design ausreichen um die Schwingungen zu beseitigen. Der Umstieg auf einen anderen Softcore würde ja in jedem Falle massive Änderungen in der FW erfordern, da ja etliche Routinen in Assembler geschrieben sind und die corespezifischen Register und Peripherie verwenden. Gruß Hayo
Hallo Hayo, nach einer Änderung des VHDL-Designs müsste die Firmware natürlich von Grunde auf neu entwickelt werden. Deshalb ist es wichtig mit der momentanen Firmware in C möglichst unabhängig vom Hardwarelayer zu werden. Dann können später große Teile (sofern noch nötig) übernommen werden. Gruß, Guido
Hallo, um auch noch etwas zur allgemeinen Verwirrung beizutragen... Also meine Versuche beruhen auf der Hayo Fw, diese läuft ja bekanntlich mit dem original VHDL Design von Welec mit integriertem Nios I Softcore. Das zu Testzwecken entwickelte VHDL arbeitet mit einem ZPU Softcore- dieser wird allerdings nur für die Darstellung des Menüs benutzt. D.h. die Signaldarstellung ist rein in HW (also in VHDL) umgesetzt. Wir, speziell Crazor, entwickeln den VHDL Code derzeit weiter um noch bessere Aussagen treffen zu können. Änderungen am bestehenden VHDL Design sind, nicht nur aus lizenzrechtlichen Gründen, nicht möglich. Der Hauptgrund ist: uns liegt der Code nicht vor! (von Sicherungen des EPCS16 im jic bzw. pof Format einmal abgesehen). Was ich allerdings nicht abschätzen kann, ob der im Original auftauchende Fehler seine Ursache im VHDL oder in einer der zahlreichen Assembler-Routinen hat. Fehler im Assembler können wir fixen, VHDL Fehler nicht. So wie es derzeit aussieht, handelt es sich bei diesem Fehler um den Überlauf irgendeines Registers. Möglicherweise haben die, bei geringeren Frequenzen auftretende vereinzelte Spikes, die gleiche Ursache. Bei meinen bisherigen Versuchen mit den verschiedenen anderen VHDL Designs sind mir solche Spikes auf jeden Fall noch nie untergekommen. ...noch reichlich Potential zum spielen, testen und verbessern. gruß, brunowe
Hallo Bruno, ich denke der Punkt ist doch, daß es ein NIOS I ( in Worten: eins ! ) Design ist und der NIOS I bei Altera überholt ist. Ich habe im Netz einen Artikel von 2001 gefunden, wo es heisst: "The Excalibur Nios embedded processor is license and royalty free when used in Altera PLDs and HardCopy(TM) devices." (Wobei im Artikel auch schon widersprüchliche Aussagen enthalten sind.) ( suche nach "Industry's Popular Nios(TM) Soft Core Processor" ) Ich habe zur letzen Embedded World eine Vertreterin von Altera dazu angesprochen. Das Problem war, daß diese ganze Sache so alt ist, daß sie sich nicht so konkret erinnern konnte. Ebenso ein Distributor. Zumindest wurde diese Möglichkeit nicht ausgeschlossen. Dehalb meine Fragen: Habt Ihr das Lizenzproblem schonmal konkret abgeklärt, oder ist hier die Differenz zum NIOS II das Problem? Vielleicht könnte man die alte Quartus-Umgebung von Altera bekommen? Im Prinzip sind die Oszi-Designs ja alle schon mal lizensiert! Damit sollte einem korrigierenden und zu Hayos Opensource FW passenden Redesign des VHDL-Codes nichts mehr im Wege stehen!? Damit setzt man zwar auf einen ziemlich"alten Gaul". Aber bisher tut er es ja, wenn auch teilweise falsch....? Was meinst Du dazu? Gruß Jürgen
Mit Sicherheit sind die alternativen FPGA-Designs die hier entwickelt werden dem WELEC-Design überlegen. Die Frage (oder besser eine der vielen Fragen) ist in welchem Zeitrahmen ein neues (funktionierendes) Design zur Verfügung steht auf das wir FW-mäßig aufsetzen können. Falls das in einem abzuschätzenden Zeitrahmen von zwei oder drei Monaten wäre, lohnte es sich kaum allzuviel Schmalz in die Fehlerbereinigung der Assemblerroutinen zu stecken. Sollte eine Fertigstellung noch nicht abzusehen sein wäre es auf jeden Fall ein Ansatz die Assemblerroutinen aufzuarbeiten (das da Fehler drin stecken haben wir ja schon gesehen -> Stefan) um in einem akzeptablen Zeitrahmen eine Verbesserung zu erzielen. Um es kurz zusammenzufassen: Die Frage sollte sein, wann gehen wir von Plan B über auf Plan A. Hayo
Vielleicht hat jemand ja mal Lust, die von Jürgen angedeutete Geschichte näher zu recherchieren? Evtl. lohnt es sich, mal direkten Kontakt mit Altera aufzunehmen, denen unsere Situation zu schildern und deren Meinung über die Lizenzfrage einzuholen. Sofern es wirklich so ist, dass der alte NIOS mittlerweile frei erhältlich ist, kann man evtl. auch nochmal an die Wittigs herantreten und um die HW-Beschreibung bitten. Wenn ich mich recht erinnere, war beim letzten Mal die Antwort eher vage und man hat uns damit abgetan, dass die lizenzrechtliche Situation im Unklaren ist. Wenn es da wirklich um die NIOS-Lizenz ging, hätten wir dann vielleicht dieses mal ein paar Fakten in der Hand. Ansonsten können wir aber vermutlich auch von den HDL-Quellen von Welec nicht viel erwarten außer Bugfixes einzubauen. Tolle Entwicklungen wie die komplett in HW realisierte Signaldarstellung wird man vermutlich nicht portieren können, ohne sich mehrere Gliedmaßen auszureißen. Zumindest ist meine Erfahrung mit den generierten SoC bei Xilinx (EDK), dass alles großartig funktioniert und leicht umzusetzen ist, solange man keine Xilinx-Funktionalitäten verändern will. Man wird also dann vermutlich einen Displaycontroller schreiben müssen, der mit dem SOPC-Builder-Kram kompatibel ist.
Hallo, das klingt aber schon danach, dass ein neues Design nicht in absehbarer Zeit zu erwarten ist. Ich stelle es mir auch sehr anspruchsvoll vor und bin auch etwas skeptisch, ob sich die Ansprüche alles in Hardware zu machen realisieren lassen. Wenn ich an Verschiebungen der Triggerposition und solche Sachen denke, wird das alles sehr komplex. @ Bruno W: Na super, je genauer man hinguckt, desto schwieriger wird es. Den Assemblercode durchzuschauen ist nicht so aufwendig, aber wenn es am Design liegt? Selbst wenn wir die Quellen hätten, wäre der Einarbeitungsaufwand riesig bis erste Änderungen erfolgen können. Gruß, Guido
Hallo Guido, ich bin überzeugt das man mit etwas Zeitaufwand innerhalb des Wittig VHDL- Code sehr wohl die gravierendsten Fehler finden und ausmerzen könnte, wenn man diesen Code denn hätte. Meiner Meinung nach wäre es das Vernünftigste den Assembler Code mal genauer unter die Lupe zu nehmen, findet sich da ein Hinweis auf einen möglichen Überlauf.... umso besser. Wenn nicht, erstmal mit dieser Einschränkung leben und auf ein neues VHDL Design hoffen- aber das kann wirklich noch etwas dauern. Die Probleme liegen auch hier im Detail und leider sind derzeit einfach zu Wenige aktiv an der VHDL Weiterentwicklung beschäftigt. Gruß, brunowe P.S.: Eine entsprechende Anfrage bei Altera wurde inzw. von André abgesetzt.
Wenn ich bei Bruno so zwischen den Zeilen lese sieht es so aus als wenn Plan B (WELEC-Design) auch weiterhin die einzige Möglichkeit ist in einem überschaubaren Zeitrahmen Verbesserungen zu erzielen. Was sich beim Review der Assemblerroutinen anböte, wäre, diese evtl. in C/C++ Code umzusetzen (der ja eigentlich wenn er gut optimiert ist auch nicht langsamer ist) und damit einen Schritt in Richtung Hardwareunabhängigkeit zu gehen. Zudem ist der C-Code auch besser wartbar. Wenn dazu noch die Möglichkeit kommen sollte das WELEC-Design zu überarbeiten, was ja dann mit nur geringen Änderungen an der Firmware verbunden wäre, kämen wir unseren Zielen doch schon sehr nahe. Hayo
Kann selber leider mit Quartus / VHDL noch nicht weiter helfen... Hab inzwischen mal versucht einen lt. Kommentar in der OS-FW 0.66 vorhandenen Filter ( Set_Vars_Default in hardware_t.cpp , Bit 21 in adc_change12_reg ) abzuschalten. Leider keine Wirkung. Das Schwingen bleibt, weiterhin abhängig von der Signalamplitude. Wäre wohl auch zu einfach gewesen :-( @Bruno Vielleicht könnte uns Wittig auch den vermutlich vorhandenen Filter aus dem Design herausnehmen und uns die zwei *.pof Dateien für 2-Kanal und 4-Kanal zur Verfügung stellen, falls der Aufwand zumutbar? Gäbe zumindest keine Lizenzprobleme und das Knowhow kann auch dort bleiben. Und wir kommen weiter. Gruß, Jürgen
Servus, jetzt auch mal mit einem offiziellen Account :) @ Jürgen, wie du ja sicherlich schon mitbekommen hast, war Welec/Wittig wer auch immer von beiden, bisher nicht sehr hilfsbereit im Bereitstellen von Sourcen. Bruno hat es mehrfach versucht, andere Leute sind seinem Beispiel gefolgt. Ich hab Welec ebenfalls angeschrieben, aber scheinbar antwortet man nur auf Emails, die eine Kaufabsicht beinhalten. Daher kann ich dir und euch nur ans Herz legen: Meldet euch via Mail bei Welec. Zeigt ihnen, dass ein echtes Interesse einer großen Gemeinschaft besteht das Gerät zu verbessen. Wenn sich genug Leute melden, dann ist man vielleicht irgendwann bereit mehr Sourcen zu offerieren. Vielleicht hilft auch eine Art offener Brief, wo jeder seine Unterschrift hinterlassen kann, keine Ahnung. Solange jedoch keine komplette Offenlegung des FPGA-Designs seitens Welec zu erwarten ist, macht es keinen Sinn Hoffnung in die Verbesserung des originalen Welec Designs zu setzen oder mit irgendwelchen Änderungswünschen aufzuwarten. Daher kann man hier nur hoffen, dass ein Fehler im Assembler Code eine Änderung des FPGA-Design für die grundsätzliche Funktion überflüssig macht. Ansonsten kann ich Hayo nur beipflichten, je System unabhängiger man die Firmware gestaltet, desto leichter ist sie später auf ein anderes System portierbar. Beste Grüße, branadic
Hi branadic, > wie du ja sicherlich schon mitbekommen hast, war Welec/Wittig wer auch > immer von beiden, bisher nicht sehr hilfsbereit im Bereitstellen von > Sourcen. Ist mir so alles bekannt. >.... Meldet euch via Mail bei Welec. Zeigt ihnen, dass ein echtes > Interesse einer großen Gemeinschaft besteht das Gerät zu verbessen. Wenn > sich genug Leute melden, dann ist man vielleicht irgendwann bereit mehr > Sourcen zu offerieren..... Guter Vorschlag! Genau, wir können darum bitten! > Solange jedoch keine komplette Offenlegung des FPGA-Designs seitens > Welec zu erwarten ist, macht es keinen Sinn Hoffnung in die Verbesserung > des originalen Welec Designs zu setzen oder mit irgendwelchen > Änderungswünschen aufzuwarten. Weil eine komplette Offenlegung offenbar seitens Wittig/Welec nicht erwünscht oder nicht möglich ist, habe ich den Vorschlag als Alternative gemacht. Und Verbesserung heisst hier doch wohl zunächst eher nur gangbar machen der ursprünglichen Spezifikation. > Daher kann man hier nur hoffen, dass ein Fehler im Assembler Code eine > Änderung des FPGA-Design für die grundsätzliche Funktion überflüssig > macht. Eben Prinzip Hoffnung... :-) > Ansonsten kann ich Hayo nur beipflichten, je System unabhängiger man die > Firmware gestaltet, desto leichter ist sie später auf ein anderes System > portierbar. Das ist dann die Versicherung.. Stimmt! Schönen Abend! Jürgen
Welec ist ein klassisches Beispiel, wie Open-Source ein Geschäftsmodell sein könnte: Welec produziert und verkauft die Hardware zu annehmbaren Preisen (350 Tacken oder so für den 200 MHz 4-Kanaler) und die Firmware und Software könnte von der Community bereitgestellt werden. Daraus könnte durchaus eine Art Volks-Oszi (verzeiht den dämlichen Begriff) werden, entsprechende Stückzahlen mit inbegriffen. Vielleicht müsste man das dem Herrn W. einfach mal in dieser Deutlichkeit sagen, dass auch er damit gute Geschäfte machen könnte...
Hab mich im Rahmen der Rollmode-Implementierung mal mit dem ADC und seiner Ansteuerung beschäftigt. Die Ansteuerung und Pufferung der Daten wird ja komplett im FPGA abgefackelt. Und da hätten wir auch schon einen Ansatzpunkt wieso die unterschiedliche Signalqualität am Design hängen könnte. Im Datenblatt des ADC1121 wird ausdrücklich darauf hingewieden, dass ein akkurates differentielles Clocksignal benötigt wird - falls das WELEC-design hier was verbockt hätten wir schon eine mögliche Ursache für die Störung. Ein weiterer Punkt ist die Übernahme der Daten. MAXIM empfiehlt hier die ansteigende Taktflanke als günstigsten Zeitpunkt zum latchen der Daten. Wenn das WELEC-Design hier ein ungünstiges Timing hat, und z.b. bei einem ADC die Daten etwas verschoben latcht, dann hätten wir auch schon den Grund für die Spikes, die dann aus undefinierten Übergangszuständen der Datenausgänge resultieren (siehe Timingdiagramm im Datasheet). http://datasheets.maxim-ic.com/en/ds/MAX1121.pdf Hayo
Vielleicht sollten wir mal eine Testversion der FW bauen, bei der nur die Daten von einem, dann zwei ADC auf dem Bildschirm dargestellt werden. Das könnte weiter Hinweise liefern. Gruß, Guido
Vielleicht sollten wir mal eine Testversion der FW bauen, bei der nur die Daten von einem, dann zwei ADC auf dem Bildschirm dargestellt werden. Das könnte weitere Hinweise liefern. Gruß, Guido
Ja sowas in der Art ging mir auch schon mal durch den Kopf, speziell nachdem ich gesehen hab welchen Einfluß die Abstimmung der einzelnen ADCs auf die Qualität hat. Hayo
Ach was mir so bei intensiverem Nachdenken einfällt: dazu brauchen wir die FW nicht zu ändern, man muß nur wissen in welcher Timebase mit welchem Faktor gearbeitet wird. Den wiederum kann man der Timebasetabelle meiner Programming Maps die ich im anderen Thread ja schon veröffentlicht hatte entnehmen. Und zwar haben wir einmal die TB 100nS die mit Faktor 2 arbeitet, was bedeutet, dass nur immer zwei ADCs zum Zuge kommen. Zum Anderen haben wir alle 2er TB mit einem Faktor 4 -> hier wird immer nur ein ADC genutzt genau wie bei den TB 1µS und 2µS die bei einem Faktor von 20 auch nur einen ADC nutzen. Hayo
Hallo Günter, Hier noch die versprochene Rauschmessung an den ADC-Pin REFIO. Man sieht das man nichts sieht ;-) Gruß, Brunowe
Bruno We schrieb: > Hier noch die versprochene Rauschmessung an den ADC-Pin REFIO. > > Man sieht das man nichts sieht ;-) Und wieder eine Möglichkeit ausgeschloßen.
Hallo Leute (Hayo) Habe jetzt mein W2024A umgetauscht. Das neue Gerät macht von den Signalen schon mal einen besseren Eindruck. Kanal 3/4 funktionieren endlich richtig. (muss erst noch genauer testen....) Zuerst hatte ich Hardware: 8C7.0L und jetzt 8C7.C9 SV = 1.4 Was mir beim sichern der SV aufgefallen ist: Die erste 1.4 hat 3,519KB die jetzige 1.4 nur 3,159KB ? Gibt es da Unterschiede in den Versionen? l.G. Roberto
Hallo Roberto, auf die HW- Version würde ich an deiner Stelle nichts geben. Nach Aussage des Hr. Wittig (von vor 2 Monaten) wird die Oszilloskop- Serie W2000a nicht mehr weiterentwickelt. Nach mein meiner seit 2006- Wenn dir aber irgendwelche HW- Unterschiede auffallen sollten, dann wäre es toll wenn du diese hier kundtun würdest. Die Größe deiner Sicherungsdatei hängt einzig vom eingestellten Flashbereich ab, nicht von deren Inhalt. War also beides mal der selbe Bereich eingestellt, sollten diese Dateien auch gleich groß sein. Öffne doch einfach mal die Dateien mit einem Texteditor und vergleiche. Gruß, brunowe
Hallo, da ist man mal ein paar Tage weg und dann gibt es solch neue Erkenntnisse. Die Assembler-Routinen sind sehr konfus programmiert. Seiteneffekte sind nicht auszuschließen. Allerdings halte ich das trotzdem für weniger wahrscheinlich. Ich werde heute Abend mal an der Stelle etwas ausprobieren. Mein Problem ist allerdings, dass ich kein Testsignal bei so hoher Frequenz habe. Ich muss gestehen, dass ich von der Entwicklung eines neuen FPGA-Designs schon angetan bin. Allein die Möglichkeiten, die sich dabei auftun. Es müsste allerdings gelingen, dies an die aktuelle Firmware einigermaßen anzupassen. Dazu müsste aber der Assembler-Code raus...
Bruno We schrieb: > Die Größe deiner Sicherungsdatei hängt einzig vom eingestellten > Flashbereich ab, nicht von deren Inhalt. War also beides mal der selbe > Bereich eingestellt, sollten diese Dateien auch gleich groß sein. Neeeeeee. Der WelecUpdater und das Perlscript lassen komplett leere Bereiche aus dem Dump weg, und da die Komplettsicherung ja auch Datenbereiche enthält (soweit ich die Speicheraufteilung bisher oberflächlich verstanden habe), kann ein Komplettbackup eines bereits verwendeten Gerätes durchaus größer sein als das eines nagelneuen Gerätes. /Hannes
>Der WelecUpdater und das Perlscript lassen komplett leere Bereiche aus dem Dump weg. Ok, ist mir bisher zwar noch nicht aufgefallen, aber ja, mag sein. Man lernt schließlich nie aus. Dennoch kann ich fast nicht glauben das an der SW viel geändert wurde. Oder übernehmen Welec (heimlich) die von Hayo und Guido gemachten Verbesserungen in ihre FW? Das wiederum wäre sehr gut möglich, sofern mit geringem Zeitaufwand und geringem notwendigen techn. Know How verbunden. Doch noch was anderes. Den russischen Entwicklern um Slog ist mein Youtube Video mit den Oszillationen inzwischen auch schon aufgefallen. Sie suchen auch nach einer Ursache (und sind bislang offensichtlich noch geteilter Meinung). Evtl. finden Sie ja noch eine andere Ursache? Vielleicht ist ja der Ein oder Andere des. russischen mächtig? (Der Google Übersetzer ist da evtl. auch bedingt hilfreich) http://forum.ixbt.com/topic.cgi?id=48:7811-8 (und folgende Seite) http://forum.ixbt.com/topic.cgi?id=48:8586 (und folgende Seite) Gruß, brunowe
Bruno We schrieb: > Ok, ist mir bisher zwar noch nicht aufgefallen, aber ja, mag sein. Ist so, ich hab's schliesslich selbst reingeschrieben. :D > Man lernt schließlich nie aus. Dennoch kann ich fast nicht glauben das > an der SW viel geändert wurde. Dieses Komplett-Backup enthält nicht nur die Firmware. Der Bereich von 0x40000 bis 0xDFFFF ist offenbar identisch, aber im Bereich von 0xE0000 bis 0x7FFFFF gibt es Unterschiede zwischen den Geräten. Auf jeden Fall unterscheidet sich das letztens von irgendwem gepostete W2022-Komplettbackup von meinem W2024-Komplettbackup (nur) in diesem Bereich. Ich bin allerdings nicht im Bilde, was genau in welchen Bereich des Speichers herumoxidiert, aber einer der Firmwareexperten wird das sicher ganz genau wissen. Hat Hayo bestimmt auch schon mal irgendwo gepostet, aber ich hab es mir wie immer nicht gemerkt. /Hannes
>Vielleicht ist ja der Ein oder Andere des. russischen mächtig? (Der >Google Übersetzer ist da evtl. auch bedingt hilfreich) >http://forum.ixbt.com/topic.cgi?id=48:7811-8 (und folgende Seite) >http://forum.ixbt.com/topic.cgi?id=48:8586 (und folgende Seite) Ich kann leider kein Russisch (Google kann es zwar theoretisch, praktisch funktioniert es aber nicht) Es wäre cool, wenn du uns da über Neuigkeiten auf dem Laufenden halten könntest. Stefan
Hallo Bruno Beide Komplett-Backup's sind jeweils nach Erhalt des Gerätes mit dem WelecUpdater V0.4.8A22 mit den Standard Adressen (0x00040000 to 0x007FFFFF) gemacht worden. Das erste 3,519KB das zweite nur 3,159KB l.G. Roberto
Bruno We schrieb: > Oder übernehmen Welec (heimlich) die von > Hayo und Guido gemachten Verbesserungen in ihre FW? Das wiederum wäre > sehr gut möglich, sofern mit geringem Zeitaufwand und geringem > notwendigen techn. Know How verbunden. Ja das tun sie definitiv! Es ist mir an einigen Stellen der FW1.4 aufgefallen das einige kleinere Bugfixes parallel zur Open Source Version erfolgten. Ich hatte WELEC allerdings auch offiziell im alten Thread dazu aufgefordert. Allerdings können sie viele Änderungen nicht übernehmen da diese sich auf das größere Grid beziehen. Insbesondere die neuen Funktionen sind für WELEC nicht so ohne weiteres verwertbar. Johannes Studt schrieb: > Ich bin allerdings nicht im Bilde, was genau in welchen Bereich des > Speichers herumoxidiert, aber einer der Firmwareexperten wird das sicher > ganz genau wissen. Hat Hayo bestimmt auch schon mal irgendwo gepostet, > aber ich hab es mir wie immer nicht gemerkt. Sollst nicht blöd sterben - anbei die immer wieder gern geposteten Maps ;-) Hayo
Nachtrag ;-) 1.) Code hat 75163 Zeilen, 2.) Code hat 67483 Zeilen
Hallo Hayo, eine sehr interessante Aussage! Damit können wir jetzt, wenn uns danach ist, die Offenlegung der FW1.4 erbeten. Da unsere FW auf Grundlage der Open Source- irgendwo steht bestimmt genau welcher, entstanden ist, sind sämtliche Weiterentwicklungen etc. mit diesem Code bzw. mit Codefragmenten ebenfalls Open Source! Anfang/ Mitte letzten Jahres, zu Beginn der "Welec SW- goes Open Source" habe ich das mal irgendwo ausführlich beschrieben. Eigentlich gehört ein entsprechender Hinweis auch in jeden Datei-Header. Gruß, brunowe
@Bruno Theoretisch hast Du wohl recht, praktisch ist der Code allerdings nicht sonderlich interessant, da es sich in etwa um den FW1.2 Code handelt mit ein paar kleinen Änderungen. Da ist unser Projekt doch schon wesentlich weiter. Hayo
Hallo, Ich hab heute mal einen 117MHz Sinus an ein W2022A gelegt. Da nicht Jeder so hohe Frequenzen zur Verfügung hat, stell ich einfach mal ein paar Fotos hier rein. Im Prinzip geht es mir immer noch um das Oszillieren. Unser eigenes VHDL Design ist da leider noch nicht stabil genug in der Triggerung. Kommt aber noch. Ich will die Fotos noch nicht großartig bewerten, zu Vieles ist mir da einfach noch unklar bzw. sind auch noch nicht alle Messungen durchgeführt. Gruß, brunowe
Hallo, um die Störsignal- Einstrahlung auf das Mainboard zu unterbinden, hab ich ein Abschirmblech zwischen dem Schaltnetzteil und dem FPGA/ ADC Board reingebastelt. Im Prinzip beträgt mein Rauschen mit diesem Schirmblech jetzt so ca. ±2 Bit. Ich hab noch ein fieses 1kHz Störsignal von ca. ±4mV auf den Leitungen INN (bzw. auch auf INP) zu den ADC. Dieses muss unbedingt noch weg, dann bin ich mir sicher das ich das Rauschen auf ±1Bit bringen kann. Nach meiner Berechnung beträgt das, durch die 4 beteiligten Analog- Verstärkerstufen produzierte Rauschen max. ±1Bit. Das ist also das Ziel ohne großartigen Tausch der Komponenten. Hat Jemand einen Tip, woher denn dieses seltsame 1kHz Signal stammt? Kann das Jemand verifizieren? Da dieses Schirmblech zumindest nicht schadet, werde ich es die nächsten Tage nochmal ordentlich anfertigen- dann stell ich auch ein Foto davon rein. Gruß, brunowe
Bei 1KHz würde ich auf Rechteckgenerator tippen. Brauchst auf die Schnelle eine FW ohne Rechteckgenerator? Dann schau ich mal.
Finde leider auf die schnelle nichts. Ich würde aber mal messen, ob das Rauschen in Phase ist mit dem Rechteckgenerator.
...Rechteck- Generator, darauf bin ich ja noch garnicht gekommen. Den kann ich einfach von der Spannung nehmen. Normalerweise (zumindest bei uns) ist der rein in VHDL implementiert, ihr werdet da wahrscheinlich nichts in der FW finden. Ich hatte sogar schon einmal angefangen diesen Generator über VHDL auf bis zu 12,5MHz aufzubohren, als Referenz- und Testsignal. Ist aber im jetzigen VHDL Design wieder verloren gegangen... Danke erstmal- Brunowe
Hallo, in dem Oszilloskop arbeiten laut Blockschaltbild pro Kanal 4 ADCs mit je 250MSamples/s im Interleaving Modus, um die 1GSamples/s zu erreichen. ADCs interleaved zu betreiben soll problematisch sein. Im Artikel "Interleaving ADCs for Higher Sample Rates" http://www.national.com/nationaledge/feb05/article.html wird darüber einiges geschrieben. Vielleicht rührt das Schwingen daher?
Hallo Stefan, also am Rechteckgenerator scheint es nicht zu liegen. Selbst bei unserem minimal VHDL- das ja derzeit ohne diesen Generator läuft, ist eine Rechteckstörung zu messen. Diese Störung wird durch die analog- Stufen verstärkt, hängt also indirekt von der gewählten Spannungsauflösung am Oszi ab. Alles noch etwas suspekt derzeit. Da hilft wohl nur eine weitere, systematische Suche. Auf jeden Fall ruft allein dieses Rechtecksignal einen Fehler von bis zu 2 Bit am ADC hervor (in den 1er Messbereichen). Das, mit etwas HF Störung überlagert, führt zu dem Rauschbild wie wir es momentan am TFT sehen. Gruß, brunowe
Ein Vorschlag: Mal per VHDL nur einen der 4 ADCs pro Kanal benutzten, dann kann man die Interleaving-Problematik ausschließen. 250 MSamples/s würden auch reichen. Evaluating Oscilloscope Sample Rates vs. Sampling Fidelity http://cp.literature.agilent.com/litweb/pdf/5989-5732EN.pdf
Hallo Kurt, ja gibt es. Inzwischen hab ich das Schirmblech einmal mit Inventor gezeichnet. André hat sich bereit erklärt bei dementsprechender Nachfrage dieses Blech professionell anzufertigen. Dafür benötigt er allerdings meine CAD- Daten und muss einen Rüstplan erstellen. Es geht in dieser Richtung also auf jeden Fall was vorwärts. Ich werde mich spätestens zur Ermittlung der ungefähren Stückzahl wieder diesbzgl. melden. Gruß, brunowe
Ich brauche den Schaltplan (pdf) der Frontplatte mit den ganzen Tastern, Drehencodern und Schieberegistern. Könnte den bitte jemand hier hochladen. Leider funktioniert das Wiki von sourceforge zur Zeit nicht.
SourceForge hat gestern einiges an der Server-Infrastruktur geändert, daher die Ausfälle. Das Trac ist ab sofort unter folgender URL zu erreichen: http://sourceforge.net/apps/trac/welecw2000a/ Die alten URLs bleiben dank Forwarding auf unbestimmte Zeit weiter gültig.
@Bruno Ich wäre auf jeden Fall an zwei Blechen interessiert. Hayo
Angehängte Dateien:
-
Welec_Schirmung_2008.jpg
32 KB
Hallo, gut, das deckt sich mit meiner Abschätzung das wir bestimmt 10 Bleche unter die Leute bringen können. Anbei mal eine Grafik wie das Ganze aussieht, der Übersichtlichkeit halber hier nicht bemaßt. wenn der der Wunsch nach der dwg/ dfx/ sat- Datei besteht kann ich die demnächst auch mal hier reinstellen. So, mal abwarten was André dazu sagt, dann kann es eigentlich auch schon losgehen. Gruß, brunowe
Ach, vielleicht noch zur besseren Vorstellung: Die kleine Lasche links unten auf dem Bild wird am Chassis befestigt, knapp unterhalb des TFT, mit der bereits vorhandenen Schraube der Gehäuserückwand. Durch die Ausklinkung in der Mitte des Blechs wird das SNT mit der Hauptplatine verbunden, da kommen also die langen Steckkontakte der Hauptplatine durch. Links und rechts neben der oberen Aussparung befindet sich je eine Bohrung, damit wird das Blech mit dem SNT verbunden. Die elektrische Verbindung findet primär über die Erdung am SNT statt- deshalb am besten mit Sägezahnscheiben befestigen.
Hallo Bruno, ich hätte auch Interesse an 2 Blechen. Mit dem Blech ist dann die komplette like Gehäusehälfte zugebaut. Nur rechts hinter den ADs, Abschirmblechen und FPGAs bleibt noch etwas Platz? Es gab mal Überlegungen, das Oszi mit einem Akkupack auszustatten. Man müsste nur nach dem AC/DC Wandler die 12V umschaltbar machen auf eine andere Quelle. Dafür ist aber sicher noch Platz vorhanden. Mfg, Kurt
@Michael, ich hätte Interesse an einer Tasche. Läuft mittlerweile die Sache mit dem FPGA? (anderes Kabel)
Hallo Bruno, ich habe Interesse an zwei Schirmblechen. Gruß Jürgen
@ Kurt Leider hatte ich das Kabel schon recht früh als Fehlerquelle ausgeschlossen. Außerdem habe ich die Treiberprobleme sowohl am PC als auch am Laptop. Auch hier scheint das Kabel egal zu sein. Da ich Freitag Abend einen Supergau am Rechner hatte, bin ich nicht weiter zum Testen gekommen und muß erstmal zusehen, dass ich den wieder zum Laufen bekomme. Hat einfach die Mitarbeit verweigert, Hardwarefehler, denke ich mal... Mal sehen, ob ich die Tage eine erste Tasche fertig bekomme. Danach werde ich dann wohl etwas Material bestellen müssen (Rucksacktuch, Reißverschlüsse und Klett). Was ich so an Material habe, gebe ich gerne ab. Wenn dann noch mehr gefragt sind, muss ich sehen, was eine Tasche materialmäßig kostet. Michel
Hallo, möchte auch mein Interesse an einem Schirmblech anmelden. Detlev
Hallo Leute, ihr braucht euch hier NIHCT wegen des Schirmbleches zu melden, dass macht nicht viel Sinn. Die Vorgehensweise wird wie folgt sein: - Fertigung eines Bleches nach den CAD-Vorlagen von Bruno - Verifikation der Verbesserung der Signale - danach werde ich dann hier die Verifikation bildlich bestätigen und eine Mailadresse bekanntgeben, an die ihr eure Anschrift und die Anzahl an Schirmblechen bekannt geben dürft, bis habe ich dann auch einen Preis für das Blech - dann setze ich eine Frist bis zu der ihr euch bei mir melden könnt und lasse eine entsprechende Stückzahl an Blechen fertigen Ich denke das ist der einzig richtige Weg. Beste Grüße, branadic
Angehängte Dateien:
Hallo, so die CAD Daten stehen. Jetzt geht es an die Prototypen- Fertigung. Das weitere läuft dann über branadic. Er wird dann rechtzeitig hier seine Email-Adr. bekannt geben. Ich hab das Ganze noch etwas für die Fertigung optimiert (Eckenrundung, Bohrlöcher durch Langlöcher ersetzt, Aussparung für die Schraubenführung der Rückwand etc.) Anbei ein Bildchen wie es letztendlich mal aussehen soll. Gruß, brunowe
Hallo @ All, helft mir bitte mal auf die Sprünge! Ich habe jetzt meine C-Routine so umgeschrieben, dass ich mir nur noch die Daten z.B. eines ADC anschauen kann. Jetzt erhalte ich mit nur einem angezeigten ADC Schwebungen wenn die Schwingungsdauer des Testsignals ein ganzzahliges Vielfaches der Abtastzeit ist. Also bei 65,5 MHZ, bei 83,33 MHz usw. Was verstehe ich hier nicht? Nyquist verbietet das doch nicht. Auch weit außerhalb dieser Bruchteile (z.B. bei 90 MHz) sind die Folgen die bekannten, die versauten Signale. Wenn bei diesen Schwebungen noch eine Phasenverschiebung zwischen den 4 ADCs dazukommt und alle vier zur Anzeige kommen, darf man sich nicht über den Murks wundern, der bei solchen Frequenzen angezeigt wird. Gruß, Guido P.S.: Falls sich das jemand anschauen möchte, s. Anhang.
Angehängte Dateien:
-
schwebung.jpg
100 KB
>Ich versteh die Frage nicht :)
Ich auch nicht. Mal ein Bild dazu: Es wird nur ein ADC auf dem
Bildschirm angezeigt. Im rechten Bild sieht man, dass es eine
Schwebung gibt. Die Signalfrequenz liegt bei ca 83,33 MHz, wobei
ich sie für das rechte Bild etwas aus der Schwebung rausgedreht
habe, damit es deutlicher wird.
Im linken Bild sieht man die Auswirkungen bei höherer Auflösung.
Wenn jetzt noch drei ADCs hinzukommen, deren Eingangsspannung
phasenverschoben ist, darf man sich nciht wundern wenn nur noch
Chaos resultiert.
Die niedrigste Frequenz bei der ich so eine Schwebung erhalte
liegt bei ca 36 MHz. Darunter ist Ruhe.
Was will uns das sagen?
Gruß, Guido
Interessant, dass das es auf den Scheitelpunkten immer ruhig ist.
Passiert das auf allen ADC oder nur auf einem? Ruhig auch mal Einzelwerte von den anderen ADC anschauen!
Hallo Daniel, das passiert auf allen 4 ADCs. Das einzige, das ich mir vorstellen kann ist, dass die Anordnung der Samplewerte im FIFO irgendwie verdreht ist. Morgen weiter überlegen, Guido
Mal eine Anmerkung von einem, der kein Scope zum Testen besitzt: Mit einem Softwarefehler (vor allem als alleinige Ursache) als Erklärung tue ich mir rein gefühlmäßig schwer. Sieht irgendwie aus als ob ein Eingangsverstärker ins Schwingen kommt, eine Masse davon läuft oder ähnliches. Vielleicht sollte man das Signal mal (mit einem professionellen Scope) direkt am Eingang des ADC messen... Beste Grüße und viel Erfolg, odic
Hallo, ja klar Odic X, die Hardwareprobleme kommen noch hinzu. Da bin ich messtechnisch auch an meinen Grenzen, habe weder einen Differenztastkopf noch ein genügend schnelles Oszilloskop. Das lässt sich aber ganz gut trennen, wenn man eine kleine Auflösung für die Spannung wählt (dann bleiben den Eingangsverstärkern mehr "Luft"). Die Schwebung sehe ich auch bei Vpp = 1 div. Mir geht es hier erstmal um das Verständnis das mir fehlt. Ich habe heute nochmal probiert und erhalte diese Schwebungen für Periodendauern von 8 ns (125 MHz), 12 ns (83,33 MHz) und 16 ns (62,54 MHz). Also bei Vielfachen der Abtatszeit von 4 ns pro ADC. Gibt es dafür eine plausible Erklärung? Dass dabei die Phasen auseinanderlaufen ist ja klar, aber dass man das auf einem Screen sieht? Ich habe jetzt sichergestellt, dass es immer derselbe ADC ist, der mir angezeigt wird. Verwende ich zwei ADCs pro Kanal, ist die Schwebung nicht mehr so deutlich zu erkennen, aber die Qualität der Darstellung wird eben auch nicht besser. Gruß, Guido
Jetzt kommt mir noch eine Idee: Könnte es sich um "stehende Wellen" auf der Platine handeln? Dann sollte ein Abschlusswiderstand an den ADC helfen. Muss ich morgen mal rechnen, Guido
aus der info würde ich folgern: der effekt is aliasing und da es ab ca. 36 Mhz auftritt --> adc hat 62Mhz sample-rate (250Mhz/4) ! dann ergeben sich "schwebungen" bei 125Mhz..usw
Entschuldige bitte die blöde Frage.... aber was für eine Signalform tastest du eigentlich ab???
Hallo, @Alfsch: Das timing der einzelnen ADC und die Realisierung in VHDL ist recht komplex. Es lässt sich dennoch sagen, das die einzelnen ADC's mit einer Freq. von 250MHz sampeln (bei 1GSa/s- wie aus Guidos Foto oben ersichtlich). In der Anlage habe ich einmal aufgelistet wie der russ. Entwickler Slog, in seiner Version 1.3 versucht, Laufzeitunterschiede bei der Ansteuerung der ADC durch einen gewissen zeitl. delay zu kompensieren. In unserem FPGA sind 4 PLL's vorhanden, welche zur zeitl. Steuerung sämtlicher Vorgänge auf dem Board benutzt werden können. Die einzelnen PLL's werden von einer Quarzfreq. von (nur) 25MHz gespeist (INclk0). Diese 25Mhz werden dann in den PLL's (für die Ansteuerung der ADC) mit einer Ratio von 1:10 auf 250MHz erhöht (c2). Dieses Signal c2 kann (muss) jetzt mit einer bestimmten Phasenverschiebung an die einzelnen ADC's ausgegeben werden. Dabei ist jede PLL einem bestimmten ADC zugeordnet (eigentlich 2 ADC's- Ch1 und Ch2) Wir erkennen das im Beispiel die Phasenverschiebung (und damit der delay bei der Ansteuerung der einzelnen ADC's) vom Ideal 0ns-1ns-2ns-3ns abweicht. Die Phasenverschiebung kann in VHDL mit einem delta von 12,5° "justiert" werden, und erlaubt somit eine gute Kompensation von Clocksignal- Laufzeitunterschieden. Das auf den anschließenden Seiten folgende Programmlisting zeigt einfach noch einmal die Zuordnung der einzelnen Clocksignale auf die jeweiligen ADC's und ist hier eher von untergeordnetem Interesse. gruß, brunowe
P.S: und doch wieder einen Fehler entdeckt! streiche in obiger Ausführung "mit einem delta von 12,5°" und setze: auf die Werte 15°, 22,5°, 30°, 45°, 60°, 67,5°, 75°, 90°, 105°, 112,5° usw. gruß, brunowe
nun ja, sagen wir so: SOLL 250Mhz clock... IST: 62 Mhz clock...jedenfalls ala messung. kann auch 250Ms sein, nur jedes 4. sample wird benutzt == 62 Ms bzgl pll 1. muss die pll auf 500Mhz laufen, wegen dem k-teiler dahinter (siehe db) 2. mehere plls für die 4 adc zu benutzen, is bescheuert, da jede pll wunderbare 90° phasen liefern kann, die dann auch 4x 90° versetzte 250Mhz clocks liefern (würden)
@Düsentrieb: also erst einmal wird doch wohl von nur einem spezifischen ADC jedes sample benutzt?! dieser ADC wird mit 250MHz getaktet- Ergo 250MSa/s. Zu 1.) Du beziehst dich da auf die Altera application note AN507 nehme ich an? Dir ist bewusst das sich diese AN507 auf Cyclon III FPGA's bezieht? (Bei uns wird der Cyclon II verwendet- da gibt es keinen post-divider k) Laut Cyclon II Device Handbuch berechnet sich die PLL- Ausgangsfreq. zu: The output frequency to the global clock network or dedicated external clock output is determined by using the following equation: fglobal/external= fin* (m/(n*c)) fIN is the clock input to the PLL and C is the setting on the c0, c1, or c2 counter. Zu 2.) Wie ebenfalls im Cyclon II Device Handbuch nachzulesen ist: "The Cyclone II PLL supports up to three global clock outputs and one dedicated external clock output." Da der "dedicated external clock output" nicht verwendet werden kann, bleibt also nichts anderes übrig als schon mal min. 2 PLL's zu nutzen. Das im Endeffekt alle 4 PLL's genutzt werden hat meines Wissens symmetrische Gründe (in Jeder Ecke des FPGA liegt eine PLL) und wird in irgendeiner AN von Altera so empfohlen (frag mich jetzt blos nicht wo!) Wie immer lass ich mich gern eines besseren belehren, ich bin schließlich kein FPGA Crack. Aber bitte schreib die Quellen deiner Aussagen dazu, damit man sich das nachlesen und sinnvoll hinterfragen kann. Gruß, brunowe
Angehängte Dateien:
-
cyc-pll.png
54 KB
http://www.altera.com/literature/lit-cyc2.jsp http://www.altera.com/literature/hb/cyc2/cyc2_cii51007.pdf -> bild
was beim oberen Bild evtl noch wichtig gewesen wäre: (3) If the VCO post scale counter = 2, a 300- to 500-MHz INTERNAL VCO frequency is available. Ansonsten kenne ich die aufgeführten Quellen natürlich, dennoch ist mir nicht ganz klar was du mir damit sagen willst.
1.
>Bei uns wird der Cyclon II verwendet- da gibt es keinen post-divider k
so? aber im bild schon... ! ?
2. eine pll hat 3 outputs, wenn pll 500Mhz + k /2 = 250Mclk :
0 : 0°
1 : 90°
2 : 270°
und 0 invertiert = 180°
benutzt wird, kann eine pll alle 4 adc steuern. und zwar immer korrekt.
3. ich bin auch kein fpga profi ...
Ok, wir haben nicht nur unsere Clocksignale, sondern auch die invertierten Clocks. Die ADC werden mit diff. Clocksignalen gespeist. Ich schätze einfach das man sich die Möglichkeit der Feinjustage der zeitl. Abfrage nicht nehmen wollte. Du bist natürlich gern dazu eingeladen deinen Vorschlag am aktuellen VHDL Design zu testen. Falls es bei uns in der laufenden VHDL Entwicklung zu timing Problemen kommt, besteht immer noch die Möglichkeit auf deinen Vorschlag zu switchen. Gruß, brunowe
Hallo, die PLLs haben zwar 3 Ausgänge, jedoch kann nur ein Takt am Ausgang pro PLL verwendet werden. Die Phasenlage muss mit zero buffer delay geregelt werden, ansonsten würde die Phasenlage des Taktausgangs falsch sein. Nebendem: Quartus synthetisiert sowieso nichts, falls irgendwas mit den Takteinstellungsmöglichkeiten am FPGA nicht stimmt. i = {0, 1 ,2} fout[i]= fin* (m/(n*c[i])) ist korrekt und wird auch von meinem design und auch dem Codeteilen von slog verwendet! Für eine Kontrolle, ob die Daten im VHDL Design richtig gereiht sind, kann nur mit einer VHDL Simulation überprüft werden, da die ADCs keine guten pseudo Testwerte (Zähler) senden können. MfG Alexander
>jedoch kann nur ein Takt am Ausgang pro PLL verwendet werden. hm, nee... aus dem cii..db: Each PLL generates three clock outputs through the c[1..0] and c2 counters. Two of these clocks can drive the global clock network through the clock control block. somit geht: 0° + 90° als clocks von einer pll 180°+270° ergeben sich durch invertieren + >Die Phasenlage muss mit zero buffer delay geregelt >werden, ansonsten würde die Phasenlage des Taktausgangs falsch sein. warum?? laut db: In no compensation mode, the PLL does not compensate for any clock networks, which leads to better jitter performance. also: ohne kompensation weniger jitter, die phasenlage stimmt aber, da alle signale ja von einer clock-pll kommen ! voila... aber macht nur, wie ihr meint...ich bin ja nicht der profi...
Falls meine Frage in eurer - zugegebenermaßen interessanten - Diskussion untergegangen sein sollte... Welche Signalform hätte eigentlich dargestellt werden sollen? Beste Grüße, odic
Ich muss zugeben, ich stecke nicht drin in dem ganzen PLL-Kram, aber mal ne ganz bescheidene Frage: Wie sollen die Clocks denn invertiert werden? In der PLL scheint sowas nicht vorgesehen (oder ich kann es nicht finden), und alles außerhalb der PLL wird doch sicher ne Phasenverschiebung nach sich ziehen?
@Alfsch, ich muss dir hier eindeutig widersprechen. Die von dir vorgeschlagene Möglichkeit geht nicht. Es gibt einen Unterschied zwischen (FPGA-) intern verfügbaren Clocksignalen und auch extern abgreifbaren. Da wir unser Clocksignal ja nach außen zu den ADC führen müssen, benötigen wir externe Taktausgänge- und davon gibt es pro PLL NUR EINEN- wie Alexander oben schon aufgeführt hat. Das ist auf der beigefügten Tabelle von Altera sehr gut zu erkennen. @Crazor: Wie in der beigefügten Tabelle ebenfalls erkennbar, ist das externe Clocksignal als singel ended, oder differentielles Signal verfügbar. D.h. die PLL erzeugt also auch ein um π phasenverschobenes Clocksignal. DENNOCH: Es führt in unserem Fall kein Weg an der Nutzung aller vier PLL's vorbei. So, und jetzt beantworte doch Jemand (Guido) die Frage von Odic.... nicht das das noch untergeht. Gruß, brunowe
#Bruno ok, ich hatte ne andere fpga architektur im kopf... echt doof, die clocks können anscheinend nicht auf die i/o-blocks rausgelegt erden --- tja , dann geht wohl echt nur 1 clock pro pll --- shit happens
Hallo Odic X., nicht das das noch untergeht :-)): Testsignal ist der Sinus eines VCO von knapp 53 MHz bis 135 MHz bei -10 dBm. Ich muss mal nach Alias googlen. Anders kann ich mir das nicht erklären. Gruß, Guido
Hallo Guido, so, nach der tiefer gehenden PLL- Diskussion zu deinem Fall zurück. Was mir an deinem linken Foto als erstes auffällt ist, das da niemals ein ADC ordentlich ausgelesen wird. An deiner Stelle würde ich erstmal die Schwebung vergessen und versuchen alle 4ns einen eindeutigen Wert eines ADC's darzustellen (am besten in Vector off). Das wäre ein interessanter Versuch um auch das HF- oszillieren näher zu untersuchen. Erst wenn die gesampelten Werte eines einzelnen ADC (im kompletten Frequenzbereich) plausible Werte liefern und zu einer nachvollziehbaren Darstellung führen, würde ich mich um eine evtl. Schwebung bzw. mit der "Zusammenschaltung" aller ADC befassen. gruß, brunowe
Angehängte Dateien:
-
resol.jpg
99 KB
Hallo, also die Samplerate ist in Ordnung. Die Bilder zeigen einen Sinus mit 31,25 MHz also einem Achtel der Samplerate pro ADC. Links mit einem ADC aufgenommen, erkenne ich sehr periodisch 8 Sample pro T, rechts mit zwei ADC ebenfalls recht sauber 16 Samples pro T. What next, Guido
Hallo Guido, Hintergrund meiner Frage war genau das Thema Aliasing. Bei einem 200MHz-Scope (keine Ahnung ob man die Welec-Scopes tatsächlich so bezeichnen darf ;-) ), würde ich eine Begrenzung der Bandbreite auf > 200MHz vermuten. Wenn du jetzt ein Rechtecksignal verwendet hättest (egal ob 63 oder 125MHz) hättest, wäre die Abtastrate auf jeden Fall zu niedrig gewesen (egal ob 63MS/s oder 250MS/s)... Ob man so aber die von dir gezeigten Darstellungsfehler erklären kann weiß ich nicht... Beste Grüße, odic
Hallo Guido, wieviele Pixel entsprechen eigentlich einem einzelnen Sample? Das geht aus der Darstellung nämlich nicht hervor. Ideal wäre, wenn 1 Sample = 1 Pixel ist, dem scheint hier aber, abgesehen von dieser seltsamen Interpolation, nicht so zu sein. Kannst du selbiges Bild mal im reinen Vector Off - Modus zeigen? Gruß, branadic
Hallo branadic, in Pixeln ist das schlecht auszudrücken. Immer die horizontale Linie ist ein Sample, das dann 2 oder 4 mal (mit 2 oder 1 ADC) in den Speicher geschrieben wird. Vectors off geht nicht, da müsste ich erst wieder die Interpolation ausschalten. Gruß, Guido
Hallo, @Odic Du hast recht- vor den ADC liegt leider kein Low pass Filter. Im Rahmen meiner Oszillations- Untersuchung hab ich auf Ch1 ein solches, mit einer Grenzfreq. von ca 200MHz eingefügt, die Schwingungen blieben dennoch. Dies, zusammen mit meinen Versuchen mit unserem VHDL Design, hat mich darauf gebracht, daß es sich wahrscheinl. (auch) um ein SW Problem handelt. @Guido Die neuen Bilder sehen doch schon besser aus, wenn diese blöde Vektordarstellung nicht wäre! Ich geh davon aus, wenn du dir 10 Perioden oder mehr anzeigen lässt, also z.B. deine 31,25 MHz bei 50ns/Div dann lässt sich auch keine Schwebung erkennen? Die Schwebung bei höheren Frequenzen lässt sich auch erklären. Schalte die Interpolation aus!!! Bedenke das du bei einem ADC mit 250Msa/s und einer Freq. von 83,33MHz nur noch 3! Punkte pro Periode hast. Das lässt sich noch korrekt darstellen (nach Nyquist), aber eben nur OHNE Interpolation. Für Interpolation ist mehrfaches Oversampling notwendig. Für sinc ist mindestens 2,5 faches oversampling, für lineare Interpolation sogar 10 faches oversampling notwendig. Gruß, brunowe
Hallo Bruno We., nach meiner Beobachtung ist die Interpolation unschuldig. Ich mache später mal noch Bilder bei höheren Frequenzen, nach meiner Erinnerung werden die Sample dann unperiodisch, deshalb der Versuch mit 31,25 MHz weil ich schon auf Undersampling getippt habe. Ist es aber wohl nicht. Naja, wenn mir die Zeit reicht, schalte ich die Interpolation wieder aus. Gruß, Guido
P.S.: Ja, bei den 31,25 MHz ist keine Schwebung! Denk dir die Interpolation einfach raus, die hor. Anteile sind die gedehnten Sample, die schrägen Verbindungen die Vektoren.
@Bruno: Keine Eingangsfilter? Sollte es sich um eine Oszilloskop handeln, welches nur für periodische Sinussignale konzipiert wurde?? Das ist ja ein echtes Novum.... ;-) Irgendwie habe ich nach deinem Posting den Blick für das zu lösende Problem verloren... Kann es nicht einfach sein, dass das dargestellte Signal unter diesen Bedingungen und mit der Interpolation eben aussieht wie es aussieht ..... sprich alles korrekt ist?
Genau dieser Meinung bin ich mittlerweile auch. Diese Darstellung der Messwerte (horizontales Strecken oder was auch immer das sein soll zzgl. der bescheidenen Interpolation) wird schlichtweg ungünstig sein. Nimm die echten Samples und versuche durch diese Punkte den Sinus zu legen, dann müsste die Frage geklärt sein. Dazu könnte ein Matheprogramm hilfreich sein, à la GNU-Plot, Octave, Matlab oder Maple. Beste Grüße, branadic
Wie ist eigentlich die BW-Begrenzung realisiert? Hardware? Software? Kein Eingangsfilter ist ja echt ein starkes Ding.
Hallo Stefan, der Schaltplan ist doch öffentlich verfügbar, du kannst dich selbst von der Sinnhaftigkeit überzeugen. Diesen hier versuche ich immer möglichst aktuell zu halten: http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment.pdf gruß, brunowe
In Software geht das nicht. Aus den abgetasteten Werten lässt sich ein Fehler, der der aufgrund zu hochfrequenter Oberwellen entsteht, auch nicht mehr "rausfiltern". Daher muss die Filterung vor der Quantifizierung erfolgen... und ich hoffe doch sehr, dass sie das auch irgendwo tut....
Naja, keine Filterung ist Euphemie. Alle in der Eingangsstufe eingesetzten Bauteile sind auf eine max. Frequenz von 200 MHz dimensioniert. Wenn da jede Stufe 3 dB beiträgt, ist das Tiefpassfilter garnicht so schlecht. Es bleibt für mich halt die prinzipielle Frage, ob nach der Theorie das Antialiasingfilter auf 125 MHz dimensioniert sein müsste (ein ADC) oder eben auf 500 MHz (alle 4 ADC)? Schimpft nicht so über die Interpolation. Ich hatte die schon deaktiviert und das hat exakt Null gebracht. Mich stört sie nicht so sehr. @ Stefan: Die Bandbreitenbegrenzung erfolgt mit einem RC-Glied bei 20 MHz. Sie macht sich auch exakt so bemerkbar, wie ich bei früheren Messungen schon angegeben habe. @ branadic: das Strecken das ich meine ist einfach die Übetragung des Wertes eines ADC auf den Speicher für 4 ADC. Normalerweise haben wir vor der Grafik die Folge ADC0-ADC1-ADC2-ADC3-ADC0. Ich verwende zum Test nur einen ADC oder zwei, was die Folgen ADC0-ADC0-ADC0-ADC0 oder ADC0-ADC0-ADC2-ADC2 ergibt. Dadurch werden die echten Samples deutlich sichtbar. Die schrägen Linien zwischen den Samples erzeugt die Interpolation, was die Beurteilung aber in keiner Weise beeinträchtigt.. Gruß, Guido
Die Aussage der fehlenden Filterung würde ich in dem Fall nicht als beschönigende Formulierung bezeichnen, sondern eher als traurige Wahrheit. Zumal ich der Meinung bin, dass man eine gute Filterung nicht auf Basis der Leistungsdaten der verwendeten Bauteile dimensionieren sollte... ;-) Schliesslich möchte man ja keine frequenzabhängige Dämpfung sondern ein möglichst "digitales" Verhalten des Filters... Was die Dimensionierung angeht: in der Theorie müsste die höchste Frequenz <500MHz sein (da ja auch sehr niederfrequente Signalanteile zulässig sein sollen). In der Praxis muss der Filter aber aufgrund seines nicht idealen Verhaltens mit etwas Spielraum dimensioniert werden. Ansonsten danke für die Erklärung der vertikalen Linien, das hatte ich bis dato anders interpretiert. Damit stören mich die Signale aber im Moment wirklich nicht.... Beste Grüße, odic
Die sog. "Schwebungen" kommen von keiner Interpolation dieser Welt. Schon gar nicht von einer linearen! Ich finde das auch mit den horizontalen Linien klar erkennbar, wo da die Samples sind. Der Hund liegt woanders begraben. Zumal sich das Verhalten mit meinem VHDL-Design wirklich nicht nachstellen lässt. A propos: Freut euch schonmal, der Downsampler läuft soweit (bis auf ein Problem bei 10µs/div, wie ich mir gerade sagen lassen habe). Abzüglich Aliasing (denn es gibt bisher keine Filter vorm Downsampling) könnt ihr bald mal spielen, also installiert schonmal den ByteBlaster Treiber ;)
Angehängte Dateien:
-
resol2.jpg
86 KB
Hallo, nächste Folge: jetzt ca. 42 MHz (6 Samples/Periode) und ca. 53 MHz (5 Samples/T). Auffällig ist, dass es doppelte Samples gibt. Das kann nicht aus Übersteuerung folgen, die Auflösungsgrenzen der ADCs liegen außerhalb des sichtbaren Grids (sic!). Wieso ändert sich bei den doppelten Samples innerhalb 4 ns der ADC-Wert nicht? Wer ist da an der Grenze? @ Odic X.: Ich bin noch nicht überzeugt. Was macht der einzelne ADC aus einem 400-MHz-Signal, das insgesamt noch unter der Nyquist-Grenze liegt? Welche Folgen hat das singuläre Undersampling? Gerade für die Oberwellen interessant. @ Daniel: Oh, das wird wieder was fürs Notebook mit Windows. Gerade war ich sehr glücklich, dass ich so schön mit Linux probieren kann (der RAM-Upload ist echt Gold wert!). Naja, ran an Altera, da wird wieder Unterhaltung geboten. ;-) Grüße, Guido
Vorausgesetzt es gibt das SDK für den FX1 auch für Linux, kannst du auch den Treiber von Linux aus laden. Mindestens aber kannst du den ByteBlaster-Treiber wohl auch von Linux aus fest ins Flash des FX1 packen. So habe ich das auch gemacht, da die ganze Re-enumeration-Sache des Driver Loaders von Slog in virtuellen Maschinen nicht so recht funktionieren mag. Ein paar Notizen von mir findest du hier: https://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster Leider habe ich das mit dem fx2_programmer auf dem Mac nie ganz zum Laufen bekommen. Es handelt sich aber ja auch um einen FX1. Das Hochladen der Firmware hat immer geklappt, aber starten mochte der Kram dann nicht richtig, der Quartus Programmer hat sich immernoch bei 1% aufgehangen. Aber vielleicht hast du im Abschnitt über den fx2_programmer schon genug Stichworte und findest mal heraus, wie das wirklich gemacht wird. Über eine überarbeitete Anleitung im Wiki zum temporären und vll auch dauerhaften Laden der ByteBlaster-Firmware würden wir uns freuen!
Ach ja, für alle ohne SourceForge-Account: Einfach das s bei https:// entfernen ;)
Wenn du mit 400MHz Signal einen Sinus mit 400MHz meinst, dann hat dieser keine Oberwellen. Die Grundschwingung von 400MHz ist gleichzeitig der Signalanteil mit der höchsten Frequenz. Somit könntest du mit >800MS/s abtasten. Sprich beim Welec-Scope geht das nur mit allen vier ADCs. Wenn dein 400MHz Signal eine andere Signalform hat, deren Grundschwingung lediglich bei 400MHz liegt, entsteht diese durch Überlagerung von Sinus und Cosinus-Schwingungen unterschiedlicher Frequenz und Amplitude. Mathematisch gesehen hast du also eine Addition der einzelnen Signalanteile. Folgende Überlegung hilft vielleicht: Theoretisch sollte es doch egal sein, ob du ein Signal (sprich die Summe aller einzelnen Schwingungen) quantisierst, oder es vorher in sein Frequenzbestandteile zerlegst, die einzelnen Schwingungen in diskrete Werte überführst und diese nachher wieder zusammenrechnest. Und genau an der Stelle treten die Probleme auf. Für die hochfrequenten Oberwellen hast du aufgrund der zu niedrigen Abtastrate nicht genügend Informationen, um sie später (durch die Interpolation) rekonstruieren zu können. Dennoch haben diese Oberwellen den diskreten Wert beeinflusst, wenn sie nicht vor der Abtastung durch einen Tiefpass aus dem Signal entfernt wurden. In der graphischen Darstellung des interpolierten Ergebnisses führt dies zu Darstellungsfehlern, dem Alias-Effekt. Das hat dann nichts damit zu tun, das die Interpolation selbst (egal ob in Software oder Hardware) fehlerhaft ist. Sie macht das was sie soll... nur eben mit den Daten, die sie bekommt. So, ich hoffe das war jetzt nicht zu wirr. Beste Grüße, odic
Hallo, Guido wrote: > Die Bandbreitenbegrenzung erfolgt mit einem RC-Glied > bei 20 MHz. Sie macht sich auch exakt so bemerkbar, wie ich bei > früheren Messungen schon angegeben habe. Tja, Guido, die ZUSCHALTBARE Bw Begrenzung funktioniert, da gebe ich dir recht. ABER! standardmäßig wird das Signal nicht mit einem TP begrenzt- und da liegt auf jeden Fall ein ganz dickes Problem, zumal der OPA656 die unschöne Eigenschaft hat, höhere Frequenzen mehr zu verstärken. Ich hab als Anlage den Frequenzverlauf der Welec analog input stages beigefügt. Meiner Meinung nach sollte man Frequenzen über 250MHz, bis auf einen Signalpegel der weniger als 1Bit Auflösung der ADC entspricht (2,4mV), dämpfen. Alles darüber bringt uns keinen echten Informationsgewinn und führt nur zu Problemen. Gruß, brunowe
Angehängte Dateien:
-
Fouriersynthese.jpg
36 KB
Sieht ja nicht sehr berauschend aus... Die rund 1dB bis 250MHz in den Bereichen 10mV bzw. 20mV würden mich bei einem Oszi in der Preisklasse weniger stören. Die ca. 1,2dB zwischen 0 und 40MHz im 50mV-Bereich schon deutlich eher. Im Anhang mal ein Bild mit einem Rechteck mit Oberwellen bis zur 9-fachen Grundschwingung. Damit wäre das Scope bei einer Eingangsdämpfung ab 250MHz noch bis ungefähr 25MHz verhältnismäßig brauchbar. odic
Hallo, na da wäre ich aber mal deutlich opszimistischer. Die in den Datenblättern angegebenen Grenzdaten werden in der Praxis nie erreicht. Wenn ich mir allein das Layout ansehe! Auch das FR4 ist bei diesen Frequenzen schon nicht mehr ganz ideal. Wenn wir einen Tiefpass brauchen, können wir dem OPA die Verstärkung rhöhen. Mit Vu = 2 sollte er ja ab 250 MHz dämpfen. Viel weiter oben habe ich ja schon den Versuch mit einem RC-Tiefpass beschrieben. Da hatte ich dem schaltbaren RC-Glied einen festen Kondensator dazu geschaltet. Den musste ich aber auf 68 pF erhöhen, um eine Verbesserung festzustellen. Das entspricht dann einer Grenzfrequenz um 50 MHz. @ Odic X.: Naja, die normalen Grenzen eines DSO halt. Mir reicht aber normalerweise die 5. Oberwelle um einen Rechteck zu erkennen. Gruß, Guido
Mit Optimismus hat das leider wenig zu tun. Die Simulationen von Bruno bzw. die Rechnungen sprechen eine deutliche Sprache... Ach ja, ein Rechteck erkennen kann ich selbstverständlich auch bei weniger Oberwellen. Aber - nichts für ungut - in der Regel benutzt man ja ein Oszi nicht zum Raten von Signalformen... ;-) Häufig möchte man auch bestimmte Signaleigenschaften beurteilen (Anstiegszeiten, Überschwingverhalten, hochfrequente Störanteile und vieles vieles mehr). In diesem Sinne viele Grüße von odic ... der gerade keine Lust hat zu arbeiten... ;-)
Hallo, habe mal eine andere Frage: es müsste doch mit dem neuen FPGA-Design möglich sein, die 1GS über alle Messbereiche beizubehalten und dafür ab einer bestimmten Zeitbasis nur noch den Mittelwert auszugeben. Das wäre zwar nicht optimal, aber zumindest in größeren Zeitbasen müsste doch das Rauschen abnehmen.
Stefan E. schrieb: > habe mal eine andere Frage: es müsste doch mit dem neuen FPGA-Design > möglich sein, die 1GS über alle Messbereiche beizubehalten und dafür ab > einer bestimmten Zeitbasis nur noch den Mittelwert auszugeben. Das wäre > zwar nicht optimal, aber zumindest in größeren Zeitbasen müsste doch das > Rauschen abnehmen. Kann man machen. Ob das sinnvoll ist, weiß ich noch nicht ;) Drüber nachgedacht habe ich aber auch schon... Müsste mal jemand mit mehr Plan drüber nachdenken, was das so für Konsequenzen haben könnte.
Hi, mal ein Beitrag zur Hardware aus völlig anderer Richtung, nachdem ich ja eigentlich mehr in der soften Ecke anzutreffen bin. Wie Ihr Euch vielleicht erinnert hatte ich mir vor kurzem ein W2014A zusätzlich zugelegt um auch 4-Kanal Support machen zu können. Bei diesem Gerät stellte ich dann fest, dass nach einiger Laufzeit (also wenn das Gerät warmgelaufen war) auf Kanal 4 extreme Störungen auftraten. Das ließ mich vermuten, dass das thermische Design des Gerätes ungefähr genauso ausgereift ist wie die FW oder der Rest der Hardware. Also hab ich mal das Gehäuse aufgeschraubt und mir das Ganze etwas genauer angesehen. Als erstes habe ich mal eine "thermische Messung" an den ADC mit dem kleinen Finger gemacht. Dabei hab ich mir fast den Finger verbrannt. Ok, damit war schon mal eins der Problemkinder lokalisiert. Sinnigerweise ist auch direkt über den ADC der Lüfter montiert. Wenn man sich das aber mal genau ansieht stellt man fest, dass der Lüfter über ziemlich schmalen Schlitzen auf Stelzen montiert ist, was dazu führt, das eigentlich nur die warme Luft im Gehäuse verquirlt wird anstatt kühle Luft anzusaugen. Hier effektive Abhilfe zu schaffen ist ausnahmsweise mal sehr einfach. Ich habe einfach die Schlitze im Kunstoffgehäuse aufgefeilt (länger und breiter) und dann um die vier Stützen einen Tesafilmring gewickelt, der den Luftzug kanalisiert und das Ansaugen von Nebenluft aus dem Gehäuse verhindert. Das funktioniert so gut, das man die aus dem Gehäuse gedrückte warme Luft an den oberen Schlitzen deutlich spürt. Ergebnis: - Das Lüftergeräusch ist jetzt wegen der größeren Öffnungen etwas lauter - Die Störungen sind verschwunden (auch im Dauerbetrieb) Da das so gut funktioniert werde ich diese Änderung auch noch an meinem W2022A vornehmen. Auf jeden Fall kann ich das allen Besitzern eines Vierkanalgerätes empfehlen. Falls allgemein Interesse besteht kann ich auch noch eine kleine bebilderte Doku erstellen. Gruß Hayo
Habe mal den Ansaugstutzen aus Klebeband nachgerüstet, aber die Schlitze habe ich gelassen, wie sie sind. Allein das Klebeband macht schon gut was aus! Nun noch einen anständigen Papst-Lüfter und evtl. eine kleine Regelung von Reichelt rein und dann ist alles super.
Hallo, ich habe auch mal dem Lüfter einen Ansaugstutzen aus Klebeband verpasst. Damit wird merklich mehr Außenluft angesaugt. Danke für den Hinweis. Grüße Kristian
Hmmm, nach Trennung vom Netz und Transport im Auto geht beim Einschalten nur noch der Luefter an und sonst passiert ueberhaupt nix. Auch die Statusmeldungen, die frueher ueber die serielle Schnittstelle rausgepurzelt kamen, bleiben aus. Flashen geht natuerlich auch nicht mehr. Ist sowas schonmal bei irgend jemandem aufgetreten? Sehr merkwuerdig... Gruessle
Hallo André, nachdem der Lüfter geht, liegst nicht am sehr wackligen Kaltgerätestecker oder am Einschalter (der z.B. bei mir schon mal hinüber war) oder an der Sicherung. Ich schätze du kommst nicht umhin das Gerät mal zu öffnen und zu kontrollieren ob die Hauptplatine noch Spannung vom SNT bekommt. Die Kontakte/ Spannungszuführungen sind ja gut zugänglich und lassen sich im Betrieb gut messen. Den Schaltplan findest du hier: http://groups.google.com/group/welec-dso/files Datei: Ext syncro.png. Einen Fehler/ Wackler direkt auf der Hauptplatine halte ich eher für unwahrscheinlich. Falls die Spannungsmessung keinen Fehler zeigt, melde dich einfach nochmal. Gruß, brunowe
Angehängte Dateien:
-
Einbau1.JPG
330 KB
Hallo zusammen, am Wochenende habe ich ein erstes Muster des Schirmbleches schneiden lassen. Anbei eine erste Inspiration. Sorry für die miese Bildqualität, aber außer einer HandyCam kann ich leider nur mit einer Webcam dienen. Ich hab noch ein paar kleinere, aber notwendige Änderungen einzubringen, ansonsten wäre dies der Stand. Das Blech ist aus 0,3mm gelasertem und gekantetem Messing. Für Skeptiker, das ist ausreichend stabil nach dem Kanten, es soll schließlich nichts tragen, nur schirmen. Für den ersten Versuch hab ich es mal an der Abkantbank gebogen. Tatsächlich würde es jedoch professionell auf eine 6-Achs-CNC-Abkantpresse hergestellt werden. Das Teil hat dann also Industriequalität. Der Preis pro Schirmblech beläuft sich auf 8,-€ inkl. Mwst. zzgl. Versandkosten (400,-€ für 50 Schirmbleche). An den Preis ist jedoch eine Bedingung geknüpft. Wir müssten mindestens 50 Schirmbleche, das entspricht einer Tafel Messing, zusammen bekommen, damit sich der Rüstaufwand der Maschine beim Abkanten überhaupt irgendwie lohnt. Das Erstellen des Biegeprogrammes und das Rüsten der Maschine mit den entsprechenden Biegewerkzeugen an den einzelnen Biegestationen verschlingt gut Zeit, die auf alle Bleche kostenmäßig umgelegt ist. Für jedes Blech sind 2 Minuten zum Abkanten veranschlagt. Das mal so außer der Reihe. Das Ganze würde wie folgt laufen. Ihr meldet euch per Mail bei mir mit Namen, Anschrift und wieviele Bleche ihr benötigt. Dafür habt ihr bis einschließlich 12. Juli Zeit. Ich bin in der Zwischenzeit eh im Urlaub, also nicht wundern, wenn es keine Antwort in der Zeit gibt. Danach werden wir sehen ob genügend Bleche zusammen gekommen sind. Falls ja mache ich das hier bekannt (natürlich auch im Falle nein) und die entsprechenden Leute werden eine Mail mit Kontodaten von mir bekommen. Ihr überweist das Geld, ich bestelle die Bleche wenn ich das Geld auf dem Konto habe und hole sie persönlich ab. Danach versende ich sie an die betreffenden Personen (das mache ich in meiner Freizeit nach Feierabend). Ich hoffe nun, dass ausreichend Anfragen von euch zusammen kommen. Und zu guter Letzt jetzt noch die Kontaktmail: branadic (ed) users (pünktchen) sourceforge (pünktchen) net Sollte verständlich sein oder? Also, meldet euch zahlreich bei mir :) Beste Grüße, branadic
Hab dir schon eine Email geschrieben. Eventuell veröffentlichst du es auch unter Sourceforge, falls die 50 Bleche nicht zustande kommen.
Also wenn hier jetzt jeder einzeln mitteilt, dass er "seine" Mail geschickt hat, ist das für die Allgemeinheit nicht wirklich von Interesse. Sollte es erforderlich sein, dass alle von diesem Vorgang erfahren, hätte Branadic sicher vorgeschlagen, dass sich jeder einzeln hier einträgt - er hatte aber sicher einen Grund dafür, eben das nicht zu machen...
Hallo zusammen, kleiner Zwischenstand: Aktuell haben wir die ersten 25 Bleche zusammen, also die Hälfte. Meldet euch weiterhin zahlreich über die angegebene Mailadresse bei mir. Beste Grüße, branadic
Hallo, ich lese hier seit kurzem mit und muß auch gleich ein Lob an alle (Hard- und Software-) Entwickler aussprechen. Mein Welec wäre beinahe wieder bei eBay gelandet... Ich bestelle gleich auch ein solches Blechle! Grüße, Hardy
Hallo Leute, ab morgen bin ich im Urlaub. Aktueller Stand ist, dass wir 42 Bleche zusammen haben. Ich denke das sich die letzten 8 in den nächsten zwei Wochen auch noch finden werden. Versand innerhalb Deutschlands wird als Warensendung erfolgen, also preislich übersichtlich bleiben. Meldet euch weiterhin zahlreich bei mir, wenn es mehr als 50 werden könnte das sogar von Vorteil sein :) Beste Grüße, branadic
@ branadic: Na dann, schönen Urlaub. Ist schon erstaunlich wie viele Leute mitlesen. Gruß, Guido
Ich möchte mich auch mal auf der Hardware- als auch bei der Softwareseite bedanken. Ihr macht das Oszi erst wirklich brauchbar!!! PS.: Ich fliege morgen um 15:00 Maturareise und habe vor ner Stunde mein Maturazeugnis bekommen. FEIERN
Angehängte Dateien:
-
Umbau.jpg
250 KB
Hallo Leute Habe heute mein W2024A zerlegt weil da Fusseln im Display waren. Bei der Gelegenheit habe ich dann gleich den Lüfter umgebaut Habe das jetzt aber ein bisschen anders gemacht. Habe die Lüftungsschlitze alle abgezwickt und mit dem Messer glatt gemacht. Dann hatte ich noch so ein Lautsprechergitter. Das habe ich zurechtgeschnitten und mit Schmelzkleber eingeklebt.Dann wieder den originalen Lüfter rauf. Rundherum dann noch so ein Aluband aus dem Lüftungsbau.(Siehe Foto) Saugt jetzt recht gut. l.G. Roberto
Angehängte Dateien:
-
Stecker.jpg
96 KB
Und weil ich gerade dabei bin, ich habe mir auch noch so einen Stecker für die 1kHz Signal-Buchse gemacht. Das ist immer so blöd da mit dem Tastkopf rannzugehen... Es passte leider kein Stecker so recht aus meiner Bastelkiste.... :-( Habe dann aber noch einen alten von meinem LEGO.. gefunden :-) l.G. Roberto
Gute Idee mit dem Lautsprechergitter! Evtl. kann man auch einen etwas größeren Lüfter einbauen und ein echtes Lüftergitter montieren. Das sollte dann noch deutlich leiser sein.
Mich hatte dieser 'Messkontakt' für den internen Oszillator auch immer genervt. Dieses letzte Stück, diese Metallhülse ist doch nur auf das Board gesteckt, oder? So ein Teil habe ich noch nie gesehen und hatte auch schon überlegt, irgend etwas Festes zu installieren. Alle anderen Oszis, die ich kenne, haben dort eine Öse oder Schlaufe montiert.
Michael W. schrieb: > Dieses letzte Stück, diese Metallhülse ist doch nur auf das > Board gesteckt, oder? gelötet.
@Roberto Sehr elegante Lösung. Gefällt mir. Wenn man nach dem Umbau die Hand auf der linken Seite des Gehäuses (beim Netzteil) über die Lüftungsschlitze hält, merkt man mal was da im Auslieferungszustand für ein Hitzestau im Gerät ist und jetzt rausgeblasen wird. Gruß Hayo
Bei mir war der Messkontakt nur gesteckt, eine feine Spitze von weniger als einem mm Durchmesser in einem verzinntem Lötpunkt. Der ist beim Öffnen des Scopes gleich rausgefallen (und beinahe unter meiner Veranda verschwunden). Wie oft kann man eigentlich das Scope öffnen? Ich hab Schiss, dass ich irgendwann einen der Drehimpulsgeber rausreisse, einige der Knöpfe sitzen doch arg fest. Da ich mit dem USB-Blaster nicht zurechtkomme, werde ich wohl das Scope nochmal ordentlich modden: - die beiden ISP-Anschlüsse werde ich mir da gleich nach draußen legen - neuer Lüfter mit Luftführung und STECKKONTAKTEN - Messbuchse anlöten - Schirmblech montieren Noch was vergessen? Michel
Hallo Michael, ich hab mein Oszi bestimmt schon 50 mal auf- und wieder zu gemacht. Ein Encoder ist mir dabei noch nicht abgebrochen, aber da die Knöpfe tw. recht fest sitzen, hab ich die Knöpfe innen etwas abgefeilt und ein bisschen Kupferpaste drauf- jetzt gehen sie gut runter ohne zu locker zu sitzen. Deine Liste der Modifikationen deckt sich in etwa mit meiner Liste der bereits durchgeführten Arbeiten: * Lüftungsmodifikation (Ein Zwischending von Hayo's und Robertos Änderung) * Lüfter mit Steckkontakten anschliessbar- wesentl. Vorteil da ich das Gerät häufig zu Messzwecken ohne Rückwand bzw. in Einzelteilen betreibe. * JTAG Anschluss nach außen geführt um problemlos VHDL Updates einspielen zu können * Statt der sehr fragwürdigen Cal. Buchse hab ich einfach eine 4mm Buchse eingebaut- die Cal. Buchse ist bei mir schon sehr früh abgebrochen. * Auf das professionell gefertigte Schirmblech warte ich natürlich auch noch. Ich hab mein Probe- Entwicklungsblech drin. Da dieses Blech nicht nur die HF Strahlung, sondern auch den Luftstrom verhindert müssen wir ggf. nochmals testen ob unser SNT dann nicht zu heiß wird! * Dann hatte ich, wie viele Andere auch, Probleme mit dem Netzschalter. Geknistert hat es da drin ja schon von Anfang an, eines Tages ging gar nichts mehr. Leider konnte ich in meiner Bastelkiste keinen brauchbaren Ersatz finden und so musste ich den Alten wieder instand setzen. Der geht jetzt zwar bestimmt schon seit einem Monat ohne Knistern und Funkenschlag, aber Dauerlösung ist wohl nur der Austausch durch einen qualitativ besseren Schalter. Evtl. findet ja Jemand was passendes? ** Die zahlreichen Änderungen an meinen analog- input- stages will ich derzeit nicht näher ausführen, leider konnte ich bislang noch keinen durchschlagenden Erfolg in Punkto Rauschreduzierung (und HF Oszillation) erzielen. Gruß, brunowe
Bei mir ist beim ersten öffnen gleich ein Drehimpulsgeber abgerissen, weil der Knopf zu fest saß. Ich habe ihn dann durch einen Alps Impulsgeber von Pollin ersetzt. Der dreht auch viel angenehmer, vielleicht ersetze ich mal alle... Gruß, Boregard
Eine Frage an die Hardwareecke: In der FW gibt es Hinweise auf einen geplanten Logicanalyser. Hierzu gibt es bereits Interruptroutinen die den Parallel IO betreffen. Gibt es auf der Platine Anschlüsse oder Vorbereitungen die darauf hinweisen, dass es da mal einen Anschluß für einen Extender geben sollte? Gruß Hayo
Man kann oberhalb des 2. FPGA der 20x4-Geräte einen unbestückten Pinheader ausmachen, der 8 IO-Pins an die Geräteoberseite herausführt. Kannst du mal sagen, wo du solche Hinweise gefunden hast?
Einen Logikanalyser für serielle Protokolle (CAN, UART, I²C, SPI (W20X4)) könnte man ja mit den vorhandenen Kanälen integrieren. Wäre eine nochmalige Aufwertung des Gerätes =)
Daniel H. schrieb: > Man kann oberhalb des 2. FPGA der 20x4-Geräte einen unbestückten > Pinheader ausmachen, der 8 IO-Pins an die Geräteoberseite herausführt. > Kannst du mal sagen, wo du solche Hinweise gefunden hast? Ok, nun hab ich schonmal selbst den Interrupt Handler dafür entdeckt ;) Zwei Dinge lassen sich sicher relativ leicht klären: 1.) Kann aus dem restlichen Code geschlossen werden, ob der Logic Analyzer nur bei Vierkanalgeräten aktiv ist? 2.) Interrupt aktivieren und schauen ob man den mittels des entdeckten Pinheaders auslösen kann (böse, ich weiß ;)
Das wäre sicher eine interessante Sache. Leider komme ich momentan nicht zu weiteren Nachforschungen, da ich mit dem Umbau der FFT ziemlich ausgelastet bin. Wie ich aber schon in der Firmwareecke gesehen habe ist da reges Interesse an einer Logikfunktion vorhanden. D.h. es wird wohl nur eine Frage der Zeit und der vorhandenen Resourcen (sprich Entwickler) sein bis wir das in irgendeiner Form implementiert haben. Gruß Hayo
Sehr interessant, was Ihr da treibt. Punkt A: Ein Tip zu den Blechen: Bei bisherigen Projekten dieses Ausmaßes hat sich immer eine hohe spätere Nachfrage ergeben. Überlegt mal, wieviele W20xx inzwischen verkauft wurden und werden. Die Frage ist, ob man gleich 100 Stück (sind das 2 Tafeln?) herstellen soll, oder erst auf praktische Erfahrungen der 1. Tafel warten soll, um ggf. in die 2. Tafel Verbesserungen (z.B. Perforation an unkritischen Punkten wg. Wärme) einzubringen. Punkt B: Wo werden die Geräte hergestellt? Woher werden die Geräte eigentlich geliefert? Wer ist der offizielle Hersteller, der die 3 Jahre Garantie gibt? Wieviele gibt es noch? Er verkauft ja wie es scheint jede Woche ca. 10 bei eb.y. Hat jemand schon mal direkt bestellt, ohne eb.y ? Wie schaut es mit Mengenrabatt aus? Macht das alles Hr. Wit... alleine? Hatte schonmal jemand Kontakt mit dem Entwickler? Hat dieser das ganze Gerät (FPGA + Firmware) alleine gemacht?
Hallo eProfi, die Geräte werden in England zusammengebaut, an Wittig in Böblingen/Konstanz/Italien geliefert und an den Endkunden versandt. Offizieller Hersteller ist Wittig Technologies GmbH. Michael Mittig arbeitet mit seinen Brüdern zusammen: http://www.wittigtechnologies.com.br/whoiswho.php Der Firmwareentwickler ist unter http://thinklogic.de/ zu finden. Er hat aber nicht alleine die Firmware verbrochen, Teile davon stammen wahrscheinlich von Hameg. Siehe auch Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Hier http://www.wittigtechnologies.com.br/w2000.php Hatten sie wohl noch FFT geplant ? Aber dann nicht mehr verwirklicht :-( l.G. Roberto
Roberto schrieb:
> Hatten sie wohl noch FFT geplant ? Aber dann nicht mehr verwirklicht :-(
Aber Hayo hat's doch gerichtet! Siehe Software-Thread...
War sogar drinnen. Nur grauenhaft schlecht und in der aktuellen FW wieder abgeschaltet. Kannst aber über die serielle Schnittstelle anschalten.
Hallo Roberto, die FFT wurde doch realisiert. Ich glaube bei der Original Version bis 1.2 oder so geht die noch (wenn man das so bezeichnen will). FFT wurde erst bei den neueren Versionen wegen massiver Performance- Probleme deaktiviert. Alles in allem kein Vergleich zu der jetzigen FFT. @Kurt: bist du dir sicher das die Gewährleistung nicht über die Fa. Welec läuft? Die ja im Prinzip nur eine Fortführung der damals Insolvent gegangen Fa. Wittig ist. @eProfi: 1.) Von thinglogic brauchen wir uns wohl keine neuen Erkenntnisse erhoffen. 2.) Die Zusammenarbeit zwischen Hameg und Wittig war wohl nur von kurzer Dauer. Hauptsache hatte Hameg wohl im VHDL seine Finger drin, Obwohl der NIOS I Softcore im Jahre 2004 auf Wittig (einmalig) lizensiert wurde. 3.) Bzgl. der Bleche halte ich es für sinnvoll die Erfahrungen aus der ersten Serie ggf. in den zweiten Satz einfließen zu lassen. Gruß, brunowe
Aha, vielen Dank auch. Aber bisher nichts Neues. Aber was ist dann mit Konstanz, wo der eb.yer tek4you_eu ansässig ist? Ist das Michaels Privatadresse? Außerdem finde ich z.B. das UNI-T, das Reich.lt verkauft, recht ähnlich. Ob hier eine "Verwandtschaft" besteht? Hat Wittig in England eine Firma, oder ist das ein separater Hersteller? Wenn ja, wer ist es? Ob der uns eine Charge auch direkt liefern mag? Noch was: in der momentanen Charge sind nur 2-Kanaler drin. Haben die keine anderen mehr. Ist das eine eigene Platine oder ist die 4-Kanal-Platine nur halb bestückt? Und noch weiter gesponnen: Wenn wir schon so viele Unzulänglichkeiten gefunden haben, können wir nicht gleich ein neues Board entwerfen? Mit besseren aktuellen Chips?
Glaubst du ernsthaft, dass man so ein Gerät für 300 Euro verkaufen kann und dabei noch Gewinn macht? Allein schon vom Materialwert her. Selbermachen lohnt sich nur ab Mengen > 500 Stück.
eProfi schrieb: > Außerdem finde ich z.B. das UNI-T, das Reich.lt verkauft, recht ähnlich. > Ob hier eine "Verwandtschaft" besteht? Ich würde sagen: YAAC - Yet Another Agilent Clone. Seh da keine ausreichende Verwandschaft zu den Wittig-Geräten. Uni-T(rend) ist wohl sowas wie Owon - ein Klonhersteller aus Asien, vermutlich also einen Schlag größer als die Wittigs. > Noch was: in der momentanen Charge sind nur 2-Kanaler drin. > Haben die keine anderen mehr. > Ist das eine eigene Platine oder ist die 4-Kanal-Platine nur halb > bestückt? Eine Platine, halb bestückt bei den 20x2. Wenn du "nachrüsten" willst, musst du BGA hinbekommen, denn so kommt der 2. FPGA daher, der für die Kanäle 3&4 benötigt wird.
Aufrüsten auf 4 Kanäle dürfte zu viel Aufwand sein (wenn man es denn überhaupt hinkriegt). Ich hab mir einfach einen 4 Kanaler zusätzlich zugelegt - bei dem Preis mußte ich nicht lange überlegen. Hayo
Ich wollte mal fragen, wie weit die neu entwickelte Firmware die Bedienung verbessert? Ich habe auch ein 4-Kanal DSO bekommen, bin aber trotz Vorwarnungen sehr entäuscht. Ich halte das Scope mit der Original-Firmware für unbenutzbar, da alles mehr als träge reagiert: Sowohl die Anzeige als auch die Reaktion auf Betätigungen der Drehknöpfe. Besonders bei längeren Zeitbasen wie z.B. 500ms, tut sich auf dem Bildschirm sehr lange nichts, bis dann endlich ein Signal angezeigt wird. Bei anderen DSOs bin ich es gewohnt, dass bei längeren Zeitablenkungen die Linie von links nach rechts langsam auf den Bildschirm gezeichnet wird. Beim Wittig ist es so, dass erst das Bild erneuert wird, wenn der Speicher voll ist. Ist es mit vertretbarem Aufwand zu erwarten, dass aus dem Scope ein brauchbares wird oder ist dies vielleicht gar nicht möglich, weil die Hardware zu beschränkt ist und die FPGAs zu wenig Rechenleistung aufweisen? Im Moment habe ich vor, das Scope zurückzugeben.
Hallo Plumpa, > Ich halte das Scope mit der Original-Firmware für > unbenutzbar, da alles mehr als träge reagiert: > Sowohl die Anzeige als auch die Reaktion auf > Betätigungen der Drehknöpfe. Das haengt auch mit dem Wittig FPGA Design zusammen und ist in Hayos Firmware zwar verbessert aber nicht optimal. Dass das DSO durchaus in der Lage waere sehr schnelle Reaktionen auf die Drehencoder und schnellere Darstellung der Signalfolgen zu bieten, zeigt Slogs Design und Testfirmware, von deren Ausgabe, ich glaube Bruno war's, ein Video existiert. Sollte sich irgendwo in diesem Thread finden, ich hab's gerade auf die Schnelle nicht parat. > Besonders bei längeren Zeitbasen wie z.B. 500ms, tut > sich auf dem Bildschirm sehr lange nichts, bis dann > endlich ein Signal angezeigt wird. > Bei anderen DSOs bin ich es gewohnt, dass bei längeren Zeitablenkungen > die Linie von links nach rechts langsam auf den Bildschirm gezeichnet > wird. Beim Wittig ist es so, dass erst das Bild erneuert wird, wenn der > Speicher voll ist. Ja, das hat mich auch tierisch gestoert. Ist in der Firmware von Hayo aber behoben. FFT gibt's seit neuestem auch. Ich wuerde Dir einfach mal folgendes Empfehlen: Lad' Dir Hayos aktuellste Firmware, zieh wie in der (beigefuegten) Dokumentation beschrieben ein Komplettdump (sicherheitshalber) und lade danach die TomCat.ram zum Testen ins RAM. Nach einem Reboot hast Du wieder die Original-Firmware von Wittig. Ist also sowas wie die "LiveCD" Version bei Linux-Distributionen. Das Geraet finde ich preislich (habe ~320 Euro fuer mein W2024A bezahlt vor einem halben Jahr) trotz der ziemlich unbenutzbaren Original Firmware sehr interessant. Ich bin aber auch kein Anwender der sein Geld unter Zuhilfenahme von Scopes verdienen wuerde, sondern Hobbynutzer der auch selbst Hand am Firmwarecode anlegen kann und moechte und zudem nicht mehr als ein paar Hundert Euro fuer ein Scope ausgeben kann. Wenn es Deine Zeit wert ist, mit den Unzulaenglichkeiten zu leben und/oder auf verbesserte Firmware und FPGA Design zu warten und Du nicht mehr fuer ein besseres Scope ausgeben willst, wuerde ich es behalten an Deiner Stelle. Niklas
Angehängte Dateien:
-
screenshot2b-lines.png
5,6 KB
Heute mal von mir ein kleiner Bericht über die Suche nach der Ursache für die chaotischen Schwingungen ab bestimmten Frequenzen/Amplituden. Bruno hat heute mal mit dem DDS, das er gerade baut, ein paar Screenshots gezogen, die wir versuchen auszuwerten. Im Anhang seht ihr einen Shot, in dem ich aus der Punktdarstellung mal wieder teilweise eine Vektordarstellung gemacht habe. Rote Punkte sind die plausiblen Samples, grüne Punkte die unplausiblen (am besten bei 200% betrachten) Eine gewisse Amplitudenabhängigkeit beobachten wir ja schon länger. Hier sieht es auch mal wieder so aus, als ob die Samples oberhalb von einer magischen Grenze einfach nicht mehr stimmen. Diese Grenze wandert außerdem mit steigender Frequenz weiter richtung x-Achse. Das Problem tritt übrigens auch an den Tiefpunkten auf, was aber auf dem Bild hier gerade einmal nicht vorgekommen ist. Wir haben schon die wildesten Vermutungen angestellt. Timing-Probleme beim Auslesen der ADC (ab gewissen Amplituden/Frequenzen ist das Sampling am ADC noch nicht abgeschlossen, wenn der FPGA die Werte latched), oder dass parasitäre kapazitäten im/am ADC ab einer bestimmten Amplitude so viel Energie speichern, dass diese nicht mehr zwischen zwei Samples abgeführt werden kann, oder ... Was haltet ihr von der Geschichte? Spekuliert ruhig ebenso wild herum wie wir, so funktioniert Brainstorming ;) Wenn ich jetzt nur mal mit dem FPGA-Redesign etwas weiter käme, damit wir mal bestätigen können, dass das Problem dort wirklich nicht auftritt...
Hallo Plumpa, such doch mal bei Youtube mit dem Suchbegriff Welec. Meine Videos sind dort unter dem Namen aquapotablees veröffentlicht. Ansonsten kann ich mich nur der Meinung von Niklas anschließen. Mal von den echt störenden Oszillationen bei höheren Frequenzen und der tw. doch recht hohen Rauschpegel abgesehen, ist das Oszi inzwischen doch schon recht brauchbar. Vielleicht kommt uns ja doch noch mal ein Gedankenblitz diesbezüglich. Gruß, brunowe
Hallo Daniel, zunächst alle Achtung und Dank an allen, die Zeit in diesem Projekt investieren! Als frisch gebackener Besitzer eines W2024 möchte ich mich an dem Brainstorming auch anschließen. (Mein berufliches Spezialgebiet ist Analog-Hardware, auf diesem Gebiet kann ich hoffentlich etwas beitragen) - zunächst die Annahme, die abgebildete Kurve ist bei der Messung eines Sinus-Signals mit ca. 66MHz Frequenz entstanden, ist das richtig? Ein Grund für Falschauslesen könnte das Clock-Timing sein. Bei 1GHz (wie abgebildet) ist es eindeutig kritisch da die ADCs mit der maximal spezifizierten Geschwindigkeit getrieben werden, aber wie ist es bei halber Clock Frequenz (500MHz) - kommen da auch Falschwerte in der selben Weise vor? Ich denke, eindeutige Erkenntnisse diesbezüglich wären ein wichtiges Ausschlußkriterium. - Auffällig ist, daß meistens Gruppen von 3 falsche Samples auftreten, so als ob einer der ADCs richtig misst, die anderen aber nicht... Wenn ich aber nachzähle, ist der "richtige" beim nächsten mall wieder ein anderer... Wenn das auch in anderen Mess-sequenzen so aussieht, so folgt die Frage, ob das Timing der Clocks stabil ist. Wenn es zeitlich (schnell!) schwankt, könnte es zu Timing-Probleme führen. Eventuelle Schwankungen könnte man dann an dem Spektrum des Clock-Signals erkennen, dazu bräuchte man einen Spektrum-Analyser. Bei diesem Spektrum (z.B. 500MHz center frequency, 100MHz sweep) is die anteilmässige Leistung der clock (500MHz) zu der s.g. Referenz-leakage (peaks bei 500+/-25MHz?) ein Maß für die Präzision des Timings. Hat jemand eine ähnliche Messung schon gemacht? - Der Abstand der falschen Werte von dem "soll" ist viel zu groß, um mit einem Spannungsprung auf der analogen Seite richtig erklärt werden zu können. Am wahrscheinlichsten kommen mir deswegen Timing-Probleme beim Auslesen der ADCs vor, wobei ich auf das falsch-Auslesen einzelner Bits tippen würde. Wenn man die binären Werte der falschen Samples unter der Annahme betrachtet, daß (meistens) ein einzelnes Bit falsch ist, ließe sich dann eine fehlerfreie Kurve rekonstruiren? Eine weitere Möglichkeit wäre wenn meistens die Bits falsch sind, die ihren Zustand vor dem nächsten Auslesen ändern müssen. Kann man die (binärene) Messdaten auf diese Annahme hin überprüfen? Die falschen (rohen) binären Werte könnten sehr aufschlussreich sein. Gruß Walter PS: Das erwähnte DDS-Projekt interessiert mich - ist es denn irgentwo vorgestellt bzw. kann ich mehr Info darüber bekommen?
Hallo Daniel, Von allem was ich bisher verstanden habe, wissen wir nicht was das FPGA mit den Samples anstellt, die Fehlerpunkte koennten zum Beispiel durch einen ueberlauf in einem FIR oder IIR Filter entstehen. Um das auszuschiessen waehre es interessant wenn eines der beiden neuen FPGA Designs so weit vorgeschritten ist um die Messung darauf zu wiederholen! Martin
Wenn die Wittigs sich mal bequemen würden, mir mein W2024A zuzusenden, dann könnte ich die Kiste mal in die Hochschule tragen und das Spektrum des Taktes an den ADCs aufnehmen. Der Spectrum Analyzer dort ist ein älterer Rohde & Schwarz mit dem das gut möglich sein sollte. Könnte der Wurm vielleicht im VHDL Design drin sein? Zum Beispiel unsauberes synchrones Schaltungsdesign? Es gibt doch auch dieses Testdesign von Slog, treten diese komischen Samplefehler dort ebenfalls auf? Interessant wäre vielleicht auch, wie der Clock auf der Platine geroutet wurde. Im Firmware Thread hat jemand einen Freund mit einem richtig dicken Agilent Scope mit 4GSa/s, würde es was helfen, wenn wir den mal beauftragen, Aufnahmen des Taktes an allen vier ADC Clock Inputs zu besorgen? Gruß, Michael
Oh da hatte jemand schon ähnliche Ideen bzgl des FPGA Designs, ich sollte vielleicht erstmal den Thread aktualisieren bevor ich antworte...
Hallo Walter, sehr interessant was du das vermutest. Ich halte es auch für sehr wahrscheinlich das der Fehler im VHDL der Wittigs steckt, weil: 1.) Oszillationen von analogen Stufen sehen anders aus. 2.) Eine Schwingung an den ADC konnte ich mit meinem zweiten Oszilloskop nicht nachweisen. 3.) Mit unserem (leider noch sehr experimentellen) eigenen VHDL Design konnte ich diese Schwingung (oder was auch immer) nicht "provozieren". Leider hab ich kein SA um das einmal näher zu untersuchen. Mir steht nur unsere eigenes VHDL Design, ein W2022A, ein DDS- Sig.gen und ein zweites, analoges Oszi zur Verfügung. Evtl. kann da mal jemand mit besserem Equipment aushelfen? Ich hab ein paar Videos zu diesem Thema in Youtube veröffentlicht, dort lässt sich die stärker werdende Oszillation mit steigendem Pegel gut beobachten und weitere Einzelheiten erfahren. S.h. auch meine Post von oben: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Walter, wenn du dich mal hier einloggst kann ich dir einmal meine Kontaktdaten bzgl. DDS-Projekt schicken. Oder du nimmst über Skype mit mir Kontakt auf:(brunowe1)- dort findet der eigentl. Austausch bzgl. der VHDL- Entwicklung statt. Gruß, brunowe
Walter schrieb: > Ein Grund für Falschauslesen könnte das Clock-Timing sein. Bei 1GHz (wie > abgebildet) ist es eindeutig kritisch da die ADCs mit der maximal > spezifizierten Geschwindigkeit getrieben werden, aber wie ist es bei > halber Clock Frequenz (500MHz) - kommen da auch Falschwerte in der > selben Weise vor? Ich denke, eindeutige Erkenntnisse diesbezüglich wären > ein wichtiges Ausschlußkriterium. Nicht vergessen: In der Kiste stecken pro Kanal 4 250MSa/s ADC, die interleaved betrieben werden. > - Der Abstand der falschen Werte von dem "soll" ist viel zu groß, um mit > einem Spannungsprung auf der analogen Seite richtig erklärt werden zu > können. Am wahrscheinlichsten kommen mir deswegen Timing-Probleme > beim Auslesen der ADCs vor, wobei ich auf das falsch-Auslesen einzelner > Bits tippen würde. Wenn man die binären Werte der falschen Samples unter > der Annahme betrachtet, daß (meistens) ein einzelnes Bit falsch ist, > ließe sich dann eine fehlerfreie Kurve rekonstruiren? Das ist auch eher mein Gefühl. Eine Auswertung bzgl. 1-bit-Fehler steht noch aus, aber die Idee hatte ich auch schon, als ich gestern beim "Malen-nach-Zahlen" über die Ursachen sinniert habe... > Eine weitere Möglichkeit wäre wenn meistens die Bits falsch sind, die > ihren Zustand vor dem nächsten Auslesen ändern müssen. Kann man die > (binärene) Messdaten auf diese Annahme hin überprüfen? Die falschen > (rohen) binären Werte könnten sehr aufschlussreich sein. Da werden wir mit Sicherheit mal eine Messreihe starten, mit gut erkennbaren Fehlern, Screenshots und Rohdaten. Mal schauen ob dazu erst noch an der FW gepfuscht werden muss oder ob das jetzt schon geht.
@Michael >Im Firmware Thread hat jemand einen Freund mit einem richtig dicken >Agilent Scope mit 4GSa/s, würde es was helfen, wenn wir den mal >beauftragen, Aufnahmen des Taktes an allen vier ADC Clock Inputs zu >besorgen? Das wird leider nix. Ich bin in Österreich und er in DE.
Hallo Allerseits, danke für die rege Diskussion! Ich habe mich die ganze Zeit gefragt, wie es zu einem Registerüberlauf kommen kann, wenn die aufgenommenen ADC-Daten außer Skalierung/Vektorisierung keine (Amplituden-) Bearbeitung erfordern? Und wie dieser Überlauf von der Frequenz und Amplitude des Eingangssignals abhängig sein kann? Dann habe ich eine weitere Diskripanz bemerkt, die eventuell die Frage beantwortet: Das angeschlossene SRAM hat die Breite 16bit (pro Kanal) und eine Zykluszeit von 8ns. Das bedeutet, bei höchster Geschwindigkeit fallen innerhalb eines RAM-Zyklus 8x8=64bit an, es können aber nur 16bit im SRAM gespeichert werden. Wenn die Daten nicht auf dem FPGA gespeichert werden (?), muß doch irgendwie eine schnelle Datenreduktion stattfinden, oder? Ein Beispiel wäre die Speicherung der Differenz zum letzten aufgenommenen Wert, die aufgrund der begrenzten Eingangsfrequenz kleiner als 256 Stufen sein muß. Das hilft aber kaum bei dem ehrgeizigen Vorhaben, 200MHz full scale messen zu wollen mit 1GHz sampling Frequenz (Tektronix wagt sich an den 200MHz Bandbreite erst bei den 2GHz Geräten, und die dürften es wissen!) – die maximal mögliche Differenz zwischen 2 aufeinanderfolgenden Samples wäre in unserem Fall 150,5LSB – da kann kein Bit gespart werden! Bruno, ich habe mich inzwischen angemeldet und freue mich auf mail von Dir. Gruß Walter
Hier [http://sourceforge.net/apps/trac/welecw2000a/wiki/Hardware] steht, dass die Daten nur bei langsamerem Sampling im SRAM landen, sonst im FPGA intern gespeichert werden.
Hallo zusammen, ich melde mich aus meinem Spanienurlaub zurück. Kalt habt ihr es hier. Mit teilweise über 40°C tagsüber im Schatten und weit über 30°C bei Nacht in der Umgebung von Andalusien kommt einem Deutschland wie in Winterstimmung vor, man friert regelrecht. Während meiner Abwesenheit haben sich doch noch einige Anfragen zu den Schirmblechen gefunden. Ich werde heute im Laufe des Tages mal prüfen, wieviele es denn nun genau sind. In "Überproduktion" wollt ich aus einem ganz einfachen Grund nicht gehen, denn irgendwer muss die Bleche ja auch bezahlen und das wäre in dem Fall dann ich. Anfragen aus Italien sind auch bei mir eingetroffen. Ich werde die entsprechenden Anfragen nach und nach beantworten, muss erst einmal wieder in soetwas wie Alltag hinein wachsen. Ich bitte da um ein wenig Verständnis. Die Frist läuft ja erst in zwei Tagen ab, es bleibt also noch Zeit sich zu entscheiden und sich bei mir zu melden. Ansonsten muss ich sagen, hat sich ja doch das ein oder andere getan. Ich hab das, sofern man ein offenes WLAN in Spanien finden konnte, teilweise verfolgt und mich etwas up to date gehalten. Schön auch zu sehen, dass weitere Köpfe zum Projekt dazu gestoßen sind. Ich stehe dann in nächster Zeit auch wieder ein wenig zum Testen bereit, wobei ich mich erst in die neuen Softwarepakete einfinden muss. Einen schönen Tag auch, Gruß, branadic
Angehängte Dateien:
-
Welec_01.jpg
310 KB
Hallo zusammen! Seit heute gehöre ich auch zu den Besitzern eines W2024A Hardware: 8C7.C9 Software: 1.4 Erster Eindruck: Brauchbar für meine Zwecke. Dem Skope lagen (entgegen der Ebay Beschreibung) 4 Probes der unteren Preisklasse bei. Nett. Was ich vermisst habe, sind eine CD und eine Bedienungsanleitung. Lediglich eine Kurzanleitung fiel als dem Karton. Dann habe ich das Skope mal zusammen mit meinem Philips PM3310 an einen NF-Generator gehängt und ein wenig verglichen. Das Philips ist ein halbdigitales Speicherscope mit 60MHz Bandbreite. Das Welec schlägt sich tapfer, kann aber dem Philips insbesondere beim Rauschen nicht das Wasser reichen. (siehe Bild) Dann habe ich versucht, mal ein TV-Signal zu messen. Große Enttäuschung! Ich habe es trotz intensiver Bemühungen nicht geschafft, das Welec auf das TV-Signal zu triggern. Das Signal läuft unkontrolliert durch, als wäre gar kein Trigger vorhanden. Im normalen Triggermodus kann ich zwar das H-Sync einigermassen einfangen, aber die TV-Modi sind völlig unbrauchbar. Das Philips hat da überhaupt keine Probleme und mittels Trigger-Delay bekomme ich da ein stehendes Bild von fast beliebigen Zeilen. Hat jemand von Euch schonmal mit dem Welec ein TV-Signal unter Verwendung der TV-Triggerung gemessen? In den Schaltplänen auf SF existiert ein LM1881 Sync Separator. Kann es sein, dass der nicht korrekt angesprochen wird? In der Bedienungsanleitung auf der Welec-Seite wird der TV Trigger auch nur am Rande erwähnt. (Warum wohl?) Werde mich jetzt mal daran machen, die Open Firmware reinzuladen. An dieder Stelle ein dickes Lob an alle, die dieses Projekt so weit voran getrieben haben! Hut ab!! Lothar
Ja ja, die feinen Unterschiede der deutschen Sprache...
>4 Probes der unteren Preisklasse
Müsste es nicht vielmehr "der untersten Preisklasse" heissen ?
Hallo Stefan! Nein, der Superlativ ist reserviert für eine "Probe", die mir vor einigen Jahren mal in die Hände fiel: Der Innenleiter war hochohmig und das aufsteckbare Häkchen bog sich durch seinen eigenen Federzug vorne gerade. Ontopic: Inzwischen habe ich die TomCat .82beta aufgespielt zuerst als RAM Version und nach kurzer Zeit geflasht. Genial! Adieu, Original Firmware! Auf den Fotos im Wiki sieht man, dass im Bereich "Trigger" noch zwei weitere LED-Tasten vorgesehen waren, aber nicht bestückt sind. Weiss jemand, was das sein sollte? Just curious ;) Habe noch einige Versuche zum TV-Triggering angestellt und immernoch keinen sauberen Trigger (bzw. überhaupt keinen) hinbekommen. Habe jetzt keine Idee mehr. Kann bitte mal jemand ein Fbas-Signal messen und die Beobachtung bestätigen? Oder hat nur mein Skope da eine Macke? Danke! Lothar
@ Lothar Merl >Auf den Fotos im Wiki sieht man, dass im Bereich "Trigger" noch >zwei weitere LED-Tasten vorgesehen waren, aber nicht bestückt sind. >Weiss jemand, was das sein sollte? Just curious ;) Beim Agilent DSO 54642A heißen diese ""Pattern" und "More" :-) Gruß Jürgen
Hallo, >Habe noch einige Versuche zum TV-Triggering angestellt und immernoch >keinen sauberen Trigger (bzw. überhaupt keinen) hinbekommen. >Habe jetzt keine Idee mehr. ich würde einfach mal behaupten, dass das noch keiner von uns gebraucht hat und der Murks an dieser Stelle noch nicht aufgefallen ist. Nachdem noch nicht einmal Auto und Normal von Haus aus richtig funktioniert haben, denke ich, dass das eine Nummer zu groß für den Entwickler war. Ich glaube, du hast soeben, dein Fachgebiet gefunden, wo du etwas zur Verbesserung beitragen kannst ;-) Ich werde mal einen kurzen Blick drauf werfen, ob etwas ins Auge sticht. Aber viel kann ich vorerst nicht versprechen. Gruß, Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.