mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wittig(welec) DSO W20xxA Hardware


Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur kräftig ziehen. ;-)

Autor: Broma.es (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry wegen schlechtem deutsch, bin Spanier und beobachte Welec 
Entwicklung.
Habe diesen LInk gefunden: 
http://apps.sourceforge.net/phpbb/welecw2000a/view... 
das ist gute Nachricht für alles Welec Oscilloscope Besitzer!
Hoffe mit euch auf gute Fortschritte bei Entwicklung-
Grusse
Broma

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=MDY...) und 
eingelötet, da hat man auch ein besseres Drehgefühl...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Broma.es:

Schau mal auf das Post-Datum, dann geht Dir vermutlich ein Licht auf :-D

Autor: Carlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael

Deutschland 01.04 = Spanien 28.12

;-)

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein Scope mit der alten Aufschrift W2014
Vielleicht kann es jemand gebrauchen

Hardware 8C7.0H
Software 1.4

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Bechtel (christophbechtel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: PycLan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allem,
Hier hat die Fotografien mit den Unterschieden PCB W2022A und W2012 
(ohne А) ausgestellt.
http://foto.ixbt.com/?id=album:19438

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann, viel Erfolg!

Schöne Ostern,

egberto

Autor: Rainer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wer sich schon mal meine ersten Messergebnisse ansehen möchte, ich hab 
sie unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/...
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An den OPs scheinen wirklich keine KerKos zu sein!?

Viele Grüße,

egberto

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte nat. OVs heißen.....

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Pfau (andreaspfau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

bei mir ist soeben das W2024 eingetroffen. Wenn ich beim Testen 
irgendwie helfen kann, bitte ich um kurze Nachricht.

/Hannes

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon125 (Gast)
Datum:
Angehängte Dateien:
  • preview image for 1.jpg
    1.jpg
    205 KB, 970 Downloads

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter D. (bigone)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, andere als die oben beschriebenen "Software-Spikes" habe ich auch 
nachlängerer Zeit nicht finden können.

Viele Grüße,

egberto

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dito.

/Hannes

Autor: Johannes S. (demofreak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sehen die Dinger hier aus.

/Hannes

Autor: Johannes S. (demofreak)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
(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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat bei mir nicht "geklappt".

Guts Nächtle,

egberto

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie versprochen habe ich heute schon mal ein paar Messergebnisse 
veröffentlicht.
http://apps.sourceforge.net/trac/welecw2000a/wiki/...
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter D. (bigone)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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/Measuremen...

Gruß, brunowe

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal wieder die Frage des Laien ;-) - warum  haben die denn da nicht auch 
ein Relais genommen?

Viele Grüße,

egberto

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
echt? das muss dann ja schon ewig her sein. die 4051-4053 beispielsweise 
gibt es doch schon seit urzeiten.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@guido
stimmt, du hast recht. ich hab die eingänge verwechselt. die 
analogschalter schalten genau anders herum als von mir vermutet. schade, 
also weitersuchen.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Measuremen...

Gruß, brunowe

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo und Guido,

ist schon ok - dann frisch ans Werk ;-)
(und Danke für das bis jetzt gemachte!)

Viele Grüße,

egberto

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier für alle die kein LTspice haben wenigstens etwas zum ansehen.

Gruß, brunowe

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS.: "Vorbereitung" klingt jedoch komisch...

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> mit Vorbereitung ist wahrscheinlich das Reworking gemeint.

Das Reworking von Non-A zur A Version?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Teplotaxl X. (t3plot4x1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Teplotaxl X. (t3plot4x1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr die Firmware komplett neuentwickelt, oder die alte 
reverseengineert und verbessert?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Crazor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@sunny + Guido

Bin momentan etwas busy, dummerweise muß ich auch noch Kohle verdienen.

Melde mich morgen dazu.

Gruß Hayo

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alles klar, danke dir.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo sunny,

bitteschön. Hoffe es funktioniert, zum Testen habe ich
keine Lust.

Gruß, Guido

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!
Das nenne ich mal fix

Gruß,
brunowe

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für deine hilfe guido. ich teste sie dann morgen. muss jetzt in 
die heia :-)

Autor: Kurt Bohnen (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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....

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Umtausch meines W20x2 gegen ein W20x2A hatte Wittig das Paket 
abholen lassen.

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich soll das Gerät unfrei zurückschicken und bekomme dann ein neues.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sunny + Guido

Haut das hin mit der modifizierten FW oder soll ich ich da noch was 
machen?

Gruß Hayo

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hayo
ich hab guido's FW gerade aufgespielt und alles haut hin.

@guido
danke noch mal für deine hilfe!

gruß sunny

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo sunny,

schön dass es klappt. Dann wünsche ich viel Erfolg.

Gruß, Guido

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, bei dem kleinen handgerät kann man auch nicht so viel verkehrt 
machen :-)

Autor: sunny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>jeder Kanal nur noch 2 ADC für sich.
wie kommst du denn darauf? jeder kanal hat 4 eigene adc's

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses OsziFox wird anscheinend von Picotechitaly hergestellt:
http://picotechitaly.8k.com/oszifox1/oszifox.html

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Roberto (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Youtube-Video "Ringing on Welec oscilloscope W2000A"

Gruß, brunowe

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, Übersteuerung...
das ist aber nicht der Fall- obwohl dieser Effekt stark daran erinnert 
und auch genauso aussieht.

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bilbo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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....

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bilbo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damals (TM) habe ich das mal an einem DVD-Player gemacht - QFP-Bein 
angehoben und den R hochkant drunter gelötet.....

Autor: Robert (Razer) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hier mein versprochenes Video:

Youtube-Video "Ringing on Welec W2000A oscilloscope- Test with new VHDL Design"

Bin mal gespannt was unsere Programmierer dazu sagen!
Meine Folgerung aus dem Video:
Die Oszillationen welche ich in 
Youtube-Video "Ringing on Welec oscilloscope W2000A"
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.

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon recht Günter, allerdings hilf uns das an dieser Stelle nicht 
wirklich weiter. Bin aber noch dran.

Gruß, branadic

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
heißt also, Hardwaremodifikationen sind (bis auf absolutes Finetuning) 
überflüssig?
Nur buggy Software (FPGA)?

Viele Grüße,

egberto

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Crazor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. B. (branadic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,

Hier noch die versprochene Rauschmessung an den ADC-Pin REFIO.

Man sieht das man nichts sieht ;-)

Gruß, Brunowe

Autor: Günter Jung (gjung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag ;-)
1.) Code hat 75163 Zeilen,  2.) Code hat 67483 Zeilen

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 1KHz würde ich auf Rechteckgenerator tippen. Brauchst auf die 
Schnelle eine FW ohne Rechteckgenerator? Dann schau ich mal.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Finde leider auf die schnelle nichts. Ich würde aber mal messen, ob das 
Rauschen in Phase ist mit dem Rechteckgenerator.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bruno,
gibt es schon Neuigkeiten von dem Schirmblech?

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael W. (slackman)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Kurt,
dies hier?

Michel

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, Danke!

Autor: Crazor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bruno

Ich wäre auf jeden Fall an zwei Blechen interessiert.

Hayo

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte auch an einem Interesse.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme auch eines.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich auch!

Gruß, Guido

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jupp,
ich bin mit einem Blech dabai :-)

Michel

Autor: Johannes S. (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mi tu. :D

/Hannes

Autor: Uwe S. (us1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen,
ich würde auch eins nehmen.

Uwe

Autor: Sebastian B. (sebbra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte auch interesse an einem Blech.

Sebastian

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael,
ich hätte Interesse an einer Tasche.

Läuft mittlerweile die Sache mit dem FPGA? (anderes Kabel)

Autor: O. Ga (entw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte interesse an einem Blech.

Ol.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bruno,

ich habe Interesse an zwei Schirmblechen.

Gruß Jürgen

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: devo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
möchte auch mein Interesse an einem Schirmblech anmelden.
Detlev

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert