Announcement: there is an English version of this forum on Hallo werte W20xxA Besitzer und Interessierte! Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten Thread Beitrag "Wittig(welec) Oszilloskop firmware problem" eröffnet. Hier sollen Hardwarefragen erörtert werden wie z.B. Bandbreitenprobleme, Schwingneigungungen der Eingangsverstärker etc. Für die Open Source Firmwareentwicklung gibt es einen eigenen Thread: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware" >Wittig(welec) DSO W20xxA Open Source Firmware< Gruß Hayo
So hier noch eine kleine Wortliste damirt der Thread auch von Google gefunden wird: DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A W2024A Gruß Hayo
Hallo Bruno W., ich habe die Fotos nochmal studiert. scheint mir, dass doch die Kerkos am OPA fehlen, ich sehe nur noch Elkos. Da könnte man ev. je einen 1206 mit 10 oder 100 nF direkt auf die Tantals löten. Bevor ich Gewalt anwende: Wie kriegt man denn die Knöpfe runter? Haben die Spannzangen oder sitzen die nur so fest? Gruß, Guido
Sorry wegen schlechtem deutsch, bin Spanier und beobachte Welec Entwicklung. Habe diesen LInk gefunden: http://apps.sourceforge.net/phpbb/welecw2000a/viewtopic.php?f=8&t=10 das ist gute Nachricht für alles Welec Oscilloscope Besitzer! Hoffe mit euch auf gute Fortschritte bei Entwicklung- Grusse Broma
Kurt Bohnen wrote: > Nur kräftig ziehen. ;-) Dabei habe ich mir allerdings auch schon einen Drehencoder zerstört, der saß so fest, daß beim abziehen das Lager der Welle ausgerissen ist. Ich habe mir dann welche von Pollin besorgt (http://www.pollin.de/shop/detail.php?pg=NQ==&a=MDY2OTU3OTk=) und eingelötet, da hat man auch ein besseres Drehgefühl...
@Broma.es: Schau mal auf das Post-Datum, dann geht Dir vermutlich ein Licht auf :-D
Soeben hatte ich nochmal Kontakt mit PycLan (s.h. die letzten Posts im Vorgänger Thread Beitrag "Wittig(welec) Oszilloskop firmware problem") Er besitzt ein W2012- ohne A und hat nach dem Update seiner FW auf die Version 1.3 bzw. 1.4 den Fehler das seine Encoder wohl nur noch zwei Stellungen kennen- min. und max. Nachdem er seine ursprüngl. FW. 1.10.03 wieder aufgespielt hat, ist dieser Fehler allerdings geblieben. Im IXBT Forum berichtet ein Russe von dem gleichen Problem. Deshalb zum Ersten nochmals der Hinweis an Alle- zieht erstmal ein Flashdump bevor ihr eine neue FW aufspielt. Es sieht fast so aus als ob Pyclan und der andere Russe sich mit dem Update einen geschützten Flash- Bereich überschrieben haben. Zweitens- hat den nicht irgendjemand ein Wittig der alten ohne "A" Serie und stellt ein Flashdump zur Verfügung... Vielleicht bekommen wir damit die beiden Geräte wieder in Betrieb. Im Gegenzug hat uns Pyclan Fotos seines Oszis versprochen um endlich eventuelle HW Unterschiede aufklären zu können. Gruß brunowe
Bruno We wrote: > Deshalb zum Ersten nochmals der Hinweis an Alle- zieht erstmal ein > Flashdump bevor ihr eine neue FW aufspielt. Es sieht fast so aus als ob > Pyclan und der andere Russe sich mit dem Update einen geschützten Flash- > Bereich überschrieben haben. > Zweitens- hat den nicht irgendjemand ein Wittig der alten ohne "A" Serie > und stellt ein Flashdump zur Verfügung... Vielleicht bekommen wir damit > die beiden Geräte wieder in Betrieb. Im alten Thread gab es mehrere Anfragen von Manja wegen eines W20xx ohne A. Allerdings war hier das Problem, das sich kein Flashdump ziehen ließ weil der Germs-Monitor nicht zu starten war mit der üblichen Tastenkombination (Funktionstasten 1 + 2 gleichzeitig drücken). Daher habe ich da erstmal von einem Update abgeraten. Übrigens habe ich versucht meine aktuelle Beta auf SFN einzustellen, hab mich aber wohl zu blöde angestellt. Jedenfalls hab ich keine Möglichkeit gefunden eine Datei upzuloaden. Kannst Du mir da einen Tip geben? Gruß Hayo
Hallo Hayo, erstmal danke für deinen Tipp bei den alten W2000 erstmal keine neue FW aufzuspielen, auch wenn dieser für Ruslan (so heißt der- PycLan ist ein Übersetzungsfehler) und den anderen Russen wohl zu spät kommt... Dir fällt also momentan auch keine Möglichkeit ein, wie wir das wieder "hinbiegen" können? Ich habe ihn erstmal an Slog verwiesen, evtl weiß der Rat. Deine FW spielen wir in SF ein, kein Problem. Eigentlich solltest du vollen Zugang haben und somit der Upload auch funktionieren, wir checken das nochmal. Gruß, brunowe
Ich habe ein Scope mit der alten Aufschrift W2014 Vielleicht kann es jemand gebrauchen Hardware 8C7.0H Software 1.4
Hallo, ich habe ein Wittig W2024A bestellt, gekommen ist ein gerät mit der Bezeichnung W2024, in der Software wird aber W2024A angezeigt. Mich wundert das etwas, denn bei Ebay hat das Gerät auch die Aufschrift W2024A, nicht wie bei mir ohne A. Was ist nun wirklich in meinem Gerät drin? Kann es nicht sein das einfach W2024 Geräte als W2024A Geräte verkauft werden indem die Software W2024A anzeigt. Das muss ja nicht zwingend stimmen. Ne kleine Änderung im Quelltext und das Gerät wäre ein W2024A anstatt eines W2024. Gibt es eine Möglichkeit zu überprüfen welche Version ich nun wirklich habe? Wo genau liegen die Unterschiede bei den Versionen? Gruß, Christoph
Achso, beim Booten zeigt das gerät folgende Informationen: Model: W2024A Hardware Version: 8C7.0L Software version 1.4 und halt ne Serial Number Evtl hilft euch das etwas weiter, aber wie gesagt, es ist ja per Software änderbar, also kann man sich auf diese Infos vllt nicht wirklich verlassen.
Doch, man kann sich darauf verlassen. Die neueren Firmware Versionen wie 1.4 laufen nämlich nicht auf den alten Geräten. Wenn dein Oszi also funktioniert, ist es ein Modell der A-Serie. Das Welec da an der Firmware manipuliert glaube ich kaum. Würden die eh nicht hinkriegen...
Okay klingt logisch, aber was gibts für ne Erklärung, dass auf dem Gehäuse W2024 draufsteht und nicht W2024A? Sind die Aufkleber ausgegangen? Oder wird einfach das alte Gehäuse mir aufkleber verwendet, weil davon noch so viele da sind? Fest steht, es gibt/gab die Geräte auch mit der W2024A Beschriftung, das sieht man auf dem aktuellen Bild bei Ebay.
Keine Ahnung. Es steht dann auch Wittig drauf, nicht Welec? Vieleicht ist es ein Gerät der alten Serie, das aber mit einer neuen FPGA Konfiguration ausgeliefert wurde. Ob es da weitere Hardwareunterschiede gibt, wurd imho noch nicht endgültig geklärt.
Hallo Christoph, Ja, ich schließe mich den Aussagen von Kurt an. Nach jetzigen Erkenntnisstand läuft die Firmware > 1.10.03 nicht auf den alten Geräten. Du könntest auch einfach einmal den hinteren Gehäusedeckel abnehmen und schauen was auf der Platine steht. Eigentlich sind, soweit mir bekannt, derzeit alle (immer noch) mit Germany V1.03 2006 bezeichnet. Wahrscheinlich hat sich die PCB Bestückung seit der alten Serie nicht geändert, schätzungsweise wurde bei der neuen A-Serie nur das VHDL- Design erneuert. Mit der neuen HW Version 8C7.OL kannst du dir aber sicher sein wirklich ein "A" zu haben....wurde doch das umlabeln vergessen- Schande
Christoph Bechtel wrote: > Okay klingt logisch, aber was gibts für ne Erklärung, dass auf dem > Gehäuse W2024 draufsteht und nicht W2024A? Sind die Aufkleber > ausgegangen? Oder wird einfach das alte Gehäuse mir aufkleber verwendet, > weil davon noch so viele da sind? > Fest steht, es gibt/gab die Geräte auch mit der W2024A Beschriftung, das > sieht man auf dem aktuellen Bild bei Ebay. Nach aktuellem Erkenntnisstand läßt sich bei der alten Version der Germs-Monitor nicht starten (zumindest nicht wie bei der A-Version). Schalte also mal Dein Gerät an und drücke die beiden linken Funktionstasten unter dem Bildschirm. Als erstes sollte der Bildschirm weiß werden und dann schwarz. Dann ist der Germs-Monitor aktiv und Du hast eine A Version - Glückwunsch. Bei mir steht übrigens auch kein A auf dem Gehäuse - ist aber trotzdem eine A-Version. Morgen bekomme ich mein 2014A (hoffe ich). Dann sag ich mal bescheid ob da ein A draufsteht. Gruß Hayo
Okay, also bei Drücken der beiden linken Tasten beim Einschalten wird der bildschwirm erst weiss und bleibt dann schwarz. Mehr tut sich darauf dann nicht. Also kann ich wohl davon ausgehn, dass ich wirklich die A Version habe. Vielen Dank!
Hallo allem, Hier hat die Fotografien mit den Unterschieden PCB W2022A und W2012 (ohne А) ausgestellt. http://foto.ixbt.com/?id=album:19438
Hallo PycLan (oder eigentlich Ruslan) hat im russischen IXBT Forum einen Thread aufgemacht, in dem er seine Probleme mit dem W2012 (altes Modell) nach dem Update auf eine neuere FW beschreibt. Hier der Link: http://forum.ixbt.com/topic.cgi?id=48:8586 Ich werde das Wichtigste übersetzen und hier posten, dauert allerdings immer ein paar Tage. Evtl. hilft es ja auch anderen Besitzern des alten Modells. Bislang sind Ruslan beim Vergleich keine gravierenden HW- Unterschiede aufgefallen, es sollte also keinen Grund geben wieso nicht auch bald eine aktuelle FW (oder auch Hayo's FW) darauf laufen sollte. Derzeit bin ich mit Messungen am offenen Gerät beschäftigt um noch ungeklärte Fragen zur Funktion einzelner Baugruppen, zum Entstehen des große Rauschen und der Schwingneigung zu beantworten. Gruß, brunowe
Hier stand irgendwo, das eventuell die Blockkondesnsatoren an den Eingangs-OVs "vergessen" wurden (daher die Schwingneigung?) - ist das so (und hat die schon jemand nachgerüstet?). Viele Grüße, egberto
Hier ist der erste Teil des russischen IXBT- Thread von Ruslan (PycLan) Ich werde wie gesagt weiter berichten/ übersetzen wenn es was Neues gibt. @egberto: Meine Messergebnisse werde ich in wenigen Tagen veröffentlichen, es macht kaum Sinn schon vorher am Board rumzulöten. Erst sollten wir die Ursachen zweifelsfrei feststellen. Die Messungen sind sehr aufwendig, dauern also etwas. Erstmal musste ich mir die entsprechenden Verlängerungen für die Stromversorgung der Hauptplatine und der Frontplatte erstellen, um das Gerät auch in Einzelteilen in Betrieb nehmen zu können. Gruß, brunowe
Zur Bezeichnung meines W2024A taucht die Kombination Gerätelabel: Wittig Technologoies W2024 - 200 MHz 1 GSa/s Model: (lt.Utility About) W2024A Hardware Version: 1C9.0L Software Version: 1.4 Serial Number: 01093011C8 Main Board: V1.03 2006, 2DR34K W2014 (mehr unter http://www.alice-dsl.net/rmw/de/elec/w2024A.html) Das würde drauf hindeuten, dass der HW-Unterschied zwischen W2014 und W2024 nur in der Bestückung(Bauteilauswahl) liegt. Gruß Rainer
Hallo, wer sich schon mal meine ersten Messergebnisse ansehen möchte, ich hab sie unter: http://apps.sourceforge.net/trac/welecw2000a/wiki/Measurements_for_Reengineering veröffentlicht. Das Ganze ist noch lange nicht vollständig und wird laufend von mir ergänzt. Vieles konnte ich aber dennoch schon herausfinden. Unter o.a. Link findet sich auch der aktuelle "Analog_input" Schaltplan. Gruß, Brunowe
An den OPs scheinen wirklich keine KerKos zu sein!? Viele Grüße, egberto
Hallo allerseits, ich wollte kurz eine Anfrage bezüglich meines neuen W2014A loswerden. Und zwar habe ich beobachtet, dass nach einiger Laufzeit - also wenn die Kiste warm geworden ist - auf Kanal 4 heftige Spikes auftreten. Wenn das DSO kalt ist, also direkt nach dem Anschalten ist das nicht vorhanden. Habt Ihr sowas auch beobachtet? Gruß Hayo
@Hayo, kannst du das Spike-Problem ein wenig genauer beschreiben (Y-Ampl, Timebase, eingespeistes Signal, Trigger etc.)? Ich sehe auf keinem Kanal besondere Spikes, nur das übliche Grundrauschen (hab deine aktuelle FW drauf). Lediglich bei einer Timebase von 5µs/50ns/20ns/10ns sehe ich starke, periodische Spikes (ca. alle 3ns), allerdings vermute ich dahinter eher ein Software-Problem im Zusammenhang mit dem Zero-Offset, das wirst du sicher genauer wissen.
Hallo Hayo, die von dir genannten Spikes habe ich bei mir in diversen Einstellungen bei Kanal 3. Ich habe bisher immer vermutet, dass das mit deiner FW zusammen hängt und möglicherweise mit dem Erhalt deines W2014A behoben werden wird. Diese Spikes hatte ich mit der originales Software nicht. Also muss es mit der FW in irgendeinem Zusammenhang stehen. Beste Grüße, branadic
Angehängte Dateien:
-
Kanal_1_ohne_R31_und_R32.JPG
340 KB
Hallo, Ich bin immer noch fleißig am messen (sofern es meine Zeit erlaubt). Bald werde ich wieder neue Ergebnise in SF stellen. Vorerst nur so viel: Ich hab bei meinem W2022A die beiden Widerstände R31 und R32 (gem. Analog_inputs schematic) von Kanal 1 ausgelötet (beide 0 Ohm). Diese verbinden die letzte Analog- Stufe mit dem Eingang der ADC. Nachdem ich auf der Spannungsversorgung der ADC nur geringe Störungen feststellen konnte und auch die Analog- Stufen relativ "sauber" arbeiten, bin ich der Frage nachgegangen woher denn dieser hohe Rauschpegel stammt. Auf dem Foto sieht man deutlich, das auch ohne Eingangssignal (Pins des ADC offen) ein deutliches Rauschen auf dem TFT zu sehen ist. Dieses Rauschen ist allerdings recht regelmäßig und von einer deutlichen Schwingung überlagert. Um zu klären ob da evtl. ein SW Fehler mit verantwortlich ist, werde ich demnächst einmal mit Hayo's FW testen. (Die bisherigen Messung finden alle mit der Original FW. 1.3 statt) Gruß, brunowe
Angehängte Dateien:
-
kerkos3.JPG
190 KB
Hallo Bruno, ich habe mal mit Kondensatoren experimentiert, bisher aber ohne durchschlagenden Erfolg. Einmal habe ich den OPAs Kerkos gegönnt (rot markiert), was mit 100 nF in 1206 problemlos ging. Hat aber keine sichtbare Verbesserung gebracht. Dann habe ich an den Eingang des 1. Videoverstärkers Kondensatoren angelötet (gelb markiert), die zusammen mit den 51-Ohm-Widerständen einen Tiefpass bilden. Um einen 20-MHz-Rechteck vernünftig darzustellen musste ich diese aber auf 69 pF erhöhen, wodurch die Bandbreite auf 50 MHz begrenzt wird. Auch unbefriedigend. Ob es eine Störeinstrahlung gibt? Ich kann ein schwaches Signal mit ca. 170 MHz messen. Ev. müsste man dann besser schirmen. Wenn ich es hinbekomme, werde ich als nächstes mal einen 170-MHz-Saugkreis an einen der Videoverstärker anlöten. Gruß, Guido
Hallo Guido, trotz konkretem Ergebniss eine sehr schöne Sache, so kann man diverse Dinge ausschließen und andere (mit eventuell weniger Geschick) werden davon abgehalten ihre Kisten zu zerlöten. Hast du eine Idee, wo die 170 Mhz herkommen könnten? Viele Grüße, egberto
Hallo Hayo, das es nicht an den Kerkos liegt, hatte ich mir auf Grundlage meiner Messungen schon fast gedacht ;-(. Mein erster Schritt wird sein, die Störungen ohne vorherige Analog- Stufen zu beseitigen. D.h. also diese seltsame Störungen die auf meinem oberen Bild zu sehen sind. Gibt es eine Möglichkeit die ADC Kalibrierung per SW durchzuführen??? So wie ich es sehe, wird die o.a. Schwingung durch unterschiedl. Nullkalibrierung der einzelnen ADC hervorgerufen. Solange die einzelnen ADC nicht optimal kalibriert sind, lassen sich die restl. Störungen nur sehr schwer zuordnen. Gruß, brunowe
Nachtrag: Meine "Störung" hat übrigens exakt eine Frequenz von 250MHz. Dies ist die Frequenz mit der die ADC ausgelesen werden. Eine Frequenz von 170MHz gibt es übrigens auf dem Board nicht! In dieser Größenordnung gibt es auf dem Board nur 125MHz und 250 MHz.
Angehängte Dateien:
Hallo, also bei mir kommt der Hauptanteil des Rauschen eindeutig von der falschen ADC Kalibrierung. Das Foto ist mit dem Slog V1_3 Design und offenen ADC Eingängen entstanden- hab also im vgl. zur Messung vom 21.04 nur auf Slog's FPGA Design gewechselt, sonst nichts verändert. Wie man auf dem heutigen Foto deutlich sieht, ist der "gelbe" ADC -Wert zu hoch, der rote zu tief. Wenn man diese beiden ADC ordentlich kalibriert, dann bleibt nicht mehr viel vom Rauschen übrig- es sind nur ganz vereinzelt einige Ausreißer zu erkennen. Störungen durch unsaubere Versorgungsspannung der ADC kann man somit ausschließen, SW Fehler allerdings nicht- z.B. was die von Hayo angesprochenen Spikes betrifft. Erst muss ich diese ADC irgendwie ordentlich kalibrieren, vorher ist eine tiefer gehende Analyse wenig sinnvoll... Gruß, brunowe
Hallo allerseits, sorry für die lange Sendepause, aber ich verfolge die beiden Threads durchaus sehr aufmerksam, nur bin ich zur Zeit sehr intensiv an der neuen FW-Version zugange. Unter anderem habe ich wegen der Anfrage von Bruno eine manuelle Abgleichfunktion eingebaut (Mit der Möglichkeit den aktuellen Abgleich im Protected-Bereich zu speichern). Da die Umbauten sehr umfangreich sind bin ich noch nicht ganz fertig. Braucht Ihr die neuen Funktionen sofort? Dann stelle ich die FW auch schon früher hier ein. Fotos von der Spike-Problematik auf Kanal 4 liefere ich noch nach. Gruß Hayo
Super Hayo! sobald das mit dem Abgleich funktioniert wäre ich dir dafür dankbar... Du siehst ja was ich auf Ch1 für eine Abweichung drauf habe... und auch auf CH2 ist meiner Meinung nach ein gewisser Trend der Fehl-Kalibrierung ersichtlich.
Angehängte Dateien:
-
Spikes_CH4.jpg
1,2 MB
So hier die angekündigten Bilder zu der Spikesproblematik, bei unterschiedlichen Zeitbasen. Parameter: - FW1.4 original WELEC (tritt aber auch bei meiner FW auf, nur dann wegen der besseren Auflösung etwas heftiger) - alle Eingänge offen - das Gerät läuft schon mindestens eine halbe Stunde und ist warm - erst Default Setup gedrückt und dann die weiteren Parameter eingestellt - alle weiteren Parameter kann man auf den Bildern sehen Offensichtlich im Zusammenhang stehen: - thermischer Zustand - die Nulllage!! - Eingangssignal Der Effeckt tritt esrt nach einiger Betriebszeit auf, insbesondere nach dem Laden einer FW, da das Gerät dann odentlich warm ist. Wenn man den Nullpunkt verschiebt verschwinden die Spikes mal ganz und mal sind sie wieder voll da. Das sieht mir wieder mal nach dem Eingangsverstärker bzw. dem Zusammenspiel zwischen OPV und DAC aus. Vielleich kann ja einer von Euch die Situation nachstellen. Gruß Hayo
Hallo Hayo, bei mir ist es gerade andersrum. Ich habe die Spikes auf Kanal 2 (nicht auf Kanal 1) sofort nach dem Einschalten. Nach ein paar Minuten verschwinden sie. Ebenfalls nur auf Kanal 2 sehe ich bei offenem Eingang auch eine Schwingung ähnlich Brunos Aufnahme, nur mit ca. 500 MHz. Bin mal gespannt auf die manuelle Kalibrierung der Wandler. Gruß, Guido
So, bei mir ist soeben das W2024 eingetroffen. Wenn ich beim Testen irgendwie helfen kann, bitte ich um kurze Nachricht. /Hannes
Johannes Studt wrote: > So, > > bei mir ist soeben das W2024 eingetroffen. Wenn ich beim Testen > irgendwie helfen kann, bitte ich um kurze Nachricht. Siehe mein Beitrag von eben! Teste mal ob bei längerem Betrieb ähnliche Störungen auftreten. Ich vermute nämlich, dass die Vierkanalgeräte da thermisch empfindlicher reagieren als die Zweikanaler. Gruß Hayo
Hi, ich habe gestern auch mein W2024 bekommen. Seit einigen Tagen 'lausche' ich diesem (und anderen) Forum. Gibt es eine gesammelte Stelle, an der mehr Infos über die Projekte liegen? Ich bin mir nicht sicher, ob ich Slog's FPGA Design installieren soll (laufen die anderen Funktionen dann noch)? Das Gleiche gilt für die Firmware von Hayo. Ich war doch ein wenig enttäuscht von dem DSO, hatte ich doch vorher nur mit analogen Geräten zu tun. Irgendwie hatte ich auch das Gefühl, dass die Tasten sehr schwammig sind. Und dann die Kämme auf den horizontalen Signalbereichen. Ich gebe aber auch gerne zu, dass ich mich noch nicht viel mit dem Teil auseinandergesetzt habe und benötige es eigentlich nur für den Controllerbereich. Im Analogbereich scheint es mir aufgrund des Rauschens zeimlich unbrauchbar zu sein... :-( Michel
Hallo, diese Spikes sind mir auch schon einmal aufgefallen, allerdings hab ich diese selbst "provoziert". Meiner Meinung nach hängt das Auftreten dieser Spikes mit den Trim- Kondensatoren C2 bzw. C5 zusammen (je nachdem in welchem V/Div- Messbereich dieses Problem auftritt). Bei mir sind diese Spikes nach einer "gröberen" Fehlanpassung aufgetreten. Ihr solltet einmal versuchen, ob die Spikes verschwinden, wenn ihr den Messbereich z.B. in den 10mV Bereich schaltet (oder entsprechend in den 20mV bzw. 50mV Bereich). Leider sind solche Phänomene messtechnisch schwer zu greifen... aber auch das werden wir irgendwie in den Griff bekommen. Gruß, brunowe
Ich habe die Spikes auf Kanal 3 + 4 "hinbekommen" (2024A), allerdings stehen die dann konstant da (einer pro Kanal) während das Rauschen weiter läuft - deutet wohl auf einen Softwarefehler (habe die welec 1.4)hin. Viele Grüße, egberto
egberto wrote: > Ich habe die Spikes auf Kanal 3 + 4 "hinbekommen" (2024A), allerdings > stehen die dann konstant da (einer pro Kanal) während das Rauschen > weiter läuft - deutet wohl auf einen Softwarefehler (habe die welec > 1.4)hin. Ja, die hatte ich auch, aber die meinte ich eigentlich nicht, da diese wie Du ja auch schon vermutest wahrscheinlich reine FW-Sache sind. Bei meiner FW sind sie mir jedenfalls noch nicht aufgefallen. Gruß Hayo
Angehängte Dateien:
-
1.jpg
200 KB
Hallo, bei meinem W2012 SW 1.4 treten diese Störungen auf Kanal 2 nach dem Einschalten auf und verschwinden nach ca. 3min. Gruß Egon125
Moin, moin da ich auch seit kurzem der Besitzer eines W2024A bin, wollte ich anmerken das mein Gerät auch nach längerer Zeit frei von Spikes ist. Ich habe nur das normale Grundrauschen. Bis denne ...
Ok, andere als die oben beschriebenen "Software-Spikes" habe ich auch nachlängerer Zeit nicht finden können. Viele Grüße, egberto
Angehängte Dateien:
-
IMG_4854.JPG
200 KB
Zum Thema Rauschen ist mir gerade noch aufgefallen, dass es sich auch mit AC-Kopplung deutlich oberhalb der Nulllinie abspielt (Channel 2, erstes Bild), und wenn ich nur "Invert" drücke, verstärkt es sich massiv (zweites Bild). Finde ich irgendwie seltsam, das Verhalten. ... Hm, sehe beim Rumspielen gerade, dass dieses "Invert" überhaupt buggy ist. Je nachdem, wo sich die Nulllinie (hurra, RSR) auf dem Bildschirm befindet, springt das invertierte Signal lustig in der Gegend herum. Je weiter die Nulllinie von der Bildschirmmittellinie entfernt ist, desto weiter springt das invertierte Signal. Unkonventionell... :D /Hannes
Hallo Hannes, den offset den du auch bei AC Kopplung feststellst, habe ich inzwischen schon ausführlich untersucht s.h. dort: http://apps.sourceforge.net/trac/welecw2000a/wiki/Measurements_for_Reengineering (Teil 2 meiner Messergebnisse kommt wahrscheinlich morgen noch- da untersuche ich das Rauschen ausführlicher). Das Invert- Verhalten ist aber wohl ein reiner SW Bug. Die o.a. einzelnen! Spikes könnten evtl. auch durch die HW entstehen... mich wundert allerdings, das sie bei Hannes auf Kanal 2, 3 und 4 gleichzeitig entstehen (Spannungsspitze?) warum dann aber nicht auf Kanal 1? ja, ja... die Arbeit geht uns nicht so schnell aus. Gruß, brunowe
Hab gerade durch Zufall die Spikes gefunden, die Hayo meint. Wenn man "Calibrate Zero Lines" durchführt, erscheinen zumindestens bei mir die bewussten Spikes auf Ch4. Nach Aus- und Wiedereinschalten sind sie wieder verschwunden. /Hannes
Johannes Studt wrote: > Hm, sehe beim Rumspielen gerade, dass dieses "Invert" überhaupt buggy > ist. Je nachdem, wo sich die Nulllinie (hurra, RSR) auf dem Bildschirm > befindet, springt das invertierte Signal lustig in der Gegend herum. Je > weiter die Nulllinie von der Bildschirmmittellinie entfernt ist, desto > weiter springt das invertierte Signal. Unkonventionell... :D Ja das Problem ist mir auch schon aufgefallen - in meiner neuen FW-Version ist er behoben! Das verstärkte Rauschen des invertierten Signals konnte ich noch nicht abstellen, ich vermute, dass im Invertierungs-Modus entweder ohne ADC-Korrektur gelesen wird oder evtl. die Korrektur ebenfalls invertiert wird, was natürlich Unsinn wäre. Die neue FW-Version stelle ich heute Abend im FW-Thread ein. Gruß Hayo
Johannes Studt wrote: > Zum Thema Rauschen ist mir gerade noch aufgefallen, dass es sich auch > mit AC-Kopplung deutlich oberhalb der Nulllinie abspielt (Channel 2, In der neuen Firmware gibt es die Möglichkeit den DAC-Offset zu verändern der für dieses Verhalten verantwortlich ist. In der nächsten Version werde ich versuchen diesen Offset beim Zeroabgleich mit zu kalibrieren. Leider ging das bei der jetzigen FW nicht mehr da ich diese Version für Brunos Tests etwas vorgezogen veröffentliche. Gruß Hayo
Hi, Nach einer Stunde Warmlaufen ähnelt die Ansicht bei meinem W2024A der von Johannes (kein Kanal mit größerer Abweichung), ab und an ein paar einzelne Spikes... By the way: hat jemand Interesse an einer Tasche für den Transport des DSOs? Ich habe mal Drachen gebaut und daher noch einen Industrienäher und etwas Material im Keller. Ich wollte mir eine Tasche nähen. Für Designwünsche bin ich offen (Taschen & Fächer). Da ich nicht genau weiss, wieviel (Tuch)Reste ich noch habe, kann ich noch keine größere Zahl versprechen. Kostenpunkt: Porto (solange ich kein Material nachkaufen muss). Michel
Hallo, wie versprochen habe ich heute schon mal ein paar Messergebnisse veröffentlicht. http://apps.sourceforge.net/trac/welecw2000a/wiki/Measurements_for_Reengineering Das Messprotokoll widmet sich dieses mal folgenden Themen: Offset voltage (part 2) Noise (from ADC's) Noise (analog amplifier chain) Es ist zwar noch nicht alles aus dokumentiert, aber da ich dieses mal viele Fotos eingefügt habe, sind die Messungen eh größtenteils selbsterklärend. Demnächst werde ich versuchen die in dieser Messreihe festgestellten Interferenzen und das Rauschen zu minimieren- nachdem ich meinen ADC offset in den Griff bekommen habe. Gruß, brunowe
Hallo Michael, eine Tasche wäre natürlich eine feine Sache. Damit möchte ich mich als erster hier öffentlich für eine solche Tasche aussprechen. Gruß, branadic (der die Signalgeneratorgeschichte noch nicht vergessen hat, jedoch aus beruflichen Gründen momentan ziemlich eingespannt ist)
Hallo Bruno We, sehr schönes Messprotokoll, jetzt verstehe ich Einiges besser, Ich werde das gelegentlich noch mal genauer anschauen. Achso, danke für den Link. In SF finde ich mich nicht gut zurecht, da sowas ohne Link zu finden? Gruß, Guido
Moin, moin also eine Tasche für das DSO wäre eine super Sache, habe schon versucht was zu finden aber nix vernünftiges gefunden. Bis denne ...
Michael Werner wrote: > By the way: > hat jemand Interesse an einer Tasche für den Transport des DSOs? Ich > habe mal Drachen gebaut und daher noch einen Industrienäher und etwas > Material im Keller. Ich wollte mir eine Tasche nähen. Für Designwünsche > bin ich offen (Taschen & Fächer). > Da ich nicht genau weiss, wieviel (Tuch)Reste ich noch habe, kann ich > noch keine größere Zahl versprechen. Kostenpunkt: Porto (solange ich > kein Material nachkaufen muss). Hi Michael, ich melde mich hiermit als offizieller dritter Interessent an einer solchen Tasche. Das hört sich wirklich gut an. Gruß Hayo
@Guido, Ja, SF ist etwas unübersichtlich... aber eben DAS Forum für Open-Source Entwicklungen, trotz aller Nachteile. Zum Prinzipiellen Aufbau: Startseite des Projekts: http://sourceforge.net/projects/welecw2000a/ Dann gibts unter dem Reiter dieser Seite die Einträge: phpBB: (Das Diskussionsforum) http://apps.sourceforge.net/phpbb/welecw2000a/ Trac: (hier findet sich das Wiki mit vielen techn. Informationen) http://apps.sourceforge.net/trac/welecw2000a/ SVN: (hier findet sich der Source Code) (unterteilt in pc: USB- Driver, Welec- Updater, Hayo's FW, usw. und FPGA: Slog's Design- unter Nios, Original Sourcen, FPGA- Design mit t51- obsolete wg. diverser Bugs im Softcore; leon3- Design; und ein FPGA Design mit ZPU,) http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/ Das ist soweit das Wichtigste in SF... aber noch nicht alles- und wir haben SF schon massiv entschlackt! Gruß, brunowe P.S.: Danke für dein Lob zum Messprotokoll, macht Mut zum weitermachen. Denn wenn's keinem nützt, kann ich mir die Schreibarbeit auch sparen. Gruß brunowe
Hallo Guido, Jetzt wo ich deine Erklärung über die Fkt des OPA gelesen habe, ist alles ganz klar! (Und ich frag mich wieso ich das nicht gleich selbst gesehen habe) Hast du mal die Versorgungsspg an dem OPA656 bzw. am OP1177 gemessen? Du hast bestimmt gesehen was ich da für eine Störung drauf habe (Messprotokoll 2)- also zumindest das sollte mit den Kerkos in den Griff zu bekommen sein. Tja, viel weiter bin ich auf meiner Suche nach dem analogen Rauschverursacher auch noch nicht gekommen... Tatsache ist auf jeden Fall, wenn man sich schon zu Beginn der analogen Verarbeitung Rauschen einfängt, bekommt man das nicht mehr weg, also am Anfang der Kette maximal rauscharm bleiben. Gruß brunowe
Hallo Bruno, schön, dass dir alles klar ist. Nach Hayos letzter Erklärung kapiere ich jetzt nämlich garnichts mehr. :-( @ Hayo: Warum musst du in verschiedenen Messbereichen unterschiedlich skalieren. Die Wandler liefern immer Werte zwischen 0 und 255, die auf die Pixelzahl hochskaliert werden müssen. Alles Weitere sollte per Hardware erfolgen. Da muss ich wirklich mal nachmessen was da passiert. @ Bruno: Das Rauschen stellt sich ja immer mehr als andere Störungen dar. Einmal die ADC-Kalibrierung, haben wir dank Hayo ja im Griff. Dann haben wir hochfrequente (periodische) Störungen, die in den verschiedenen Messbereichen unterschiedlich stark wirken. Ich glaube am Ende gibt es das Rauschen selbst garnicht (wäre auch für slog eine schöne Überraschung). Gruß, Guido
Hallo Guido, genau diese Messungen hab ich mir für heute Abend auch vorgenommen. Dann können wir ja die Ergebnisse vergleichen- perfekt. Mir war bewusst das der 8 bit Wertebereich der ADC auf die noch verbleibenden 400Px? in y-Richtung gestreckt werden, das es aber unterschiedl. Faktoren dafür gibt, wusste ich auch nicht- doch die SW Reparatur eines Verstärkungsfehlers??? ok- das klärt sich abends. Wäre/ ist aber natürlich eine gute Erklärung des Untersch. hohen Rauschanteil in den versch. Messbereichen. Ich vermute schon lange das das eigentl. Rauschen garnicht so schlimm ist, sondern der Fehler wo anders steckt... Mit einem hatte ich ja schon recht - mit der Fehlanpassung eines meiner ADC und dem daraus resultierenden hohen Rauschen- das eigentl. gar keines ist. Gruß, brunowe
So, habe mal die kleinen grauen Zellen bemüht, vllt. kann Hayo das von der Softwareseite bestätigen: Grundmessbereich ist 50 mV/div, Offset in Schirmmitte. Ergibt einen Anzeigebereich von +-200 mV. Der ADC macht hieraus 128 +- 81, Planung war wohl die +- 80 auf +- 200 Pixel zu skalieren. Wird die Verstärkung des OPA immer benutzt so ergibt sich nach dem ADC 128 +- 100, aber nur für die 5er Bereiche, sonst muss umskaliert werden. @ Bruno: ich muss wohl Kabel aus dem Gehäuse führen um da nachzumessen. Mal sehen ob es heute noch reicht. Gruß, Guido
@ Guido Ja, mit diesen Messungen ist garnicht so einfach- hab auch ein paar Tage gebraucht bis ich mein Scope so weit hatte! Ich hab die Messungen schon mal durchgeführt- ist eigentl. nicht notwendig das du dafür dein Scope zerlegst, seh es dir einfach mal an. http://welecw2000a.sourceforge.net/docs/Measurements/Messprotokoll3.pdf Gruß, brunowe
Hmmh Bruno, sieht echt so aus, dass die Verstärkung des OPA in den 5er Bereichen auf 1,25 steht, sonst auf 1. Die Videoverstärker verhalten sich wie erwartet. Da werde ich mich mal in die Quellen vertiefen un zu sehen, ob ich das umdrehen kann. Wir verlieren dadurch minimal an Auflösung, dafür muss Hayo nur immer mit 2,5 skalieren (shl, shr, add), was ganz schön beschleunigen könnte. Gruß, Guido
Irgendwo ist da noch ganz mächtig der Wurm drin! Auf jeden Fall scheint unsere Vermutung mit der Verstärkung zu stimmen! So... uns jetzt erklär mal wie du oben auf z.B. 128±81 usw. kommst... was ist denn das? 128 stellt die Mitte dar- soweit ok- aber sollte es denn nicht Ziel sein die ADC möglichst voll auszusteuern?
Hallo Bruno,
>aber sollte es denn nicht Ziel sein die ADC möglichst voll auszusteuern?
das geht aber nur über einen Hardwareeingriff: Verstärkung anheben
wodurch
gleichzeitig aber die Bandbreite sinkt. Heben wir uns als Ultima Ratio
auf. :-)
Der ADC macht aus +0,3125 V 128 + 127, dementsprechend bei +0,20 V
128 + 81(,3). Negativ entsprechend.
Gruß, Guido
ich habe heute auch mal etwas auf der platine rumgemessen und möglicherweise eine der rauschquellen gefunden. zuerst hab ich den eingangskanal vom adc getrennt. ergebnis war eine saubere linie. als nächstes hab ich die verbindung zum adc wieder her gestellt und den signalweg am pin8 des ersten ad8131 aufgetrennt. ergebnis, das rauschen war wieder da und wurde beim umschalten in die 2x und 1x bereiche wie gewohnt schlimmer. es entsteht also in dem schaltungsteil mit den 3 ad's und den 2 analogschaltern. mein gedankengang war nun, vll. mögen es ja die ad's nicht wenn man ihren neg. eingang über einen analogschalter nach masse schaltet. ich hab dann im 10mv messbereich, bei dem ja der neg. eingang vom 2. und 3. ad nach masse geschaltet wird, die beiden eingänge mit einer drahtbrücke direkt an masse gelegt und die analogschalter quasi überbrückt. ergebnis der aktion, das rauschen reduzierte sich im 10mv messbereich in etwa auf das niveu des 50mv messbereiches.
Mal wieder die Frage des Laien ;-) - warum haben die denn da nicht auch ein Relais genommen? Viele Grüße, egberto
@ Sunny: gut gemacht! diese blöden U7AD hatte ich auch schon mit auf der Liste! @ Guido: Ich hab einmal mit einen DC Signal gemessen bei welchen Pegeln die Anzeige des Welec in den einzelnen Messbereich lt. Display in den Vollausschlag geht. Ich werde das morgen ordentl. ins Messprotokoll 3 aufnehmen- jetzt nur soviel: in 500mV/DiV beträgt das Δ zwischen INN und INP des ADC ca. 900mV in 200mV ca. 560mV und in 100mV ca. 575mV. Diese Spannungen legen also den max. Bereich am ADC fest der angezeigt wird. Gruß, brunowe
@egberto das wird wohl eine kostenfrage gewesen sein. an dieser stelle sind ja keine extremen pegel wie direkt am eingang zu erwarten. da hat sich der entwickler gedacht, ach wird schon gehen mit dem analogschalter. der kostet schließlich nur ein bruchteil von einem relais. @all ich werd morgen mal versuchen die beiden analogschalter rings herum mit ein paar smd kondensatoren abzublocken. auch die digitale steuerleitung. mal sehen ob das was bringt.
@sunny zu meiner Zeit (TM) waren Analogschalter noch viel teurer als Relais (im Diplom hatte ich Mühe, einen zu bekommen)! Viele Grüße, egberto
echt? das muss dann ja schon ewig her sein. die 4051-4053 beispielsweise gibt es doch schon seit urzeiten.
Hallo sunny, das ist schon klar: in den 5er Bereichen sind die Videoverstärker auf Vu=1 gestellt. Wenn du in den anderen Bereichen die Analogschalter brückst, schaltest du ebenfalls auf Vu=1. Durch die kleinere Spannungsverstärkung sinkt das Rauschen. @ Bruno We: jo, das ist nicht ok, ich warte mal bis Hayo sich äußert. Deine Messwerte sind o.k., die Aussteuerung der ADC ist wohl nicht in allen Messbereichen dieselbe. Das können wir aber per Firmware ändern, habe "SetSwitches" schon gefunden. :-) @ egberto: Tja, wie die Zeit vergeht, gell. :-)) Aber die CMOS-Switches sind nicht mehr so übel. Wo notwendig sind im Oszi schon Relais eingesetzt: Insgesamt möchte ich den Mund garnicht weit aufreissen, das Hardwaredesign ist nicht schlecht, da ist ne ganze Menge KnowHow erkennbar. Die 200-MHz-Ambition war wohl nur etwas zuviel. Gruß, Guido
Hi, Ihr kommt ja hardwareseitig gut voran, von mir nur soviel - der volle Bereich der ADCs wird in der Tat nicht genutzt. Der Fullscale-Wert liegt in allen Meßbereichen ein ganzes Stück über bzw. unterhalb des Grids - eigentlich schade, hier wird einiges verschenkt. Zur Skalierung: Man muß hier auch noch unterscheiden zwischen dem Wittig-Grid (384 Pixel) und meinem Grid (400 Pixel). Die Skalierung unterscheidet sich hier natürliche geringfügig und bei meinem etwas größeren Grid sieht man natürlich das Rauschen auch etwas mehr. Die genauen Faktoren sind 5V - 2,1 / 2V - 3,25 / 1V - 3,25 alles durch ausmessen mit Labormultimeter ermittelt. Bei der originalen FW kann man sehen, dass die Faktoren nicht stimmen, es gibt gerade in den 2er und 1er Bereichen Abweichungen. Gruß Hayo
@ sunny Na ok, ich will hier nicht den totalen Metusalem raushängen lassen - zu Wendezeit war das besorgen solcher Bauelemente halt sehr problematisch (Relais hatten wir Kistenweise). Viele Grüße, egberto PS: Leider bin ich in der IT gelandet - so mache ich Elektronik nur noch nach Dienst im Keller.
Hallo Hayo, es bleibt die Frage ob wir nicht mal die Auflösung vorerst auf +-80 reduzieren. Das wäre dann für alle Bereiche identisch, die Skalierung auf 200 Pixel ist dann in int problemlos. Weiter werde ich mal versuchen die DAC-Einstellung (Offset) für alle 4 Kanäle einstellbar zu machen (Testfunktion, einfach mit switch) und deren Einstellung im Flash zu speichern. Da habe ich jetzt ziemliche Fehler zwischen den Beeichen. Gruß, Guido
@guido stimmt, du hast recht. ich hab die eingänge verwechselt. die analogschalter schalten genau anders herum als von mir vermutet. schade, also weitersuchen.
Hallo, @sunny- du hast bei abgeklemmten Analogstufen eine gerade Linie? Kein +- 1Bit? wo kommt diese Schwankung dann bei mir her? War also nix mit den Analog-Schaltern, schade... dabei hatte ich die auch schon im Verdacht. Ich hab die Messergebnisse/ Auswertung über die genutzten "voltage ranges" am ADC- und der daraus resultierenden Bitrange mal veröffentlicht: (hoffentl. habe ich mich auf die Schnelle nicht verrechnet!) http://welecw2000a.sourceforge.net/docs/Measurements/Messprotokoll3.pdf Gruß, brunowe
ja hab ich. manchmal muss man dafür die ablenkzeit hin und herschalten. ab und an wackelt mal ein ein bit aber sonst wie mit dem linial gezogen. getestet hab ich das aber nur an kanal 1.
@Guido du willst dich heute mit den Verstärkungen spielen? Hast du dir vielleicht schon mal überlegt den OPA656 durch einen OPA657 zu ersetzen? Dieser hat ein wesentl. höheres BW x gain Produkt. Von den elektr. Werten sollte man die beiden OP's relativ ersetzen können. Damit lies sich auf jeden Fall der Spannungspegel zur Vollaussteuerung der ADC erreichen. Mit einer Gain von 5...8 könnte man damit sogar die Eingangsempfindlichkeit des Oszi's erhöhen. Selbstverständlich müsste man dazu einige Widerstände und die SW anpassen- war mir bislang ehrlich gesagt einfach zu viel Arbeit. Gruß, brunowe
@ Bruno We, sowas hebe ich mir ev. für später auf, da entstehen sicher eine ganze Menge neue Probleme. Ich will nur mal die Einstellungen probieren, die IMHO dem Entwurf zu Grunde lagen. Mal schauen, warum da so gemurkst wurde. Gruß, Guido
@Bruno We, mit dem OPA657 wäre ich vorsichtig, der hat zwar die höhere Bandbreite ist aber nicht 'Unity-Gain Stable', d.h. nicht bei einer Verstärkung von 1 zu gebrauchen (siehe Datenblatt) Gruß, Günter
Hallo auch von meiner Seite, bin soeben auch Besetzer eines W2024A. Da ich derzeit gerade im Maturastress bin und meine Diplomarbeit fertig schreiben muss habe ich gerade nicht viel Zeit zum Mitentwickeln. Aber in einem Monat ist alles vorbei. Als angehender Telematikstudent (ok es dauert noch ein bisschen wegen Bundesheer) sehe ich im Oszilloskop durchaus Potential und freue mich zur Verbesserung beitragen zu können. Ich habe gute C/C++ Kenntnisse und kenne mich ein bisschen Analog aus. Ich hoffe das ich helfen kann. lg Robert
@gjung der Opa657 soll ja auch nicht mit einer gain von 1 betrieben werden. Ich weiß natürlich nicht ob du die letzten Posts verfolgt hast... Die hinter diesem Gedanke stehende Motivation ist auch nicht die höhere BW, sondern eine bei 200MHz noch zu erreichende höhere Verstärkung. Letztendlich soll damit erreicht werden, das ein ausreichender Signalpegel an den ADC zur Verfügung steht um diese voll auszusteuern. Gruß, brunowe P.S.: Aber wir sind auch für andere Vorschläge dankbar.
Hallo, ich stelle das mal zur Diskussion: Ich habe die Firmware so geändert, dass die Verstärkungen bei 1.0, 2.5 und 5.0 liegen sollten. Damit ergeben sich in allen Bereichen max. ADC-Werte von ca. 160, die leicht per int auf 400 Pixel skaliert werden können. Dadurch wird das Gerät nach meinem Gefühl deutlich schneller. Wer möchte kann das ja mal probieren, ich nenne das Studie1 weil es keine offizielle Beta ist, die gibt immer noch Hayo raus. In den 1er und 2er Bereichen wird die Amplitude um ca. 10 % zu klein angezeigt, die Verstärkung stimmt wohl nicht. Das lässt sich leicht per Software korrigieren aber solange noch an der Hardware geforscht wird, ist das wohl nicht sinnvoll. In den 5er Bereichen könnte die OPA-Verstärkung wieder aktiviert werden, damit hier die Auflösung der ADC etwas besser ausgenutzt wird. Gruß, Guido
@Guido Ich experimentiere gerade mit einem Assembler Makro, welches die Floating Point Multiplikation ersetzen soll. Der Welec-Entwickler hatte dies ursprünglich auch benutzt da es ziemlich schnell ist. Leider erschließt sich mir die Funktion von außen nicht so ganz auf Anhieb, so dass ich gezwungen bin auf iterativem Wege zu einer Lösung zu kommen. Wenn das hinhaut sollte die Geschwindigkeit wieder wie bei der originalen FW sein, nur genauer. Gruß Hayo
Hallo Hayo, der Vergleich mit der Originalfirmw. fällt mir schwer, ist zu lange her. Ich meine aber richtig schnell, kann mir nicht vorstellen wozu noch schneller gut sein soll. Habe aber noch die reine Pixelversionen geändert (ohne Vektoren), da ist die Anzeige schneller als ich gucken kann (mit nur einem Kanal). Die max. Genauigkeit können wir ruhig der Messwertanzeige überlassen. In Pixeln hat man davon nicht viel. Ich schau jetzt mal, ob ich eine "Baustelle" finde, bei der ich weiterkomme. Gruß, Guido
hier mal eine überlegung die ich heute hatte. ein großteil des rauschens entsteht ja durch die drei ad8131. könnte man nicht 2 von denen weg rationalisieren und urch einen einzigen rauscharmen highspeed opv mit variabler gegenkopplung ersetzen? also u10 und u11 fallen weg. der neue opv wird als nichtinvert. verstärker geschaltet. in der gegenkopplung werden 2 wiederstände in reihe geschaltet. jeder wird von einem analogschalter überbrückt. die werte werden so gewählt, dass die stufenverstärkung zwischen 1(beide analogschalter geschlossen),2(ein as geschlossen) und 4(beide as geöffnet) umgeschaltet werden kann. der ausgang der stufe wird an pin8 von u12 angeschlossen pin1 von u12 wird auf masse gelegt. problem wird sein einen geeigneten opv zu finden. was denkt ihr? gute idee? schlechte idee?
@Guido Die Geschwindigkeit hat mehrere Vorteile, erstens läßt sich das Userinterface flüssiger bedienen, zum anderen hat man Rserven für andere Berechnungen. Zur Genauigkeit: Wenn mein Oszi wie bei der Originalfirmware im 2V-Bereich statt 6V nur 5,5V anzeigt, ist mir das nicht genau genug - Dir etwa? Gruß Hayo
Hallo Hayo, das ist mir auch nicht genau genug, die 10 % in den meisten Bereichen stören mich auch noch, lassen sich aber leicht verringern. Ich meine nur, dass normalerweise niemand mt der Lupe vor dem Oszi sitzt und Pixel zählt, weil das auch bei einer geschätzten Grundgenauigkeit von 5 % sinnlos wäre. Mehr Speed ins Userinterface, das wäre jetzt genau das was ich mir vorstellen könnte. Da bin ich aber (noch) ziemlich ratlos. Gruß, Guido
@Hayo Der ursprüngliche Entwickler steht ja in den Quellen drin und ist auch im Netz auffindbar - eventuell ist er ja kooperativ und kann einige Dinge erklären. Eine Mail könnte da eventuell viel Zeit in der Entwicklung sparen... Nur so ein Gedanke... egberto
Hallo egberto, glaubst du wirklich, der Oli könnte uns weiter bringen? Herr Wittig hat seinen Code schon überarbeiten müssen. Nö, Hayo weiß schon was er tut und ist voll im Code drin. Manchmal brauchen die Dinge halt etwas Zeit. Gruß, Guido
egberto wrote: > @Hayo > > Der ursprüngliche Entwickler steht ja in den Quellen drin und ist auch > im Netz auffindbar - eventuell ist er ja kooperativ und kann einige > Dinge erklären. > Eine Mail könnte da eventuell viel Zeit in der Entwicklung sparen... Ja das ist natürlich eine Idee - aber ich hatte vom Coding her auch so den Eindruck als wenn der Entwickler auf die gleiche Art zu seinem Ergebnis gekommen ist. Da wimmelt es nämlich förmlich vor Hilfs-Offsets und mal eben so ins Coding geschriebene Korrekturwerte die das Ergebnis dann so hinbiegen wie es ungefähr sein soll. Zudem bin ich nach einigen Versuchen auch schon dicht dran ein vernünftiges Ergebnis zu erzielen - ohne Hilfs-Offsets und Ähnliches. Zugegebenerweise ist auch ein wenig Ehrgeiz dabei, kann mir wohl keiner verübeln, oder? Gruß Hayo
Hallo Hayo und Guido, ist schon ok - dann frisch ans Werk ;-) (und Danke für das bis jetzt gemachte!) Viele Grüße, egberto
Guido wrote: > 400 Pixel skaliert werden können. Dadurch wird das Gerät nach > meinem Gefühl deutlich schneller. Wer möchte kann das ja mal > probieren Hab ich gemacht, fühlt sich auf jeden Fall schneller an als die originale FW. So kann man auch mit 4 Kanälen arbeiten, ohne bei Einstellungen einen Krampf zu bekommen, weil sich die Werte nur im Sekundentakt ändern. > vorstellen wozu noch schneller gut sein soll. Habe aber noch > die reine Pixelversionen geändert (ohne Vektoren), da ist die > Anzeige schneller als ich gucken kann (mit nur einem Kanal). Die Darstellung ohne Vektoren ist bei 4 Kanälen nicht wesentlich schneller als mit Vektoren (so ungefähr 3fps zu 4fps). Ok, im Verhältnis sind es 30%, aber beim Arbeiten ist es kein großer Unterschied. > In den 1er und 2er Bereichen wird die Amplitude um ca. 10 % > zu klein angezeigt, die Verstärkung stimmt wohl nicht. Das Geschätzt mit der Cursors-Funktion und dem Testsignal: MB 100mV: Cursor 104mV/div (4%) -> abgelesen 739mV MB 200mV: Cursor 208mV/div (4%) -> abgelesen 741mV MB 500mV: Cursor 520mV/div (4%) -> abgelesen 750mV Ich seh da keine Unterschiede zwischen den Messbereichen. Wo ist mein Denkfehler? /Hannes
Mal noch was ganz anderes: hat noch jemand ausser mir einen Wackelkontakt in der Netzbuchse? Anders gefragt: lohnt es sich, da mal aufzuschrauben und nachzulöten, oder ist das eine billige Buchsenserie, wo man mit dem Wackler leben muss? /Hannes
Hallo Den Wackler mit dem Netzstecker hatte ich auch. Da passen anscheinend die Buchse an der Netzzuleitung und die Stifte am Gerätestecker nicht zusammen. Entweder sind die Anschlußstifte am Gerät zu kurz oder die Buchsen in der Netzzuleitung zu tief eingelassen so entsteht nur ein minimaler Kontakt und beim kleinsten Wackler ist die Verbindug unterbrochen. Habe eine Anschlußleitung gefunden wo die Buchsen nicht so tief eingelassen sind und damir funktioniert es. Eigentlich gehört da eine abgewinkelte Netzbuchse hin wegen dem Bügel, leider im normalen Elektrohandel schwer zu bekommen. Gruß Josef
Hallo Johannes, die Abweichungen habe ich nur grob abgelesen. Das sind aber ziemlich sicher Toleranzen der Hardware und können daher von Gerät zu Gerät schwanken. Sollten wir vllt. mal noch genauer vergleichen. Meine Zeitangaben beziehen sich auf einen Zweikanaler, weil ich nur einen solchen habe. Wackelkontakt habe ich auch, liegt aber am Kabel. Nimm mal ein besseres, die hat man ja rumliegen. Gru0, Guido
Hallo zusammen, bzgl. Wackelkontakt: Was auf jeden Fall recht hilfreich ist, ist das Nachlöten der bleifreien Kleckerverbindung zwischen Netzbuchse und Platine. Die Lötverbindung war bei meinem Gerät höchst zweifelhaft, es hat gerade so zum Verbinden gereicht, vom Umschmelzen konnte keine Rede sein. Jetzt glänzt die Lötverbindung auch, so wie es sich gehört. Gruß, branadic
Hallo allerseits, ich will mal einem kleinen Zwischenbericht abgeben, nicht das ihr denkt das hier nichts mehr läuft... Derzeit werden zwei unterschiedliche Ansätze verfolgt um die HW des Oszi's zu verbessern: 1.) Es ist von mir angedacht, den OPA656 rauszuwerfen und testweise durch einen OPA657, bzw. durch einen OPA659 zu ersetzen. Da der OPA657 nicht Unity Gain stable ist, soll dieser mit g=7 betrieben werden (er hat dann immer noch eine BW von 350MHz). Diese Änderung ginge also mit einer Steigerung der Eingangsempfindlichkeit einher. Selbstverständlich müssen für beide Änderungen Anpassungen durchgeführt werden. Beide Maßnahmen will ich erstmal mit Ltspice simulieren, dauert noch etwas. 2.) Sunny will die drei AD8131 durch einen THS4508 ersetzen. Dies ist nur durch den Einbau einer kleinen Huckepack- Platine (ca. 20x30mm) möglich. Diese Schaltung hab ich, als erste Planungsgrundlage schon mal mit Ltspice simuliert -s.h. Anhang.
Und hier für alle die kein LTspice haben wenigstens etwas zum ansehen. Gruß, brunowe
branadic schrieb: > Hallo zusammen, > > bzgl. Wackelkontakt: > > Was auf jeden Fall recht hilfreich ist, ist das Nachlöten der bleifreien > Kleckerverbindung zwischen Netzbuchse und Platine. Die Lötverbindung war > bei meinem Gerät höchst zweifelhaft, es hat gerade so zum Verbinden > gereicht, vom Umschmelzen konnte keine Rede sein. Bei mir war die Buchse so eng, dass man den Stecker zuerst nicht richtig reingekriegt hat - das gab dann sauberes Gebritzel. Wenn man den Stecker dann mit etwas mehr Kraftaufwand reinsteckt ist alles ok. Gruß Hayo
@Bruno Ich bin mächtig gespannt was bei Euren Versuchen rauskommt! Da könnte man ja noch mächtig was aus der Kiste rausholen. Wenn Ihr eine FW-Version mit anderen Skalierungen braucht sagt Bescheid, dann klöppel ich Euch schnell was Ihr braucht. Was ist eigentlich aus der Abgleichgeschichte mit den internen Kondensatoren geworden? Wolltest Du da nicht eine kleine Anleitung machen wie man da evtl. die Schwingneigung bei hohen Frequenzen wegbekommt? Ich wollte da jetzt nicht ohne Plan einfach dran rumdrehen. Andererseits, wenn die ohnehin nicht abgeglichen sind kann man wohl auch nicht soviel verkehrt machen oder? Gruß Hayo
Hallo Hayo, das mit dem Abgleich ist -natürlich- nicht vergessen! Da aber mein Scope mehr oder weniger weit auseinandergebaut vor mir liegt, kann ich momentan keinen zuverlässigen Abgleich durchführen und somit möchte ich auch keine Anleitung schreiben. Solange aber die silbernen Abschirmbleche drauf sind kann man sich die Startposition gut markieren und immer wieder zurückdrehen. Ohne diese Bleche war es bei mir wg. Einstreuungen auch wesentl. schlechter zum abgleichen. Wichtig ist evtl. ein Blick in den Schaltplan damit man sieht welcher Drehko. für welchen Messbereich zuständig ist. Dann den TK bei 1kHz abgleichen- die 200MHz TK an beiden Einstellern! Dto. bei höherer Frequenz- ein 10....50Mhz Rechteck von einem Quarzoszillator ist dazu perfekt. Erst danach bei einer Freq. in der Nähe der Schwingneigung (ca. 80MHz- je nach Pegel und Messbereich) an den Geräte internen Drehko's. Diese Maßnahme verbessert die Schwingneigung zwar (zumindest an meinem Scope), löst aber nicht das ursächliche Problem- deshalb auch von meiner Seite die Versuche mit den anderen OPA's. Gruß, brunowe
hallo hayo
>Ich bin mächtig gespannt was bei Euren Versuchen rauskommt!
ich auch ;-) bis jetzt ist noch nicht abzusehen ob meine idee auch in
der praxis funktioniert.
bezüglich der skalierungen, frag ich mal anders herum. was währe denn
programmiertechnisch günstig um den aussteuerbereich des adc möglichst
gut auszunutzen? der eingangsverstärker währe nach dem umbau im hinblick
auf die verstärkungen recht variabel. soll heißen es ließen sich auch
unrunde verstärkungen wie 1,5 o.ä. realisieren.
sunny schrieb: > bezüglich der skalierungen, frag ich mal anders herum. was währe denn > programmiertechnisch günstig um den aussteuerbereich des adc möglichst > gut auszunutzen? Also die Eckdaten stehen ja fest: Das neue Raster ist 400 Punkte hoch bei 256 Spannungsstufen, momentan arbeiten wir mit Verstärkung 2 für die 5er Bereiche und mehr als 3 für die 2er und 1er Bereiche. Optimal wäre natürlich eine 100% ige Ausnutzung des Aussteuerbereiches - heißt also 1,56. D.h. 1,5 wäre gerade zu wenig und die nächste sich anbietende Verstärkung wäre 2. Wenn also in allen Bereichen eine Verstärkung von 2 zu nutzen wäre dann hätte das schon einen deutlich positiven Einfluß auf die Signalqualität und das effektiv sichtbare Rauschen. Gruß Hayo
Hallo Hayo, ich musste deinen Text 2mal lesen bis ich wusste was du meinst. Setze im obigen Text überall anstatt Verstärkung so etwas wie "Zooming durch SW Maßnahme", dann ist es besser verständlich. Selbstverständlich lässt sich auch eine ungerade Verstärkung (damit meine ich die HW-gain des OP's) realisieren, so dass du in jedem Messbereich deine 256 Spannungsstufen voll ausnutzt. ABER- wäre es nicht wesentlich schneller vom SW- Rechenaufwand wenn du nur 200 Spannungsstufen auf 400 Px erhöhen musst, anstatt mit 1,56 zu multiplizieren? Das war die Frage die ihm Raum stand. Also die vermeindlich höhere Auflösung von 256 Stufen durch langsamere Verarbeitung und Rundungsfehler wieder zu nicht machen, oder sich direkt mit 200 Spannungsstufen begnügen. Gruß, brunowe
In einem Anflug von blankem Wahnsinn habe ich mir noch ein W2024A zugelegt. Nun wurde mir der Versand bis spätestens 04.05 zugesagt. Natürlich ist bis jetzt nichts gekommen. @Hayo, wie lange hast du insgesammt auf dein Oszi gewartet? @ Robert (Razer), hast du auch die mail bekommen, das Oszi sei in der Vorbereitung und solle bis spätestens...
Hallo Kurt, Genau diese Mail habe ich gestern auch bekommen. Versand bist 9.05. Daraufhin hab ich gestern nachgefragt, aber noch keine Antwort bekommen. lg Robert
Hallo, mit Vorbereitung ist wahrscheinlich das Reworking gemeint. @ Kurt: So ist es richtig, in der Krise optimistisch auf die Zukunft setzen! Das waren ca. 318 Eur gestern? Gruß, Guido
>> mit Vorbereitung ist wahrscheinlich das Reworking gemeint.
Das Reworking von Non-A zur A Version?
@Kurt @Robert Bei mir hat es danach noch locker eine Woche gedauert! Den Verlauf kann man hier in den Foren nachlesen wenn man Lust hat eine wenig nach meinen Beiträgen zu suchen. Es ging sogar schon soweit, dass erste Verschwörungstheorien aufkamen ;-) Also wird es wohl noch etwas dauern. Allerdings habe ich so den Eindruck, dass bei WELEC tatsächlich nur noch Restbestände abverkauft werden so wie es mit den Gehäuselabels aussieht und der Tatsache, dass ein Modell inzwischen nicht mehr zu kriegen ist (mein erstes WELEC mit 2 Kanaälen nämlich). Gruß Hayo
Ohne euch stören zu wollen: Kann mir mal jemand eine kurze Zusammenfassung des Projektes geben und um was es hier geht. Wie fing alles an?
>Das Reworking von Non-A zur A Version?
Keine Ahnung, aber man sieht ja, dass auf der Platine von Hand
nachgelötet wurde. Ich denke auch, dass es die Reste aus der
K-Masse sind, die je nach Fortschritt beim Reworking versteigert
werden.
@Guido, gestern 202 Euro für das W2012A (14 mal) und 400 Euro für das W2024A (6 mal) Ich hatte die Woche davor 350 Eur für das 2024A bezahlt. Jetzt steht nur noch ein einziges überteuertes 2012A drin.
@ Teplotaxl X. : Aber wirklich nur ganz kurz: Es geht um eine Serie DSOs, die einst teuer verkauft wurden und jetzt billig in der Bucht zu kriegen sind. Funktioniert haben sie nie richtig, man kann aber toll damit spielen. ;-) @ Kurt: eventuell kommen wieder welche, da gab es schon öfter mal Pausen.
Habt ihr die Firmware komplett neuentwickelt, oder die alte reverseengineert und verbessert?
@Bruno + Sunny Ich hab mich im gestrigen Beitrag wohl etwas missverständlich ausgedrückt. Im Prinzip meinte ich eher den Skalierungsfaktor als die Verstärkung. Ich werde mal weiter unten neu ansetzen, jetzt erstmal zu Euren Fragen: Bruno We schrieb: > Selbstverständlich lässt sich auch eine ungerade Verstärkung (damit > meine ich die HW-gain des OP's) realisieren, so dass du in jedem > Messbereich deine 256 Spannungsstufen voll ausnutzt. ABER- wäre es nicht > wesentlich schneller vom SW- Rechenaufwand wenn du nur 200 > Spannungsstufen auf 400 Px erhöhen musst, anstatt mit 1,56 zu > multiplizieren? Grundsätzlich ist natürlich die Verarbeitung schneller wenn ich nur reine Integer-Multiplikationen durchführen muß. Ich bezweifle aber, dass die Verstärkung so genau einzustellen ist dass das hinhaut. Letztlich müßte ich dann um einigermaßen genau zu werden doch wieder Nachkommastellen verwenden. > Das war die Frage die ihm Raum stand. Also die vermeindlich höhere > Auflösung von 256 Stufen durch langsamere Verarbeitung und > Rundungsfehler wieder zu nicht machen, oder sich direkt mit 200 > Spannungsstufen begnügen. Ja das ist doch schon der Fall in den 5er-Bereichen, da werden in der Tat nur 200 Stufen genutzt, und in den anderen Bereichen nur ca 128, was der halben ADC-Aussteuerung entspricht - kein Wunder wenn das Signal scheiße aussieht (tschuldigung). So noch mal ein neuer Ansatz: Wichtig ist es den Fullscalebereich des ADC optimal auf das Grid abzubilden. Dann wird das Rauschen am geringsten und das Signal am genauesten (feinere Stufen = detailgetreuere Signaldarstellung). D.h. wir brauchen den Fullscalebereich des ADC (steht im Datenblatt - müßte ich mal nachsehen). Der muß dann auf den jeweiligen Spannungsbereich abgestimmt werden, so dass die Gesamtverstärkung aus Eingangsspannungsteilern und Verstärker den ADC-Fullscalebereich mit dem Grid in Deckung bringt. Beispiel: bei 2V/DIV wäre die optimale Fullscaleaussteuerung für den ADC bei 16V am Eingang (8 Divs a 50 Pixel = 400 bei 1 Div = 2V). Das Widerstandsnetzwerk plus Verstärker müssen dann die 16V so runterteilen, dass gerade der Fullscalewert des ADC erreicht wird. Allerdings wäre es schon eine deutliche Verbesserung, wenn wir in den 1er und 2er Bereichen einen Skalierungsfaktor von 2 erreichen könnten wie in den 5er Bereichen. So ich hoffe das war jetzt besser... Gruß Hayo
Teplotaxl X. schrieb: > Habt ihr die Firmware komplett neuentwickelt, oder die alte > reverseengineert und verbessert? Nein, WELEC hat die Version 1.2 als Open Source freigegeben und wir machen jetzt das Beste draus... Gruß Hayo
Hallo, zur Vollaussteuerung benötigt der ADC eine Differenzspannung von 625 mV. Kann die Auflösung von 8 Bit voll genutzt werden, ist keine Realberechnung nötig. Der Skalierungsfaktor auf 400 Pixel ist dann 1,5625 = 1 + !/2 + 1/16, wozu nur ">>" benötigt wird. @ Teplotaxl X.: der Hersteller hat eine ältere Version der Firmware im Source freigegeben, an der wir (naja, hauptsächlich Hayo) uns vergnügen. Gruß, Guido
Guido schrieb: > zur Vollaussteuerung benötigt der ADC eine Differenzspannung > von 625 mV. Oha, Du bist aber schnell, na dann haben wir doch die Info die wir brauchen. > Kann die Auflösung von 8 Bit voll genutzt werden, > ist keine Realberechnung nötig. Der Skalierungsfaktor auf 400 > Pixel ist dann 1,5625 = 1 + !/2 + 1/16, wozu nur ">>" benötigt > wird. Cool, das hatte ich noch gar nicht gesehen, dann sollte das eigentlich recht flott gehen. Gruß Hayo
Ohne selbst eines zu besitzen: Schnell kann man das vielleicht berechnen, scheiße aussehen tuts vermutlich trotzdem. Die sinnvollste Lösung ist wohl wirklich, die Verstärkung für den den ADC auf 128 +- 100 auszulegen. Das Umskalieren bräuchte für eine saubere Darstellung Subpixelgenauigkeit, also gewichtetes Rendern. Wie soetwas dann aussieht kann man z.B. bei den 6000ern von Agilent sehen. Sehr schön und durchaus nützlich. Wie belegt sind eigentlich die FPGAs mit der Datenerfassung und wie siehts mit Speicher aus? Für eine schnelle Darstellung würde sich HW-Beschleunigng fürs Rendern doch geradezu aufdrängen. Der Nios müsste sich dann nur noch um das MMI und den Buffer-Flip kümmern...
Hallo Karl, auch wenn ich dieses Forum aufgrund der Unübersichtlichkeit und kilometerlangen Threads meistens meide, hat mich Bruno gebeten, hier mal Stellung zu nehmen. Generell können wir erstmal am Hardware-Design nichts verändern, zumindest nicht "unterhalb" der Originalsoft, da Wittig uns die Hardwarebeschreibung aus (vorgeschobenen?) lizenzrechtlichen Gründen (oder so) nicht zur Verfügung gestellt hat. Ansonsten passiert auf Sourceforge ja momentan parallel zu den Verbesserungsbemühungen an der originalen Software eine komplette Neuentwicklung der Firmware inklusive neuem FPGA-Design. Hier stehen wir momentan noch ziemlich am Anfang und zurren gerade das Grundgerüst des Systems fest (neuer Softprozessor, Ansteuerung der Hardware außerhalb des FPGA usw.). Der Ansatz, den wir momentan verfolgen, stammt ursprünglich vom russischen Kollegen Slog, der angefangen hat, von der Messwerterfassung bis hin zur Bildschirmdarstellung ALLES mit VHDL in Hardware zu erschlagen. Viele Teile davon verwenden wir auch immernoch, insbesondere die Hardwareumsetzung der Messwerterfassung und -darstellung, weil das enorme Geschwindigkeitsvorteile bietet. Der Softprozessor ist bei uns bewusst klein und einfach gewählt, da ihm ausschließlich Kontrollaufgaben zugesprochen werden (GUI, Benutzereingaben, Menüs, Ansteuerung der eigentlichen Signalerfassung in der HW, also das Setzen der Parameter wie Timebase usw.). Hoffe, dieser kleine Einblick hilft dir zu deiner Frage etwas weiter ;) Ach ja, die leidige Speicherfrage fehlt noch: Der FPGA hat leider notorisch zu wenig Blockram, und wir können auch nicht behaupten, Wittig hätte endlos SRAM spendiert. Zumal letzterer als Samplespeicher i.d.R. zu langsam ist. Grüße Daniel
Karl schrieb: > Ohne selbst eines zu besitzen: Schnell kann man das vielleicht > berechnen, scheiße aussehen tuts vermutlich trotzdem. Die sinnvollste > Lösung ist wohl wirklich, die Verstärkung für den den ADC auf 128 +- 100 > auszulegen. Also bei optimaler Fullscaleaussteuerung wird es mitnichten scheiße aussehen! Bessere Optik ist dann nur noch mit einem höher auflösenden ADC zu erreichen, da dann aufs Pixel genau dargestellt wird. Also wenn es hinhaut die Verstärkung dahingehend anzupassen wäre das eine deutliche Verbesserung wenn nicht sogar eine andere Klasse! Gruß Hayo
Hallo Crazor, danke für deinen Bericht. Jetzt kapiere ich mal die Tragweite von Slogs Meinung alles in VHDL zu machen. Helfen kann ich da mangels Wissen nicht, aber ich würde mich schon freuen, wenn du oder ihr auch hier Neuerungen mitteilen würdest. Bin doch sehr gespannt, was aus dieser Hardware rauszuholen ist. @ Hayo: Das meine ich ja mit Integerarithmetik und das geht im Prinzip auch in den momentanen Messbereichen. Man bekommt das problemlos mit Integern hin, ob zwei oder 4 Schiebeoperationen pro Wert ist völlig wurscht. Einen Fehler in der dritten Stelle nehme ich dabei in Kauf, das ist auf dem Schirm eh nicht zu erkennen. Die Geschwindigkeit wird dadurch schon gut erhöht, das wollte ich nur mal probieren. Was meinst du zu meiner Drehgeberidee? Da habe ich leider noch gar keine Rückmeldung. (o.k. ein nr_delay(25) im if-Zweig verbessert die Sache vermutlich noch, 50 ms sind etwas zu lang). Gruß, Guido
hallo hayo, könntest du uns, für unsere harwarespielerein, mal eine testfirmware mit verschiedenen skalierungen erstellen? wir bräuchten folgendes kanal 1 skalierungsfaktor = 1 kanal 2 skalierungsfaktor = 1,5625 kanal 3 skalierungsfaktor = 2 und zwar fix für alle messbereiche. also keine änderung der skalierung beim umschalten von 5'er 2'er und 1'er bereich. währe nett von dir. gruß sunny
@sunny + Guido Bin momentan etwas busy, dummerweise muß ich auch noch Kohle verdienen. Melde mich morgen dazu. Gruß Hayo
Hallo sunny, wenn Hayo keine Zeit hat kann ich das auch erledigen. Soweit steige ich im Code durch. Melde dich also falls es eilt. Gruß, Guido
hi guido, es ist nicht wirklich eilig aber wenn's dir keine großen umstände bereitet, kannst du's gerne tun. ich würde mich freuen. dann kann ich morgen schon mal ein bischen rum spielen. grüße sunny
Hallo sunny, bitteschön. Hoffe es funktioniert, zum Testen habe ich keine Lust. Gruß, Guido
Danke! Das nenne ich mal fix Gruß, brunowe
danke für deine hilfe guido. ich teste sie dann morgen. muss jetzt in die heia :-)
Angehängte Dateien:
-
w2024a.jpg
490 KB
Das 2024 ist heute gekommen. Wie schon vermutet, mit dem alten Wittig Label. Leider sind einige Fussel im Bildschirm weswegen ich das Gerät wohl umtauschen muss. Anfrage an Welec ist raus, Antwort hoffentlich morgen.
> Leider sind einige Fussel im Bildschirm weswegen ich das Gerät wohl > umtauschen muss. Anfrage an Welec ist raus, Antwort hoffentlich morgen. Hoffentlich klappt der Austausch. Hoffe, dass ich mehr Glück habe. Wohne nämlich in Österreich, und dann das ganze hin und her schicken....
Beim Umtausch meines W20x2 gegen ein W20x2A hatte Wittig das Paket abholen lassen.
> Beim Umtausch meines W20x2 gegen ein W20x2A hatte Wittig das Paket > abholen lassen. Danke für die Info. Mir wurde der Versand bis Samstag versprochen. Auf die Email wurde nicht geantwortet. Mal schauen...
Ich soll das Gerät unfrei zurückschicken und bekomme dann ein neues.
@Sunny + Guido Haut das hin mit der modifizierten FW oder soll ich ich da noch was machen? Gruß Hayo
@hayo ich hab guido's FW gerade aufgespielt und alles haut hin. @guido danke noch mal für deine hilfe! gruß sunny
Hallo sunny, schön dass es klappt. Dann wünsche ich viel Erfolg. Gruß, Guido
Hmm, also in meiner Mail stand ebenfalls "Vorbereitung" und "sollte bis spätestens 27. April an Sie versendet werden.". Erhalten habe ich bis heute nichts. Hat jemand aehnlich lang gewartet? Ich hab per Mail bereits darauf hingewiesen, dass die Sache Ende der Woche zum Anwalt wandert. So ein Mist schon wieder... ;). Gruessle
Hallo, Guido schrieb: < Für mich verfestigt sich der Eindruck, dass da ein Schwingen im < Eingangskreis stattfindet. Das ist kein Rauschen der Bauteile, < dafür ist es um Größenordnungen zu stark. Natürlich oszilliert da was, das vermuten wir doch schon lange. Nicht umsonst spielen wir uns mit einer anderen Eingangsstufe bestehend aus nur einem THS4508 (anstatt drei AD8131). Dieser THS kann z.B. von einem OPA656 (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. Interessant ist, selbst in den Simulationen die wir erstellt haben (Multisim bzw. auch mit LTSpice), zeigt der OPA656 ein eindeutiges Schwingen. Der OPA657 verstärkt hingegen ab einer gain von ca. 7 absolut stabil. Leider ist auch der THS4508 auch erst aber einer Verstärkung von 2 stabil. Unser Problem derzeit ist, das wir eigentlich viel zu viel Verstärkung haben... Zum Anderen gilt es die parasitäre Kapazitäten möglichst gering zu halten (z.B. die der Switches)- 200MHz ist halt schon etwas. Gruß, brunowe
> also in meiner Mail stand ebenfalls "Vorbereitung" und "sollte bis > spätestens > 27. April an Sie versendet werden.". Erhalten habe ich bis heute nichts. > Hat jemand aehnlich lang gewartet? Ich hab per Mail bereits darauf > hingewiesen, dass die Sache Ende der Woche zum Anwalt wandert. So ein > Mist schon wieder... ;). Hallo Andre, Ich hab am 28.04 gekauft. Mir wurde der Versand des Gerätes bis 9.5 versprochen. Heute habe habe ich eine Versandbestätigung mit Trackingnummer bekommen. lg Robert
Ich hab mit dem Gerät zwar nichts zu tun und auch nur sporadisch mitgelesen aber mal ein Vorschlag: Testweise die Eingangsspannung runterteilen und den Gain der Eingangsstufe so weit aufdrehen, daß die OPs im sicheren, nicht-schwingenden Betrieb arbeiten.
Alexander schrieb: > Testweise die Eingangsspannung runterteilen und den Gain der > Eingangsstufe so weit aufdrehen, daß die OPs im sicheren, > nicht-schwingenden Betrieb arbeiten. Die Idee hatte ich auch schon, aber dazu müßte man das ganze Widerstandsnetzwerk ändern - ziemlich aufwändig nur für einen Test. Allerdings könnte es damit gehen. Gruß Hayo
Hallo, Ich stelle nochmal eine Simulation mit LTSpice hier rein in der sehr deutlich wird, wie der OPA (auch im realen Betrieb) schwingt. Da dieses Schwingen hauptsächlich vom Switch 7Z66 abhängt (bzw. von dessen parasitären Kapazitäten), werde ich diesen zu Testzwecken einfach mal rauslöten. Ich berichte dann wieder... Gruß, brunowe
Angehängte Dateien:
-
Phasenverschiebung.JPG
66 KB
So, der Switch ist raus. Ob das bzgl. des Oszillieren was gebracht hat, kann ich aber leider noch nicht sagen. Auf jeden Fall ist mir jetzt erstmalig ein anderes Problem aufgefallen. Früher ging dieser Effekt immer etwas im Rauschen und im schlechten ADC Abgleich unter. Wie man auf dem Foto gut erkennt, wird ein ADC zu spät ausgelesen. Dies führt zu einem (zusätzlichen) phasenverschobene Signal. An der HW kann das nicht liegen, die Eingänge aller 4 ADC eines Kanals sind fix miteinander verdrahtet. Ein Wechsel der FW auf eine ältere Version (original Wittig V1.3) hat auch keine Besserung gebracht. Nach längerem hin und her ist mir eingefallen, das ich mir vor längerer Zeit mal den protected Flash zerschossen (und dabei z.B. die ADC Kal. Werte überschrieben) habe. Weil es mit meiner Sicherung Probleme gab, hab ich mir das protected Flash (ich glaube es stammt ursprünglich von Hayo) drauf... Kann es sein, das es da Unterschiede in den protected Flash gibt? (Ich hab ein W2022A, Hayo glaub ich ein W2012). Inzwischen weiß ich auch wie das geschehen ist... wenn man beim Welec Updater auf "NEIN" drückt bedeutet das, die Werkseinstellungen werden überschrieben- Ja bedeutet Werkseinstellung behalten- das hab ich wohl damals überlesen... tja, jetzt versuch ich nochmal meinen eigen Dump des protected Flash- 71 582 Zeilen.... das kann dauern.
Ich hab ein W2022 und ein W2014. Aber nur von meinem W2014 hab ich originale Backups. Beim W2022 war Falk so nett Markus und mir aus der Klemme zu helfen. Von welchem Gerät das stammt weiß ich allerdings nicht. Allerdings hatte ich nicht das Gefühl, dass mein W2022 anders reagiert hat, nachdem ich es mit dem Flash vom W2014 gefüttert hab. Bin übrigens mit dem DAC-Abgleich etwas weiter gekommen, das Problem hing witzigerweise mit der Start/Stop Logik des ADC zusammen, die auch für den Freeze-Bug verantwortlich ist. Falls Du den Firmwarethread mit verfolgt hast, bin gestern mit Guidos Hilfe drauf gestoßen. Gruß Hayo
Hallo Hayo, das mit dem protected Flash ist das Letzte das mir noch eingefallen ist... Ich bin natürlich auch gern für andere Hinweise offen! Je mehr wir an dem Gerät rumbasteln, desto mehr Fragen werden aufgeworfen. Dennoch sind Fortschritte klar erkennbar und das zählt im Endeffekt. Meiner Meinung steckt noch viel ungenutztes Potential in dem Gerät. Das mit dem DAC Abgleich hab ich natürlich mitverfolgt, wäre schön wenn wieder ein Bug weniger in der SW ist. Ist dir eigentlich schon einmal aufgefallen, das bei invertierter Signaldarstellung die ADC Kalibrierung nicht mit berücksichtigt, bzw. nicht mit invertiert wird... was natürlich völliger Quatsch ist. Nur das euch die Arbeit nicht ausgeht ;-) Gruß, brunowe
Bruno We schrieb: > Ist dir eigentlich schon einmal aufgefallen, das bei invertierter > Signaldarstellung die ADC Kalibrierung nicht mit berücksichtigt, bzw. > nicht mit invertiert wird... was natürlich völliger Quatsch ist. Hi Bruno, ja das ist mir auch schon aufgefallen (läuft bei mir noch unter minor bugs). Der Ort des Geschehens ist auch schon klar. Die Invertierung wird nicht wie man vermuten könnte nach dem Auslesen des ADC berechnet sondern direkt in dieser (Assembler) Routine. Leider hat der Programmierer bei dieser Routine vergessen die Korrektur zu berücksichtigen. Da die Assemblerroutinen etwas schwieriger zu verstehen sind wollte ich nicht mitten im Fehlergesuche noch einen eventuellen weiteren Fehler einbauen. Daher hab ich das erstmal vor mir hergeschoben. Bei meiner Suche nach dem Freeze-Bug bin ich übrigens auf eine weitere Baustelle gestoßen, die auch die offiziellen FW betreffen. Ich werde im FW-Thread darüber berichten. Gruß Hayo
Hallo Leute Habe mir jetzt auch ein W2024A geleistet :-) Hardw.:8c7.0L, SV.:1.4 Weis jetzt nicht ob das der richtige Thread für Fehler ist, aber schreibe mal meinen rein. 1.)Ab 5us kommt am Kanal 3 und 4 nur misst (bei 10us ist es noch Ok) 2.)Auch stellt Kanal 3 und 4 die Frequenz am LCD mit zu hoher Frequenz dar. Org. 100Hz, Darstellung = 312khz ?! (Eingang auf 1V/div) Das ganze mit original 1.4 SW (muss mich erst durch die ganzen Dokus zum updaten durchkämpfen ;-) ) Macht weiter so :-) Ganz toll!! l.G. Roberto
Angehängte Dateien:
-
New_Protected_Flash.JPG
160 KB
So, der Fehler ist draußen, das soll mir mal einer erklären... Jetzt kann ich wieder sinnvoll weiter testen. Aber, da ich nun auch die original FW drauf habe, ist das Rauschen auch wieder bedeutend stärker geworden- speziell auf Ch2 zu erkennen. Wenn man so list, (und aus Erfahrung selbst täglich erfährt) welche halbherzig entwickelten Geräte Wittig da auf den Markt wirft, könnte man es fast bedauern das wir mit unserem Engagement und unseren Verbesserungen auch noch den Verkauf ankurbeln! Echt schade das von Wittig/ Welec keine Resonanz kommt- Offensichtlich ist denen alles außer ihrem Umsatz egal. Gruß, brunowe
Hi Bruno, ich hab nochmal bei mir getestet, den Phasenfehler kann ich bei mir nicht feststellen - und eine Erklärung dafür hab ich auch nicht. Falls aber irgendjemand Flashdumps braucht, ich stelle gerne alles zur Verfügung von Protekted Config über Config bis zum Komplettdump. Alles vom neuen W2014 welches ich vor zwei Wochen geschossen habe. Gruß Hayo
Wieso keine Resonanz? In der Verstärkerstufe ist schon mehr als genug Resonanz drin ;-) Aber die haben auch besseres zu tun als an den alten, verpfuschten Geräten zu basteln: http://oszifox.com
Hallo Bruno We, liegt es nicht vllt. einfach daran, dass beim neuen Bild der 2. Kanal aktiviert ist? Dann hat doch jeder Kanal nur noch 2 ADC für sich. Gruß, Guido
ja, bei dem kleinen handgerät kann man auch nicht so viel verkehrt machen :-)
>jeder Kanal nur noch 2 ADC für sich.
wie kommst du denn darauf? jeder kanal hat 4 eigene adc's
Oszifox- das hört sich interessant an- vor allem das da jetzt Head Office Europe in Italien steht. Man kann nur hoffen das dieses Gerät besser abgekupfert wurde als die W2000 Serie. Diese OsziFox waren einmal "RadioShack ProbeScope 22-310" @Guido: Oje, Oje Gruß, brunowe
Kurt Bohnen schrieb: > Aber die haben auch besseres zu tun als an den alten, verpfuschten > Geräten zu basteln: http://oszifox.com Ups, wird da gerade umfirmiert oder war es das jetzt? Könnte es sein dass wir die letzten seiner Art ergattert haben? @Guido wie Sunny schon sagt - jeder Kanal hat ein vierer Set an ADCs die so gekoppelt sind, dass sie phasenverschoben abtasten (kann man auch gut auf der Platine sehen). Jeder läuft bei der maximalen Abtastrate mit 250 MSa/s macht insgesamt 1GSa/s. Wenn jetzt einer der ADCs nicht korrekt in Phase angesteuert wird kann das Phänomen auftreten welches Bruno erlebt hat. Es kann natürlich auch sein, dass die ADCs alle korrekt in Phase arbeiten, aber die Reihenfolge beim Auslesen durcheinanderkommt. Dann sieht es nämlich genauso aus. ein Beispiel: wenn die Werte eigentlich 1,2,3,4 sind (also eine ansteigende Gerade) aber die Werte 3 und 4 des ADC vertauscht sind, dann hat man an jedem vierten Pixel einen Peak (1,2,4,3 - 5,6,8,7 - usw.). Je stärker die Steigung, desto höher der Peak. bei einer flachen Linie fällt es dagegen überhaupt nicht auf. Gruß Hayo
@Bruno vielleicht hat ja auch Oszifox WELEC aufgekauft weil sie kein konkurenzfähiges Modell hatten und übernehmen jetzt das W20xx. Man darf gespannt sein. Gruß Hayo
Hallo an alke, mein W2024A ist aus Italien geliefert worden. Von der ob genannten Adresse. Ich denke Oszifox ist von Wittig. Siehe: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" lg Robert
Hallo, Asche auf mein Haupt. Ich war davon ausgegangen, dass insgesamt 4 ADCs vorhanden sind. Ihr habt natürlich recht, habe auf SF wieder für mich Neues gefunden. Gruß, Guido
Also das Wittig von OsziFox aufgekauft wurde glaub ich nicht, weil: 1.) OsziFox scheint nur der Name des Produkts zu sein. 2.) Auf Jeder Domain Oszifox.com, OsziFox.eu, und OsziFox.de prangert groß das Wittig Symbol. Da das OsziFox (wieder) unter dem Namen Wittig läuft frage ich mich viel mehr- WAS iST MIT WELEC LOS? Auch für Rücksendungen der W2000 Serie wichtig- im Garantiefall.
Dieses OsziFox wird anscheinend von Picotechitaly hergestellt: http://picotechitaly.8k.com/oszifox1/oszifox.html
Beindruckende Einstellung die Welec/Wittig da an den Tag legt. Das Eine läuft noch nicht mal richtig, da mischt man schon am Nächsten herum, getreu dem Motto: "Wenn was nicht klappt, fang was Neues an, vielleicht klappt das ja auch nicht". Wenn das jeder so machen würde, dann würde bald nichts mehr funktionieren. Gruß, branadic
Naja, nach 3 Jahren erfolglosem rumdoktern an der W2000/ W2000A Serie hätte ich auch das Handtuch geschmissen. Aber dann wieder unter dem gleichen Namen was auf den Markt zu werfen ist.... naja nennen wir's mal mutig.
Bruno We schrieb: > Ist dir eigentlich schon einmal aufgefallen, das bei invertierter > Signaldarstellung die ADC Kalibrierung nicht mit berücksichtigt, bzw. > nicht mit invertiert wird... was natürlich völliger Quatsch ist. Übrigens ist Dir aufgefallen, dass dieser Fehler auch im Averaging Betrieb auftritt? Der wird nämlich auch in besagter Assemblerroutine mit abgefackelt. Wer sich berufen fühlt - das Coding findet Ihr im Anhang - der möge sich betätigen. Gruß Hayo
>Wer sich berufen fühlt - das Coding findet Ihr im Anhang - >der möge sich betätigen. Ohha. Ich schau mal drüber ;-) Gruß, Stefan
Hallo Leute Könnte bitte jemand probieren: An Kanal 1 und 4 ein 10Hz Signal anschließen.(Sinus) Bei mir verändert sich der Sinus beim drehen Schrittweite(Frequenz/diff), nur auf Kanal 1. Auf Kanal 4 sieht man immer die gleiche Schwingung (Schwingweite) Ab 5us/Div spinnen dann Kanal 3 und 4 sowieso..!! :-( Kanal 3 und 4 wird immer um das vielfache von Kanal 1(2) dargestellt ?! Gerät W2024A SW.:1.4, Hardw.: 8c7.0L Ich werde das Gerät zurückgeben.. :-( l.G. Roberto
Hallo Roberto, das von der originalen FW nicht all zu viel zu erwarten ist hast du mitbekommen? Schon mal ein vollständiges FlashDump durchgeführt und Hayo's aktuelle FW aufgespielt? Vielleicht sieht das danach deutlich besser aus? Das für das Geld kein Tektronix erwarten kannst sollte dir ja sicherlich klar sein. Gruß, branadic
Roberto schrieb:
> Ich werde das Gerät zurückgeben.. :-(
Bevor Du das Gerät zurückgibst mach doch das was Branadic schon
vorgeschlagen hat - sichere alles und spiel mal die aktuelle beta auf,
vielleich gefällt Dir ja was Du siehst. Nur soviel, es kommt noch
einiges dazu, was die originale FW nicht zu bieten hat.
Gruß Hayo
Ach ja noch was, um die Alternativen aufzuzeigen: Entweder Du legst erheblich mehr Geld an, dann darf es auch ein Agilent oder Tek sein - ok ist eine andere Klasse, oder Du kaufst was Chinesisches (Owon und ähnl.). Da hast Du aber bei gleichem oder mehr Geld ein schlechteres Display und auch keine Garantie das alles läuft - und vor allem keinen Open Source Support. Daher wäre für mich die erste Variante die einzig akzeptable Alternative. Gruß Hayo
Hallo Brandic >Vielleicht sieht das danach deutlich besser aus? >Das für das Geld kein Tektronix erwarten kannst sollte dir ja sicherlich >klar sein. Das ist klar ! Ich würde auch mit ein bisschen rauschen zufrieden sein... Ich bin mir schon bewusst von dem Preis Leistungs-Verhältnis :-) Mich würde interessieren, ob dieser beschriebene Fehler von der Soft oder von der Hardware kommt? Gibt es dazu schon andere Berichte? (Bitte neue DSO-Erwerber melden!!) Danke einstweilen :-)
Roberto schrieb: > Mich würde interessieren, ob dieser beschriebene Fehler von der Soft > oder von der Hardware kommt? > Gibt es dazu schon andere Berichte? (Bitte neue DSO-Erwerber melden!!) Dazu müßte ich meinen Flashdump zurückspielen, zur Zeit hab ich die 1.4 nur auf dem W2022 für Vergleichszwecke laufen. Auf dem W2014 hab ich meine 0.61 beta laufen, und da tritt der Fehler nicht auf wie ich gerade überprüft habe. Gruß Hayo
Hi Roberto, es ist nur zum Teil ein Hardwareproblem: Wenn Du den Thread verfolgt hast, wirst Du sehen, dass in der Eingangsstufe noch etwas Optimierungspotenzial liegt... Der Hauptgrund für die schlechten Werte liegt aber sicher in der ungenügenden Firmware - naja, ein Entwicklungsteam kostet halt mehr als nur ein Entwickler. Hayo (& Co) sind sicherlich auf dem richtigen Weg. Ich hatte auch überlegt, mein 2024A wieder zurückzugeben. Inzwischen bin ich aber Hayo's Ansicht, dass man mit einer Open Source Firmware sicherlich Einiges reißen kann. Für den Hobbybereich sollte es dann reichen. Ich arbeite nicht häufig genug mit dem Gerät, sodass sich ein Profi-Scope von daher erübrigt. Mit viel Aufwand hatte ich mir mal vor jahren ein externes DSO gebaut (LPT-Port, 60 MS/s, alte Cache-RAMs aus den 486er Boards,...). Der Aufwand war erheblich und das Ergebnis nicht annähernd so gut wie das W2024 (mal abgesehen von der Qualität ein 'autonomes' Scope zu haben). Michel
@Michel Jo, so ist es. @Roberto Du solltest auf jeden Fall prüfen ob es ein Hardwarefehler ist. Dann auf jeden Fall tauschen das Teil. Ansonsten wenn es ein Softwarefehler ist, dann sollte es auch bei anderen auftreten und dann empfehle ich mal die nächste beta von mir aufzuspielen - kommt heute oder morgen. Gruß Hayo
Angehängte Dateien:
-
Kanal3_4_Fehler.jpg
73 KB
Hallo Hayo Ich habe mal ein Bild angehängt.(leider ein bisschen unscharf) Signal = 100kHz auf Kanal 1 und 3 Linkes Bild bei 10us/Dif und rechtes Bild bei 5us/Dif Ab 5us/Dif , spinnt Kanal 3 und 4 ganz! Vorher zeigt er eine vielfache Frequenz von Kanal 1(2) an Ich glaube das liegt an der Hardware... :-( l.G. Roberto
Man sieht leider keine Details. Hast Du schon mal das Default Setup aufgerufen? Erkenne ich das richtig, dass die Aufnahmen mit einer meiner Betas gemacht wurde? Hast Du alle anderen Einstellungen mal durchgespielt? Wenn ja und ja und ja, dann sieht es nicht so gut aus. Sowas wie bei Dir hab ich bislang noch nicht gesehen. Dann also Flashdump wieder zurückspielen und das Teil zurück an WELEC schicken. Vorher per Mail nach den Versandmodalitäten erkundigen. Gruß Hayo
Hallo, ich hab meine ein kleines Video über das oszillieren auf YouTube gestellt. Für Alle die dieser Effekt noch gar nicht aufgefallen ist. Leider schaff ich es nicht dieses oszillieren messtechnisch zu erfassen. Wenn ich an den einzelnen Stages der analogen Verstärkung messe, ist das Signal jeweils stabil (am Messoszi)- die chaotische Anzeige des Welec ändert sich nicht. Kann es vielleicht irgendein Timing Problem beim Auslesen der Daten vom ADC sein, oder an einer anderen Stelle der digitalen Verarbeitung??? Es ist einfach sehr seltsam das ich diese Oszillation nicht messen kann- Vorschläge? http://www.youtube.com/watch?v=wo5eUZIkU5w&feature=channel_page Gruß, brunowe
Sowas wie dort von dir beschrieben kenne ich nur, wenn man einen ADC "überfährt", sprich wenn man ein Einganssignal anlegt, welches größer als der maximal digitalisierbare Wert ist. Der Effekt ist v.a. bei Digitalendstufen nett anzuhören... ;-) /Hannes
ja, Übersteuerung... das ist aber nicht der Fall- obwohl dieser Effekt stark daran erinnert und auch genauso aussieht.
Angehängte Dateien:
-
rechteck2.jpg
190 KB
Hallo, da ich ganz unverhofft auch Feiertag hatte, habe ich mich mal wieder etwas um die Hardware gekümmert, die hochfrequenten Schwingungen stören mich halt auch. Lesen bildet und das Datenblatt des AD8131 beschreibt solche Störungen eigentlich schon, für den Fall kapazitiver Lasten. Die A/D-Wandler haben eine Eingangskapazität von 9 pF, parasitäre Kapazitäten kommen noch hinzu. Mittlerweile habe ich ja gelernt, dass 4 solcher Wandler pro Kanal parallel geschaltet sind und mehr als 40 pF sind in diesem Bereich absolut nicht mehr vernachlässigbar. Im linken Bild sieht man den Erfolg bei einem steilflankigen Rechteck mit 20 MHz. An den Flanken treten die bekannten Schwingungen auf. Das Datenblatt empfiehlt Widerstände von 24 Ohm in die Anschlussleitungen einzufügen, also habe ich für Kanal 1 die 0-Ohm-Widerstände durch welche mit 22 Ohm ersetzt. Das Resultat zeigt das mittlere Bild, es gibt noch deutliche Überschwingungen aber grundsätzlich wirkt die Maßnahme. das rechte Bild als Vergleich mit dem Tek TDS210 (60 MHz). Das ist noch nicht optimal, aber die Bandbreite wird dadurch, gemessen bis 100 MHz, nicht wesentlich geschmälert. Als nächstes müsste man noch einen Abschlusswiderstand ergänzen, der AD9131 soll mit 220 Ohm abgeschlossen werden. Das Layout dieses Teils ist etwas ungewöhnlich (für die Frequenz), das Signal wird von ADC zu ADC geschleift, wobei mehrmals der Layer gewechselt wird. Auch ist die Leitungsführung viel zu lang. Bei Gelegenheit suche ich mal den "hintersten" ADC raus, an dem könnte man sicher einen Abschlusswiderstand an die Vias anlöten (Eingangswiderstand der ADC berücksichtigen!). Gruß, Guido
Hallo Guido, genau genommen empfiehlt das Datenblatt 25 Ohm nur weil es die nicht gibt nimmt man 24,9 Ohm aus der E96-Reihe. Sei es wie es will, du hast eindeutig eine Verbesserung durch diese Maßnahme erzielt. Allerdings ist das immer noch "jwd" von dem was auf dem Tek dargestellt wird. Ich denke an dem Layout sind auch noch einige Fehler zu suchen, die sich nicht mehr beseitigen lassen werden. Offensichtlich hat es ja auch nicht mehr für ein Redesign der Platine gereicht, da man im großen Stil nachträgliche Leitungen eingelötet hat, auch wenn es sich hierbei "nur" um Versorgungsspannungen handelt. Aber von der Schaltungstechnik selbst ist offenbar doch noch was machbar. Witzigerweise sind ja auch einige Widerstände nachträglich gebrückt worden. Vielleicht sollte man diese auch mal näher mit berücksichtigen, ob das nicht vielleicht eine kontraproduktive Maßnahme war. Gruß, branadic
Hallo Guido, vielleicht für alle zum Festhalten, könntest du anhand dieses Bildes kurz zeigen, welche Widerstände du getauscht hast? http://welecw2000a.sourceforge.net/docs/pcb/input.JPG Beste Grüße, branadic
Angehängte Dateien:
-
input.JPG
800 KB
Hallo branadic, Widerstände gebrückt? Ist mir noch garnicht aufgefallen, das muss ich mir noch genauer anschauen. Nach meiner Vermutung war die heilige Kuh für Wittig die Bandbreite. Die ist aber mit diesen Mitteln nicht zu halten. Schaut man in die Datenblätter der Bauteile findet man als Gemeinsames immer "very low cost". Die Änderung ist ganz limks in der Mitte. Gruß, Guido
Hallo Guido, diese beiden 0 Ohmer hab ich bei mir schon längst durch 11 Ohm Widerstände ersetzt. Diese Maßnahme reduziert allerdings den Pegel an den ADC's und letztendlich auch die Bandbreite, aus diesem Grund habe ich diese Möglichkeit nicht weiter verfolgt. Die Kapazität der ADC spielt bestimmt eine entscheidende Rolle bei diesen Überschwingen, ist aber nicht die einzigste Problemstelle. Versuchsweise hab ich auch schon einmal ein Signal direkt nach dem R20 eingeschleift (also nach dem OPA656), das bringt ebenfalls eine gewaltige Verbesserung, aber auch keinen Durchbruch. Derzeit warte ich noch auf eine FW- Testversion in VHDL (Crazor!) um evtl. Berechnungsfehler bzw. Timingprobleme im Assemblercode der original FW endgültig ausschließen zu können... Vor den Eingänge der ADC hab ich zu Testzwecken auch schon einmal mit einem LPF (Grenzfrequenz ca. 200MHz) experimentiert- bringt auch eine geringe Verbesserung, aber keinen Durchbruch. Irgendwie sind wir von einer echten Optimierung, welche nicht auf Kosten der BW geht, noch weit entfernt... Gruß, brunowe
Hi, ich bin zwar nicht der absolute Hardwarefreak und ich hab' auch keine Vorstellung davon in wieweit sich das mit dem vorliegenden Layout machen lässt. Aber wäre es nicht eventuell eine Möglichkeit die vier ADC dadurch zu entkoppeln, daß man die ADC jeweils getrennt durch ja zwei mal 24 Ohm ansteuert? Gruß, Günter
Hallo Günter, du bist "zwar nicht der absolute Hardwarefreak", hast aber bessere Ideen als die Entwickler von Wittig ;-). Auf der Platine lässt sich das aber wohl nicht realisieren. @ Bruno We: Ist immer die Frage, was du unter der Bandbreite verstehst. 200 MHz sind mit der vorliegenden Schaltung und dem Layout nicht zu wollen. Die 25-Ohm-Widerstände machen da noch am wenigsten, das ergibt eine Zeitkonstante unter 2 ns. Ich versuche erstmal nur einen 20-MHz-Rechteck vernünftig darzustellen, höhere Ansprüche lass ich erstmal bei Seite. Aber schon für diesen liegen die Oberwellen im UHF-Bereich und danach sieht das Layout wirklich nicht aus. Eine relevante Signalabschwächung bekomme ich durch die Widerstände nicht, die kommt aber wenn ein vernünftiger Abschluss hinzukommt. Das kann eigentlich nur vom OPA ausgeglichen werden, wodurch natürlich wieder die Bandbreite sinkt. Klar, ich weine deswegen nicht, weil ich nur für ein 100-MHz-Gerät bezahlt habe, aber besser wird es höchstens durch eine komplett neue Eingangsschaltung. Gruß, Guido
>Auf der Platine lässt sich >das aber wohl nicht realisieren. Warum eigentlich nicht? Irgendwo muß die Leierbahn zu den einzelnen OVs doch mal oben und ein Stück gerade verlaufen.... 2 x durchkratzen + Enden vom Stoplack befreien + 2 x Rs draufpappen Ok, zugegeben, nur für einen Test ein recht harter Eingriff....
>Warum eigentlich nicht? Irgendwo muß die Leierbahn zu den einzelnen OVs >doch mal oben und ein Stück gerade verlaufen.... 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, Guido
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???