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


von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo werte W20xxA Besitzer und Interessierte!

Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread

Beitrag "Wittig(welec) DSO W20xxA Hardware"

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"

So hier noch eine kleine Wortliste damit der Thread auch von Google
gefunden wird:

DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A
W2024A

Gruß, brunowe

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

wie angekündigt hab ich heute die Abstrahlung eines W2022A im 
Frequenzbereich von 150kHz bis 1GHZ in einer Absorberkammer vermessen.

Gleich einmal vorweg... da ich beruflich mit solchen Messungen zu tun 
habe, ist mir schon einiges an nicht normgerechten Geräten 
untergekommen... Aber unser Welec hat selbst viele Geräte an 
Störaussendungen überboten, die erst in einem frühen Entwicklungsstadium 
sind.
SO WÜRDE ICH DAS W2022A NIEMALS FÜR DEN EUROPÄISCHEN MARKT ZULASSEN!!!
Mir ist wirklich schleierhaft, wie das Scope diese Messungen einst 
bestanden haben soll!

Aufgrund der unterschiedlichen Einsatzbereiche meiner Antennen musste 
ich die Messungen splitten. Der erste Bereich von 150kHz- 30MHz wurde 
mit einer Stabantenne gemessen. Der Bereich von 30MHz bis 1Ghz mit einer 
Antenne die ich üblicherweise für meine Messungen im Automotive Bereich 
einsetze.

Von 150kHz bis 30MHz sind laut Norm EN 55011 keine Grenzwerte definiert. 
Diese Messung gilt also rein informativen Zwecken. Auch ist der 
Absolutpegel dieser Messung nicht ganz realistisch (dieser liegt in 
Wahrheit  10dB höher).
Begründung: Niedrige Frequenzen werden bevorzugt von Leitungen, nicht 
vom Gerät abgestrahlt. Unsere Messleitungen (Tastköpfe) entsprechen 
nicht der normativen Länge für diese Messungen.
Die gemessene Differenz des Absolutpegels lässt sich somit u.a. durch 
den höheren Abstand des "Strahlers" Oszilloskop von der Antenne im 
Vergleich zu der Messung bei 30MHz bis 1GHz erklären.


Im Anhang erst mal ein paar Fotos vom Messaufbau zur Einstimmung.

von Bruno W. (brunowe) Benutzerseite



Lesenswert?

Hallo,

jetzt gehts ins Eingemachte...

Angefangen hab ich mit ein paar Vergleichsmessungen, um die Auswirkungen 
des Abschlusses der BNC Buchsen (Messeingänge)zu untersuchen.

Fazit: Egal, ob die BNC Buchsen mit 50Ohm, ob sie offen oder mit unseren 
Tastköpfen abgeschlossen sind, die Änderung der abgestrahlten Leistung 
ist minimal und daher zu vernachlässigen.
->Aus unseren Eingängen wird keine nennenswerte Leistung abgestrahlt! 
(Zum Glück für unsere Messobjekte!)

Auch hat die Polarisierung der Antenne kaum Änderungen am Gesamtbild 
aufgezeigt, was den Messaufwand schon mal halbiert hat.

Allgemeines zur abgestrahlten Leistung: In der EMV sind vor Allem 
Quasipeak, Peak und Average Werte von Bedeutung. Die entsprechende Norm 
verlangt eine Messung der Quasipeakwerte. Nur für diese sind Grenzwerte 
angegeben.

In den Auswertegrafiken sind die grünen Kurven jeweils der Average- 
Messwert, blau ist der gemessene Peak Wert ( bzw. der QP Wert im Anhang 
3).
Bei der Nachmessung (Anhang 4) repräsentieren die blauen Kreuze den QP 
Wert. Die rote Gerade (mit dem Knick) stellt das erlaubte Limit gemäß 
Norm dar.

Eine komplette Quasipeak Messung (QP) von 30MHz bis 1GHz mit nur einer 
Polarisation dauert ca. 5 Stunden! (Wen interessiert warum das so ist, 
empfehle ich Wikipedias Definition des Quasipeak- Wertes)
Für die Praxis bedeutet das, es wird der Average Wert und der Peak Wert 
gemessen und nur die kritischen Frequenzen (solche die über -6dB unter 
dem zulässigen Grenzwert liegen) werden einzeln nachgemessen.
Mit diesem Verfahren lässt sich die Messzeit auf ca. 20-25min pro 
Polarisation verkürzen.
Zum Vergleich hab ich dennoch mal einen kurzen Teil-Scan mit QP 
erstellt.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Nun noch der Teil mit den Messergebnissen von 150kHz bis 30MHz.
Wie bereis geschrieben gibt es für diesen Bereich keine Grenzwerte für 
radiated emission.
Ich hoffe auch diese Grafik ist mit dem oben Geschriebenen ausreichend 
erklärt.
Als nächstes will ich noch die Störungen, welches unser Oszilloskop auf 
die Netzleitung zurückspeist, messen. Die conducted emission also. 
Niederfrequente Störungen werden sich, speziell wenn billige DC-DC 
Wandler eingesetzt wurden, massiv auf diese Weise zeigen.

Kommentare zu den Messungen sind herzlich willkommen.

Noch ein Nachtrag: aus vorigem Anhang mit den Nachmessungen lassen sich 
gut die exakten Frequenzen der Störungen ablesen. Evtl kommt uns die ein 
oder andere Frequenz davon bekannt vor? Markant sind natürlich immer die 
exakten Frequenzen wie z.B. 150MHz und der Oberwellen (300MHz, 
450MHz...). Wahrscheinl. basiert das Ganze sogar auf den gemessenen 
49,98MHz. Eine gewisse Frequenzabweichung ergibt sich hier durch die 
Messbandbreite von 120kHz. Normalerweise misst man solche Stellen dann 
einzeln nach, um bereits bei der Geräteentwicklung solche Problemstellen 
identifizieren und beseitigen zu können.
...Das wurde bei unserem Scope wohl verpennt?

So, erst mal genug für heute.

Gruß, brunowe

von Jörg H. (idc-dragon)


Lesenswert?

25 MHz sind der Grundtakt, mit dem die FPGAs laufen und aus denen sich 
auch das Timing der externen Speicher ableitet. Eine Spitze in dem 
Bereich kann ich mir gut vorstellen.

Jörg

von Guido (Gast)


Lesenswert?

Hmmh,

die 150 kHz bis 30 Mhz sehen ja sauber aus. Normalerweise werden
die doch nur leitungsgebunden geprüft? Womit öffnet man die rtf-Dateien?

Danke für die Messungen, toller Arbeitsplatz! Guido

von Bernhard M. (boregard)


Lesenswert?

Guido schrieb:
> Womit öffnet man die rtf-Dateien?

OpenOffice (oowriter) bzw. LibreOffice....

von Bruno W. (brunowe) Benutzerseite



Lesenswert?

Hallo,

mein Rhode und Schwarz EMC32 Programm erstellt die Reports direkt im 
rtf- Format. Gestern hat die Umwandlung in pdf irgendwie gezickt...
Heute ging das seltsamerweise problemlos...hier also die Testreports im 
pdf.

@Guido: es gibt einen gewissen Bereich in dem beide Messarten erlaubt, 
bzw. auch verlangt werden.
Momentan führe ich z.B eine leitungsgebundene Störspannungsmessung von 
30MHz bis 108MHz für die Automobilindustrie durch. Für das gleiche 
Produkt ist aber auch eine RE Messung ab 150kHz (bis 2,9GHz) angesetzt.

Gruß, Bruno

von Jörg H. (idc-dragon)



Lesenswert?

Ich untersuche im Ramen von Osoz gerade, was unser Welec beim Capturing 
eigentlich anstellt, mit den 4 versetzten ADCs bei 1GSa Abtastrate.

Das ist ganz interessant buggy, auch abhängig vom FPGA-Bitstream. Mir 
sind 2 Versionen bekannt. Mein Scope kam mit 8C7, seit ich es 
umprogrammieren kann habe ich mit 1C9 rumgespielt. So wie die Abfragen 
in der alten Firmware programmiert sind ist 8C7 die neuere FPGA-Version.

In Osoz habe ich einen Testbutton eingebaut, der die Rohwerte auf die 
RS232 rausschreibt. Mit Excel etwas aufbereitet kommen dann solche 
Bilder raus wie im Anhang. Dargestellt ist eine steigende Flanke, 
absichtlich keine allzu schnelle. Ich habe die Meßwerte der 4 ADCs 
zyklisch eingefärbt, so sieht man gut wer welchen Beitrag leistet. Das 
sind Rohwerte, absichtlich ohne Offsetkompensation zueinander. Im Ein- 
uns Auslauf sieht man diese Fehler als horizontales zyklisches 
"Geklingel".

Mit FPGA v1C9 ist ADC1 (blaue Rauten) etwa 8 Samples zu früh dran. Ich 
habe ihn im zweiten Bild um 8 Samples nach rechts verschoben, dann paßt 
es schon besser. ADC2 (rote Quadrate) liefert ein schlechtes Signal. Ich 
habe den Eindruck es gibt da eine Hold Time Violation zum FPGA und 
mindestens ein Bit bestimmter Wertigkeit kippt gerne. Wenn ich die 
Nullinie mit dem Offset herumschiebe merke ich auch das es Positionen 
gibt, wo das +/-1 Rauschen bevorzugt Ausreißer zeigt, ich glaube um 16 
Pixel. Von daher kann man sich die Bitnummer schon ausrechnen...

Ich vermute das FPGA filtert intern noch, weshalb die Ausreißer auch die 
Nachbarschaft beeinträchtigen, allerdings nur innerhalb desselben ADCs.

Mit FPGA Version 8C9 sieht das Bild anders aus. Es ist natürlich nicht 
das identische Capturing, nur ein ähnliches.
Nun benimmt ADC2 sich ordentlich, überhaupt sehen alle ADCs gut aus. Es 
gibt einen anderen zeitlichen Versatz. Für das letzte Bild habe ich ADC2 
um 8 Samples und ADC1 um 4 Samples nach rechts verschoben, der Dateiname 
deutet es an. Dann liegen sie einigermaßen übereinander, der Rest könnte 
dem Offset-Geklingel entsprechen.

8C9 ist zumindest in diesem Belang und auf meinem Gerät die bessere 
Version.

Apropos Offset, damit habe ich auch experimentiert. Mit einer reinen 
Offsetkompensation der ADCs zueinander sah es immer noch nicht richtig 
gut aus. Der Offset ist sozusagen pegelabhängig. Oder anders 
ausgedrückt, die ADCs haben etwas zueinander abweichende Kennlinien. Ich 
überlege, ob man zusätzlich noch eine Skalierung aufnimmt, zur Laufzeit 
dann pro ADC eine Lookup-Table draus baut. Mit den Offset-DACs und 
kurzgeschlossenem Eingang könnte man die ADCs zur Kalibrierung 
durchwobbeln.

All diese Probleme gelten nur für Abtastraten >250MSa, darunter ist nur 
ein ADC in Betrieb. Der restliche Capture-Speicher Speicher im FPGA 
bleibt leider ungenutzt.

Jörg

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

heute habe ich die conducted emission Messungen mit meinem W2022A 
durchgeführt. Bei diesen Messungen wird das Scope über eine 50 Ohm/ 50 
μH Netznachbildung (LISN) angeschlossen und die leitungsgebundene 
Störspannung mittels eines EMI Receivers gemessen.

Die Referenzmessung zeigt den systembedingten Messfehler der 
Messanordnung auf. Hierbei war zwar die LISN angeschlossen, der 230VAC 
Ausgang aber nicht belastet.

Wo Grenzwerte definiert sind, hab ich diese eingetragen.
Ich hab auch Bereiche gemessen in denen keine Grenzwerte definiert sind 
(z.B. schon ab 9kHz)

Schön zu erkennen ist der einzelne Peak bei 25MHz, dieser "schafft" es 
allerdings nicht eine nennenswerte Störung des 230VAC Netzes 
hervorzurufen.

Unser Scope hätte nach den Vorgaben der EN 55011 die CE Messung 
bestanden.

Ich werde mir die Tage einmal überlegen, was man gegen die Störstrahlung 
unternehmen könnte und wo welche Frequenz abgestrahlt wird. D.h. ich 
werde einmal mit der Nahfeldsonde das Scope abtasten.

Gruß, Bruno

von Blue F. (blueflash)


Lesenswert?

Das sind ja interessante Neuigkeiten aus verschiedenen Richtungen.

Auch wenn ich Momentan nicht dazu komme mitzuwirken, bin ich als 
Mitleser immer dabei.

Zu Jörgs Ergebnis:

Da müßte man ja eigentlich die 1C9 Versionen auf 8C7 umschießen, um da 
noch etwas rauszuholen. Das müßte doch eigentlich machbar sein oder?

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Hayo W. schrieb:
> Da müßte man ja eigentlich die 1C9 Versionen auf 8C7 umschießen, um da
> noch etwas rauszuholen. Das müßte doch eigentlich machbar sein oder?

Klar kann man das. Habe ich heute morgen für die beiden hinteren Bilder 
auch gemacht, mein Scope wieder auf 8C7 zurückgeflasht.

Man braucht den unter Windows 7 knifflig zu installierenden Slog-Treiber 
und Quartus.

Vielleicht verhält sich die Hardware mit "besserer" 
Softwareinitialisierung ja auch noch unterschiedlich. Es gibt in dem 
Bereich magische Zahlen die in die ADC-Register geschrieben werden und 
die ich nicht verstehe. Teils kommen die eigentlich aus dem sog. 
Protected Flash, bei mir sind sie noch hart codiert.

Was ich noch vergessen habe zu fragen: ihr hattet meine ich doch auch 
schon verschiedene Grundlagenforschung betrieben?

Jörg

von Blue F. (blueflash)


Lesenswert?

Jörg H. schrieb:
> ihr hattet meine ich doch auch
> schon verschiedene Grundlagenforschung betrieben?

Ja, ist richtig. Einiges davon ist auf der W2000A Wikiseite zu finden, 
wenn ich mich recht erinnere. Auch zur Verschiebung der ADCs hatten wir 
schon Tests gemacht - aber noch keine endgültige Lösung gefunden da die 
FPGA-Versionen hier für etwas durcheinander sorgten.

Bei den Registerwerten habe ich auch schon herumexperimentiert, die 
aktuellen Lösungen findet man bei mir in der FW. Das Optimum ist das 
aber sicherlich nicht.

Jörg H. schrieb:
> Klar kann man das. Habe ich heute morgen für die beiden hinteren Bilder
> auch gemacht, mein Scope wieder auf 8C7 zurückgeflasht.

Dann kann man den 1C9 Besitzern eigentlich nur empfehlen Ihr FPGA auf 
8C7 upzudaten. Denn dann wäre wenigsten das übelste Spikeproblem 
behoben.

Die Frage ist in wie weit man die unterschiedlichen Versionen supporten 
kann um auf die gleiche Signalqualität zu kommen.

Hilfestellung zum FPGA-Update könntest Du dann ja sicherlich geben.

Gruß Hayo

von Roberto (Gast)


Lesenswert?

Hallo Brunowe (habs erst jetzt gesehen..)
Danke für die tolle Erläuterung...
l.G. Roberto

von Michael H. (stronzo83)


Lesenswert?

Hallo zusammen.

@Bruno
Danke für die interessanten Messergebnisse!
Es amüsiert mich, dass das Welec in Sachen leitungsgebundene Störungen 
besteht...denn das Schaltnetzteil ist ja ein Zukaufteil und nicht von 
den Wittigs entwickelt :)
Dass die radiated emissions übel aussehen müssen, ist einem bei einem 
Blick in die Kiste eigentlich klar - Toll, dass du das mit Daten 
untermauert hast.

@Jörg
Es macht Spaß, dir bei der Arbeit "zuzulesen": du gehst derart 
methodisch und fundiert an alles heran, dass es eine wahre Freude ist. 
Schnellschüsse oder Bastellösungen sucht man bei dir vergebens - 
wirklich vorbildlich.

Gruß
Michael

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo

@ Michael: stimmt, das SNT ist ja ein Zukaufteil, das erklärt die guten 
Messergebnisse ;)

Als erstes reiche ich noch ein Foto vom gestrigen Messaufbau (CE Tests 
mit unserem Welec) nach.

Heute hab ich mal eine RE Messung an einem "richtigen" Oszilloskop 
vorgenommen. Der Probant war ein TEK DPO 4054, 500MHz, 2,5GS/s.

Mich haben die Ergebnisse unseres Welec's einfach ziemlich schockiert 
und ich wollte mal sehen was ein gutes Gerät so abstrahlt....

Fazit: Es liegen Welten dazwischen, auch wenn ich bei dem TEK eine 
Schwachstelle lokalisieren konnte. Ich hoffe die im pdf eingefügten 
Fotos und die Erklärung dort machen das deutlich.
Aufgeschraubt hab ich das TEK nicht um meine Vermutung zu bestätigen. 
Das wäre bei einem normalen Gerätetest (Qualifizierung) der logische 
nächste Schritt....


@Jörg: Wenn ich mehr Ahnung hätte, von dem was du da treibst, dann würde 
meine Anerkennung bestimmt noch stärker ausfallen... Dennoch Respekt!

Gruß, Bruno

von Blue F. (blueflash)


Lesenswert?

Hi Bruno,

Du testest wie ich sehe ein 2-Kanalgerät. Ich könnte mir vorstellen, 
dass die 4-Kanaler sogar noch einen drauflegen,da ja zusätzlich 
Leitungen und Signale abstrahlen.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

ja da hast du bestimmt recht. Das Ergebnis war aber auch so erschreckend 
genug.
Bin heute auch schon mal mit der Nahfeldsonde an unser Oszi ran.
Die Vorderseite war relativ clean, abstrahlungstechnisch. Das lässt sich 
aber relativ einfach durch das Metall Chassis auf denen unsere Knöpfe 
und Drehencoder montiert sind, erklären. Besonders die 25MHz waren aber 
seitlich und auf der Rückseite gut zu messen.
Ich werde demnächst noch ein paar Fotos mit Messungen am offenen Herzen 
anfertigen ;)
Wenn Frequenzen dermassen stark abgestrahlt werden, so ist das ein 
sicheres Zeichen, dass entweder nur eine schlechte oder gar keine 
Schirmung vorhanden ist. Darüber hinaus ist auch wahrscheinlich, dass 
keine Massnahmen ergriffen wurden um die leitungsgeführte Ausbreitung 
der unerwünschten Frequenzen zu unterdrücken -> schlechtes Layout (ggf. 
schlechte Masseanbindung) , bzw. schlechtes Schaltungskonzept.

So langsam glaub ich, mit dem know how der Leute hier im Forum, hätten 
wir locker ein mindestens genauso gutes Oszi neu entwickeln können!
Wäre mal ne interessante Aufstellung was da an Entwicklungsarbeit und 
Kosten zu investieren wäre...

Gruß, Bruno

von Jörg H. (idc-dragon)


Lesenswert?

Bruno We schrieb:
> So langsam glaub ich, mit dem know how der Leute hier im Forum, hätten
> wir locker ein mindestens genauso gutes Oszi neu entwickeln können!
> Wäre mal ne interessante Aufstellung was da an Entwicklungsarbeit und
> Kosten zu investieren wäre...

An ein mechanisch kompatibles Mainboard habe ich vage auch schon mal 
gedacht. Das Gehäuse kann meinetwegen bleiben.
Mittlerweile gibt es glaubich die Leistung der 4 ADCs auch in einem 
Chip, was deutlich einfacher zu handhaben wäre. Die Consumer-Grade FPGAs 
dürften mittlerweile auch leistungsfähiger geworden sein. Mehr interner 
Speicher wäre nett.

Der analoge Part wurde mit der neuen Eingangsstufe ja schon recht weit 
getrieben, die gleich mit drauf ist doch schon die halbe Miete?

Aber vorerst bin ich mit der bestehenden Technik noch ganz gut 
beschäftigt...

Jörg


PS: danke für die Blumen!

Bruno We schrieb:
> @Jörg: Wenn ich mehr Ahnung hätte, von dem was du da treibst, dann würde
> meine Anerkennung bestimmt noch stärker ausfallen...

Geht mir genauso, bitte deute mein Schweigen zu EMV-Themen nicht als 
Ignoranz, sondern stille Bewunderung.

Michael H. schrieb:
> @Jörg
> Es macht Spaß, dir bei der Arbeit "zuzulesen": du gehst derart
> methodisch und fundiert an alles heran, dass es eine wahre Freude ist.

Ich versuche schnellen Erfolgserlebnissen zu widerstehen. Ist mir mit 
dem Capturing doch ziemlich lange gelungen? Bottom-Up ist wie auf dem 
Bau: erstmal ein Teil aushärten lassen (hier: testen) bevor man die 
nächste Lage draufstellt, das hält besser.
Ich versuche, von unten beim Prozessor und der Hardware angefangen die 
Dinge jeweils vollständig zu verstehen bevor ich drauf baue.
Gelingt aber nicht immer. ;-)

von Michael H. (stronzo83)


Lesenswert?

Hallo zusammen,
vielleicht kann mir einer von euch helfen. Mein Oszi geht ja schon eine 
ganze Weile nicht mehr und mittlerweile weiß ich zumindest, dass die 
Symptome zu einem nicht funktionierenden SRAM passen. Nachlöten bringt 
nichts, also möchte ich es ersetzen - nur leider ist es sehr schlecht 
erhältlich.
Meine Frage ist nun: weiß jemand, wie schnell die SRAMs angesprochen 
werden? Es sind ja 8ns SRAMs drauf, einen äquivalenten Typ mit 10ns 
hätte ich aufgetrieben und wüsste nun gern, ob der schnell genug ist.

Ich bin für jede Hilfe dankbar!

Gruß
Michael

von Jörg H. (idc-dragon)


Lesenswert?


von Errico (Gast)


Lesenswert?

Hello! I have many 0603 resistors (24,9 and 150 ohm) for welec hardware 
mod.
If interested feel free to send me a private mail: eprota at tiscali.it

Thanks

Erry

von frankman (Gast)


Lesenswert?

Tja, vielleicht kann man ja das Eine oder Andere noch etwas entstören?
Da könnte ich Hilfe anbieten...

von Jörg H. (idc-dragon)


Lesenswert?

Hallo,

was für's Sommerloch, ich habe hier (hoffentlich) eine kleine Sensation:
Das originale FPGA-Design von Welec!
Es ist ja bisher sehr hinderlich, das wir nicht recht wissen was da drin 
steckt, und an den Bugs nichts beheben können.

Da baggere ich schon seit Februar mühsam dran rum, vor ein paar Tagen 
habe ich endlich erste Dateien erhalten, auch mit der Erlaubnis sie zu 
veröffentlichen. Bisher habe ich hier im Forum noch nichts davon 
erzählt, damit nicht etwa ein Bedenkenträger bei Wittig aufgescheucht 
wird.
Leider ist es nicht das letzte, aktuelle Design, sondern wohl ein 
Zwischenstand der Entwicklung. Es scheint aber nichts grundsätzliches zu 
fehlen. Vielleicht kriegen wir in ein paar Wochen noch ein Update.

Hier die Links, wohin ich die Files hochgeladen habe. Bei Anonfiles 
gehen die Dateinamen verloren (Nomen est Omen?), bitte wieder zurück 
umbenennen.

Das hier ist das mit Abstand vollständigste Design:
TomCat-CII_2006_02_23.zip
https://anonfiles.com/file/6c0d44ac02012bb14dbec405dadaae0a

Da sind alle möglichen Files drin, bestimmt auch erzeugte/temporäre, 
nicht nur die Quellen. Weil ich mich damit nicht auskenne kippe ich das 
lieber vollständig hier ab.

Dann gibt es noch andere Dateibäume, mit andersartigen Nios-Designs ohne 
Capture-Einheit. Pinbelegung paßt nicht, die Nios-Peripherie auch nicht. 
Vermutlich uninteressant, vielleicht Teile für FPGA-Boards zur 
Softwareentwicklung ohne Oszi-Komponenten.

TomCat-CII_2004_06_24.zip
https://anonfiles.com/file/0238b1032ca321333a850bed47e94e8c
TomCat-CII_2006_10_26.zip
https://anonfiles.com/file/7ae427ba9b7dc8ab471fabc3072ca1d3

Als Addon haben wir hier noch den Quellcode für das Welec-Tool, ist 
vermutlich uninteressant. Software-Update kann ich bestimmt besser.
Delphi.zip
https://anonfiles.com/file/d0c4a3bf43128ffc931a90515ffa3e67

Im nächsten Posting beschreibe ich, was ich aus 
TomCat-CII_2006_02_23.zip bisher rausgefunden habe.


Grüße
Jörg

von Jörg H. (idc-dragon)


Lesenswert?

So, weiter gehts.

Vorweg: Ich bin kein FPGA-Entwickler (sondern Firmware-Entwickler), aber 
arbeite in einer Firma die sowas kann. Bei der Arbeit haben wir auch die 
Altera-Tools und entsprechende Lizenzen. Ich kenne den Kram ein bischen 
vom Hörensagen, aber habe selbst noch nicht an Logikdesigns 
rumgefummelt.

Mit einem Altera-erfahrenen Kollegen habe ich mich da dran gesetzt. Wir 
haben obiges Design recht problemlos synthetisiert und gemapped 
bekommen.
Das Design ist zu Zeiten von Quartus 5 entstanden (aktuell ist 12), 
übersetzt haben wir es mit Quartus 9.1. (Wir mußten Zeile 101 in 
TomCat-CII.qsf auskommentieren, da wird ein Tool namens "exemplar" 
angesprochen was wir nicht haben.)


Nochmal zurück, was ist in dem .zip drin?

Das Design ist nicht in einer Hardwarebeschreibungssprache wie VHDL oder 
Verilog formuliert, sondern als ein Satz hierarchische Schaltpläne 
grafisch gezeichnet. Das hat den Charme, das auch Laien wie ich da 
draufschauen können und eine Chance haben, die Logik zu verstehen. Mit 
dem bei Altera kostenlos herunterladbaren Quartus Web Edition kann man 
sich das angucken, wenn auch nicht übersetzen.
Kleine Anleitung: Quartus installieren und starten, das Top-Level 
Projekt TomCat-CII.qpf öffnen, links im Projektnavigator den Reiter 
"Files" anklicken, den Schaltplan TomCat-CII.bdf öffnen. Ab da geht's 
ganz intuitiv grafisch weiter, Unter-Blöcke kann man mit Doppelklick als 
neues Blatt öffnen.

Dieser Schaltplan-Satz ist schon eine beachtliche Leistung, mein 
Respekt. In den Hierarchien ist einiges drin. Mit HDL kann man komplexe 
Designs sicher besser beherrschen, außerdem sind sie portabel. Ich 
stelle mir vor, ich müßte meine Software komplett als Struktogramm 
zeichen statt in C programmieren...

Die CPU und ihre Peripherie ist vom Altera SOPC Builder erzeugt, ein 
mitgeliefertes Tool was so einen Softcore erzeugt, mit Bussen und 
Peripherie bestückt und aus dem Ganzen ein großes Verilog-File erzeugt, 
plus glaube ich ein paar Tabellen mit Microcode oder so.
Bei der Arbeit haben wir keine Bibliothek für den Nios, es gibt nur noch 
den Nachfolger Nios-II. Weil das ursprünglich erzeugte Verilog-File noch 
da ist können wir das so als Block zwar mit übersetzen, aber nicht mit 
dem SOPC Builder verändern. Gegenüber dem Stand in unseren Oszis sind 
die Interrupts anders zugeordnet und es fehlen noch 3 GPIO-Ports. Einen 
davon benutze ich bei Osoz, den VSync-Interrupt, die anderen beiden sind 
für (ungenutzte) Software-Abfrage der Boot-Tasten. Die 
Interrupt-Zuordnung könnte man zur Not im Verilog kompatibel patchen.
Mit ein paar Mausklicks könnten wir auch die CPU durch einen Nios-II 
ersetzen...

Weiter zum Stand des Logikdesigns, was mir so aufgefallen ist:

- Die zwei FPGAs der Vierkanäler haben denselben Inhalt. Es gibt einen 
Pin (E9), der festlegt ob der Chip Master oder Slave ist. Davon abhängig 
wechselt die Richtung von 6 bidirektionalen Verbindungsleitungen, mit 
denen sie sich über z.B. Trigger und Kanalprogrammierung verständigen. 
Der Bus geht an beide.

- Die LED+Keyboard Anschlüsse tragen gerade andere Testsignale, für die 
originale Funktion müßte man die wieder zu den ursprünglichen Ausgängen 
gerade durchverbinden. Das habe ich erst nach unserer Synthese bemerkt, 
daher das Produkt auch nicht ausprobiert. Außerdem weiß ich nicht, wie 
ich mein erzeugtes .sof File für beide FPGAs in ein .jic File bekomme, 
mit dem ich bisher die FPGAs gebrannt habe.

- Es gibt ein paar Open Ends: einen "Triangle Generator", einiges bei 
den Kanälen, z.B. Trigger min/max Speicher

- Ein weiteres Open End ist der Logic Analyzer. Der begegnete uns in der 
Software auch schon mal in Andeutung, Funktion war komplett unbekannt. 
Anscheinend werden 16 Bit breite Daten die sonst von 2 ADCs kommen 
zusätzlich separat behandelt, in einen kleinen Extra-Speicher mit einer 
Triggermimik. Bei Zeitauflösungen die nicht alle 4 ADCs erforden hat 
Wittig sich wohl eine LA-Möglichkeit vorgestellt. Das ist noch unfertig, 
z.B. ist der Reset dieser Baugruppe nur an einen externen Button 
angeschlossen statt an den Systemreset. Ohne entsprechende Vorbereitung 
der Platine wäre das auch schwer zu nutzen, braucht Eingangstreiber mit 
LVDS-Ausgängen parallen zu 2 ADCs.

- Die Trigger Mode Register sind noch nicht vollständig. Wir haben da 
vermutlich 8 Register, hier sind es erst 5, ferner noch nicht alle 
späteren Bits belegt. Schade, speziell dieser Teil ist nämlich sehr 
rätselhaft, es wird ihm auch Einfluß auf das Spike-Problem nachgesagt.

- Ein späterer "Hack" für programmierbare Grid-Farbe fehlt noch. Dazu 
wurden später 6 Bit von einem obigem Mode-Register zweckentfremdet.

- Der Ausgang des Testgenerators ist noch nicht verdrahtet (später Y9). 
Dafür ist er mit einem Test-Out-Register programmierbar (vielleicht eine 
8-bit PWM?), was bei uns keinen Einfluß hat.


Soweit der Stand meiner Forschungen. Ich hoffe, das wirklich 
Hardware-Kundige sich des Designs annehmen. Wir können da hoffentlich 
noch viel lernen, und den "klassischen" Grund-Übeln nachspüren.

Es wäre z.B. überaus interessant, dem Spike-Problem nachzugehen. Und 
warum die Sortierung der ausgelesenen Meßwerte in 4-ADC-Zeitbasen 
"verrutscht", vielleicht ist da in der Software auch noch was 
unzureichend bedient.


Soweit erstmal, mal schauen was sich noch so ergibt.
Viel Spaß bei der Schaltplan-Lektüre!
Jörg

von Cy (Gast)


Lesenswert?

@Jörg
Hi,
I'm going to see your documents for which I thank you.
I do not understand a couple of things.
The documents you shows us are been obtained starting from the original 
Wittig's FPGA artichecture?
If no, how you have obtained them?
Even if not documented (I know Wittig's documentations is lack), with 
the debugging tools that you described would not be possible to obtain 
similar documents starting from the original FPGA architecture developed 
by Wittig?
Cheer,
Cy

von Jörg H. (idc-dragon)


Lesenswert?

Hello Cy,

may I ask who you are, or where from? I haven't seen you here before. 
Does babelfish work for you, or shall I translate parts of my posting?

The files I posted are the original Wittig design. However not the most 
recent version, as in the devices been sold. But it's a starting point.

Jörg

von Cy (Gast)


Lesenswert?

@Jörg
Hi Jörg,
you are right, I understand I was rude, I'm so sorry for that.
Then, let me introduce myself.
My name is Paul and I'm from Canton Ticino (Italian Switzerland, at this 
moment I'm spending the holidays in Italy).
Starting last April I became interested in Wittig's oscilloscopes 
because I received a second hand W2012 as gift.
Meanwhile starting to read up on it I found this forum where I learned a 
lot of things about it.
You never seen me here before because I'm generally a lurker and the 
only time I wrote in the forum I did it on day May 20 2012 in the 
firmware section.
I never used a online translator due the fact I prefer try to translate 
myself.
As you can see my English is poor and even more poor is my German, so 
it's pretty normal that I cannot understand some parts in your post and 
I'm so sorry about this.
Thank you for your willingness to act as a translator if necessary, I 
hope it will not be needed.
Next  time I will try to use a online translator as you suggested me.
Thank you also for all the useful informations and answers you provided 
me.
Cheer,
Cy

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

das ist ja wirklich sehr interessant!
Ich hatte vor ca. 4 Jahren den ersten Kontakt mit dem Welec Scope und 
konnte damals nach langem Hin und Her die C-Code files von Wittig 
ergattern. Damals wurde mir gestattet die Files zu veröffentlichen und 
das Projekt als Open Source ins Leben zu rufen. Recht bald ist den 
Profis hier aufgefallen, dass es gravierende Fehler im FPGA Design gibt. 
Ich (und auch Andere hier aus dem Forum) haben dann noch über Monate 
versucht von Wittig die FPGA Files zu bekommen.
Die Aussage von Wittig damals war immer die Gleiche: Die Rechte liegen 
nicht bei Ihnen und somit dürfen und können Sie den Code nicht 
freigeben. Nach deren Aussage haben Sie den Code nicht einmal (das Scope 
wird in GB gefertigt!). Jetzt wäre also wirklich interessant wo der FPGA 
Code her kommt... ich  hatte damals eigentlich nicht den Eindruck dass 
mir die Unwahrheit erzählt wird...

Jetzt sind also unsere FPGA Cracks gefragt...

Gruß, Brunowe

von Guido (Gast)


Lesenswert?

Hi Brunowe,

schön mal wieder von dir zu lesen. Jörg hat offensichtlich Mittel,
über die wir nicht verfügen. Ob es was hilft müssen wir mal abwarten.
Da wohl immer noch Closed-Design mit drin ist lässt sich das Ganze
ja nicht überarbeiten. So bleibt weiterhin nur die Möglichkeit
Schwächen des FPGA-Designs per Software auszugleichen.

von Blue F. (blueflash)


Lesenswert?

Bruno We schrieb:
> Die Aussage von Wittig damals war immer die Gleiche: Die Rechte liegen
> nicht bei Ihnen und somit dürfen und können Sie den Code nicht
> freigeben. Nach deren Aussage haben Sie den Code nicht einmal (das Scope
> wird in GB gefertigt!). Jetzt wäre also wirklich interessant wo der FPGA
> Code her kommt...

Ja ich erinnere mich. Aber anscheinend war es doch nicht die ganze 
Wahrheit.

Guido schrieb:
> So bleibt weiterhin nur die Möglichkeit
> Schwächen des FPGA-Designs per Software auszugleichen.

Nicht nur! Erstens ergeben sich Erkenntnisse über Detailfunktionen und 
weiterhin läßt sich evtl. auch was am Design ändern.

Die Frage ist hierbei nur wie tiefgreifend wir da ändern wollen. Eine 
Möglichkeit die Jörg ja schon angesprochen hat ist der Wechsel (bei 
ansonsten gleichen Design) auf NIOS II, was wohl deutlich mehr 
Performance verspricht. Auf jeden Fall könnten wir Leute mit 
FPGA-Knowhow gut gebrauchen...

Gruß Hayo

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

Hi,

na das ist doch mal eine gute Nachricht und ein ziemlicher schritt nach 
vorn.

hier mal die exemplar.lmf aus meiner max+plus installation. Damit lässt 
sich das Projekt unter Quartus 9 ohne Modifikationen bauen. (wenn auch 
mit reichlich Warnings)
Was das Übertragen der .sof Datei an geht, sollte sie sich direkt aus 
quartus heraus über USB einspielen lassen wenn das scope im ByteBlaster 
modus ist. Mit meiner Quartus Installation lässt sich auch der NIOS im 
SOPC-Builder öffnen und bearbeiten. Demnach sollte also Designmäßig 
alles soweit offen liegen und vorhanden sein.

grüße sunny

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

Für diejenigen bei denen das mit dem SOPC-Builder nicht funktioniert, 
hier mal die Portmap der bislang unbekannten Register

von Guido (Gast)


Lesenswert?

Hi sunny,

ich kenne  mich mit Altera nicht aus, aber das klingt ja schon
mal gut wenn du das bauen kannst. Was ist mit dem "exemplar",
das Jörg auskommentieren musste macht das max+plus automatisch?

Wozu verwendet man denn dieses max+Plus? Mit Gurgel finde ich
da nix verständliches.

Grüße, Guido

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Hi all!

Entgegen meiner obigen Aussage kann man das Design auch mit der freien 
Quartus Web Edition übersetzen. Ob es auch läuft weiß ich noch nicht.

Es gibt übrigens keine nicht einsehbaren Teile, hatte ja irgendwer 
befürchtet.

@Bruno: hast du noch Komntrakt zu Slog? Du könntest ihn ja mal hierauf 
stubsen. Und bei der Gelegenheit fragen, ob er seinen sehr praktischen 
Blaster-Treiber auch für 64Bit-Windows kompilieren kann. ;-)

@sunny: Danke für das .lmf File. Die Register kennen wir, und sogar noch 
ein paar weniger wichtige mehr, die in diesem Design noch fehlen. Es 
wird für uns Softwerker auch ein Header-File erzeugt, das vom aktuellen 
Design haben wir.

Weitere Erkenntnisse meinerseits, was mir seitdem auffiel:

- Die Kanalauswahl für den Trigger ist anscheinend noch nicht 
verdrahtet.

- Ein Reset per Softkey-Kombination ist vermutlich noch nicht möglich, 
denn dann müßte der Keyboard-Teil entsprechende Ausgänge haben. Sprung 
in den GERMSloader erst recht nicht, da kommt ein fehlendes Register ins 
Spiel.

- Als externer Oszillator war wohl mal 50 MHz vorgesehen, nicht 25 MHz 
wie bei uns bestückt. Die Leitungen heißen noch so, auch die PLLs sind 
drauf eingestellt. Der Takt zum Nios (halber Systemtakt) ist im 
SOPC-Builder allerdings bereits mit 12,5 MHz angegeben. Da hatte man 
wohl gerade ein Problem festgestellt und gedrosselt. So wie es jetzt 
steht würde der Nios also wie gewohnt laufen, Capturing aber nur mit 
halber Geschwindigkeit.

- Ich habe ganz eventuell den Fehler gefunden, warum im 4ADC-Modus die 
ADCs gegeneinander verschoben erscheinen. In der Datei tc_acq_ram.bdf: 
das Signal "record_ff" wird in allen 4 clock domains für das 
Rücksetzsignal "aclr" der Adreßzähler verwendet, aber mit nur dem ersten 
Clock "clk_g10" synchronisiert. Für die anderen ist es dann eher Zufall, 
wann sie loslaufen. Aber vielleicht habe ich das auch nicht verstanden. 
Wie man das korrekt löst weiß ich erst recht nicht.

- In dem Design haben wir keine sog. Constraints gefunden. Das sind 
Informationen an die Synthese, wie schnell wir denn z.B. takten wollen. 
Von daher kann das Tool auch nicht ausgeben, ob das so klappt. Nur 
hinter den PLLs sind die Takte bekannt, da gibt es auch prompt etliche 
Violations.

- Ferner habe ich eine Pinliste erstellt, mit den Belegungen im 
Wittig-Design sowie den Community-Anläufen ZPU/Leon, siehe Anhang. 
Entgegen meiner Hoffnung kamen dabei keine neuen, unbekannten Pins 
zutage. Es fehlen im Gegenteil sogar 2, der Kalibrierausgang und ein 
Takt. Zwei LVDS-Pärchen für 2 ADC-Pins sind anders verdrahtet. Wer hat 
nun recht? Ich vermute "unser" Pinning, vermutlich gab es da noch eine 
Layoutänderung.
Die Differenzen habe ich in der Tabelle gelb markiert. Potentiell 27 
I/Os sind noch frei. Dürfte aber schwierig sein, da unter dem BGA 
dranzukommen.

Mehr später,
Jörg

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Jörg,

Slog ist immer noch im ixbt Forum aktiv. Du kannst ihm ja dort eine 
Nachricht auf englisch hinterlassen. Mein Russisch ist zwischenzeitlich 
auch schon etwas eingerostet...
http://forum.ixbt.com/topic.cgi?id=48:7811-10


Gruß, Brunowe

von sunny (Gast)


Lesenswert?

@guido
max+plus ist die alte Entwicklungsumgebung für Altera FPGA's. Also das 
was heute Quartus ist.
Wieso die exemplar.lmf damals mit bei war und heute nicht, weiss ich 
auch nicht.

gruß sunny

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Bruno We schrieb:
> Slog ist immer noch im ixbt Forum aktiv. Du kannst ihm ja dort eine
> Nachricht auf englisch hinterlassen. Mein Russisch ist zwischenzeitlich
> auch schon etwas eingerostet...
> http://forum.ixbt.com/topic.cgi?id=48:7811-10

@Bruno: ich kann kein Wort Russisch. Hab's trotzdem versucht, mich mit 
Hilfe von Google Translate dort angemeldet und ihm eine PM geschickt. 
Bin mir aber nicht abschließend sicher, ob das geklappt hat und ihn 
erreicht. Wenn du eine Email-Adresse hast wär's einfacher.

@all:
Ich kann jetzt .sof Files in das FPGA laden, das Ergebnis von Synthese 
und Mapping. Tut sich leider gar nichts. Eigentlich müßte der ROM 
Bootloader eine Kennung auf die serielle Schnittstelle senden. Ich bin 
mir nicht sicher, ob der Bootloader tatsächlich den Weg in das .sof 
gefunden hat, kennt sich jemand damit aus?
Ich habe im Design folgende Änderungen gemacht (siehe Datei im Anhang): 
die Anschlüsse für LED und Keyboard wieder an die originalen Signale 
gelegt, den Testgenerator an Pin Y9 verkabelt, eine Inkonsistenz am 
SRAM-Adreßbus beseitigt (die untersten 2 Bits weglassen).

Jörg

von Fritz R. (f_richter)


Lesenswert?

Hallo Jörg,
ich hatte es gestern auch schon probiert, leider vorerst auch mit dem 
selben Resultat. Die Änderungen hatte ich auch schon gemacht.
Der Bootloader müsste eigentlich automatisch eingebaut werden.
Ich werde mich jetzt aber nochmal dransetzen und erst mal Deine bdf 
verwenden.
Gruß

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Jörg,

ok, ja die Anmeldung ist etwas tricky wenn man kein Russisch kann.
Ich hab eine Email Adresse und schick Sie dir als PN, will die hier 
nicht öffentlich rein stellen.

Gruß, Bruno

von Fritz R. (f_richter)


Lesenswert?

So, zumindest tut das neugebaute Design jetzt etwas:
**********************************************
        BlueFlash firmware starting!
**********************************************

- Hardware initialization
spurious interrupt number: 00000013

Der Grund, warum das Design bisher scheinbar tot war, ist die 
Master-Slave Umschaltung. Ich habe die deshalb vorerst mal fest an GND 
gelegt.
Wie Jörg schon festgestellt hatte passen die Ints nicht zu unserer 
Software,
deshalb wahrscheinlich die "spurious interrupt number".
Außerdem ist die Takterzeugung noch ziemlich buggy, deshalb stimmt die 
Baudrate am UART nicht.

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Sehr gut Fritz, das ist ja mal ein Anfang!
(Geradezu genial, wie bist du denn darauf gekommen?)

Ich habe das gerade nachvollzogen, den Inverter hinter dem 
Master-Eingang rausgenommen. Vielleicht war der nur zu Testzwecken drin?
Jetzt kriege ich immerhin schon die Startmeldung von Hayos Software zu 
sehen, inmitten buntem Pixelsturm. Auf der seriellen ist auch was los. 
Eine unorthodoxe Bitrate, ich mußte den LA bemühen: ich messe 1/4 der 
nominellen 115200, 28800 Baud, an meinem Terminal nicht einstellbar.

Die Interruptprioritäten habe ich im generierten Verilog des 
Nios-Systems auf "unsere" Werte geändert. Das ist dort ganz gut 
nachvollziehbar, ab Zeile 3474 in "TCCPU.v". Der Optik halber auch im 
SOPC-Builder, aber das ist wirklich nur zur Anschauung, ohne die 
Nios-Lib kann ich das nicht neu erzeugen.

Siehe da, es geht ein gutes Stück weiter. Ich sehe (inmitten des bunten 
Pixelsturms) das Grid, UI und bewegte Wellen. Scheint also im Groben zu 
arbeiten. Es reagiert aber nicht auf Tastendrücke und Drehgeber. Außer 
Softkey F2, das löst einen Reset aus. Die LEDs sind wohl anders 
verteilt, leuchten jetzt in "unsinniger" Anordnung.

Anbei meine geänderten Dateien. (Vielleicht sollten wir das Design in 
svn einchecken? Welche Dateien braucht man denn wirklich?)
Und ein Bild vom der GUI im Pixelsturm. Den müßt ihr euch noch bewegt 
vorstellen.

Jörg

von Fritz R. (f_richter)


Lesenswert?

Jörg H. schrieb:
> (Geradezu genial, wie bist du denn darauf gekommen?)

Naja es war ziemlich offensichtlich, das da etwas generelles nicht 
stimmen kann, also habe ich mir als erstes Takterzeugung und Reset 
angesehen.
Die NIOS Lib habe ich leider auch nicht, vielleicht sollten wir doch 
versuchen den alten NIOS durch den NIOS2 zu tauschen. Ich habs sogar 
schon getan, allerdings passt dann die Software nicht mehr. Der 
Germs-loader sollte sich einfach übersetzen lassen, allerdings schwebte 
mir eher gleich Dein ucl-loader vor.
Meinst Du, das Du den für den NIOS2 übersetzen kannst, ich hab mich an 
deinen ASM Code noch nicht rangetraut.
Außerdem hat der NIOS2 nur Int's bis 32, dort müssten wir also dann 
umsortieren.

Gruß Fritz

von Jörg H. (idc-dragon)


Lesenswert?

Den Nios II hatte ich testweise auch schon reingetauscht, um zu sehen 
wie groß er ist. Das geht mit dem SOPC-Builder ja ganz einfach, mit ein 
paar Mausklicks.
Wir können uns den performantesten Nios II, die Variante /f, locker 
leisten. Das wird nur unwesentlich größer als mit dem Nios32. Mit 
solchen Annehmlichkeiten wie JTAG-Debugging, Multiplikation, ggf. sogar 
Division (brauchen wir vermutlich nicht). Als ich spaßeshalber noch die 
FPU angewählt hatte bekam ich aber eine Fehlermeldung bei der Synthese 
(undefined entity "fpoint_wrapper"), vielleicht fehlt was.

Aber wenn schon, denn schon: Ich würde eher "auf der grünen Wiese" ein 
neues Nios-Subsystem zusammenbauen. Die Hardware könnte viel mehr als 
mit dem jetzigen Design. Unser SRAM ist 8ns schnell, das reicht in die 
Region von 100 MHz. Laut Altera kann man den Nios II auf unserem FPGA 
mit 140 MHz synthetisieren, laut meinem Kollegen kann man diese Angabe 
auf 2/3 reduzieren, weiterhin haben wir den langsamsten Speed Grade des 
FPGA, während Altera bestimmt den schnellsten für's Benchmarking 
herangezogen hat.
Also irgendwas bei ca. 70 MHz. Etwas langsamer als der Speicher könnte. 
Den Nios-II kann man mit Cache versehen, was ihn zu einem gewissen Grad 
unabhängig macht.
Aber asynchroner Speicher soll hohe Strafe kosten, 12 Zyklen oder so. Da 
läßt man den Speicher wohl besser auf gleicher Geschwindigkeit.
Das Flash muß allerdings langsamer laufen, dort greift diese Strafe. 
Glücklicherweise hat es einen eigenen Bus.

Im Altera-Baukasten gibt es auch noch solche Dinge wie DMA-Controller, 
das könnte auch nützlich sein. Mit den Custom-Instructions kann man 
einiges anstellen, vielleicht noch einen DMA-Filter der gleich 
min/max/average/rms oder sowas bestimmt, viele Möglichkeiten.

Zu ändern wäre der LCD-Controller. Eine saubere Implementierung wäre, 
den als Avalon-Busmaster auszuführen und ihm Priorität gegenüber der CPU 
zu geben. Er klaut dann Bandbreite vom Speicher, braucht 12,5 MHz davon, 
und minus Blanking nur zu <80% der Zeit. Ist also zu verschmerzen.
Ich habe mir schon einige Gedanken gemacht, wie man den LCD-Controller 
realisieren könnte. Das Bitplane-Konzept möchte ich unbedingt 
beibehalten, für schnelles unabhängiges Zeichnen. Um das flexibler zu 
haben stelle ich mir 16 Hardwareregister für die Planes vor, in die man 
SRAM-Startadresse und den 9bit-Farbwert reinschreibt. Das paßt zusammen 
in 32 Bit. So kann man eine offscreen-Bitplane durch einfaches Umsetzen 
des Registers sichtbar machen, muß den Inhalt nicht umkopieren.
Der Controller muß dann diese 16 Planes reihum als Busmaster lesen, um 
einen neuen Satz Worte für Schieberegisterwerte bereitzustellen, während 
die bisherigen pixelweise mit der LCD-Clock rausgeschoben und die Farbe 
bestimmt wird.

Die SPI-Ketten für Tastatur, Drehgeber, LEDs und onboard-Outputs sind 
dagegen vermutlich vergleichsweise einfach zu implementieren. Da haben 
wir ja auch gleich mehrere Designs zur Auswahl, zum Abgucken.

Das FPGA hat 4 PLLs. Die sind für die 4 um 90 Grad phasenverschobenen 
ADC-Clocks (4*250 MHz) leider schon aufgebraucht. Ich habe aber gesehen, 
daß man mit einer PLL nebenbei auch noch andere Frequenzen erzeugen 
kann. Bei Wittig geschieht das für den LA-Teil, der noch 100 MHz 
bezieht. Das ist sogar recht fein einstellbar, in Schritten von wenigen 
MHz. Wir könnten unser neues Nios-System also feintunen.

Und wenn's dann soweit ist würde ich vorschlagen die Capture-Unit von 
Alex einzubauen. Die erscheint mir wesentlich ausgefeilter. Geringere 
Zeitauflösungen werden durch weiterhin hohe Abtastrate und Filterung 
erzeugt, statt durch einfach langsamere Abtastung. Zudem funktionieren 
die Werte und der Trigger.  ;-)

Soviel zum nächsten made-from-scratch Ansatz...

Ach ja, die Software. Ein neuer Bootloader muß her, keine Ahnung ob 
Altera da auch sowas wie den GERMSloader für Nios II anbietet, wo man 
nur noch UART-Adresse, Tasten-Override und Flash-Routinen anpassen muß. 
Von mir aus muß der gar nicht soviel können, lediglich das Flash 
anspringen oder auf Tastendruck in einen Modus gehen der vom UART ein 
Stückchen Code entgegennimmt und ausführt.
Mein UCL-Loader war ja auch mal in C. Aber der muß es wegen mir nicht 
sein, reicht auch "im Nachgang". Zumal es ihn in 2 Versionen gibt, für 
RAM und Flash. Der Bootloader sollte möglicht klein sein, spart Block 
RAM im FPGA, was ich lieber für Capturing einsetzen würde. Statt 16 kB 
müßten eigentlich auch 24 kB pro Kanal möglich sein, dummerweise keine 
Zweierpotenz, gibt krummere Zähler.

So long
Jörg

von Fritz R. (f_richter)


Lesenswert?

Klingt wirklich alles ganz interessant und vor allem realisierbar.
Etwas FPGA Erfahrung und einen "Spieloszi" habe ich, um etwas von Deinen 
Ideen umzusetzen.
Zur Software, den GERMS-loader gibts in dieser Form soweit ich weiß für 
NIOS II nicht, allerdings müsste sich der vorhandene Portieren lassen.
Es gibt wohl auch die Möglichkeit den NIOS direkt aus dem 
Konfigurations-Flash booten zu lassen, dort ist ja noch Platz vorhanden 
denn für den FPGA brauchen wir nur 6 von den 16Mbits.

Gruß Fritz

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Realisierbar klingt gut!

Fritz, hast du meine PM von wegen Skype-Gruppe erhalten?

Ich habe mit Kollegenhilfe zum Ausprobieren ein frisches Minimalsystem 
mit dem Nios-II aufgesetzt, siehe Anhang. Da sind mal nur die benötigten 
(?) Dateien drin, die Pinbelegung von Wittig, .sopc File (also den SOPC 
Builder erstmal den ganzen Wahnsinn generieren lassen), die 4 PLLs, ein 
Toplevel in Verilog und (neu!) ein .sdc File mit Angaben zur 
Taktversorgung drin, damit Quartus uns sagen kann wie das denn so 
klappt.

Es hat die gleiche Memory-Map wie unser Nios32-Design. Es enthält die 3 
Memories (Boot, SRAM, Flash), 3 Timer, 2 UARTs. Das täte für ein "Hello 
World" mehr als ausreichen. Die ganzen Ports sind mit Absicht noch nicht 
dabei.

Den Nios takte ich aus einer PLL mit derzeit 1/3 ADC-Clock, also 83,3 
MHz. Die Timinganalyse sagt wir könnten bis etwa 90 MHz. Nicht schlecht, 
finde ich!

Ob's auch läuft weiß ich nicht. Dazu müßte man Software schreiben, den 
Flow kenne ich noch nicht...

Jörg

von Fritz R. (f_richter)


Lesenswert?

Ein "Hello World" sollte ich dem schon entlocken können.
Zumindest wurde Dein Design schon übersetzt. Was mir auffiel, ich glaube 
man braucht unbedingt noch eine sysid komponente im NIOS II.
Außerdem sollten die unbenutzten Pins nicht zwangsweise auf GND liegen, 
das kann man beim Device->"Device und Pin Options" einstellen.

So long

von Jörg H. (idc-dragon)


Lesenswert?

Fritz Richter schrieb:
> Zumindest wurde Dein Design schon übersetzt. Was mir auffiel, ich glaube
> man braucht unbedingt noch eine sysid komponente im NIOS II.
Ist das dies Zahl beim Nios-Erstellen, die Standardmäßig Null ist? Ach 
nee, die heißt cpuid. Gegoogelt: Den Check darauf kann man wohl auch 
ausschalten:
http://www.alteraforum.com/forum/showthread.php?t=17705

> Außerdem sollten die unbenutzten Pins nicht zwangsweise auf GND liegen,
> das kann man beim Device->"Device und Pin Options" einstellen.
Das hatte ich gemacht, habe auch schon von der Unart des 
Default-Verhaltens gehört. War wieder verschwunden? Tss...

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Dank Fritz' Hilfe:
Gestern lief ein erstes "Hello World" auch bei mir auf dem frischen 
Nios-II System. Sehr spannend, das alles.
Mit 83 MHz und dem externen SRAM kommt er anscheinend klar.

Stay tuned...
Jörg

von Blue F. (blueflash)


Lesenswert?

Sehr spannend!

Ich verfolge das hier natürlich die ganze Zeit mit, bin aber noch zur 
Untätigkeit verdammt da bei mir nur ein Notsystem läuft.

Etwas Offtopic zwar, aber ich hab die ursprünglich bestellte Festplatte 
(Amaz...) jetzt nach 3 Wochen storniert und bei einem kleineren Händler 
eine andere bestellt die nach 1 Tag da war!!! Jetzt bin ich dabei zu 
formatieren und zu kopieren. Hoffe ich bin bald wieder am Ball...

Hayo

von Peter M. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo allseits,
ich war schon eine ganze Weile nicht mehr welecmaessig unterwegs. 
Beeindruckend was ihr alle auf die Beine gestellt habt. Hut ab!
Joerg hat ja ganz schoene Impulse mit seinem Neuansatz gebracht.

Die Quartus-Sourcen sind schon interessant. TomCat-CII.fit.summary siehe 
Anhang zeigt den Resourcenverbrauch im FPGA. Ist noch was frei, vor 
allem bei den Multipliern. Nios2 ist ja wesendlich sparsamer beim 
Resourcenverbrauch im FPGA was auch wieder was frei machen sollte. 
Ausserdem muss auch noch entschieden werden, welcher der 3 Nios2-Typen 
genommen wird.

In TomCat-CII.pin steht das genaue Pinning. Einige sind NC. Frage ist, 
ob sie auf dem Board auch kein Ziel haben.

Vielleicht rueckt ja Joergs Sourcenquelle auch die Schaltplaene raus. 
Traeumen darf man ja ;-)

Fritz Richter schrieb:
> Zur Software, den GERMS-loader gibts in dieser Form soweit ich weiß für
> NIOS II nicht, allerdings müsste sich der vorhandene Portieren lassen.
> Es gibt wohl auch die Möglichkeit den NIOS direkt aus dem
> Konfigurations-Flash booten zu lassen, dort ist ja noch Platz vorhanden
> denn für den FPGA brauchen wir nur 6 von den 16Mbits.

Da hat er recht. GERMS wird nicht mehr bei Nios2 unterstuetzt. Es gibt 
zwar eine von Altera nicht unterstuetzte Portierung bis Quartus6, aber 
das wars.
Machen wir halt alles ueber USB. Dann koennen wir uns auch die RS232 
sparen oder fuer etwas anderes nutzen. Hat schon einer kuerzlich den 
'USB Blaster on the FX1' zum Leben erweckt?

Den Nios wuerde ich auch aus dem SPI-Flash mit Daten versorgen, denn 
drin ist er da ja eh schon. Das Flash koennte man ja auch auf 64MBit 
aufbohren, natuerlich nicht mit einem ECP64 von Altera. Leicht zu 
Loeten, da 0.8er Pitch.

Gibt es eigentlich noch Rohleiterplatten von den neuen Eingangsstufen 
V1.4.?

Gruss, Peter

von Jörg H. (idc-dragon)


Lesenswert?

Auch hallo!

> Die Quartus-Sourcen sind schon interessant. TomCat-CII.fit.summary siehe
> Anhang zeigt den Resourcenverbrauch im FPGA. Ist noch was frei, vor
> allem bei den Multipliern. Nios2 ist ja wesendlich sparsamer beim
> Resourcenverbrauch im FPGA was auch wieder was frei machen sollte.
> Ausserdem muss auch noch entschieden werden, welcher der 3 Nios2-Typen
> genommen wird.

Keine Frage, den schnellsten, die Variante /f.
Der ist etwa genausogroß wie der alte Nios32, mit ein paar Extras kann 
er noch wachsen. (Mit Fließkommaeinheit um ca. Faktor 1,5...)
Der nächstkleinere ist nur halb so schnell und wenig kleiner, warum 
sollten wir uns das antun? Und der ganz kleine leistet gar nur 1/10.

Das der alte Nios keinen Multiplikationsbefehl konfiguriert bekommen hat 
war einfach blöd. Den hätte es quasi gratis gegeben.

> In TomCat-CII.pin steht das genaue Pinning. Einige sind NC. Frage ist,
> ob sie auf dem Board auch kein Ziel haben.

Da Slog genau das gleiche rausgemessen hat habe ich da wenig Hoffnung. 
Siehe mein Posting dazu mit Pin-Excel weiter oben.

> Vielleicht rueckt ja Joergs Sourcenquelle auch die Schaltplaene raus.
> Traeumen darf man ja ;-)

Liegen leider nicht vor, wenig Hoffnung.

> Da hat er recht. GERMS wird nicht mehr bei Nios2 unterstuetzt. Es gibt
> zwar eine von Altera nicht unterstuetzte Portierung bis Quartus6, aber
> das wars.
> Machen wir halt alles ueber USB. Dann koennen wir uns auch die RS232
> sparen oder fuer etwas anderes nutzen. Hat schon einer kuerzlich den
> 'USB Blaster on the FX1' zum Leben erweckt?

Mit 32Bit-Windows hatte ich den Slog-Treiber verwendet.
Um USB schnell zu kriegen bedarf es einer neuen FX-Firmware. die 
derzeitige spricht an 2 GPIO-Pins des FX1 57600 Baud. Ob es der 8051 da 
drin auch schneller schafft weiß ich nicht.
Die RS232 ist momentan unser schnellstes Interface. In meinem neuen 
Nios-II System erlaube ich auch höhere Baudraten als 115200, der 
Pegelwandler kann noch mindestens das doppelte.

> Den Nios wuerde ich auch aus dem SPI-Flash mit Daten versorgen, denn
> drin ist er da ja eh schon. Das Flash koennte man ja auch auf 64MBit
> aufbohren, natuerlich nicht mit einem ECP64 von Altera. Leicht zu
> Loeten, da 0.8er Pitch.

Wir haben aber auch 8 MB paralleles Flash...

Das mit dem Booten aus EPSC-Flash ist nach aktuellsten Erkenntnissen 
doch kein Vorteil. Wir dachten wir sparen RAM im FPGA, aber dort wird 
trotzdem eines angelegt, beim Booten mit dem EPSC-Inhalt beschrieben.

Jörg

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Hi nochmal,

am Wochenende habe ich viel mit dem SOPC-Builer von Altera 
herumprobiert, wie man das neue Nios-System schnell kriegt. Habe einiges 
gelernt. Mein schneller neuer PC durfte sich endlich mal an was 
rechenintensivem austoben, hat das FPGA zig Mal synthetisiert.

Bei den Vorbereitungen für den LCD-Controller hatte ich erstmal einen 
Schreck bekommen. Der zusätzliche Busmaster und ein testweiser 
DMA-Controller haben unsere Performance auf ca. 60 MHz gedrosselt, wohl 
durch die vielen neuen Verbindungen in der Busmatrix.

Nun habe ich gelernt, das in zwei Teile zu teilen, einen möglichst 
schnellen für nur das allernötigste (Prozessor, RAM, LCD), und einen 
langsamen (25 MHz) für das ganze Peripheriegedöns und auch das Flash. 
Dazwischen kommt eine "clock crossing bridge".
Außerdem kostet der JTAG-Debugger recht viel, weil der sich auch überall 
anschließt. Im Moment brauchen wir ihn aber, weil wir noch keine andere 
Möglichkeit haben da Software reinzubringen. Später könnten wir eine 
langsamere Debug-Version für Entwickler bauen und eine schnellere für 
User, ohne JTAG.

Ohne LCD synthetisiert das Nios-System mittlerweile für ganz knapp 100 
MHz. Also habe ich mal mutig die PLL auf 100 MHz gestellt und das Hello 
World ausprobiert. Klappt aber nicht, das ist wohl doch zu schnell für 
den externen Bus. Ich kriege einen "verify error" beim Laden des 
Programms. Eine Stufe langsamer ist 93,8 MHz, das funktioniert noch. 
Hier ist also wohl das Ende unserer Fahnenstange. Aber von 12,5 MHz 
kommend nicht schlecht, oder?

Anbei das aktuelle Design. Ja, ich sollte es besser in svn einschecken. 
Uns fehlt noch ein Konzept zur Verzeichnisstruktur.

Im schnellen Teil vom Bus habe ich einer Empfehlung folgend die 
Basisadressen so vergeben, daß sie sich bereits durch das MSB 
unterscheiden. Dann wird der Adreßdekoder sehr einfach, es ist einfach 
das Bit. Das kann auch Geschwindigkeitsvorteile bringen. Unsere 
Memory-Map ist nicht mehr kompatibel, aber warum sollte sie auch?
Ich habe ein paar PIOs für Tasten, SPI, Drehgeber etc. recht freihändig 
vergeben. Sind weniger als vorher, dafür etwas breiter. Denn da können 
wir bei der Gelegenheit auch aufräumen, warum soll jeder Fitzel seine 
eigene 1 Bit breite PIO haben? Das ist aber bei Bedarf leicht 
anzupassen, ist jetzt eher ein Platzhalter.

Ich verwende den SOPC Builder, nicht das neue Qsys. Der Grund dahinter 
ist das unsere Nios-Lizenz in der Firma auf Quartus 9 läuft, da gab es 
noch kein Qsys. Man kann das SOPC Design aber auch in Qsys laden und 
ggf. dort weiterarbeiten. Das habe ich auch ausprobiert (Qsys soll laut 
ALtera ja soo viel besser sein, das neue Persil...), aber es war kaum 
ein Unterschied, vielleicht 0,5 MHz schneller, das kann aber auch die 
Streuung der Anfangsbedingung sein. Auffällig ist das Qsys selbst viel 
langsamer arbeitet, die Erzeugung dauert ziemlich.

So long,
Jörg

von alex008 (Gast)


Lesenswert?

Hallo!

Nach langer Abwesenheit melde ich mich wieder mal zum FPGA Thema zu 
Wort:

@Jörg
Das meiste wird dir bekannt sein, bitte sehen meine Ratschläge zum neuen 
NIOSII FPGA-Design als Checkliste ansehen.

Niemals auf den JTAG verzichten, mit dem kann man auch nette 
Firmware-Updates machen + man könnte ihn eventuell zur 
Datenkommunikation  missbrauchen.

Grundsätzlich keine FPU verwenden!
Grund: macht den Rest langsamer!
Division braucht man auch nicht wirklich (Schiebebefehl).
Program Cache maximieren, Daten Cache vorsehen.
SRAM Zugriff schnell machen, da dies der Flaschenhals jedes CPU-Systems 
mit Framebuffer VGA ist (Pipelining).
Der SRAM des Welec verhält sich sehr eigenartig:
CS des SRAM unbedingt auf Aktiv low belassen (, solange man nicht mit 
dem anderen FPGA sprechen möchte!).
Überprüfen ob die Byte Write Zugriffe funktionieren: 
sprintf("%x",0x11223344)

@Jörg
Auch wenn es für dich sehr hart ist: Mache dich mit dem Gedanken 
vertraut, den Code im SRAM auszuführen, ansonsten wird dir warscheinlich 
das Oszi performancemäßig einschlafen.

Schneller Bus:
Slaves:
SRAM, FLASH, SignalSpeicher (Blockram im Trigger-ea.vhd)
Master:
NIOSII, VGA-Master, DMA (, JTAG)

Der Rest kommt in den langsamen Bus!

MfG
Alexander

von Jörg H. (idc-dragon)


Lesenswert?

alex008 schrieb:
> Hallo!
>
> Nach langer Abwesenheit melde ich mich wieder mal zum FPGA Thema zu
> Wort:

Willkommen, @all: Alex war gestern auch im Chat, was denke ich zum 
jetzigen Zeitpunkt sehr nützlich ist.

> @Jörg
> Das meiste wird dir bekannt sein, bitte sehen meine Ratschläge zum neuen
> NIOSII FPGA-Design als Checkliste ansehen.

Danke, in Folge noch ein paar Kommentare.

> Niemals auf den JTAG verzichten, mit dem kann man auch nette
> Firmware-Updates machen + man könnte ihn eventuell zur
> Datenkommunikation  missbrauchen.

Er kostet uns aber ca. 10 MHz Performance. Ich würde ihn nur in der 
Developerversion drinlassen. Dort ist er in der Tat sehr nützlich.
Firmware-Updates sollen wie gehabt über den Bootloader laufen, finde 
ich.
Zur schnellen Datenkommunikation habe ich den RS232 entdrosselt, mal 
schauen was der zu 2x...8x mal 115200 Baud sagt. Ganz aktuell ist nun 
auch ein UART mit FIFO drin.

> Grundsätzlich keine FPU verwenden!
> Grund: macht den Rest langsamer!

Ich habe es ausprobiert: Das tut sie in der Tat, aber ist nicht so wild, 
etwa 3 MHz. die CPU wird aber 50% größer. Wenn wir aus irgendwelchen 
Gründen eh Tempo rausnehmen müssen wäre die FPU ggf. drin.

> Division braucht man auch nicht wirklich (Schiebebefehl).

Habe ich auch ausprobiert, der Divisionsbefehl hat keine Nachteile. 
Aktuell ist er drin.

Die Software würde derzeit allerdings von beidem nicht profitieren. Es 
ist in keiner inneren Schleife eine Division oder gar Fließkomma. Soll 
hoffentlich auch so bleiben.

> Program Cache maximieren, Daten Cache vorsehen.

Weil unser SRAM so schnell ist habe ich die Caches minimiert, 512 Bytes 
für Code (ohne geht nicht), kein Datencache. Hintergrund ist das ich 
gern den Samplespeicher von 16K/Kanal auf eher 24K/Kanal vergrößern 
würde. Dazu muß man beim Rest extrem sparsam sein, nur noch 9 RAM-Blöcke 
wären dann übrig. Braucht deine Filterung welche?

> SRAM Zugriff schnell machen, da dies der Flaschenhals jedes CPU-Systems
> mit Framebuffer VGA ist (Pipelining).
> Der SRAM des Welec verhält sich sehr eigenartig:
> CS des SRAM unbedingt auf Aktiv low belassen (, solange man nicht mit
> dem anderen FPGA sprechen möchte!).

Scheint ohne besondere Maßnamen zu funktionieren. Ein genauerer 
Speichertest steht noch aus. Wir haben mit dem Avalon auch ein anderes 
Bussystem, andere Komponenten.

> @Jörg
> Auch wenn es für dich sehr hart ist: Mache dich mit dem Gedanken
> vertraut, den Code im SRAM auszuführen, ansonsten wird dir warscheinlich
> das Oszi performancemäßig einschlafen.

Das ist keine Härte, sondern schon immer so gelaufen.
Ich hatte im Hinterkopf, unkritische Codeteile im üppig großen Flash 
laufen zu lassen, falls es im SRAM eng wird.

> Schneller Bus:
> Slaves:
> SRAM, FLASH, SignalSpeicher (Blockram im Trigger-ea.vhd)
> Master:
> NIOSII, VGA-Master, DMA (, JTAG)
>
> Der Rest kommt in den langsamen Bus!

Ich bin noch weiter gegangen und habe auch das Flash am langsamen Bus. 
Den DMA-Controller habe ich mir auch vorerst verkniffen, der kostet uns 
derzeit heftige 20 MHz. Eine kleine Assembler-Kopierschleife im Cache 
der CPU ausgeführt ist vermutlich fast genauso schnell.

Auf das Sample-RAM muß man über extern zugreifen können, von daher kommt 
es wohl auch nicht an den schnellen Bus. Ich habe noch keine Ahnung, wie 
das zu bewerkstelligen ist.

Im Moment bin ich am LCD-Controller dran. Er kann bereits das Timing 
generieren, auf dem Schirm sind aber noch keine Daten sondern eine feste 
Farbe.

FPGA-Mitstreiter sind herzlich willkommen!

Grüße
Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Ein paar Updates:

Ich habe das neue FPGA-Design jetzt bei Sourceforge ins svn eingecheckt. 
Besser als hier Zipfiles posten, gell?
Die Verzeichnisstruktur habe ich soweit mir möglich aufgeräumt, was geht 
in Unterverzeichnisse, weil Quartus das Projektverzeichnis zumüllt.

Es gibt eine Wiki-Seite zu unserem neuen Projekt:
https://sourceforge.net/apps/trac/welecw2000a/wiki/niosII

Mit dem LCD-Controller geht es voran. Ich habe ihn der Übersichtlichkeit 
halber in 3 Teile geteilt, für Pixel- und Sync-Erzeugung, 
Programmierregister und DMA-Speicherleser. Letzterer ist noch nicht 
fertig.

Jörg

von alex008 (Gast)


Lesenswert?

Hallo Jörg!

RAM-Blöcke:
Ja, meine Filterung braucht diese FPGA internen RAM-Blöcke.
Auswendig weiß ich das leider nicht mehr.
1GS/s->100MS/s keine
100MS/s->10MS/s ????
10MS/s->1MS/s + darunter:
sollte jeweils ein Block-RAM pro Kanal sein und ist konfigurierbar.
Siehe Utilisation by Entity im Quartus Map? Report.

Den Sample-Speicher von 16 kB auf 24 kB zu erweitern sehe ich als nicht 
sinnvoll an.
Stattdessen sollte ein ein intelligienter DMA mit höchster Priorität die 
Daten vom Samplepuffer in den externen SRAM schreiben.
Das könnte theoretisch vielleicht sogar bis 20 MS/s gehen.

Hast du schon mal ein printf("%d ",12345678) ausprobiert?
Damit kannst du sichergehen, dass die Grafikfehler eines deiner Bilder 
nicht von fehlerhaften Halfword- oder Byte-Write- SRAM-Zugriffen kommt.
Solche Fehler führen nur sehr selten zu einem Absturz, da die Pointer 
bei 32 Bit Systemen 32 Bit groß sind.

Wie viele LUTs verbraucht nun das Design mit dem NIOSII ohne FPU?
Das LEON3 Design hat ca. 17000 gebraucht.
Davon hat mein Teil über 7000 LUTs ausgemacht.
Grund meiner Frage ist, dass je nach Design und FPGA das ganze ab einer 
bestimmten größe (1/3 bis 1/2) der FPGA Kappazität viel langsamer wird!
Zweitens bin ich mir nicht sicher, wenn du meinen Signalerfassungsteil 
verwenden möchtest, dass eine Verwendung von ungleich 2^n Bytes für den 
Signaldaten-Speicher leicht zu bewerkstelligen ist.

Da wäre schon sinnvoller das auf die wahnsinnig performante ZynQ 
Plattform oder die vergleichbare Cyclone V SOC zu bringen.
Der ZynQ hat glaube ich noch einen zweiten DDR3? RAM Controller für den 
FPGA Bereich (DDR3 Samplespeicher :-) ).
Übrigens gibts für die Teile schon preiswerte Tochterboards mit SRAM und 
FLASH.

Alexander

von branadic (Gast)


Lesenswert?

Etwas offtopic, passt aber gut hier rein.
Offenbar haben sich die Jungs von Wittig noch nicht vollständig aus dem 
Scope-Geschäft zurück gezogen, wie ein aktueller Artikel aus der 
Elektronikpraxis beweist:

http://www.elektronikpraxis.vogel.de/messen-und-testen/articles/374429/

Zitat:
"... Das Open-Source-Oszilloskop misst 76 mm x 84 mm und ist für 59 Euro 
plus Mehrwertsteuer direkt bei Wittig zu beziehen..."

branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

...und alles open source! Das ist doch mal ein Ansatz!
Software, Schaltplan...
Ob da finanziell viel hängen bleibt? Produktion in China und Versand 
nach D, aber die Bauteile sind auch nicht ganz zum Nulltarif (A/D 
Wandler, Display...)

Gruß, Brunowe

von branadic (Gast)


Lesenswert?

Bruno We schrieb:
> Produktion in China und Versand
> nach D

Laut Leiterplattenaufdruck "Made in Italy"

branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

das mit der Produktion ist ne echt eigenartige Sache. Wer das Ding als 
letztes in der Hand hatte und daran produktiv tätig war, kann seinen 
Staat als Produktionsstätte angeben. Evtl. wurde in Italien noch ein 
Schutzlack auf die Platinen aufgebracht oder ein Käbelchen angelötet.
Glaubt mir, das ist gar nicht so selten. Ich arbeite in einem 
EMV-Prüflabor und hab öfter mit so einem Vorgehen zu tun.

Gru0, Brunowe

von Jürgen (Gast)


Lesenswert?

branadic schrieb:
> Etwas offtopic, passt aber gut hier rein.

Nein, das passt wirklich nicht mehr hier! ist einfach nur off topic.

von Jörg H. (idc-dragon)


Lesenswert?

Hallo liebe Leut',

ich bin aus dem Urlaub wieder da. Vor ein paar Stunden gelandet, leicht 
zeitverschoben und gaaanz müde...
Schnell noch ein paar Anmerkungen zu Alex:

alex008 schrieb:
> Den Sample-Speicher von 16 kB auf 24 kB zu erweitern sehe ich als nicht
> sinnvoll an.

Schade, ein bischen mehr hätten wir uns noch leisten können. Zugegeben 
wird die Adressierung komplizierter.

> Stattdessen sollte ein ein intelligienter DMA mit höchster Priorität die
> Daten vom Samplepuffer in den externen SRAM schreiben.
> Das könnte theoretisch vielleicht sogar bis 20 MS/s gehen.

Aber leider nur für Kanal 1+2, nicht für das 2. FPGA bei den 4Kanälern? 
Zumindest fällt mir nichts ein, wie man das vernünftig lösen könnte. 
FPGA1 liefert die Adressen, FPGA2 die Daten? Ginge nur mit dem 
25MHz-Clock, weil den beide FPGAs haben. Display und CPU wollen aber 
auch dran.

> Hast du schon mal ein printf("%d ",12345678) ausprobiert?

Noch nicht, im Moment kriege ich noch gar nichts hin... Hoffentlich nur 
Anlaufschwierigkeiten.

> Damit kannst du sichergehen, dass die Grafikfehler eines deiner Bilder
> nicht von fehlerhaften Halfword- oder Byte-Write- SRAM-Zugriffen kommt.

Soweit bin ich noch nicht, "eigene" Grafikfehler zu produzieren.  ;-)
Der Pixelsturm war mit dem Welec-Design.

> Solche Fehler führen nur sehr selten zu einem Absturz, da die Pointer
> bei 32 Bit Systemen 32 Bit groß sind.

Lesen sollte eigentlich immer gehen, weil er das nur 32bittig macht und 
intern maskiert. Beim Schreiben wird es spannender, ob man die Byte 
Enables richtig verdrahtet hat.

> Wie viele LUTs verbraucht nun das Design mit dem NIOSII ohne FPU?
> Das LEON3 Design hat ca. 17000 gebraucht.
> Davon hat mein Teil über 7000 LUTs ausgemacht.

Hui. Der Nios II ist etwa halb so groß.
Mein LCD-Controller wird allerdings auch einiges brauchen, alleine 1024 
Flipflops, für die 16 Schieberegister der Planes und weitere 16 
Prefetch-Register (alle 32 Bit breit).

> Grund meiner Frage ist, dass je nach Design und FPGA das ganze ab einer
> bestimmten größe (1/3 bis 1/2) der FPGA Kappazität viel langsamer wird!

Davor habe ich auch schon Angst. Vielleicht helfen Layout-Tricks wie 
diese LogicLocks.

> Da wäre schon sinnvoller das auf die wahnsinnig performante ZynQ
> Plattform oder die vergleichbare Cyclone V SOC zu bringen.
> Der ZynQ hat glaube ich noch einen zweiten DDR3? RAM Controller für den
> FPGA Bereich (DDR3 Samplespeicher :-) ).
> Übrigens gibts für die Teile schon preiswerte Tochterboards mit SRAM und
> FLASH.

Mit anderer Hardwareplattform ist natürlich einiges möglich. Mein Ziel 
ist aber, das Welec so wie es ist (mit ggf. kleineren Mods) auszureizen.
Ein neues Mainboard dafür zu bauen ist zwar auch interessant, hätte z.B. 
eine Chance die Analogprobleme lösen, aber wäre teuer und hätte nur eine 
sehr kleine Nutzerbasis.

So long
Jörg

von alex008 (Gast)


Lesenswert?

Hallo Jörg!

Jörg schrieb:

> Aber leider nur für Kanal 1+2, nicht für das 2. FPGA bei den 4Kanälern?
> Zumindest fällt mir nichts ein, wie man das vernünftig lösen könnte.
> FPGA1 liefert die Adressen, FPGA2 die Daten? Ginge nur mit dem
> 25MHz-Clock, weil den beide FPGAs haben. Display und CPU wollen aber
> auch dran.

Man muss nicht ubedingt den ursprünglichen 25 MHz Takt für den 
Datenaustausch zwischen den FPGAs verwenden. Ich gehe davon aus, dass 
eine Taktviertelung über Strobesignale ausreicht um den Datenaustausch 
zwischen den FPGAs zum laufen zu bringen.
Ausserdem sind alle gleichfunktionierenden Takte des zweiten FPGAs zu 
zum ersten synchron, da sie ja aus dem selben Ursprungsquarz abgeleitet 
werden.
Da würde es dann reichen, wenn man ein einfaches Togglesignal nimmt, bei 
dem man bei der steigenden Flanke liest und bei der fallenden schreibt 
(so wie bei dem SPI).
Vielleicht funktioniert das auch ohne Taktviertelung (, falls die 
Verzögerungszeit zwischen den Register der FPGAs höher ist, als deren 
PLL-Jitter -> 2*200 pS)!

MfG
Alexander

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Alex & alle,

Danke für deinen Beitrag. Stimmt, die PLLs in beiden FPGAs laufen ja 
halbwegs synchron, vielleicht läßt sich damit was anfangen. Ich hatte da 
zuwenig Vertrauen. Das mit der Taktviertelung habe ich nicht verstanden, 
wodurch entstünde die? Irgendwas geviertelt ist trotzdem schneller als 
25 MHz?

Am Tristate Master des SRAM habe ich meinen schnellen Busclock von 
derzeit 75-94 MHz. Die Gegenseite muß dann auch damit klarkommen, ich 
weiß nicht ob und wie verschiedene Geschwindigkeiten möglich sind. 
Wittig hat an diesen Bus noch andere Teilnehmer angeschlossen, nämlich 
den Zugriff auf Capturespeicher und Konfiguration. So liest man da vom 
eigenen FPGA oder vom anderen. Die Adressen sind anscheinend nicht 
durchverbunden, deshalb gibt es da nur einen Auto-Inkrement.

Ich sehe noch nicht wie man einen weiteren Master von außen in das 
andere FPGA kriegen würde. Und ich bin bestimmt zu begriffsstutzig das 
hier abschließend zu klären, damit langweilen wir den Rest, besser bei 
Gelegenheit im Chat. ;-)

So, nun an alle:

Ich freue mich gerade, daß ich am Wochenende meinen LCD-Controller zum 
Laufen bekommen habe, mein erstes Design im FPGA. Das ging sogar relativ 
problemlos, fast auf Anhieb.
Ähnlich zum Original liest er parallel aus 16 unabhängigen Bitplanes 
(definierbar, könnten auch weniger sein) und legt die gewissermaßen 
transparent übereinander. Jede Plane hat eine definierte Farbe, das 
oberste gesetzte Pixel-Bit "gewinnt", das Pixel kriegt deren Farbe.
Im Unterschied zum Original sind die Startadressen und die Farben 
programmierbar, können also zur Laufzeit herumjongliert werden.

Läuft erstmal, es gibt noch ein paar Dinge zu verbessern:
- Es sind noch Warnings drin über inkompatible Bitbreiten.
- Ich habe eine Idee wie ich die Hälfte der Flipflops einsparen kann, 
wenn ich einen Memoryblock als FIFO einsetze. Dann muß ich Schieben und 
Farbbestimmung vorher machen.
- Der VSync-Interrupt ist noch nicht da, ferner will ich in einem 
Kontrollregister das Scanning abschaltbar machen.

Als ich mit dem Quartus-eigenen Logic Analyzer die Bustimings angeschaut 
habe mußte ich leider feststellen, daß unser SRAM nicht mit 0 Waitstates 
angesteuert wird, sondern mit 2. Es ist also 3 mal langsamer als 
vermutet. Das ist ein ziemlicher Klotz am Bein, die LCD-Zugriffe lasten 
es nun bereits zur Hälfte aus. Ich weiß noch nicht wo das herkommt, ob 
es durch Multimaster und Arbitrierung passiert oder durch den 
SRAM-Controller. Den hatte ich eigentlich schon mal überflogen und zuvor 
nichts Bremsendes festgestellt.

Von diesen Optimierungen abgesehen wären als nächstes die SPI-Sachen 
dran, LEDs, Drehgeber, Tasten. Ich suche auch noch, wo die Leitungen für 
die ersten beiden Softkeys an das FPGA angeschlossen sind. Die haben 
nämlich eine Sonderbehandlung, für den Reset/Bootloader. In den bisher 
bekannten Pins tauchen sie nicht auf.

Soweit erstmal,
Jörg

von Andiiiy (Gast)


Lesenswert?

Jörg H. schrieb:
> Und ich bin bestimmt zu begriffsstutzig das
> hier abschließend zu klären, damit langweilen wir den Rest, besser bei
> Gelegenheit im Chat. ;-)

Hallo Jörg,
hallo Alex,

ich möchte Euch weiter ermuntern ... WIR LESEN GERNE MIT!

Welche Version von Quartus nimmst Du Joerg ? Aus den Quellen lese ich 
die Version 9.1!
Ist das die Quartus II Web Edition Software Version 9.1 Service Pack 2 
... ?

Da ich derzeit nur 4-Kanal-Versionen im Besitz habe, ist mir noch nicht 
klar ob ich die FW über den Blaster dirket in beide FPGA's lade ... Als 
ich die alte Welec-Version gesichert hatte, war nur einer zu sehen!
Wenn ich richtig auf der Platine gesehen habe, kann aber jeder einzeln 
bespielt werden.

Gruß Andiiiy

von Jörg H. (idc-dragon)


Lesenswert?

Andiiiy schrieb:
> Welche Version von Quartus nimmst Du Joerg ? Aus den Quellen lese ich
> die Version 9.1!

Bei der Arbeit, ja. Das ist die Version, mit der die späteren Releases 
entstehen würden, wegen Nios-Lizenz.
Zuhause verwende ich Version 11. Damit läuft der Nios nur eine Stunde im 
Evaluierungsmodus, bzw. länger mit angeschlossenem Debugger. Zum 
Rumbasteln reicht das.
Je nachdem welchen Stand ich gerade einchecke steht da also 9 oder 11, 
nicht verwirren lassen!

> Ist das die Quartus II Web Edition Software Version 9.1 Service Pack 2
> ... ?

Mag sein...

Wie das mit dem 2. FPGA laden geht weiß ich noch nicht. Wenn man das 
Config-Flash sichert (*.jic oder *.pof) sind aber beide dabei.


Wo ich gerade tippe:
Ich weiß jetzt wo die Waitstates herkommen.
In dem Script unter 
"ip/altera/nios2_ip/altera_nios_dev_kit_stratix_edition_sram/mk_sram.pl" 
ist ein Check auf >50MHz, dann wird was eingefügt. Wenn ich den 
SOPC-Builder bescheiße und dort als Memory-Clock weniger eingebe (die 
Angabe ist eh rein informativ), dann kriegen wir 0WS, aber es funktiert 
nicht richtig, weil das Read-Signal zu spät kommt.

Eine richtige Lösung dagegen habe ich aber noch nicht. Mir scheint, 
Altera hat gar keinen "richtigen" Controller für asynchrones SRAM im 
Sortiment. Die drehen nur die Bustimings so, das man ein SRAM zwar 
direkt anschließen kann, es aber nicht optimal angesteuert wird.
Bei Gelegenheit schaue ich mal, ob man einen als Komponente bauen kann. 
Betrachte ich aber als nicht vordringlich. Dürfte nicht so schwer sein. 
Schreiben ist blöd, weil man da einen Puls braucht, passt nicht so ins 
Taktraster. Ein halber Takt ist zu wenig, wenn man einen ganzen nimmt 
muß man bei aufeinanderfolgenden Writes einen Waitstate erzwingen, damit 
es auch ein Puls wird. Könnte zu verschmerzen sein, dürfte selten 
auftreten.

Eher ärgere ich mich über die 2 noch nicht gefundenen Tasteneingänge. 
Was kann man denn da machen, gibt es eine Art Durchklingeltool? Wenn ich 
im Projekt unbenutzte Eingänge auf Masse ziehen lasse sind diese 
Eingänge auch low. Fallen also in diese Kategorie.

Apropos Durchklingeln:

Ich würde da gern noch andere Tests machen, mag mir ein 2Kanal-User beim 
Messen helfen, oder mir seine Hauptplatine ausleihen (ganzes Gerät muß 
nicht)?
Beim 2Kanäler sind ja die Pads des 2. FPGA zugänglich. Ich würde gerne 
testen, ob z.B. die Adressleitungen wirklich nicht angeschlossen sind, 
oder read/write tatsächlich doch. Müßte teils im Betrieb erfolgen, was 
knifflig ist, die FPGAs sind auf der Vorderseite. Ich habe mir 
Verlängerungsleitungen für abgesetzten Betrieb gebastelt.
Außerdem hat Osoz ja noch ein Problem mit 2Kanälern, was ich nicht 
debuggen kann.

Jörg

von Guido B. (guido-b)


Lesenswert?

Hallo Jörg,

ich kann dir gerne meinen Zweikanaler (W2012A) zum Testen zur
Verfügung stellen. Ich werde sicher über längere Zeit nicht
dazukommen etwas damit anzufangen, lese aber immer noch begeistert
mit. Achso, der Powerschalter müsste ersetzt werden. :-(

Grüße, Guido

von Jörg H. (idc-dragon)


Lesenswert?

Guido, danke für das Angebot, du hast eine PM.

zum Stand der Dinge:
Eine der beiden Softkey-Leitungen habe ich nun (wieder)gefunden, 
erinnerte mich dran, daß F2 im vorliegenden Design einen Reset auslöst. 
Es ist also der dort als reset_n bezeichnete FPGA-Pin V14. Ich bringe 
gerade meine Pinliste auf Vordermann.

Nun suche ich noch den anderen. Das ganze soll dem noch zu erstellenden 
Bootloader dienen, damit der sich wie gewohnt komfortabel verhalten 
kann.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Ich war zu voreilig, es war nicht reset_n, sondern master_slave, Pin E9. 
Der hat im Wittig-Design eine ähnliche Wirkung, weil beim Slave, dem 2. 
FPGA, die CPU im Reset gehalten wird.

Die Pinnings sind doch noch recht unterschiedlich. Slog wußte es besser, 
in seiner Liste stand das drin. Auch den 2. Softkey habe ich nun dank 
Slog gefunden, im Wittig-Design heißt der noch clk_led, Pin AB12. Es ist 
ein bischen durcheinander, Wittig hat später wohl noch ein paar Dinge 
geändert.

Dummerweise wissen wir jetzt nicht mehr, wo der echte master_slave Pin 
nun zu liegen gekommen ist. Mathias hat ein Boundary-Scan Tool, das 
könnte helfen, in Verbindung mit der 2kanal-Platine. Gesucht ist ein 
Pin, der am 1. FPGA auf high und beim 2. auf low liegt.

Nochmal zu den wiedergefundenen Softkeys:
Als kleine Änderung habe ich im FPGA-Toplevel den Reset mit den beiden 
verodert. Drücken beider Softkeys gleichzeitig löst einen Reset aus, wie 
gehabt. Die Leitungen liegen auch an einem Input-Port, so daß die 
Software sie lesen kann. Dann kann ein Bootloader reagieren wenn eine 
bestimmte noch gehalten ist. An der Baustelle könnte es also losgehen...

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Ein Update:

Jörg H. schrieb:
> Läuft erstmal, es gibt noch ein paar Dinge zu verbessern:
> - Es sind noch Warnings drin über inkompatible Bitbreiten.
> - Ich habe eine Idee wie ich die Hälfte der Flipflops einsparen kann,
> wenn ich einen Memoryblock als FIFO einsetze. Dann muß ich Schieben und
> Farbbestimmung vorher machen.
> - Der VSync-Interrupt ist noch nicht da, ferner will ich in einem
> Kontrollregister das Scanning abschaltbar machen.

Die Sache mit dem FIFO habe ich jetzt eingebaut. Spart zum Preis eines 
Memoryblocks etwa 512 Flipflops, plus/minus etwas Veränderung an der 
Logik drumrum. Die Maximalfrequenz ist um ein paar MHz gestiegen. 
Anscheinend hatte ich da einen kritischen Pfad gebaut.
Wenn da jemand mit RTL-Erfahrung mal draufguchen mag: der DMA-Teil 
erscheint mir recht groß, ich sehe dicke Multiplexer. Vielleicht 
entstehen die durch ein unbedarftes if() im HDL, vielleicht geht das 
besser.

Auch habe ich die Programmierregister verändert: es sind nun getrennte 
Register, mit denen Basisadresse und Farbe eingestellt werden. Das ist 
für die Software einfacher, weil sie i.d.R. nur eines von beiden 
verändern wird.
Die Komplexität der Hardware beeinflußt es quasi nicht.

Nun gucke ich nochmal auf das Thema Waitstates. Bin aber noch nicht 
damit durch. Das IP für das RAM habe ich versuchsweise in unser Projekt 
kopiert. Dort kann ich dann dran rumändern. Habe es statt für IDT71V416 
etwas umgedengelt auf unser IS61LV51216 und experimentiere mit den 
Timings.
Es ist ein sog. "Tristate Slave" (bzw. ein Script das einen erzeugt), 
zum Anschluß hinter einen "Tristate Master". Man kann so mehrere Slaves 
an einen Bus hängen. Das brauchen wir auch, nämlich für den Zugriff auf 
das andere FPGA.
Dummerweise hat ein Tristate Slave keinen Zugriff mehr auf das 
Wait-Signal. Das wird ihm bereits abgenommen, man konfiguriert bei der 
Erstellung pauschal die gewünschten Waitstates, Quartus baut dann selbst 
eine Logik dafür. Ich hätte es aber gern weniger pauschal, für read und 
write unterschiedlicher, und je nach Vorgeschichte...

Eine Lösung wäre, auch den Tristate Master selbst zu bauen. Der kann das 
definitiv noch selbst steuern. Dann müssen wir uns aber selbst "zu Fuß" 
um die Sache mit dem 2. FPGA kümmern. Kann sein das man das eh besser 
täte. Ist aber erstmal mehr Arbeit.

So long
Jörg

von alex008 (Gast)


Lesenswert?

Hallo Jörg!

Falls du ein wenig mit der Suche nach dem Master/Slave Pin suchst:
Wieso nimmst du nicht einfach die Schieberegisterkette für die 
Drehknöpfe, Taster + DACs her?
Wenn du da einen Mist beim DAC (lauter einser oder lauter nuller) 
ausließt, könnte man doch darauf schließen, dass die SW am FPGA2 läuft.
Des weiteren könnte man die EMV Problematik verringern, indem man zwei 
verschiedene FPGA Designs baut.

LCD DMA Controller optimierungen:

78   wire next_planeaddress;
79   assign next_planeaddress = datafetch_pulse || (loading && 
!waitrequest && (plane_load != PLANES));
80
81   wire all_reads_done; // when all plane reads are done
82   assign all_reads_done = loading && !waitrequest && (plane_load == 
PLANES);

Diese zwei Zuweisungen könnte man zwei Registerzuweisungen machen (extra 
Pipeline-Stufe, die einiges zum umschreiben verlangt!).

if (reset_n == 0)
89   begin
90   loading <= 0;
91   end
92   else if (datafetch_pulse)
93   begin
94   loading <= 1; // set to active
95   end
96   else if (all_reads_done)
97   begin
98   loading <= 0; // in consequence, this de-asserts all_reads_done, 
makes it a one cycle pulse
99   end

So sollte man keine HDL Code schreiben.
Eine Registerbeschreibung hat immer so auszusehen!

if (reset_n == 0)
 begin
 x = 0;
 ...
 end
else
 begin
  if (y == 0)
   x++;
  else if (...)
   begin
   ...
   end
 end
end

VHDL:
if reset_n = '0' then
 x <= 0;
elsif rising_edge(clk) then
 if (x != 0) then
   x <= x +1;
 elsif (...) then
   ...
 end if;
end if;

Und das was sicher am meisten bringen wird.

164   if (next_planeaddress)
165   begin
166   load_address <= RAM_Base_Address | ((planeoffset[plane_load] + 
reg_addrcount) << 2);
167   end

vor 164:
offset <= planeoffset[plane_load];

statt 166:
load_address(upper:middle+1) <= RAM_Base_Address(ub:mb+1);
load_address(middle:2) <= RAM_Base_Address(mb:2) | offset + 
regaddrcount;
load_address(1:0) <= 0;

Bitte das nicht als funktionierenden Code ansehen, nur als Hilfestellung 
für die Optimierung der Taktgeschwindigkeit. Das zusätzliche Offset 
Register musst du anderswo ausgleichen!

Danach bist du die Verzögerung des Multiplexers los + kleinerer Addierer 
+ weniger oder Verknüpfungen.


MfG
Alexander

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Hallo Alex, danke für's Feedback!

> Falls du ein wenig mit der Suche nach dem Master/Slave Pin suchst:
> Wieso nimmst du nicht einfach die Schieberegisterkette für die
> Drehknöpfe, Taster + DACs her?
> Wenn du da einen Mist beim DAC (lauter einser oder lauter nuller)
> ausließt, könnte man doch darauf schließen, dass die SW am FPGA2 läuft.

Muß aber in Hardware passieren. Den Prozessor können wir nicht starten, 
weil er nicht an Flash und RAM kommt.


> Des weiteren könnte man die EMV Problematik verringern, indem man zwei
> verschiedene FPGA Designs baut.

Wenn's denn nicht zu erkennen geht bräuchte man zwei verschiedene 
FPGA-Designs. Würde ich erstmal versuchen zu vermeiden.


> 79   assign next_planeaddress = datafetch_pulse || (loading &&
> !waitrequest && (plane_load != PLANES));
> 82   assign all_reads_done = loading && !waitrequest && (plane_load ==
> PLANES);
>
> Diese zwei Zuweisungen könnte man zwei Registerzuweisungen machen (extra
> Pipeline-Stufe, die einiges zum umschreiben verlangt!).

Du meinst das ist bereits zu viel Kombinatorik? Du hast gesehen das die 
Terme verschieden sind?


> So sollte man keine HDL Code schreiben.
> Eine Registerbeschreibung hat immer so auszusehen!
>
> if (reset_n == 0)
>  begin
>  x = 0;
>  ...

Du meinst, das ich nochmal extra begin-end um die die 
nicht-reset-Bedingungen schreiben soll? Oder ist was Funktionales dran 
faul?
Gut, kann ich machen.


> Und das was sicher am meisten bringen wird.
> vor 164:
> offset <= planeoffset[plane_load];

Du meinst, die Bestimmung des Offsets in einen anderen Takt auslagern? 
Hmm, dann habe ich das Ergebnis einen später. Erfordert Umbau, muß mal 
sehen wie das geht.


> statt 166:
> load_address(upper:middle+1) <= RAM_Base_Address(ub:mb+1);
> load_address(middle:2) <= RAM_Base_Address(mb:2) | offset +
> regaddrcount;
> load_address(1:0) <= 0;

So eine Zusammensetzung statt großem Oder hatte ich bereits versucht. 
Das Design wurde nicht kleiner (oder sogar größer?). Anscheinend erkennt 
die Synthese das bereits. Die Addition wird bestimmt nur so breit wie 
die Operanden ausgeführt, beim Oder werden konstant auf Null stehende 
Bits wohl auch erkannt.


Ansonsten:

Ich habe angefangen, einen neuen Speichercontroller zu schreiben, für 
mehr Performance. Wir werden wohl ohne "echte" Waitstates auskommen, 
brauchen aber Pipelining. Beim Lesen steht ein Datenwort erst nach 3 
Takten zur Verfügung, aber derweil können bereits 2 weitere Lesezugriffe 
angefangen werden.

Von Guido habe ich eine 2kanal Hauptplatine bekommen. Ich bin mühsam 
alle alle 484 Pins des 2. FPGA durchgegangen, leider fast ohne neue 
Erkenntnisse. Es ist kein Pins angeschlossen, der nicht schon bekannt 
wäre. Die Pinreihe über FPGA2 ist wohl zum Test, an verschiedene Pins 
angeschlossen die der nicht braucht (wären bei FPGA1 RAM-Leitungen).

Osoz habe ich auch drauf losgelassen, um zu schauen was für ein Problem 
der mit 2kanälern hat. Nach ca. 20 Capture-Runden kommt einfach kein 
Capture-Interrupt mehr, keine Ahnung warum. Diese Wittig-Capturelogik 
ist ja leider ein Buch mit sieben Siegeln. Also auch da keine schnellen 
Erkenntnisse.

Was ich aber rausgefunden habe: Hab' mich immer schon über die 3+3 
leeren Footprints rechts und links unterhalb von FPGA2 gewundert (siehe 
Bild). Je oben und unten ein 8poliger wie für ein Widerstandsarray, in 
der Mitte ein dickerer.
Die Boards sind anscheinend für eine individuelle Kalibrierung der ADCs 
zueinander vorbereitet. An den äußeren Pinreihen liegt von jedem der 16 
ADCs der Pin REFADJ an. Damit könnte man die ADCs einzeln trimmen. Ich 
weiß noch nicht was in die Mitte sollte, ein elektronisches 8fach Poti?


So long,
Jörg

von Michael D. (mike0815)


Lesenswert?

oh man Jörg, jetzt hast du aber an der falschen Stelle gespart( :-) ), 
ich habe eine 26 Zöller und kann das Bild kaum sichten...
Und es wird immer interessanter, Respekt!

Gruß Michael

von Jörg H. (idc-dragon)


Lesenswert?

Michael D. schrieb:
> oh man Jörg, jetzt hast du aber an der falschen Stelle gespart( :-) ),
> ich habe eine 26 Zöller und kann das Bild kaum sichten...

Ich hatte grad kein besser aufgelöstes Bild zur Hand. Das ist aus dem 
Wiki, schnell gecropt und 2 Kringel reingemalt.

Jörg

von Michael D. (mike0815)


Lesenswert?

Ich nehme alles zurück, habe auch nur das Pic und mir schon einen Wolf 
nach was brauchbarem gesucht.
Selber habe ich jede Menge Pic's gemacht, natürlich von dem Teil nicht, 
wie solls auch anders sein :-(((

Gruß Michael

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Besser so?
(Dank an Kurt für das Rohmaterial)

Jörg

von Michael D. (mike0815)


Lesenswert?

absolut!!! ;-)

von Jörg H. (idc-dragon)


Lesenswert?

Ich habe mal bei Digikey nach 8fach DACs in passendem Gehäuse gesucht:
Das fehlende Bauteil in der Mitte dürfte ein MAX5259 sein, Abmessungen 
und Belegung passen.
Ich weiß noch nicht wo die Steuerleitungen hinführen.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Jörg H. schrieb:
> Ich weiß noch nicht wo die Steuerleitungen hinführen.

Jetzt weiß ich es:
- DIN und SCLK gehen über je einen Transistor an die bekannte, "große" 
SPI-Chain, Data und Clock
- /CS geht an das FPGA, Pin E7, für den ersten DAC direkt, für den 
zweiten über einen Inverter
- /LDAC geht an das FPGA, Pin V9

Die FPGA-Pins hatten bei Wittig schon so verdächtige Namen, so kam ich 
drauf. Mit einem Testdesign im FPGA habe ich das nun überprüft.

Der Spaß kann also losgehen.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Wenn keiner was schreibt muß ich halt alleine weiterbloggen...

MAX5259 ist bestellt, sollte hoffentlich bald eintrudeln. Vermutlich 
kann man den DAC auch mit dem bestehenden Nios-Design ansteuern. Die 
Kalibrierung ist aber nur für die Modi interessant, bei denen mehrere 
ADCs arbeiten und deshalb zueinander kalibriert werden müssen. Genau 
diese Modi sind im alten Design aber ziemlich kaputt, wie ihr ja wißt. 
(Vertauschung, Spikes)

Zum neuen Design: (das kann noch lange nicht messen)
Heute habe ich die Vorschläge von Alex in meinen LCD-Controller 
eingearbeitet. Er hatte per Skype seinerzeit geduldig meine Rückfragen 
beantwortet. Nochmals danke an Alex, das er sich so tiefgehend damit 
beschäftigt hat.
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/nios2/altera/ip/W2000_LCD_Controller/lcd_dma.sv?r1=676&r2=684
Nun sieht es da drin schon aufgeräumter aus. Ist nun nicht mehr mein 
HDL-Erstlingswerk, sondern eher mein drittes...
Ich habe die Adressberechnung in 3 Pipelinestufen zerteilt. Etliche 
Kombinatorik wurde einfacher, dann habe ich noch überflüssige 
Bedingungen bei der Zuweisung der Ausgangsdaten gefunden.
Die Maximalfrequenz des Gesamtdesigns liegt nun etwa 5 MHz höher. 
Entweder lag das an einem kritischen Pfad bei mir, oder an nun 
gesunkener Komplexität.

Ansonsten schlage ich mich schon sehr lange mit meinem SRAM-Controller 
herum. Das Ding steigt mir oberhalb von 75MHz beim Schreiben aus, obwohl 
das eigentlich nicht sein kann. Lesen scheint zu gehen, und das ist 
kritischer. (Schön zügig, jeder Takt ein Datenwort.)

Jörg

von Andreas W. (andiiiy)


Lesenswert?

Das mit den zusätzlichen DAC's ist ja interessant. Ich hatte mich schon 
immer gefragt, wie die diese Teile Baugleich bekommen. Ich hatte vor ca. 
einem Jahr ein Oszi mit starken Spikes zu den Wittek-Brüdern gesendet. 
Als dieser zurück kam, waren die wirklich weg. Gesehen habe ich auf dem 
Board aber nichts. Wenn die die DAC's nicht einsetzten ... wie habe die 
das dann gemacht?

To Jörg:
Sehr schöne Erfolge ... man(n) kann ja jeden Tag die Neuerungen lesen 
und verfolgen ... ;-)

Wie testest Du denn den neuen FPGA-Inhalt? ... im Quartus ...oder hast 
Du schon ein System geschlachtet ... und arbeitest mit Testprogrammmen 
und NIOS2?

Grüße Andi

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Andreas,

> Ich hatte vor ca.
> einem Jahr ein Oszi mit starken Spikes zu den Wittek-Brüdern gesendet.
> Als dieser zurück kam, waren die wirklich weg. Gesehen habe ich auf dem
> Board aber nichts. Wenn die die DAC's nicht einsetzten ... wie habe die
> das dann gemacht?

Ist es denn noch die gleiche Hardware, oder wurde evtl. die Hauptplatine 
getauscht? Was für eine Hardwareversion hast du? (Mit der BF-Firmware 
unter Utility -> About)

> Wie testest Du denn den neuen FPGA-Inhalt? ... im Quartus ...oder hast
> Du schon ein System geschlachtet ... und arbeitest mit Testprogrammmen
> und NIOS2?

Schon mit der echten Hardware. Schlachten braucht man da nix. Mit dem 
Slog-Treiber braucht man das Gerät nicht mal öffnen.
Weil der unter 64Bit Windows nicht geht habe ich aber doch einen 
"echten" USB JTAG Adapter (Byteblaster) im Einsatz, an der Hauptplatine 
angesteckt.

So kann ich das FPGA mit meinem neuen Inhalt laden, Testprogramme für 
den Nios 2 hinterher. Ist (derzeit, mit Absicht) flüchtig, beim nächsten 
Einschalten ist wieder alles beim alten.

Jörg

PS: Ich mache endlich Fortschritte mit dem Speichercontroller. Später 
mehr.

von Andreas W. (andiiiy)


Lesenswert?

> Ist es denn noch die gleiche Hardware, oder wurde evtl. die Hauptplatine
> getauscht?

Die Seriennummer war noch gleich... Nun ist mir nicht klar ob die das 
Board getauscht haben und mir die alte SN eingespielt. Glaube ich aber 
fast nicht.

> Was für eine Hardwareversion hast du? (Mit der BF-Firmware
> unter Utility -> About)

Ich verwende beide Versionen ... 1C9.0L und 8C7.0E

> Mit dem Slog-Treiber braucht man das Gerät nicht mal öffnen.

Ja diesen hatte ich zum Auslesen/ Sichern des EPCS16 auch benutzt. Da 
ich die 4-Kanal-Variante verwende, musste ich aber vorher eine Brücke 
(Platinenjumper) schließen.

> Weil der unter 64Bit Windows nicht geht habe ich aber doch einen
> "echten" USB JTAG Adapter (Byteblaster) im Einsatz, an der Hauptplatine
> angesteckt.

Ja der USB-Blaster liegt auch noch vor mir und findet ab und an seinen 
Einsatz ...

> So kann ich das FPGA mit meinem neuen Inhalt laden, Testprogramme für
> den Nios 2 hinterher. Ist (derzeit, mit Absicht) flüchtig, beim nächsten
> Einschalten ist wieder alles beim alten.

Mir war gar nicht bewusst, dass Du den FPGA-Inhalt flüchtig gestalten 
kannst. Wie gehst Du denn dabei vor?
Ich verwende jetzt die selbe Quartusversion 11.0 wie Du. Nach einem Test 
mit der Version 9.1 und doch vielen Fehler hatte ich mich dann 
umentschlossen.
Leider war des UART-Modul noch eine Herausforderung, da dieser unbedingt 
den Ausgabepfad C:\Dokumente verwenden wollte. Eine Kompilierung (der 1 
Stundenversion) war aber später erfolgreich.

Andi

von Jörg H. (idc-dragon)


Lesenswert?

Andreas W. schrieb:
>> Was für eine Hardwareversion hast du? (Mit der BF-Firmware
>> unter Utility -> About)
>
> Ich verwende beide Versionen ... 1C9.0L und 8C7.0E

Du brutzelst das selber hin und her, deine nicht-mehr-Spikes sind also 
unabhängig vom FPGA-Inhalt?
Interessant, dann muß da ja was in echter Hardware verändert worden 
sein. Ich hoffe, dir fällt noch was auf?

> Mir war gar nicht bewusst, dass Du den FPGA-Inhalt flüchtig gestalten
> kannst. Wie gehst Du denn dabei vor?

Ohne Nios-Lizenz geht es sogar nur so, es werden keine ROM-Files 
erzeugt, sondern nur eine .sof Datei. Die kannst du mit dem Programmer 
oder dem Signal Tap Logic Analyzer übertragen. Ich nehme nur noch 
letzteren, weil ich in der Regel auch interne Signale angucken will. 
(Merkwürdigerweise muß man da aber immer zweimal probieren, beim ersten 
Mal tut er nix.)

> Ich verwende jetzt die selbe Quartusversion 11.0 wie Du. Nach einem Test
> mit der Version 9.1 und doch vielen Fehler hatte ich mich dann
> umentschlossen.

Mit 9.1 muß es aber auch passend gemacht werden, weil wir die auf der 
Arbeit haben. Im .tcl von meinem SRAM-Controller müssen noch ein paar 
inkompatible Zeilen raus, war beim LCD auch so.

> Leider war des UART-Modul noch eine Herausforderung, da dieser unbedingt
> den Ausgabepfad C:\Dokumente verwenden wollte. Eine Kompilierung (der 1
> Stundenversion) war aber später erfolgreich.

Komisch, hat bei mir auch unter Linux geklappt, ich wechsele da munter 
hin und her.


Jörg

von Andiiiy (Gast)


Lesenswert?

> Komisch, hat bei mir auch unter Linux geklappt, ich wechsele da munter
> hin und her.

Da es bei Dir sofort ging, habe ich mir heute das Thema noch einmal 
angesehen. Ja es liegt an den Pfadangaben im Windows. Bitte nutzt keinen 
Pfad mit einem Leerzeichen ... da scheint es teilweise im Quartus zu 
hängen.
Ich habe den Ordner direkt mal nach C:\NIOS2 geschoben ... und siehe da 
es geht (auch nach dem löschen der UART's.v).

Mit dem Signal Tap Logic Analyzer kann ich noch nicht starten, da ich 
zwar die Enwicklungsplattform sehe (durch den Slog-Treiber) aber noch 
keinen FPGA. Es scheint so als ob ich erst wieder die genannte Brücke 
schließen muss.

Andi

von Jörg H. (idc-dragon)


Lesenswert?

Ich wollte ja noch was zum Speichercontroller schreiben, der das SRAM 
ansteuert:

Nach laaangem Getüftel kann ich das nun mit voller Geschwindigkeit ohne 
Waitstates (nur Latenz für Pipelining), aber es ist knifflig und hat so 
seine Kompromisse. Ich kann auch nicht gut testen, denn um mein 
Speichertestprogramm laufen zu lassen brauche ich derzeit den JTAG, der 
den Nios langsamer macht.

Ich brauche verschobene/verlängerte Hilfs-Takte:

Einen für die Datenübername beim Lesen, denn das SRAM tut uns nicht 
unbedingt den Gefallen, die Daten passend zu einer normalen Clockflanke 
gültig zu haben. Die Daten können/müssen 27ns nach Anlegen der Adresse 
durch das FPGA übernommen werden. Solange dauert die Runde raus aus dem 
FPGA, zum RAM, Zugriff (nominell 8ns) und wieder rein. Bei 75 MHz klappt 
das gut, das sind 2 Takte. Aber je nach Taktrate ist da keine Flanke, 
dann muß besagter Hilfsclock das in ein Register takten, von dem es 
weiter übernommen wird. Das Spiel konnte ich testweise bis 125 MHz(!) 
treiben (ohne CPU, nur LCD gucken), aber der Übernahmezeitpunkt wird 
super-kritisch, im sub-ns Bereich. Die CPU lief stabil mit 94 MHz.

Der zweite Takt für den Schreibpuls. Den brauchen wir einmal pro Takt, 
aber laut Datenblatt muß er mindestens 6.5ns breit sein. Man kann 
kombinatorisch mit dem Takt verknüpfen, kriegt dann einen Puls mit 
halber Zyklusdauer. Ab 75MHz wird der aber zu kurz. Dann brauche ich den 
zweiten Hilfstakt, mit Duty Cycle > 50% und passender Phasenlage. Damit 
geht auch das Schreiben mit 94 MHz, aber etwas instabil, ich habe das 
noch nicht so genau eingestellt.

Im Moment habe ich noch die 2kanal Platine von Guido da. Ein kurzer Test 
mit meinen Timings schlug fehl, vermutlich ist der Bus schneller weil 
die Last des 2. FPGAs fehlt, und/oder Exemplarsteuung.

Für diese verschobenen Takte werden die PLL-Resourcen knapp. Wir haben 4 
PLLs, mit je 3 Ausgängen. Derzeit erzeugt jede der PLLs einen der 4 
verschobenen Quadraturclocks für die ADCs. Bei Alex zusätzlich noch 
einen halb so schnellen, mit dem er seine Verarbeitung macht. Bleibt 
noch je ein Ausgang frei für unsere Zwecke, aber wenn ich meine 3 Clocks 
aus verschiedenen PLLs nehme stehen die nicht so wie sie sollen. Man 
müßte das also anders belegen, könnte nachteilig für die 
ADC-Taktqualität sein.

Fazit: 75 MHz für den Nios ist ein "sweet spot". Ihn so schnell zu 
takten wie derzeit synthetisierbar ist möglich, aber das 
Speicherinterface wird knifflig.


Jörg

von Michael (Gast)


Lesenswert?

Hallo Jörg,

tolle Arbeit die du da leistes.

Eines verstehe das nicht. 27ns für eine Runde. Was braucht da so lange?

8ns braucht das RAM. Dann haben wir noch 19ns. In der Zeit legt das 
Licht 5,7m zurück. OK auf der Leiterkarte warscheinlich nur 2m. Also 
sind es die Leitungslänge schon mal nicht. Sind die Bussteiber im FPGA 
richtig eingestellt?

Michael

PS. Habe leider von der Materie zu wenig Ahnung um zu helfen.

von Jörg H. (idc-dragon)


Lesenswert?

Michael schrieb:
> Eines verstehe das nicht. 27ns für eine Runde. Was braucht da so lange?
Kommt mir auch viel vor, ich weiß nicht. Die "fehlenden" 19ns sind für 
raus und rein, pro Richtung also etwa 9 ns. Es gibt innerhalb des FPGA 
natürlich Delays, und rückwärts ist vor dem Eintakten eine Setup-Zeit 
einzuhalten. Was haben wir denn so, ein paar Werte habe ich versucht 
nachzulesen:
- von Taktflanke bis es tatsächlich im Register ist: 0.3ns
- Routing vom Register zum Ausgang: je nachdem
- Geschwindigkeit des Ausgangs, in Konfiguration LVTTL 24mA: 3ns
- kapazitive Last am Ausgang macht ein Deratating: 60ps/pF
- ringing an unterminierten Leitungen?
- Jitter addiert sich zum worst-case: 0.5ns
Dann durch's SRAM, 8ns später in ähnlicher Weise von dort wieder zurück.

> Sind die Bussteiber im FPGA richtig eingestellt?
Ich denke schon, die sind auf maximalen Strom eingestellt. Vielleicht 
macht weniger Strom aber auch weniger Ringing.

> PS. Habe leider von der Materie zu wenig Ahnung um zu helfen.
Da haben wir was gemeinsam... Ich frage nochmal die Kollegen.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Ein paar Updates zu verschieden Themen:

Mit dem Speicherbus habe ich noch etwas experimentiert und einen 
Kollegen konsultiert. Er kann sich vorstellen, das wir mit Reflexionen 
auf den Leitungen zu tun haben, es daher die 27ns braucht bis sich die 
Lage beruhigt hat. Die Topologie ist ungünstig: In der Mitte das FPGA, 
nach links zum SRAM, nach rechts zum anderen FPGA, nirgendwo 
Serienwiderstände oder Terminierung. Das ist halt nicht für high speed 
gebaut, Wittig betreibt das mit 25 MHz. Versuchsweise habe ich mal die 
Treiberleistung vom FPGA reduziert, in der Hoffnung wenige Geklingel zu 
erzeugen. Wurde aber eher schlechter.
Seien wir also zufrieden mit 75 MHz, ist ja immerhin 6 mal schneller als 
die alte CPU.

Dann ist ein CY7C64713 eingetroffen, das ist der USB FX1 Chip im Scope. 
Mit dem will ich ein Bastelsystem aufbauen, um zu schauen was aus dem so 
rauszukitzeln ist. Das ist aber ein Langfristprojekt, für später mal, es 
sei denn es kümmert sich wer anders drum. Man könnte in das Scope evtl. 
auch den pinkompatiblen FX2-Chip einlöten, für USB2-Speed...

Noch mehr Chips: Die Trim-Dacs sind da. Ich habe sie eingelötet und eine 
Softwareansteuerung dafür geschrieben. Letzteres erfordert beim 4kanäler 
einige Tricks, weil der 2. Chip ungünstig angeschlossen ist. Er bekommt 
ein gegenüber dem ersten Chip invertiertes SPI Chip Select. Das führt 
dazu das sich immer beide angesprochen fühlen, jeder auf einer Flanke. 
Wenn ich anfange mit dem normal angeschlossenen zu "reden", dann meint 
der verkehrte, die letzten 16 Bits auf dem Bus seien für ihn gewesen und 
interpretiert die als Kommando. Ich muß ihm also vorher irgendwas 
sinnvolles auf den Bus tun, ohne das sich sein Chip Select bewegt. Ich 
mißbrauche dazu ein Dummy-Kommando an den Offset-DAC. Das hat 24 Bit, 
ein NOP ist auch dabei, dann sind die unteren 16 Bit don't care und ich 
kann dort ein Kommando für den Trim-DAC reinschreiben. (Alles klar?) 
Glücklicherweise interpretiert jener nur die letzten 16 Bit als 
Kommando, stört sich nicht dran wenn es mehr waren, sowas habe ich 
nämlich auch schon erlebt.

Mit diesem Trick kann ich paarig beliebige Kommandos an die beiden 
Trim-DACs schicken. Auch dort gibt es ein NOP, so das ich gezielt auch 
nur einen ansprechen kann.

Mit der eigentlichen Trimmung geht es frühestens weiter wenn die 
Hardware steht, logo. Die Dimensionierung der Serienwiderstände ist 
gerade in Arbeit.


So long,
Jörg

von Peter M. (none)


Angehängte Dateien:

Lesenswert?

Jörg H. schrieb:
> Die Topologie ist ungünstig: In der Mitte das FPGA,
> nach links zum SRAM, nach rechts zum anderen FPGA, nirgendwo
> Serienwiderstände oder Terminierung.

Hallo Joerg,

klasse, was du da machst.

Hast du schon mal die 'Cyclone II On-Chip Termination' ausprobiert?

http://www.altera.com/devices/fpga/cyclone2/features/onchip/cy2-onchip.html

Im 'Pin Planner' einfach mit links auf 'Node Name' oder einen anderen 
Spaltennamen und 'Customize Columns...' waehlen (siehe Anhang).

Dann kannst du auch zusaetzlich noch einmal mit den Stromtreibern 
spielen.

Viel Erfolg und Gruss, Peter

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Peter,

aha, das kannte ich noch nicht. Ich wußte auch nicht, das es da 
potentiell noch mehr Spalten gibt. Ist ein Serienwiderstand nicht so 
ähnlich wie verringerte Treiberstärke?
Danke für solche Tool-Tipps. Das kann ich gut gebrauchen. Mir ist zwar 
von der Logik meist klar was zu tun ist, aber die Stellschrauben der mir 
neuen Werkzeuge kenne ich mitunter nicht.

Im Moment habe ich keine Lust mehr auf die Baustelle Optimierung des 
SRAM-Interfaces, habe das zurückgestellt, denn das ist wohl "premature 
Optimization". Später muß man da mal dran messen um zu sehen was 
wirklich anliegt, wie knapp das ist oder wo noch Luft ist. In der Firma 
haben wir ein geeignetes Oszi.
Um weiter zu kommen habe ich das Timing auf konservativ eingestellt, 
sogar einen Waitstate beim Schreiben weil es mit dem Write Pulse auf 1/2 
Clockbreite noch Fehler gab.
Später werden wir sehen wie schnell das vollere FPGA den überhaupt noch 
laufen kann, was für Hilfstakte noch möglich sind, etc.

Ich habe mich jetzt dem Thema SPI zugewandt (LEDs, Tasten, Drehgeber, 
Kanaleinstellungen), um das System vollständig genug für eine 
Softwareportierung zu kriegen. Mehr dazu später.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Zum SPI und sonstigem:

Die SPI-Teile baue ich derzeit als Buskomponenten. Das hat gegenüber dem 
Anschluss an PIOs den Vorteil, dass das nicht so ein Nadelöhr ist. Auch 
kann ein Schreibzugriff direkt eine Aktion auslösen, man muss nicht erst 
mit einem Startpin wackeln. Aber mal der Reihe nach:

LEDs:
Damit habe ich angefangen, sozusagen zum Warmwerden. Die LEDs haben 
ihren eigenen SPI-Bus, also eine schön abgeschlossene Sache. Es gibt nun 
ein LED-Register im Adressraum. Wenn die Software da drauf schreibt geht 
es gleich los, die Bits werden rausgetaktet. Es muß nichts abgewartet 
werden. Selbst wenn die Software das Register noch während des Schiebens 
neu beschreibt wird einfach abgebrochen und ein neuer Transfer 
gestartet. Die Software merkt also gar nicht, daß das in Wirklichkeit 
keine parallelen Bits sind. Die einfache Bedienung könnte für z.B. 
Bootloader-Experimente nützlich sein.

Tasten:
Die lange SPI-Kette (56 Bit) mit den Tasten und Drehgebern wird 
natürlich zyklisch gelesen, mit etwa 7 kHz. Die Tastenbits davon landen 
in einem Register. Ich habe auch die unbenutzten Bits des letzten 
Schieberegisters dazugenommen (sind dann 32, eine schöne Zahl für ein 
Register). So haben wir potentiell 4 Eingänge mehr, ist gedacht für 
Drehgeber mit Pushbutton. Liegen schon länger bei mir herum.
Eine Änderung des Tastenstatus kann einen Interrupt auslösen. Im 
Unterschied zum originalen Design kriegen wir nicht nur die Info das 
eine Taste gedrückt wurde, sondern auch das sie losgelassen wurde, auch 
haben wir Zugriff auf den Status aller Tasten gleichzeitig. Das erlaubt 
potentiell andere Bedienung, z.B. Scrollen solange Taste gedrückt, 
Umschaltfunktionen, langes Drücken macht was anderes, o.Ä.

Drehgeber:
Der obige Tastenscanner reicht die abgetasteten 12*2 Leitungen der 
Drehgeber an ein weiteres Modul. Ist getrennt weil ein Avalon-Slave nur 
einen Interrupt haben kann, ich für Tasten und Drehgeber aber 
unterschiedliche möchte. Hier gibt es 12 Zähler auf die die Software 
Zugriff hat. Wenn ein Encoder bewegt wurde wird ein zugehöriges Bit in 
einem Statusregister gesetzt und kann ein Interrupt ausgelöst werden. 
Die Software sieht dann mit einem Blick ins Statusregister um welchen 
Zählerwert sie sich kümmern darf (und setzt den Status zurück).
So macht es keinen Unterschied, wenn mal 2 Knöpfe gleichzeitig gedreht 
werden (Pong wird möglich ;-). Das originale Design kann das nicht. Es 
hat auch die lästige Eigenart, schnellere Bewegungen erst im Nachhinein 
zu melden wenn der Knopf nicht mehr bewegt wird, oder nur noch langsam.

Kanaleinstellungen:
Der SPI-Teil für Relais, Verstärkung, Offset-DACSs und demnächst 
Trim-DACs ist die Hölle. Da ist alles mögliche dran angeschlossen, was 
unterschiedlich behandelt werden will. 8, 16, 24 Bit Länge, invertiert 
oder nicht, Chip Selects auf verschiedene Weise, usw. Das originale 
Design kümmert sich selbst um diesen Zoo, aber es geht nur das was 
vorgesehen war. Soweit will ich mit Absicht nicht gehen, ich mache den 
Transfer in einem Config-Register in all diesen Aspekten parametrierbar, 
die Software ist dann verantwortlich. Es gibt ein abfragbares Busy-Bit, 
das hatte mir gefehlt. Kann auch einen Interrupt auslösen.
Ich bin noch am Debuggen von dem Ding.

Wenn das fertig ist wäre das Grundsystem (ohne Capturing) soweit 
vollständig. Dann kann es mit der Software richtig losgehen, Boot-ROM, 
UCL-Dekompressor, Build-Environment, Osoz portieren...

Ich habe bei Tasten und Drehgebern drauf geachtet, dass die 
Bitpositionen gleich bleiben. So brauche ich die Header nicht ändern.

In der Hardware fehlt außer dem Capturing (große Baustelle, klar) noch 
ein PWM-Generator für den externen Triggerpegel und der 1kHz 
Testgenerator. Wollen wir den vielleicht auch auf z.B. 1 MHz umschaltbar 
haben, falls die Schaltung das hergibt?

Hier zu guter Letzt nochmal der Aufruf das Mitmacher immer herzlich 
willkommen sind. Danke an Thomas aka Fritzi für seine Unterstützung!

So long,
Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Jörg H. schrieb:
> Wenn das fertig ist wäre das Grundsystem (ohne Capturing) soweit
> vollständig. Dann kann es mit der Software richtig losgehen, Boot-ROM,
> UCL-Dekompressor, Build-Environment, Osoz portieren...

SPI funktioniert soweit, ich kann keine Fehler mehr feststellen. Damit 
wäre mein selbstgesteckter Meilenstein erreicht, das Nios-II Design ist 
bereit für die Software.

Noch ein paar News vom 2. FPGA: Mathias hat dem JTAG hinterher 
gefahndet, die Platine von Guido war auch nützlich. Am 2. FPGA ist der 
JTAG leider nicht vollständig angeschlossen, nur TDI und TDO, aber kein 
TCK und TMS. Warum auch immer. Damit haben wir leider keine Chance, das 
2. FPGA so komfortabel wie das 1. in Betrieb zu nehemen. Es geht nur 
Blindflug, den Inhalt mit ins Config-Flash packen und hoffen.



Jörg

von Blue F. (blueflash)


Lesenswert?

Hi, sitze hier am Flufhafen Wien und warte auf den Weiterflug - gute 
Gelegenheit mal den Fortschritt zu verfolgen. Ich bin beeindruckt. Das 
nimmt ja Formen an, die wir vorher kaum für möglich hielten.

Leider kann ich FPGA-Seitig wenig Hilfe anbieten. Doch hoffe ich bei der 
Implementierung der neuen Software wieder meinen Beitrag leisten zu 
können.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

(Hayo, siehe weiter unten)

Am Wochenende habe ich einen Bootloader für den Nios II und unsere 
Hardware geschrieben. (Die Ablösung für den GERMSloader, der wird nicht 
mehr unterstützt.) Ging schneller als erwartet, ich hätte nicht gedacht 
das Thema schon abschließen zu können. Ich mußte schließlich erstmal 
lernen, wie man denn was im Boot ROM plaziert, wie Assemblercode dafür 
erstellt.
Es gibt eine gute Vorlage, eine AppNote samt Sourcecode von Altera:
http://www.altera.com/literature/an/an458.pdf

Unser neuer Bootloader basiert nun auf dem "Small Boot Copier Example". 
Ich habe ihn noch verschlankt/beschleunigt, z.B. auf immer 32bittig 
kopieren statt byteweise, Nutzung des Datencache.
Altera hat sich ein Format ausgedacht, wie ein Programm im Flash 
abgelegt ist, mit was für Headern drumrum, und liefert Scripte die sowas 
erzeugen. (Sie nennen es "Boot Image".) Also machen wir das auch so, 
kein Grund das Rad neu zu erfinden.

Was den Bootloader dann zu "unserem" macht ist die Abfrage, ob beim 
Booten F1 gehalten ist, und wenn ja nimmt er so ein Image nicht aus dem 
Flash, sondern von der seriellen Schnittstelle entgegen. Binär, keine 
S-Records mehr.

Seinen Status vermeldet er mit LEDs, die grüne Run-LED wenn er vom Flash 
startet, die rote Single-LED wenn man ihn mit F1 angehalten hat und er 
auf die RS232 wartet, sowie verschiedene Fehlerzustände.

Von den 512 Bytes sind derzeit noch 160 frei, wir könnten uns also sogar 
noch etwas Luxus erlauben, eine Bootmeldung oder sowas. Vorschläge?

Hayo, es gibt da noch etwas was du ohne viel Aufwand Gutes tun könntest:
Ich brauche einen definierten Platz in Flash, wo das Nios-II Boot Image 
liegen kann, den die alte Firmware nicht anfasst. Wir sollten für den 
Übergang das Flash sinnvoll partitionieren. Von den grotesk vielen 
möglichen Signalspeichern könnte man gut was freimachen, die Firmware da 
einschränken. Könntest du einen Release mit sowas machen?

Weitere News:
Die Widerstandsarrays für die Trim-DACs sind bei mir eingetroffen. Ich 
habe sie aufgelötet, die Hardware ist nun vollständig, aber noch nichts 
weiter damit gemacht. Die Baustelle kommt später. Ich habe noch welche 
übrig, weil eine Verpackungseinheit 50 Stück waren, kann also ggf. noch 
Leute damit versorgen.

Meine Probierplatine für den FX1 USB-Chip ist da. Ich habe sie bestückt, 
mal kurz angestöpselt, aber auch hier noch nichts weiter gemacht. Das 
wird auch noch länger nix.

Als nächstes gucke ich mir die Portierung der UCL-Loader an, oder gleich 
Osoz, mal schauen.

So long,
Jörg

von Andreas W. (andiiiy)


Angehängte Dateien:

Lesenswert?

Hallo Jörg,

mit meinen eigenen Pfad-Vorstellungen hat sich das NIOS2 System nicht in 
Betrieb nehmen lassen ... was soll's nun heiße ich auf meinem Rechner 
halt Joerg ... ;-)

Hura ... die ersten UART-Meldungen sowie Bildschirmanzeigen sind zu 
sehen.

Leider kann ich derteit nur die "Pulse Width" Taste drücken! Alle 
anderen reagieren nicht.
Wenn ich aber die geannte Taste drücke, kann ich über den U/Div Kanal 1 
etwas ändern bis zum Assert ... (wie im Bild zu sehen...)
Ein Grundmenü kann ich auch schon erfolgreich sehen ...

Hat Deine schon vollzogene Hardwareänderung der Trimmung evtl. schon 
negative Folgen für den Lauf meines Systems?

Das Debuggen ist ja absolut genial ...

Gruß Andi

von Jörg H. (idc-dragon)


Lesenswert?

Andreas W. schrieb:
> mit meinen eigenen Pfad-Vorstellungen hat sich das NIOS2 System nicht in
> Betrieb nehmen lassen ... was soll's nun heiße ich auf meinem Rechner
> halt Joerg ... ;-)
Oh, da sind irgendwo absolute Pfade drin? Mist. Wo denn?
Es soll sich ja niemand verleugnen müssen...
Wenn du mit dem SOPC Builder das System neu erzeugst muß auch das BSP 
"aufgefrischt" werden, mit der aktuellen System ID und Timestamp. Oder 
man muß die Verwendung selbiger wegkonfigurieren.

> Hura ... die ersten UART-Meldungen sowie Bildschirmanzeigen sind zu
> sehen.
Glückwunsch! Ich freue mich sehr, wenn jemand das nachvollzieht. Ein 
erster Schritt zur Mitarbeit.  :-)
Und für mich eine gute Kontrolle, ob ich das richtige eingecheckt habe. 
Offensichtlich noch nicht ganz.
Für interaktive Dinge kann man mich im Skype-Gruppenchat erwischen. Wer 
da rein will möge mir seine ID mitteilen.

> Leider kann ich derteit nur die "Pulse Width" Taste drücken! Alle
> anderen reagieren nicht.
> Wenn ich aber die geannte Taste drücke, kann ich über den U/Div Kanal 1
> etwas ändern bis zum Assert ... (wie im Bild zu sehen...)
> Ein Grundmenü kann ich auch schon erfolgreich sehen ...
Du kommst da weiter als ich, habe ich den Eindruck. Bei mir zerlegt es 
sich i.d.R. schon vor der Hauptschleife. Da ist noch irgendwas richtig 
faul, und ich habe derzeit keinen Schimmer. Seit meiner letzten Meldung 
kam ich auch noch zu nix.

> Hat Deine schon vollzogene Hardwareänderung der Trimmung evtl. schon
> negative Folgen für den Lauf meines Systems?
Nein, das ist mit ziemlicher Sicherheit auszuschließen. Die DACs zu 
beschreiben ist "fire and forget", ob sie wirklich da sind merkt der 
Rest nicht.

> Das Debuggen ist ja absolut genial ...
Ist schon ein Fortschritt, gell? Nett wäre wenn er mir anzeigen würde 
woher meine Exception kommt. Vielleicht geht das irgendwie, und ich habe 
das Knöpfchen noch nicht gefunden.

Jörg

von Andreas W. (andiiiy)


Lesenswert?

Hallo Jörg,

> Oh, da sind irgendwo absolute Pfade drin? Mist. Wo denn?
> Es soll sich ja niemand verleugnen müssen...
> Wenn du mit dem SOPC Builder das System neu erzeugst muß auch das BSP
> "aufgefrischt" werden, mit der aktuellen System ID und Timestamp. Oder
> man muß die Verwendung selbiger wegkonfigurieren.

... genau da sind noch absolute Pfade drin. Diese hatte ich versucht 
anzupassen ... bis auf einen (der war nicht im Editor sichtbar ... 
müsste also im Klartext geändert werden) ... damit musste ich das BSP 
sowie so neu kompilieren.

Die System ID und Timestamp frische ich immer in der Software auf ... 
ist eh bei jedem Start von Quartus notwendig ... bzw. erst beim 
Verbinden und einspielen der Software (nach NIOS2).

Ich freue mich auch über den derzeitigen Lauf ... und den Assert über 
den UART. Ich werde mal versuchen ein genaueres Debuggen zu ermöglichen.

> Ein erster Schritt zur Mitarbeit.  :-)
Ich habe für Hajo schon einige beschriebene BUGs entfernt ... ;-) und 
freue mich schon wenn Hajo wieder Zeit hat.

Ich werde mich erst einmal in die Software einarbeiten ... und suchen wo 
der Welec-Typ festgelegt wird (2 oder 4 Kanal) ...

Gruß Andi

von Jörg H. (idc-dragon)


Lesenswert?

> Die System ID und Timestamp frische ich immer in der Software auf ...
> ist eh bei jedem Start von Quartus notwendig ... bzw. erst beim
> Verbinden und einspielen der Software (nach NIOS2).

Hmm, das muß ich deutlich seltener, mittlerweile fast gar nicht mehr. 
Nur wenn sich im SOPC Builder was geändert hat, Peripherie, 
Basisadressen, solche Dinge.

> Ich freue mich auch über den derzeitigen Lauf ... und den Assert über
> den UART. Ich werde mal versuchen ein genaueres Debuggen zu ermöglichen.

Die Assertion ist weg, heute habe ich etliche Bugs entfernt. 
Mittlerweile läuft das System normal, zumindest auf der 2Kanalplatine 
von Guido die ich gerade dranhabe. Ich habe den seriellen Treiber noch 
nicht eingecheckt, baue da zwischenzeitliche krude Workarounds wieder 
aus.

> Ich werde mich erst einmal in die Software einarbeiten ... und suchen wo
> der Welec-Typ festgelegt wird (2 oder 4 Kanal) ...

Bei Osoz? In CaptureInit(), bzw. abgefragt durch 
CaptureGetNumChannels(). Für den Nios II habe ich da derzeit hart 2 
eingetragen, bis zum zweiten FPGA ist es noch ein gutes Stück Arbeit... 
Für den jetzigen Trockenbetrieb kannst du aber wohl auch eine 4 
eintragen.

Jörg

von Andreas W. (andiiiy)


Lesenswert?

Jörg H. schrieb:
> Bei Osoz? In CaptureInit(), bzw. abgefragt durch
> CaptureGetNumChannels(). Für den Nios II habe ich da derzeit hart 2
> eingetragen, bis zum zweiten FPGA ist es noch ein gutes Stück Arbeit...
> Für den jetzigen Trockenbetrieb kannst du aber wohl auch eine 4
> eintragen.

Ach da hatte ich mich gestern doch nicht versehen ...
Ja ich meine bei Osoz für NIOS II ...

Na da werde ich nach dem "Einchecken" mal einen Test machen ... 
Prinzipell sollte das ja auch mit der 4 Kanal-Variante funktionieren.

Gruß

von Jörg H. (idc-dragon)


Lesenswert?

> Na da werde ich nach dem "Einchecken" mal einen Test machen ...
> Prinzipell sollte das ja auch mit der 4 Kanal-Variante funktionieren.

So, ist drin. Das serielle Kommandointerface geht bei mir wieder.
Weil der neue UART ja FIFOs hat (und wegen der Granularität der 
FPGA-Memories sogar je 512 Bytes groß) habe ich das gepufferte Senden 
per Interrupt für den Nios II ausgebaut. Der Sende-FIFO hat quasi den 
gleichen Effekt, und es beißt sich nicht mit "unbehandeltem" printf().

Jörg

von Andreas W. (andiiiy)


Angehängte Dateien:

Lesenswert?

Test vor UART-Checkin:

Also der BugFix für die Tasten ist gelungen ... wenn auch die Tasten 
sehr empfindlich sind (besonders "Main / Delayed" habe ich das Gefühl).

Die Anzeige für den Kanal 1 sieht noch etwas komisch aus ... siehe Bild.
- ist auf der Linie des Kanals um ein Pixel nach rechts verschoben
- die Anzeige BW und DC/AC sieht verknispelt aus

Ja sonst ist das schon ein geniales Stück Software was da entstanden ist 
...

Andi

von Jörg H. (idc-dragon)


Lesenswert?

> Also der BugFix für die Tasten ist gelungen ... wenn auch die Tasten
> sehr empfindlich sind (besonders "Main / Delayed" habe ich das Gefühl).
Ja, die prellen noch, da muß ich nochmal an die Hardware. Ich habe es 
auch speziell bei Main/Delayed gemerkt.

> Die Anzeige für den Kanal 1 sieht noch etwas komisch aus ... siehe Bild.
> - ist auf der Linie des Kanals um ein Pixel nach rechts verschoben
> - die Anzeige BW und DC/AC sieht verknispelt aus
Das habe ich gar nicht. Hast du was Spezielles gemacht? Auch die 
verschobene Linie gefällt mir nicht. Steht das still, oder zittert was?
Könnten Probleme mit dem Speicher sein, zu agressives Timing. 
Zerdetschte Grafik hatte ich, als der LCD-Treiber cachebaren Speicher 
rausgereicht hat. Das tut er nun übergangsweise nicht, später wird man 
nach Grafikupdates den Cache flushen.

Jörg

von Andreas W. (andiiiy)


Lesenswert?

Jörg H. schrieb:
> Das habe ich gar nicht. Hast du was Spezielles gemacht? Auch die
> verschobene Linie gefällt mir nicht. Steht das still, oder zittert was?

Naja ... das ist so eine Frage ... Ich habe auf dieser Position schon 
beim einspielen von NIOSII eine Linie (sieht jedenfalls so aus) ... wenn 
gewünscht kann ich Dir mal ein Foto einstellen nach dem Einspielen von 
NIOSII ohne Software!

ABER ...

Drehe ich am Encoder die 0-Position des Kanal 1 geht dieser Strich mit. 
Die Grafik AC/DC zittert etwas ...

Ich habe derzeit noch keine Besonderheiten eingestellt. Noch ist (fast) 
alles wie bei Dir ... nur mit einem 4-Kanaler im Test ...

Bei den schlechten Fotos sollten wir auf jeden Fall wieder an einer 
Screenshotfunktion arbeiten ;-)

Andi

von Jörg H. (idc-dragon)


Lesenswert?

> Naja ... das ist so eine Frage ... Ich habe auf dieser Position schon
> beim einspielen von NIOSII eine Linie (sieht jedenfalls so aus) ... wenn
> gewünscht kann ich Dir mal ein Foto einstellen nach dem Einspielen von
> NIOSII ohne Software!
Dann ist wohl meine Hardware im FPGA schuld.
Ich habe ferner manchmal den Eindruck, das Quartus ab und zu einen 
schlechten Tag hat und mit dem Syntheseergebnis wenig anzufangen ist. 
Vielleicht fehlt mir noch ein nötiger Constraint oder sowas. Hast du das 
mal neu angeworfen?

> Drehe ich am Encoder die 0-Position des Kanal 1 geht dieser Strich mit.
Was heißt "geht mit"?

> Die Grafik AC/DC zittert etwas ...
Zittern ist schlecht. Deutet auf irgendwas marginales mit dem SRAM hin. 
Normalerweise zerlegt es dann die Software aber sehr schnell. Unter 
altera/software/hello sind noch meine Unittests, da ist auch ein 
Speichertest dabei, den könntest du mal probieren. Ich habe ihn mir ins 
Flash gebrannt, so zum Test des Bootloaders.

> Ich habe derzeit noch keine Besonderheiten eingestellt. Noch ist (fast)
> alles wie bei Dir ... nur mit einem 4-Kanaler im Test ...
Ich habe jetzt auch meine Platine wieder dran. Uh, geht längst nicht so 
gut, die üblen Exceptions sind wieder da.  :-(
Da ist wohl echt noch der Wurm drin, in der Hardware.

> Bei den schlechten Fotos sollten wir auf jeden Fall wieder an einer
> Screenshotfunktion arbeiten ;-)
Die ist nach wie vor drin. Im Terminal "screenshot" eingeben. Erscheint 
mir auch schneller als vorher. Aber es gibt immer noch keine 
Empfängersoftware.
Speicherfehler wird sie auch nicht wiedergeben.
(Ich weiß, du hast es nicht ernst gemeint.)

Jörg

von Andreas W. (andiiiy)


Lesenswert?

> Dann ist wohl meine Hardware im FPGA schuld.
> Ich habe ferner manchmal den Eindruck, das Quartus ab und zu einen
> schlechten Tag hat und mit dem Syntheseergebnis wenig anzufangen ist.
> Vielleicht fehlt mir noch ein nötiger Constraint oder sowas. Hast du das
> mal neu angeworfen?

Oh ja ... da vergeht eine Zeit (ca. 3 Minuten bei einem Intel E8400).

> Was heißt "geht mit"?

Ich meine, dass die genannte Linie mit dem Pixel nach rechts in der 
Y-Achse mitwandert wenn ich den 0-Punkt-Encoder drehe.

> Zittern ist schlecht. Deutet auf irgendwas marginales mit dem SRAM hin.
> Normalerweise zerlegt es dann die Software aber sehr schnell.

Hatte ich heute bis jetzt (außer gestern) noch gar nicht!

> Unter altera/software/hello sind noch meine Unittests, da ist auch ein
> Speichertest dabei, den könntest du mal probieren. Ich habe ihn mir ins
> Flash gebrannt, so zum Test des Bootloaders.

Den werde ich morgen mal probieren ...

> Ich habe jetzt auch meine Platine wieder dran. Uh, geht längst nicht so
> gut, die üblen Exceptions sind wieder da.  :-(
> Da ist wohl echt noch der Wurm drin, in der Hardware.

Da habe ich derzeit gar keine ... bzw. war das UART-Modul nicht ganz 
fit.

> Speicherfehler wird sie auch nicht wiedergeben.
> (Ich weiß, du hast es nicht ernst gemeint.)

;-)

Andi

von Jörg H. (idc-dragon)


Lesenswert?

Es gibt erstes Wellengezappel mit dem Nios II Design und Osoz drauf!
Ich habe zum Test ganz grob was reingestrickt, nur 2kanal, immer 1GS, 
kein Trigger. Hat noch nichts mit Alex' Sachen zu tun, gibt Timing 
Violations und sogar Spikes. (Ich gebe mir echt Mühe, das originalgetreu 
hinzukriegen ;-)
Aber schön, da erstes Leben zu sehen. Ermöglicht weitere Tests, z.B. ob 
die Kanaleinstellungen funktionieren.

Es zappelt sogar ziemlich schnell, obwohl ich den Datencache noch nicht 
recht nutze, der Compiler unoptimierten Code erzeugt und die 
Möglichkeiten der neuen Hardware wie LCD-Flip statt Copy noch ungenutzt 
sind.
Vielversprechend, das wird mal richtig schnell!

Was ich dabei noch gelernt habe, als ich die vielen LVDS-Leitungen von 
den ADCs erstmals benutzt habe:
Der Fitter duldet in der Nachbarschaft der LVDS-Pins keine "normalen" 
TTL-Pegel. Ich hatte vorher alle unbenutzten / noch unbekannten 
Leitungen zum Test auf PIOs gelegt, um ggf. zu gucken ob sich da was 
tut. Die mußte ich nun größtenteils wegnehmen oder zu differentiell 
umwidmen, wo möglich.
Es gibt nun nur noch einen(!) freien/unbekannten I/O der für Logikpegel 
verwendbar ist. Ferner noch ein paar Clockeingänge, die theoretisch 
Inputs sein könnten. Die FPGA-Hardware ist also von den Pins praktisch 
ausgereizt, wenig Wahrscheinlichkeit da noch unbekannte Features zu 
entdecken.
Das erklärt auch, warum das LCD ärgerlicherweise mit nur 3 Bit pro Farbe 
angebunden ist, es gab einfach keine Pins mehr.

Jörg

von Thomas (kosmos)


Lesenswert?

Jörg ein Video z.B. auf Youtube wäre mal interesant, würde mir gerne mal 
ansehen wie schnell das "zappelt"

von Jörg H. (idc-dragon)


Lesenswert?

Geduld, da sind jetzt noch diverse Bremsklötze dran, wir wollen uns ja 
nicht vorab den Ruf versauen...

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Den Haupt-Bremsklotz habe ich gerade mal testweise gelöst, den Code mit 
Optimierungen übersetzt. Hiu, da geht's ab, ich bin echt von den Socken!

Die neue Hardware ist in dem Fall den ich verglichen habe etwa 10 mal 
schneller. Eine ruhige Nullinie wird mit etwa 1500 fps gezeichnet (kein 
Tippfehler). Komplexere Signale, zwei Kanäle immer noch 200 fps. Mit 
Main/Delay Gesamtdarstellung gut 40 fps (das war vorher ziemlich lahm).

Wenn das mit dem LCD-Flip statt Copy drin ist wird es nochmal schneller. 
Der für LCD noch ungenutzte Datencache macht sich hingegen quasi nicht 
bemerkbar. Mit Cache ist es nicht schneller.

Weitere Hardware-News:
Die Glitches und die Timing Violations sind weg. Ich habe jetzt den 
"echten" Capture-Datenpfad gebaut, mit halber Frequenz und doppelter 
Breite. Damit kommt das FPGA besser klar. Am Eingang verwende ich 
DDR-Zellen um den Takt zu reduzieren. So wird das recht elegant und 
passiert direkt an den Pins. Alex hatte das seinerzeit "zu Fuß" gebaut. 
Vor seiner Filterei habe ich große Hochachtung, da traue ich mich noch 
nicht ran... Wir haben aber neulich länger telefoniert, er hat mir eine 
Tour gegeben.

Ich kämpfe noch etwas mit dem Capture-Speicher, das erste Datenwort ist 
immer falsch, auch wenn ich es überspringe, sehr merkwürdig.

Im SPI-Teil habe ich einen Glitch gehabt, der zu Querbeeinflussung der 
Kanaleinstellung führte. Ist nun sauber.

Gibt trotzdem immer noch viele Baustellen. Irgendwas ist instabil 
(Businterface?), besonders mit meiner Hardware. Ich verwende derzeit 
meist die von Guido, aber das muß natürlich noch gelöst werden.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Ich schreib' mal wieder was, ist eine Weile her, seitdem ist einiges 
passiert.

Alex hat mir mit dem Sample-Speicher geholfen, der funktioniert jetzt.

Ich habe erste Vorbereitungen für das 2. FPGA getroffen. Der Bootloader 
testet jetzt, ob er das Flash erreichen kann (was nur auf dem 1. FPGA, 
dem Master, möglich ist). Wenn nicht, dann läuft das wohl auf dem Slave. 
Abhängig davon werden interne Signale für Rollenverteilung und die 
Richtungsumschaltung der Verbindungsleitungen gesetzt. Beim Slave geht 
die CPU dann in Dauer-Reset.

Das 2. FPGA wird blöd zu debuggen, weil Wittig dort leider 2 wichtige 
JTAG-Signale nicht angeschlossen hat. Wir können nur den Bitstream ins 
Config-Flash brennen und hoffen.

Zu Testzwecken kann es auch die kleinste Nios-II Version sein, der /e. 
Der ist nämlich lizenzfrei und ich kann auch daheim den ROM-Inhalt 
erzeugen. Geht sonst nur mit JTAG im Evaluationsbetrieb.

Letzte Woche habe ich mich und die Chat-Teilnehmer ausführlich mit einem 
"Phasenabgleich" der 4 ADCs pro Kanal beschäftigt. Die sampeln reihum 
versetzt mit 250 MHz, um 1 GSa/s zu erzeugen. Diesen Versatz können wir 
mit den 4 PLLs recht fein einjustieren, um die Abtastzeitpunkte akkurat 
zu haben. Ich habe mit Andrés Hilfe ein Matlab-/Octave-Script gebastelt, 
was den Phasenversatz der ADCs bestimmen kann, um dann geeignet 
nachzukalibrieren. Das gab erstmal Verwirrung, wie sich rausstellte 
hatte ich die ADCs anders angeschlossen als die Clocks.

Nun wo das endlich gefunden ist kann ich einen Kanal perfekt einstellen, 
den 2. aber leider nicht, weil Wittig sozusagen einen Layoutfehler 
gemacht hat. Die 4 Takte gehen nicht gleichartig von dem einen 
ADC-"Cluster" zu dem des anderen Kanals, sondern 2 Takte kommen von 
hinten, 2 von vorn. Die Laufzeitunterschiede addieren sich zu ziemlich 
genau 90° Phasenverschiebung. So fallen 2 ADCs eines Kanals für eine 
sinnvolle Messung praktisch aus. Wir haben etwas Glück im Unglück, es 
sind die ADCs 2 und 4, die bereits für 500 MSa/s nicht mehr verwendet 
werden. Man kann also mit Kanal 1 (und 3, falls vorhanden) 1GSa messen, 
mit Kanal 2 (und 4) sinnvoll nur 500 MSa. Oder wir stellen das so ein, 
das es für beide Kanäle mittelkrumm ist...

Die PLLs sind nicht zur Laufzeit programmierbar, das passiert bei der 
Erstellung des FPGA.

So long,
Jörg

von Jörg H. (idc-dragon)


Lesenswert?

An die stillen Leser, was hat sich inzwischen getan:

Ich habe die Wittig-Hardware vermessen, was für Farben am LCD denn genau 
rauskommen und das als Default nun auch so eingestellt.

Es gibt ein rudimentäres Empfängertool für das Screenshot-Format von 
Osoz. Es kann den Terminaloutput zu .bmp Grafiken dekomprimieren. 
Andreas macht da hoffentlich was Schöneres draus.

Den LCD-Controller habe ich nochmal überarbeitet. Den Ausgabeteil hatte 
ich Neuling mir vom Altera-Code abgeguckt, mittlerweile fand ich geht 
das einfacher. Hatte den sehr schönen Nebeneffekt das die 
Bildschirmdarstellung jetzt auch bei Andreas in Ordnung ist. :-)

Der Nios-II Bootloader kann nun erkennen, ob er auf FPGA1 (Master) oder 
FPGA2 (Slave) läuft. Er testet, ob er das Flash erreichen kann und setzt 
entsprechend Portbits. Beim Slave wird dann die CPU im Dauerreset 
gehalten. Die Portbits hatte ich mir für eine Richtungsumschaltung der 
bidirektionalen Verbindungsleitungen vorgestellt, sowie allgemein die 
Rollenzuweisung.
Den Ansatz habe ich aber mittlerweile verworfen, die jeweils ungenutzten 
Busteilnehmer haben zu viele Nachteile. Es werden nun doch 2 
verschiedene FPGAs, die aber viel Code gemeinsam haben. Ich hoffe ich 
kriege das 2. im JTAG-losen Blindflug hin...

Ich habe erste Experimente mit dem zweiten FPGA gemacht, da einfache 
Testdesigns reingebrannt die Daten eintakten und wieder zurückgeben. So 
habe ich getestet, wie schnell denn das werden kann. Weil der Datenbus 
mit dem SRAM geteilt wird ist es sehr erstrebenswert, dort mit dem 
gleichen Takt arbeiten zu können (derzeit 75 MHz, angestrebt bis zu 94 
MHz). Das klappt so gerade.

Den SRAM-Controller habe ich in Vorbereitung auf seine Doppelrolle 
umgebaut. Seine Ausgänge sind jetzt durchgehend Register, keine 
Kombinatorik mehr dahinter (außer bei der Schreibleitung, s.u.). Davon 
erhoffe ich mir stabileres Timing.

Die PLLs habe ich noch mal umsortiert. Weil die 125 MHz DDR-Takte der 
Datenübername so schön unkritisch sind traue ich mich auch, sie in einer 
anderen PLL zu haben als den zugeordneten ADC-Takt. Bisher war das mit 
Rücksicht auf Jitter in der jeweils gleichen. Das schafft nun Raum für 
einen zukünftigen SRAM-Lesetakt in der gleichen PLL wie der normale 
CPU+SRAM-Takt, der bei höheren Takten nötig ist. Auch den 3/4 
Schreibtakt habe ich wiederbelebt, wenn auch aus der nächsten PLL. Damit 
geht das Schreiben doppelt so schnell, ohne Waitstates dazwischen. 
Bisher hatte ich das Toggeln der Schreibleitung synchron erzeugt, und 
das gibt halbe Frequenz. Ein initialer Waitstate ist auch entfallen, 
damit ist das SRAM-Interface jetzt komplett ohne Waitstates.

Klappt aber immer noch nicht zuverlässig. Meine Hardware ist sehr 
kritisch, bei Guidos läuft das in der Regel, die Ergebnisse der Synthese 
sind mitunter nicht reproduzierbar. Timing nach Extern habe ich noch 
nicht richtig verstanden...
Zauberworte sind Constraints, set_input_delay, set_output_delay, 
set_min_delay, set_max_delay, FAST_INPUT_REGISTER, FAST_OUTPUT_REGISTER, 
FAST_OUTPUT_ENABLE_REGISTER, kennt sich damit jemand aus?

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Hallo,

noch hat sich keine Hilfe zu den Timingfragen aufgedrängt. Der Kollege 
den ich fragen könnte ist schwer beschäftigt.

Bei mir tat sich erstmal nicht, ich habe vor einer Woche die Platte 
meines Festplattenrecorders falsch umkopiert und eine Woche mit 
erfolglosen Datenrettungsversuchen verbracht.

OT, für Linux-Experten: Sinngemäß habe ich ein "dd if=/dev/sda1 
of=/dev/sda" statt einem "dd if=/dev/sda1 of=/dev/sdb1" abgesetzt. Bis 
ich es gemerkt und (leider) abgebrochen habe waren ca. 10GB Daten ein 
unbekanntes Stück nach vorn kopiert, über die Partitionstabelle.
Dann habe ich ein Tool geschrieben um den Versatz zu suchen, habe auch 
einen Kandidaten. Es ungeschehen machen klappte leider doch nicht, das 
zusammengefügte Filesystem mounted nicht.

Zurück zum Welec: ich bin nun etwas raus, vielleicht geht es dieses WE 
weiter, mal sehen.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Wünsche frohe Weihnachten gehabt zu haben!

Die Daten von meinem Festplattenrecorder sind wieder da, nicht zuletzt 
dank tatkräftiger Mithilfe aus dem Forum. Da bin ich ja froh, das hier 
eher beiläufig erwähnt zu haben.
Das Oszi hatte eine längere Zwangspause, in der ich stattdessen über das 
ext3-Dateisystem gelernt habe.

Nun versuche ich wieder reinzukommen, muß gestehen es gelingt mir nicht. 
Der (wegen gemeinsamer Datenleitungen) Mix aus SRAM-Interface und 
externem Interface zum zweiten FPGA ist eine harte Nuß für mich. 
Vielleicht fehlt mir da die richtige Methodik. Als State-Machine wäre es 
wohl übersichtlicher, aber wegen des Pipelinings ist es eine mir gerade 
nicht mehr verständliche Ansammlung von Signalen und Flipflops, während 
mir die Kobinatorik dazwischen zu komplex für anständige Taktfrequenzen 
wird...

Jörg

von Ben L. (elecblu)


Angehängte Dateien:

Lesenswert?

hab seit kurzem Probleme mit Spikes. Und zwar treten diese bei Kanal 2 
erheblich auf, auch sogar ohne Signal. Kanal 1 ist i.O.
Wenn das Gerät dann eine Zeit lang betrieben wird verschwinden sie 
vollständig, bei kühlem Gerät (12-18°C Werkstatt) wieder Spikes.
Defintiv thermisch, Lötstelle? Wären da die SRAMs denkbar?

von Jörg H. (idc-dragon)


Lesenswert?

Ich bin mir recht sicher das die Spikes interne Timingprobleme im FPGA 
sind. Das Design da drin ist zu sehr auf Kante genäht. Das Problem 
scheint ja quasi jeder zu haben, mehr oder weniger. Daher glaube ich 
nicht an im Einzelfall auch denkbare Lötfehler am FPGA oder einem ADC.

Das RAM wird es sicher nicht sein, da stürzt dir vorher die Software ab 
oder so.

Mit dem Leon-Design oder dem neuen Nios-II Design sind die Spikes 
bestimmt weg, weil die internen Datenpfade mit halber Geschwindigkeit, 
aber doppelter Breite arbeiten. So ist auch ein "legales" Timing 
hinzukriegen.
Ich habe leider noch nichts schlüsselfertiges mit Nios-II zum Testen, 
das war mal besser, bevor ich die SRAM-Baustelle wieder aufgerissen 
habe...

Jörg

von Ben L. (elecblu)


Lesenswert?

aber das trat so stark nie auf, ist jetzt nicht auf den Bildern zu sehen 
aber ich habe zum Teil heftige Spikes schon ohne Signal auf der 
Nulllinie, noch stärker als im Foto. Sobald das Teil dann warm ist (die 
reine Betriebsdauer seit dem anschalten ist nicht entscheidend) ist 
alles augenscheinlich prima.
Anfangs (das Scope ist 3 Jahre alt) gabs da nichts derartiges, da hatte 
ich nur die Spikes an den bekannten Stellen, die selten auftraten, aber 
nicht im normalen Signal.
So ist das Oszi quasi unbrauchbar, ich kann eigentlich nur an ein 
Hardwareproblem glauben, am FPGA Design sollte sich ja nichts von heut 
auf morgen ändern?

von Ben L. (elecblu)


Lesenswert?

okay, im Thread von 2009 gelesen... Gabs schon öfter dass die Spikes 
wieder verschwinden nach aufwärmen. Mich wundert aber das auftreten nach 
mehreren Jahren dennoch.

von Blue F. (blueflash)


Lesenswert?

Hm, merkwürdig. Bei mir treten die Spikes nur auf wenn das Gerät warm 
wird und auch nur beim 4 Kanaler. Das 2 Kanal Gerät hat nichts 
dergleichen. Falls es tatsächlich ein Problem mit kalten Lötstellen sein 
sollte, tippe ich eher auf die ADCs. Einfache Möglichkeit - rückwärtige 
Geräteabdeckung entfernen und während des Auftretens der Spikes mal auf 
die ADCs drücken.

Beim RAM würden andere Symptome auftreten. Von Streifen auf dem 
Bildschirm über Abstürze bis überhaupt kein Firmwarestart.

Die Tatsache, dass die Spikes jetzt auf einmal nach drei Jahren 
auftreten, könnte theoretisch auch an alternden Bauteilen liegen 
(Kondensator). Das wäre aber dann der erste mir bekannte Fall.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Nachschlag:

Deine Bilder zeigen auf Kanal 2 verschiedene Spannungsbereiche für 
mit/ohne Spikes.
- Treten die Spikes nur in bestimmten Spannungsbereichen auf oder in 
allen?
- sind alle Zeitbasen betroffen oder nur bestimmte?

Hayo

von Ben L. (elecblu)


Lesenswert?

ne, also tritt bei verschiedensten Zeit- und Spannungseinstellungen auf, 
wobei ich jetzt nicht jede Kombination ausprobiert habe. Zum Teil auch 
noch viel heftiger als auf dem Foto.
Im alten Thread hatte Guido und Bruno mal berichtet dass er sein Gerät 
auch aufwärmen muss bis die Spikes weg sind.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)" 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

Werde mir die ADCs und den Rest der Platine mal ansehen, viel mehr kann 
ich ja eigentlich nicht machen.
Das Zusammenspiel mit der Temperatur ist halt seltsam.

von Andreas G. (andreasgs)


Lesenswert?

Du kannst ja mal versuchen, teile der Elektronik per Kältespray zu 
malträtieren. Alternativ kannst du auch versuchen, die Chips mit dem 
Lötkolben am Gehäuse aufzuheizen.

Dann kannst du zumindest den Fehler eingrenzen und dir Sicher sein, ob 
es ein Temperaturthema ist oder nicht.

von Ben L. (elecblu)


Lesenswert?

werde ich machen. Ein Problem mit der Temperatur ist es aber defintiv, 
lässt sich 100% reproduzieren. Dauert aber noch paar Tage bis ich das 
angreife.
Vielleicht mag auch mal einer sein W2022 ins kühle stellen und schauen 
was passiert. So 10-12°C rum hatte ich den Fehler dann eigentlich immer. 
Wobei ich mir eigentlich sicher bin, dass es früher nicht so empfindlich 
darauf war.

von Blue F. (blueflash)


Lesenswert?

Werde meines mal draußen auf der Terasse in Betrieb nehmen, mal sehen ab 
da was passiert.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ok Ben, laß Dein Oszi zu!

Mein Versuch auf der Terasse endete mit einem Aha-Erlebnis.

Temperatur 5 - 6 Grad Celsius. Zwei Stunden draußen stehen gelassen und 
dann in Betrieb genommen.

Bei mir war exakt das Gleiche zu beobachten wie bei Dir. Kanal 1 ohne 
Probleme. Kanal 2 genau die gleichen Spikes wie bei Deinem Gerät, auch 
an den gleichen Stellen.

Also das Gerät wieder reingeholt und kurz warmlaufen lassen - Spikes 
sind weg.

Offensichtlich ist es bei mir im Programmierzimmerchen wohl so warm, 
dass mir das nie aufgefallen ist.

Eine kalte Lötstelle kann daher wohl ausgeschlossen werden. Mit 
ziemlicher Sicherheit hat Jörg recht und das Timing des FPGA ist so 
grenzwertig ausgelegt, dass schon geringe Temperaturschwankungen das 
Ganze aus dem Gleichgewicht bringen.

Ein Grund mehr auf ein neues FPGA-Design zu setzen.

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

gibt es keine Möglichkeit, das zu kompensieren?
Bei meinem 2 Kanal, tritt es ja auch, mal mehr, mal weniger auf.
Zur Beobachtung, bei horizontaler Signalverschiebung, also nach oben 
oder unten, nehmen die Spikes aber ab u. zu.
Könnte es sein, das es etwas mit der Pixelberechnung der Displayausgabe 
zusammenhängt? Mir kommt das manchmal so vor...

Gruß Michael

von Ben L. (elecblu)


Lesenswert?

Danke Hayo (und all die anderen)!
Dann hab ich das Oszi wohl tatsächlich bisher kaum benutzt, bevor die 
Werkstatt nicht angenehme 20°C hatte und es ist nicht aufgefallen. 
Temperatur ist schon fies...

Michael, werden die Spikes bei dir auch weniger wenn das Gerät eine Zeit 
lang in Betrieb ist? Nach 30 Minuten war bei mir alles gut.

von Blue F. (blueflash)


Lesenswert?

Nein, die Pixelberechnung ist definitiv nicht temperaturabhängig :-)

Die Vertikalverschiebung der Nulllinie bewirkt allerdings auch eine 
Änderung der Spikes. Das hängt aber wohl eher mit dem binären 8 bit Wert 
zusammen der an den entsprechenden Stellen der Spikes auftritt und 
anscheinend irgendwie verfälscht wird.

Softwareseitig läßt sich das eigentlich so gut wie gar nicht 
kompensieren, evtl. mit dem Noise Filter etwas abschwächen.

Einzige Möglichkeit - Gerät erst warmlaufen lassen (5 Minuten reichen 
bei mir), dann ist nichts mehr von den Spikes zu sehen.

Hayo

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

@Ben
> Michael, werden die Spikes bei dir auch weniger wenn das Gerät eine Zeit
> lang in Betrieb ist? Nach 30 Minuten war bei mir alles gut.
Nun ja, ich habe hier 18°C und noch rammeln die Spikes bei 500MSa/s 
munter weiter...vielleicht sollte ich das Teil mal auf den Ofen stellen 
;-)))

Von 1GSa/s bis runter 250MSa/s sind die Spikes am häufigsten und das 
Signal ist sehr unruhig.
Ab 25MSa/s ist wieder alles hübsch und ruhig.

Gruß Michael

von Ben L. (elecblu)


Lesenswert?

was ich dazusagen muss, mein Gerät hat einen gemoddeten Lüfter der eher 
weniger als mehr Luft als der Originale bringt (gedrosselter 
Noiseblocker 40mm, aber mit "Luftkanal" nach außen blasend)+ 
Schrimblech, also gut möglich dass sich deswegen eine etwas höhere 
Innentemperatur einstellt (geschätzt gute 40°C).

von Blue F. (blueflash)


Lesenswert?

Michael D. schrieb:
> Ab 25MSa/s ist wieder alles hübsch und ruhig.

Ja das liegt daran, dass ab dieser Samplerate nur noch 1 ADC arbeitet 
statt 4. D.h. es müssen nicht mehr 4 Register ausgelesen werden sondern 
nur noch Eines.

Ben L. schrieb:
> mein Gerät hat einen gemoddeten Lüfter der eher
> weniger als mehr Luft als der Originale bringt

Das hat aber eher keine Auswirkungen. Bei mir arbeitet ein 
hochmotivierter 80er Lüfter, und nach 5 Minuten ist alles warm genug. 
Der Stein des Anstoßes ist das FPGA, und das liegt außerhalb des 
Luftstromes zwischen den beiden Platinen. Vermutlich sind da eher 
unterschiedliche FPGA Revisionen der Grund.
(Bei mir 8C7.0L)


Hayo

von Blue F. (blueflash)


Lesenswert?

Jörg H. schrieb:

> Warum nicht gleich den richtigen Widerstand von 174 Ohm einlöten?

Ich konnte 174 Ohm weder auf irgendwelchen Teileträgern noch als Neuteil 
zum Kauf finden, jedenfalls nicht bei meinen üblichen Verdächtigen.

Also habe ich mich für den nächsten gängigen Wert entschieden. Die 
Widerstände haben 1% Toleranz und ich habe mir die rausgesucht die etwas 
nach unten abweichen. Der resultierende Unterschied dürfte im Rahmen der 
üblichen Bauteiletoleranzen liegen und sich auch nicht weiter auf die 
Skalierungsfaktoren auswirken. Für mich war aber interessant zu sehen, 
dass sich tatsächlich gegenüber den 150 Ohm eine sichtbare Verbesserung 
einstellte. Die Fehlanpassung nach unten hatte wohl doch einigen 
negativen Einfluß.

Also wer 174 Ohm zur Hand hat sollte die dann natürlich nehmen. Ich kann 
den Wert ja im Hardwaremenu auf 174 ändern, damit da keine 
Missverständnisse aufkommen.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Bei RS oder Farnell kann man die 174 Ohm kaufen, bei Mouser oder Digikey 
natürlich erst recht. Bis vor kurzem bei RS sogar ohne Versandkosten... 
:-(

Der Wert ist leicht aufgerundet.
Zugegeben kann laut Datenblatt der Innenwiderstand der ADCs stark 
streuen, im Mittel 4400 Ohm, aber von 3000 Ohm bis 6500 Ohm.
4 ADCs parallel und noch unser Widerstand parallel sollen 150 Ohm 
ergeben.

Also R = 1 / (1/150Ohm - 4/Ri)

Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber 
unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz 
liegen.

Jörg

von Michael D. (mike0815)


Lesenswert?

@Jörg,
> Längswiderstände: Mit denen verringert sich die Spannung am ADC und der
> Vorteiler kann im Ausgleich mehr draufgeben, eine Stufe unempfindlicher
> werden. Beides zusammen sorgt dafür, das der ADC wesentlich besser
> ausgesteuert wird, quasi perfekt statt vorher nur gut zur Hälfte. Die
> Darstellung wird deutlich feiner, weil die Software die Rohwerte nicht
> so aufzoomen muß.
> Leider beginnt im neu erreichten Aussteuerbereich bereits die Sättigung
> der letzten Ausgangsstufe, die wird dort etwas nichtlinear. (Müßte in
> der FFT-Darstellung gut als K3 zu sehen sein.) Um das zu vermeiden kann
> laut Branadic die Versorgungsspannung des letzten OpAmp von 3,3V auf 5V
> umgeändert werden. Das hat aber noch keiner ausprobiert. Scheint
> zusammen mit Längswiderständen eine sinnvolle Modifikation zu sein.
Wenn die 5V in der Nähe der ADC's verlaufen, sollte das machbar sein.
Die 3V kappen und die 5V Volt druff, nur wenn die zu weit weg sind und 
man erst einen Kilometer Kabel ziehen muß, könnte man sich darüber ein 
paar Parasiten einfangen, oder?

> Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber
> unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz
> liegen.
Bei mir sind es ja "nur" 2 ADC's, wenn die von derselben Charge sind, 
sollte das passen!

(mal den Plan und das Layout raus popeln...)

Gruß Michael

von Jörg H. (idc-dragon)


Lesenswert?

Michael D. schrieb:
> Wenn die 5V in der Nähe der ADC's verlaufen, sollte das machbar sein.
> Die 3V kappen und die 5V Volt druff, nur wenn die zu weit weg sind und
> man erst einen Kilometer Kabel ziehen muß, könnte man sich darüber ein
> paar Parasiten einfangen, oder?

Es gibt in der Nähe 5V. Etwas weiter unten sitzt ein Spannungsregler, so 
zwischen 2 Kanälen, der aus 6V "frische" 5V erregelt. Wo die noch 
hingehen weiß ich aber nicht.

Am OpAmp möchte man ja noch einen Blockkondensator behalten, damit wird 
es etwas kniffliger. Ich habe mir da noch keinen Plan zurechtgelegt.

>> Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber
>> unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz
>> liegen.
> Bei mir sind es ja "nur" 2 ADC's, wenn die von derselben Charge sind,
> sollte das passen!

Auch bei dir sind es 4 ADCs, nämlich pro Kanal. ;-)
(Es sei denn, du hast auf 500MSa abgerüstet und die Häfte weggebaut...)

Jörg

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Nachtrag:

Hier der Beginn eines Plans. Die 5V gehen an so einiges im Analogteil. 
Entgegen dem Schaltplan liegen da keine 6V an, sondern besagte 5V.

Ich habe das in beiliegendem Bild markiert. (Für Kanal 1+2, 3+4 sieht 
ähnlich aus.) Rot umrandet und nach unten gezogen sind die 5V-Bereiche, 
lila und nach oben gezogen die Versorgungspins der Ausgangs-OpAmps. 
Praktischerweise geht eine 5V-Leiterbahn nach oben hoch, bis fast an den 
einen OpAmp ran.

Man könnte den Blockkondensator oberhalb des OpAmp um 90° verdreht auf 
seinem Massepad auflöten, so daß Masse noch verbunden ist, aber der 
andere Anschluß im freien Bereich liegt. Dann von dort einen Fädeldraht 
an den hochgebogenen Pin 3 und weiter nach 5V.

Jörg

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

> Auch bei dir sind es 4 ADCs, nämlich pro Kanal. ;-)
> (Es sei denn, du hast auf 500MSa abgerüstet und die Häfte weggebaut...)
:-)))
Du hast natürlich Recht! Hätte es wissen müssen, habe denen ja noch die 
Kühlkörper verpasst, wie man sieht... :-(

von Michael D. (mike0815)


Lesenswert?

bei den AD8131, wird das ein schönes Gefummel geben.
Ich habe da auch die schicken nachgelöteten Drähte mit einem penetranten 
Kleber in der Nähe...

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Nur Mut, das geht schon. Siehe angehängtes Nachher-Bild, ich hab's heute 
morgen mal ausprobiert, an der schwierigeren Stelle (Kanal 2). Der 
vorhandene weiße Patchdraht ist teflonisoliert, dem passiert nichts.

- Mit Flußmittel und Entlötlitze für weniger Zinn an dem OpAmp-Beinchen 
sorgen
- Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den 
Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!
- Sicherstellen das man keine Lötbrücke hochgezogen hat. Mit nochmal 
Flußmittel das verbliebene Zinn auf der Platine verflüssigen, so daß es 
glatt fließt.
- den Blockkondensator auslöten und neu ausrichten, schräg am Massepad 
wieder anlöten, mit Pluspol frei
- einen neuen Patchdraht ziehen, vom freien Pin des Blockkondensators 
zum OpAmp-Pin und zu +5V.
- Sicherstellen das auch wirklich kein Kurzschluß zwischen den 
vorherigen 3,3V und den neuen 5V besteht oder bei Berührung von Pin3 
passieren kann. Ggf. Kleber oder Isoliermaterial dazwischen.

Ich hatte noch keine Zeit zu testen, ob sich die Linearität verbessert. 
Werde ich am Wochenende probieren.

Jörg

von Michael D. (mike0815)


Lesenswert?

Moin Jörg,

> - Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den
> Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!
Pfff...das wär's dann gewesen :-(

Den Kerko 90° zu drehen, wäre wohl etwas eng geworden? Das dachte ich 
mir schon fast.
Heute Abend, wollte ich sowieso mal die Widerstände Austauschen... wenn 
ich bis dahin wüsste, das die 5V was bringen, dann würde ich das gleich 
mitmachen!
Sagst du gleich bescheid, wenn du getestet hast?

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Du hast bei Kanal 1 noch die 0 Ohm Widerstände drin???
Zu Testzwecken?

Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Michael D. schrieb:
>> - Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den
>> Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!
> Pfff...das wär's dann gewesen :-(
Naja, dann muß man einen neuen einlöten und kann das dann auch gleich 
ordentlich machen. ;-)
Beim Einbau der neuen Eingangsstufe bleiben je Kanal 1-2 davon übrig.

> Den Kerko 90° zu drehen, wäre wohl etwas eng geworden? Das dachte ich
> mir schon fast.
Es ginge wohl schon, aber so ist der Patchdraht etwas kürzer. Die Länge 
bis zum Blockkondensator sollte induktionsarm sein.

> Heute Abend, wollte ich sowieso mal die Widerstände Austauschen... wenn
> ich bis dahin wüsste, das die 5V was bringen, dann würde ich das gleich
> mitmachen!
> Sagst du gleich bescheid, wenn du getestet hast?

Heute ab 22:00 guckt meine Frau ihre Lieblingssendung, dann könnt's 
gehen. ;-)

Hayo W. schrieb:
> Du hast bei Kanal 1 noch die 0 Ohm Widerstände drin???
> Zu Testzwecken?

Ja, damit ich die Software auch für Forumskollegen mit originalem Oszi 
ausprobieren kann. Kanal 3+4 haben die neue Eingangsstufe (nicht mehr im 
Bild). Die müßte für die 5V-Modifikation leider kurz wieder beiseite, um 
das da drunter machen zu können.

Jörg

von Blue F. (blueflash)


Lesenswert?

Ob sich die Änderung auf 5V auf die Linearität positiv auswirkt würde 
mich auch mal interessieren. Desweiteren, ob die Skalierung sich dadurch 
ändert, was eigentlich nicht der Fall sein sollte.

Wenn das positiv verläuft werde ich das auch gleich mal nachziehen. Ich 
hatte beim Blockkondensator allerdings so die Idee selbigen einfach 
senkrecht stehend auf seinem Pad aufzulöten, dann ist man schön frei vom 
3.3V-Pad und der Draht ist auch nicht länger.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Hayo W. schrieb:
> Ich
> hatte beim Blockkondensator allerdings so die Idee selbigen einfach
> senkrecht stehend auf seinem Pad aufzulöten, dann ist man schön frei vom
> 3.3V-Pad und der Draht ist auch nicht länger.

Hatte ich auch erwogen, der Draht wird dann noch kürzer. Ist mir aber zu 
abbrech-gefährdet, wenn man mal unbedarft über die Platine fingert.

Zum Thema Linearität hatte ich mich im Osoz-Thread mal ausgelassen. Hier 
der allgemeine Text:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Hier im Update (2 Postings später) die besser visualisierten Daten:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Erste vorläufige Messung: die Linearität wird nicht besser, sieht 
gegen Ende der Skala etwa gleich krumm aus wie vorher.

Mist!

Was nun, liebe Hardwerker?


Jörg

von Blue F. (blueflash)


Lesenswert?

Das ist ja doof :-(

Dann gibt es ja nix zu basteln...
Naja hab auch softwareseitig genug zu tun.

Hayo

von Michael D. (mike0815)


Lesenswert?

> Erste vorläufige Messung: die Linearität wird nicht besser, sieht
> gegen Ende der Skala etwa gleich krumm aus wie vorher.
so ein Mist, hatte mir doch eine kleine Veränderung erhofft, also lohnt 
der Aufwand nicht?!

Na ja, werde schon mal die 24 Ohm und den 180 Ohmler Tauschen.
Gibt es nur diesen einen Abschlusswiderstand?
(jetzt muss ich mal blöd fragen)
Müssten da nicht zwei sein, also je einer pro Kanal?

Gruß Michael

von Jörg H. (idc-dragon)


Lesenswert?

Michael D. schrieb:
>> Erste vorläufige Messung: die Linearität wird nicht besser, sieht
>> gegen Ende der Skala etwa gleich krumm aus wie vorher.
> so ein Mist, hatte mir doch eine kleine Veränderung erhofft, also lohnt
> der Aufwand nicht?!
Tja, ich war auch recht zuversichtlich, daß das die Ursache ist, hatte 
wenig Zweifel am Sinn der Maßname.
Es kann sein daß es für die neue Eingangsstufe sinnvoll ist, wäre an der 
Stelle noch den Versuch wert. Denn dort ist dieser OpAmp das letzte 
verbliebene Originalteil im Signalweg. Und auch dort ist die 
Nichtlinearität in gleicher Weise sichtbar.

> Gibt es nur diesen einen Abschlusswiderstand?
> (jetzt muss ich mal blöd fragen)
> Müssten da nicht zwei sein, also je einer pro Kanal?
Ja, jeder Kanal hat einen Abschlußwiderstand, so ziemlich mittig auf der 
Rückseite der 4 ADCs. Und 2 Längswiderstände hinter besagtem letzen 
OpAmp.

Jörg

von branadic (Gast)


Lesenswert?

Michael D. schrieb:
> Müssten da nicht zwei sein, also je einer pro Kanal?

Es ist ein differentieller Abschluss, man könnte jeden Pfad einzeln 
gegen Masse abschließen oder einfach einen Abschluss zwischen den beiden 
Pfaden einlöten, dass spart dann ein Bauteil.

Ich wundere mich doch sehr, dass die 5V-Versorgung keine Verbesserung in 
der Linearität bringen soll. Allerdings muss ich zugeben, dass ich den 
Einfluss dieser Maßnahme nicht für die originale Eingangsstufe überdacht 
habe sondern ausschließlich für die neue Eingangsstufe.

branadic

von Jürgen (Gast)


Lesenswert?

Hallo Jörg,

ist denn schon bekannt, wie das PIN4 der MAX1121 beschalten ist? 
Eigentlich sollten doch alle 4 ADC eines Kanals mit der gleichen 
externen common mode Spannung beschalten sein. Lt. 
"Analog-Input-Part_assignment_V1_3_3.pdf" ( was der letzte Stand ist?) 
müsste also PIN2/U12, Messpunkt13 und PIN3 der 4 ADC je Kanal verbunden 
sein. Im Datenblatt MAX1121 wird von 1,4V Vcm gesprochen. Mit dem 
eingezeichneten Teiler im Stromlaufplan kommen wir aber nur auf 1,25V? 
Kann das eine Ursache für die Begrenzung der Spannungen sein?

Gruß
Jürgen

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Jürgen,

guter Punkt, da liegen 1,25V an, weil die ADCs es so brauchen.
Von daher bringt eine großartige Erweiterung des positiven Rails 
vermutlich wenig, man könnte das negative etwas tiefer als Masse legen.
Aber vorher mal messen, was da wirklich passiert...
(Dank an branadic für die Diskussion per Skype)

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Uff, mir fällt ein Stein vom Herzen, endlich habe ich das mit dem 
SRAM-Interface für das Nios II Design hingekriegt. Beide mir zur 
Verfügung stehenden Hauptplatinen laufen stabil.

Schon von einem Monat habe ich das Interface gründlich umgebaut, auf 
Registerausgänge, in der Hoffnung das Timing sauberer zu kriegen. Aber 
nach Sekundenbruchteilen stürzte es hoffnungslos ab, auf meiner Platine 
ging es gar nicht.

Nun habe ich mir am Wochenende ein stark verkleinertes Testdesign 
gebaut, nur noch Speicher, LCD und ein Dummy-Master, keine CPU und keine 
Peripherie. Das kompiliert in 20 Sekunden statt 2 Minuten, so konnte ich 
schneller systematisch an der PLL für die Speichertakte rumspielen, am 
LCD dann sehen ob das Bild OK ist.

Ergebnis war: das neue SRAM-Interface ist "zu gut"! Die Timings hatten 
sich um ca. einen halben Takt nach vorne verschoben, mein 
Abtastzeitpunkt lag nun voll daneben. Das neue Interface würde sich bei 
110 MHz am wohlsten fühlen, dann gingen die Lesedaten mit passender 
Phasenlage für den Speichertakt glatt durch. Es ist total unkritisch, 
auch die Maximalfrequenz von 125 MHz ist (mit einem passenden Lesetakt) 
kein Problem. Vorher waren solche Frequenzen höchst kritisch, ging 
praktisch nicht, die PLL für den Lesetakt mußte auf Bruchteile von 
Nanosekunden stimmen. Nun ist da üppig Luft.

Das ist aber alles zuviel für unseren Nios und die Verbindung zum 
zweiten FPGA, da bleibt es vorerst bei 75 MHz. Von daher muß ich das 
SRAM ein bischen ausbremsen, die Daten zum halben Takt in ein 
Zwischenregister übernehmen, dort ein bischen rumtrödeln lassen bis zur 
"richtigen" Taktflanke.

Und noch ein zweiter Fehler spuckte mir in die SRAM-Suppe: Solange das 
zweite FPGA noch seinen Originalinhalt hat darf ich an den beiden 
Interconnects nicht rühren, die bisher ein Chip Select dafür darstellen. 
Sonst treibt es auf den SRAM-Bus und macht mir dort die Daten kaputt. 
Ich hatte angefangen die für meine neue Verbindungsmimik umzuwidmen, das 
darf so noch nicht.
Deshalb ging auf meiner 4kanal-Platine gar nichts mehr. (2 Fehler 
übereinander mit gleichem Symptom sind übel, man bemerkt es nicht wenn 
man einen behebt.) Nun habe ich das umbelegt, Osoz rast wieder fröhlich 
vor sich hin.

Puh, ich bin heilfroh über diesen Berg zu sein!

Jörg

von Blue F. (blueflash)


Lesenswert?

Na das nenn ich mal eine Erfolgsmeldung. Dann rückt eine Neugeburt 
unseres DSO ja in greifbare Nähe.

Zu dem Trigger API - ich teste/probiere gerade intensiv an den Holdoff 
und Pulsweiteneinstellungen herum in der Hoffnung hier neue Erkenntnisse 
zu gewinnen. Für die Tests am Holdoff brauche ich allerdings erstmal 
einen Bitmustergenerator, sonst komme ich da nicht weiter.

Kennt jemand eine Software, die Bitmuster auf RS232 oder LPT ausgeben 
kann?

Ansonsten bin ich am überlegen, ob ich mir selbst was schreibe, oder mir 
einen Generator aus einem Schieberegister selbst zusammenbaue.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Hayo W. schrieb:
> Für die Tests am Holdoff brauche ich allerdings erstmal
> einen Bitmustergenerator, sonst komme ich da nicht weiter.
>
> Kennt jemand eine Software, die Bitmuster auf RS232 oder LPT ausgeben
> kann?

Die Tx-Leitung der RS232 könntest du in Grenzen nehmen. Start- und 
Stopbit liegen vom Pegel zwar fest, aber mit den Bits dazwischen ließen 
sich einfache Muster bauen. Über die Baudrate kannst du noch das Timing 
hindrehen.

Wenn das reicht kannst du dir eine große Datei mit immer dem gleichen 
Zeichen (oder dem Zeichenmuster) machen, die dann auf den COM-Port 
kopieren. Oder ein Script/Programm, was in Endlosschleife drauf 
schreibt.

Mit der Soundhardware lassen sich lange und freie Muster bauen. 
Allerdings sind die Ausgänge AC-gekoppelt. Eventuell läßt sich das 
Signal vorher abgreifen, an z.B. einer USB-Hardware?

Jörg

von Blue F. (blueflash)


Lesenswert?

Jörg H. schrieb:

> Die Tx-Leitung der RS232 könntest du in Grenzen nehmen. Start- und
> Stopbit liegen vom Pegel zwar fest, aber mit den Bits dazwischen ließen
> sich einfache Muster bauen. Über die Baudrate kannst du noch das Timing
> hindrehen.
Ja sowas in der Art hatte ich mir auch schon überlegt .bzw. das weiter 
unten...


> Wenn das reicht kannst du dir eine große Datei mit immer dem gleichen
> Zeichen (oder dem Zeichenmuster) machen, die dann auf den COM-Port
> kopieren. Oder ein Script/Programm, was in Endlosschleife drauf
> schreibt.

...nämlich mit einem kleinen Programm Muster auf den Ports ausgeben.

> Mit der Soundhardware lassen sich lange und freie Muster bauen.
> Allerdings sind die Ausgänge AC-gekoppelt.

Da hatte ich die Hoffnung, dass ich nicht der Erste bin, der sowas 
braucht und dass sich schon mal jemand rangesetzt hat und sowas 
geschrieben hat.
Habe aber per Google-Suche nix gefunden.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Eventuell hilft dir das ja weiter.....

http://wndlpt.sourceforge.net/

von Blue F. (blueflash)


Lesenswert?

Nur bedingt,

da würde ich dann lieber ein kleines C-Progrämmchen schreiben. Aber 
danke für den Tip. Ich denke ich werde mir mit einem Schieberegister 
einen Mustergenerator bauen, den ich dann mit dem Funktiongenerator 
takte, da bin ich dann mit der Frequenz schön flexibel.

Gruß Hayo

von Sebastian .. (zahlenfreak)


Lesenswert?

Sowas hier?

http://sourceforge.net/projects/signalgenerator/

Grüße, Sebastian

von Blue F. (blueflash)


Lesenswert?

Hi Sebastian,

nein auch nicht ganz. Die Signale sind eher für Audio Projekte gedacht. 
Mir geht es um digitale Bitmuster, die die Funktion der Holdoff-Zeiten 
wiederspiegeln können.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Mal eine Statusmeldung von der Nios II Hardware:

Ich habe ziemlich lange an der Anbindung des 2. FPGAs herumgetüftelt. 
Das ist eine Erweiterung des SRAM-Controllers, weil dessen Bus quasi 
nebenberuflich die Verbindung bildet. Er muß es also auch koordinieren.
Ist mir bisher noch nicht gelungen, da Timing fliegt mir um die Ohren, 
zuviel Logik zwischen 2 Takten. Und das, obwohl ich das schon mit einem 
Waitstate für den externen Zugriff entschärft habe. Da muß ich nochmal 
zurück ans Reißbrett.

Andiiiy meinte, ich solle mich erstmal mal um Trigger und Zeitbasis 
kümmern, damit es zumindest als 2Kanäler mehr einsetzbar wird und wir 
mehr Begeisterung für die Softwareentwicklung wecken, Hayo abholen.
Grübel grübel, auch keine leichte Sache, das mit dem Trigger. Die 
Ansprüche steigen ja auch gerade...

Ich habe mir in dem Zuge das Leon-Design genauer angeguckt, da gibt es 
ja schon mehr als ich dazu je zustande brächte. Eigentlich hatte ich 
geplant, das hoffentlich irgendwann schrittweise zu verstehen und zu 
portieren.
Die Quellen sind leider kaum kommentiert. Dieses Wochenende habe ich 
VHDL-Legastheniker damit verbracht, mich durch die Hierarchien zu 
wühlen, um rauszufinden wo denn da unten und oben ist. Und es reifte ein 
Plan:
Wir könnten den Signalverarbeitungsteil so wie er ist in ein (großes) IP 
verpacken, als Avalon-Slave. Also als eine von den vielen Einheiten am 
Bus, der Rest des Systems besteht auch aus solchen, schon fertige von 
Altera oder selbstgeschriebene für unsere speziellen Hardwareeinheiten. 
Dann spielt es auch keine Rolle daß das in VHDL geschrieben ist und mein 
Rest in Verilog. Damit hätten wir hoffentlich eine solide Ausgangsbasis. 
Alex hat sein Zeug ja schon simuliert und getestet.

Ein paar Details:

Alex hat ausgenutzt, das die 125 MHz Signalverarbeitung (250 MHz / 2) 
ein Vielfaches von seiner CPU-Frequenz von 31,25 MHz ist. Das möchte ich 
nicht, aber wir haben eh einen langsameren Peripherietakt, an den wäre 
das IP sowieso angeschlossen. Den habe ich nun von 25 auf 31,25 MHz 
umgestellt. Ich wollte den eh erhöhen, um das 90 ns Timing für das Flash 
besser erzeugen zu können. Momentan wurde das zu 120 ns aufgerundet, nun 
sind es 96 ns, fast perfekt.

Ich habe mir die Interfaces des Signalteils angeguckt. Es erscheint gut 
machbar, das für uns anzupassen. Nur zwei Komponenten müssen stark 
verändert oder neu gemacht werden:

1. Der Bus-Anschlus für die Programmierregister und den Zugriff auf den 
Samplespeicher muß in die Altera-Welt überführt werden. Aus taktischen 
Gründen mache ich 2 Slaves draus, einen für SFR, einen anderen für den 
Speicher. Nur SFR braucht die 31,25 MHz, den Speicher kann ich dann 
später im 2. FPGA an den schnellen Bus anschließen. Ein leeres IP für 
diesen Doppel-Slave habe ich schon gebaut und eine VHDL-Hülle erzeugen 
lassen.

2. Die ADC-Daten kommen bei uns anders rein, da würde ich gerne den 
DDR-Trick weiterhin anwenden. Alex hat in dem Teil auch die PLLs 
instantiiert und stellt nebenbei alle Systemtakte zu Verfügung. Bei uns 
geschieht das außerhalb, das kann entfallen.

Alles was nicht zum Signalteil gehört kommt raus. Also der Leon und 
seine verschiedenen IPs, sowie die Alex-Teile für RAM-Interface, LCD, 
Keyboard, Drehgeber. All das habe ich ja bereits passend für Alteras 
Avalon-Bus und mit Verlaub, in recht leistungsfähiger Ausführung.

Für jemanden der VHDL kann ist dieser Umbau vermutlich keine große 
Sache. Ich hingegen müßte das erst lernen. Mag mir jemand helfen, haben 
wir noch unentdeckte Talente?

Viele Grüße
Jörg

von Blue F. (blueflash)


Lesenswert?

Also da ich mit FPGAs im Studium nur am Rande zu tun hatte kann ich da 
nur anerkennend nicken. Ich bin ja gespannt was dabei rauskommt. Das 
hört sich ja sehr vielversprechend an.

Achtung, ab hier kurzfristig  etwas offtopic...

Inzwischen habe ich mal in der neuen Version versuchsweise mit einer 
Execution Queue experimentiert, auch mit verschieden priorisierten 
Tasks. Das funktionierte auch ganz gut, nur bei zeitkritischen Vorgängen 
war dann der Verwaltungsoverhead für die bescheidene Rechenleistung des 
NIOS zu groß. Da funktionierte dann die simple Flagsteuerung in der 
Endlosschleife besser. Ich hab das dann also erst mal wieder 
rausgenommen und nur eine einfache verzögerte dynamische 
Funktionsausführung mittels VSync-Interrupt implementiert.

Ab hier wieder voll im Thema...

Mit der neuen FPGA-Implementierung sehe ich aber wirklich interessante 
Möglichkeiten da dank der deutlich besseren Performance auch keine 
Abstriche mehr wegen etwas Verwaltungsoverhead gemacht werden müssen.

Solange das neue FPGA-Design noch "under constuction" ist werden ich 
noch etwas an der alten Firmware rumtüfteln, bin aber schon ganz 
gespannt was so alles möglich sein wird.

In diesem Sinne

Gute Nacht (oder Morgen)

Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Moin,

Hayo, tüftele nicht zuviel, das kann nun recht schnell gehen hier. Nach 
dem Einbau des Leon-Signalteils wäre das neue Design zumindest als 
2Kanäler fertig. (Vorbehaltlich Debugging, es ist noch nicht alles 
getestet.)

Für jemanden der VHDL kann wäre der Einbau vermutlich eine Sache von 
wenigen Stunden. Ich hingegen muß erst ein Buch lesen...

Zum offtopic:
Komisch, für so'n bischen Verwaltungskram sollte die CPU-Geschwindigkeit 
keine Rolle spielen. Bei Osoz geht's doch auch?

Jörg

von Blue F. (blueflash)


Lesenswert?

Ich ziehe für die 6.3 noch ein paar Kleinigkeiten glatt, keine großen 
Sachen. Das Experimentieren mit der Queue war auch für mich zum lernen 
gedacht. War einfach neugierig ob das gut funktioniert und das tut es. 
Meine Queue war 8 Handles lang und im Normalbetrieb waren maximal 4 
Handles gleichzeitig belegt da die längste Prozesskette eben 4 Prozesse 
enthält.

Nur bei den ganz langsamen Zeitbasen (Rollmode) da ist das Timing so 
eng, dass der NIOS es nur alle 5 - 10 Acquisitionen schafft, die 
komplette Prozesskette zu durchlaufen. Das führte dann ständig zu 
Queue-Überläufen oder eingefrorenem Bildschirm. Da ist die Schleife mit 
den Flags  einfach stabiler und arbeitet die asynchron auftretenden 
Anforderungen ohne Ruckler ab.

Mit der Rechenleistung des NIOS II sollte das aber kein Problem sein.
Hmm, ist ja eigentlich völlig offtopic hier...

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, von mir mal wieder einige Screenshots zu einem Thema das mir seit 
einiger Zeit durch den Kopf geht. Da ich zum Testen immer an allen 
Kanälen das gleiche Signal liegen habe ist mir aufgefallen, dass bei 
meinem unmodifizierten W2014A die Amplitude des Signals je nach 
Abtastrate zwischen den Kanälen stark abweicht. Ich habe mal von 01 - 06 
die Abtastrate kontinuierlich erhöht. Man sieht sehr schön wie die 
Amplitude immer mehr abweicht. Auf Bild 07 und 08 kann man sehen, dass 
Kanal 1 und 3 kaum Abweichung haben, dagegen Kanal 2 und 4 sehr starke 
Abweichung.

An allen Kanälen liegt das gleiche Signal mit gleich langen Zuleitungen 
an.
Die Frequenz des Signals ist die ganze Zeit gleich (35Hz Rechteck).

Hat jemand vergleichbare Beobachtungen gemacht?

Mein Verdacht ist ja, dass das evtl. mit unseren bekannten 
Abschlußwiderständen zusammenhängt, denn siehe nächster Beitrag...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...beim modifizierten W2022A mit der Widerstandskombination 24.9/180 Ohm 
ist das so gut wie überhaupt nicht zu beobachten.

Mich würde ja interessieren ob die Verteilung der Abweichung über die 
Kanäle bei allen Geräten gleich ist, oder ob das so rein zufällig 
verteilt ist.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Noch ein kleiner Nachschlag, wenn man die beiden am stärksten 
voneinander abweichenden Kanäle nimmt (2 + 4) und dann ans Ende des 
Memory scrollt stellt man fest, dass sich die Amplituden zum Ende hin 
wieder annähern, was irgendwie auf kapazitiven Einfluß hindeutet bzw. 
auf eine (parasitäre?) RC-Kombination. Kann gut sein, dass unsere 
Abschlußwiderstände hier mit reinspielen. Ich werde wohl demnächst auch 
das 2014A mal mit den richtigen Widerständen ausstatten, dann habe ich 
den direkten Vergleich.

Was ich mir auch vorstellen könnte, das ist das die Abgleicheinsteller 
im Eingang unter den Abschirmblechen da einen Einfluß drauf haben. Das 
Thema hatten wir ja auch schon mal vor längerer Zeit.

Hayo

von Guido (Gast)


Lesenswert?

Jo, sieht nach Überschwinger (grün) bzw. Kriechen (rot) aus.
In den späteren Bildern ist das durch die extreme Dehnung
nicht mehr zu erkennen. Ich würde das erstmal mit 1 kHz
kontrollieren, sollte aber durch Abgleich behebbar sein.

Grüße, Guido

von Luc (Gast)


Lesenswert?

Guten Abend Hayo, Branadic, Jörg H.,  Kurt Bohnen und all jene, die an 
dem Projekt beteiligt sind Welec!

Hayo W. schrieb:
>...beim modifizierten W2022A mit der Widerstandskombination 24.9/180 Ohm
>ist das so gut wie überhaupt nicht zu beobachten.

It is a bit of time that I wanted to ask some questions about the 
hardware in the Welec DSOs.
The new resistors as was suggested by Branadic (RESPECT!) last summer 
and experimented by Jörg H. (RESPECT!) and others (RESPECT!) should be 
of 174 Ohm for the best results.
I understand their values range is between 165,3 and 187,5 Ohm but 
better choice is 173,684Ohm (~ 174 Ohm) but in order to match with the 
HARDWARE setting in the latest firmware release what is the right 
value?, 180 or 174Ohm?
I guess 180 Ohm is the value that Hayo used to recompile the 
tc_vars.cpp file, because the 174 Ohm is more hard to find: is it 
correct?
Also I guess they should be at least with tolerances of 1% or better and 
with temperature coefficients of 1ppm/°K or better.
24,9/150 Ohm resistors I put in my DSOs were as gift in the materials I 
bought from Kurt Bohnen (many thanks and RESPECT!) and I don't know 
their tollerance and temperature coefficients, again seems to me I never 
read about it in the Forum (but maybe I wrong).
So now in order to do the modify what are the right tolerances value and 
temperature coefficients?
Thanks in advance.
After I changed the front-end's resistors in my two DSOs (a W2022a and a 
W2012a) the 3dB bandwidth became incredibly linear and much better than 
before.
Now I read that changing the 150 Ohm resistors with new ones 180 Ohm 
values (~174 Ohm) then it is possible to obtain a further improvement 
and I'd like to make the modify because I often have to deal with RF 
signals.
Even if the final improvement is still small it would be useful to me, 
waiting for the pickaback by Branadic can it be handled by the firmware 
in the new "OZOS" FPGA by Jörg H. & C.

Hayo W. schrieb:
>Hat jemand vergleichbare Beobachtungen gemacht?

Hayo, what you wrote is really very interesting.
Since roughly one year my DSOs have a 24,9/150 Ohm resistors in them and 
seems to me the DSOs' behaviour is what You have described.
The only thing that I can add and that I had already pointed out long 
ago is that in my point of vision could be a little mismatch among the 
channels phase as I wrote here:

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"
and going ahead.

Nochmals vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Jörg H. (idc-dragon)


Lesenswert?

In Bezug auf Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)":
Ich habe in meinem Buch gelesen, VHDL gelernt (ist gar nicht so schlimm 
wie alle sagen) und mich da mal rangemacht.

Im ersten Schritt (svn #852) habe ich das jetzige Sampler-IP im Nios II 
Design so umgebaut, wie auch das Leon-IP aussehen soll. Dadurch sind die 
beiden einfach austauschbar.

Im zweiten Schritt (svn #855) habe ich den vorhandenen Sampler in das 
zukünftige IP kopiert und nach VHDL übersetzt, sozusagen zum Üben. Er 
funktioniert noch.

Im dritten Schritt habe ich die Leon-Sourcen die wir brauchen dort 
eingepflegt und sukzessive umgebaut. Die restlichen Systemteile raus, 
Eingang und Businterfaces quasi neu. Das ging insgesamt besser als ich 
dachte. Alex hatte das schon recht gut strukturiert. Die meisten Dateien 
konnte ich unverändert übernehmen.
Wer schauen mag, wie das nun aussieht, was für Änderungen nötig waren:
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/nios2/altera/ip/W2000_Downsample/
Die Verzeichnisstruktur habe ich stark vereinfacht, aber die Dateien 
heißen noch wie im Original.

Der aktuelle Stand enthält also bereits den Signalteil und Trigger vom 
Leon-Design, mit dessen aufwändiger Filtermöglichkeit und so. Das FPGA 
ist nun etwa halb voll, dauert ca. 1,5 mal so lange zu übersetzen wie 
davor (der neue Teil ist schon ein großes IP).

Als nächstes steht an, das zu testen und den Softwaretreiber anzupassen. 
Auf Anhieb wird bestimmt nicht alles richtig sein. Ich muß nun erstmal 
schauen, was ich denn mit den neuen Register so anstellen soll...

(Ich sollte Alex mal Bescheid sagen, das seine Diplomarbeit nun nach 4 
Jahren hoffentlich endlich zu Ehren kommt.)

Jörg

von Luc (Gast)


Lesenswert?

Guten Abend Jörg H. und all jene, die an dem Projekt beteiligt sind 
Welec!

Jorg, es ist wirklich interessant, was du geschrieben hast.
Vielen Dank für die Arbeit und Freizeit, die uns freundlicherweise zur 
Verfügung gestellt: KLASSE!
Ich habe ein paar Fragen.
Ihr neuer FPGA-Design "OSOZ" wird in das Oszilloskop auf die gleiche 
Weise die Alex [alex008] LEON geladen? (Vielen Dank an Alex: KLASSE!)
Sie können versuchen, es in den Speicher des Oszilloskops ohne die 
Notwendigkeit, sie dauerhaft setzen, wie es für LEON war?
Vielen Dank im Voraus!

Mit freundlichen Grüßen,

Luc

von Jörg H. (idc-dragon)


Lesenswert?

Hello Luc,

let me try to clarify:

Osoz is the new software. It currently runs on both the original FPGA 
and the new one I'm working on.
For the original FPGA, Osoz loads pretty much the same way as Hayo's BF 
software, to Flash or RAM, using my compression loader.

The 2nd half of last year I got distracted from continuing it, because 
we got hold of an earlier version of the original FPGA design sources. 
They turned out to be not really useful, but I got interested in 
bringing up a new design which best utilizes our Altera FPGA and 
toolchain. Made from scratch on a higher level, not just the software, 
also the hardware.

It doesn't have a catchy name yet, so far we just call it the Nios II 
design, after the now used CPU core. It is probably the most powerful 
you can get into that FPGA, can be clocked about 2-3 times faster than 
the Leon, because it is specifically designed for (Altera) FPGAs, versus 
the Leon is for ASICs (real chips), doesn't synthesize too well on an 
FPGA. Unfortunately it's not free, but we have a license at work.

I made all the W20xx specific peripherals as IPs for the Altera SOPC 
builder, their way of graphically putting a system together. The newly 
developed IPs are the sampler, SRAM interface, keys, LCD, LED, PWM 
generators, rotary, SPI, bridge to 2nd FPGA. A lot of stuff...
For the sampler I sortof gave up my primitive proof of concept design 
and lately adapted the signal processing part of Alex' design, which is 
pretty sophisticated.
All in all we now have (or will shortly have) a best of all worlds 
design!

It was pretty easy to port Osoz to the Nios II design, because it was 
made to be portable and the new hardware has similarities to the old 
one.

You asked how to load it:

FPGA loading is similar to the procedure with the Leon design, using 
Altera Quartus. You can load it using the Slog driver and the builtin 
USB1 chip, which only works for 32 bit Windows and is a bit tricky to 
install, because Windows so much loves to use its builtin HID driver 
instead.
Or better get a cheap $10 USB blaster clone and plug it to the JTAG 
port, giving you USB2 speed.

After FPGA loading, which can be done non-volatile, the Nios II has the 
advantage that you can download and debug its software over JTAG, too. 
(With Leon this was done cumbersome over the serial, I never managed 
that.)

Osoz for the Nios II can be flashed, thanks to the bootloader I wrote. 
It has a different load address, so both can coexist, the Flash is 
rather large. You can prepare that while still using the original 
design. If this is in place, once the FPGA has been loaded with Nios II, 
it immediately starts its software from Flash.

If ony day you love it, you can also program the FPGA permanently, into 
it's dedicated configuration flash. If for some reason you change your 
mind, flash your original backup.

Nothing released yet, stay tuned...

(Right now I'm tring to figure out how to configure Alex' capture unit. 
It's not my hardware, for a change.)

Jörg

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

Neulich war mal eine variable Amplitudeneinstellung Thema, wenn ich 
recht erinnere. Oft ist die starre 1-2-5 Teilung etwas grob. Bei meinem 
uralten Analogoszi kann ich mit einem Extraregler das kalibrierte Grid 
verlassen und das Signal so groß stellen wie ich mag. Ist mitunter 
nützlich, um 2 Signale verschiedener Amplitude zu vergleichen, z.B. Ein- 
und Ausgang.

Kollege branadic hat noch auf einen weiteren Vorteil der neuen 
Eingangsstufe hingewiesen:
Die Verstärkung ist dort in 2dB-Schritten einstellbar. Damit sind 
feinere Abstufungen möglich, unter Beibehaltung einer guten 
ADC-Aussteuerung.
Statt 1 - 2 - 5 hätten wir pro Dekade:
1 - 1,25 - 1,6 - 2 - 2,5 - 3,2 - 4 - 5 - 6,4 - 8
Also jeweils 2-3 Zwischenstufen, oder anders ausgedrückt 10 statt nur 3 
Schritte pro Dekade..
Was kontinuierliches dazwischen wäre mit Softwareskalierung möglich.

Wer's genau wissen will, was da wann intern zu schalten und wie zu 
skalieren ist, siehe Anhang. (Ist auch von branadic.)

Jörg

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hallo Jörg,
das ist nicht nur bei deinem Analogoszi so.
Das Voltcraft/Hantek/Tekway, hat das ebenfalls und zwar auch stufenlos.
Bei der groben Einstellung gehen die großen Sprünge ebenfalls auf 1-2-5.
Hier ein paar Shots, wie das in der Menuführung dargestellt ist.
Zur besseren Darstellung, habe ich die V/DIV Anzeige markiert.

Gruß Michael

von Luc (Gast)


Lesenswert?

Guten Abend Jörg H., Branadic und all jene, die an dem Projekt beteiligt 
sind Welec!

Well Jörg, thank you very much for this great explanation: RESPECT!
Before I didn't know some things but now all it's much clear, thank You 
again also for the great work You are working on: KLASSE!
I know QUARTUS so I think it will easy to put your new design on the 
DSO, I can't wait for the public release!  :-)

Jörg H. schrieb:
>Neulich war mal eine variable Amplitudeneinstellung Thema, wenn ich
>recht erinnere. Oft ist die starre 1-2-5 Teilung etwas grob. Bei meinem
>uralten Analogoszi kann ich mit einem Extraregler das kalibrierte Grid
>verlassen und das Signal so groß stellen wie ich mag. Ist mitunter
>nützlich, um 2 Signale verschiedener Amplitude zu vergleichen, z.B. Ein-
>und Ausgang.
Really very impressive, this is as dream come true, no words: RESPECT!!!

@Jörg H. and Branadic
Much terrific what I read, again this time I'm speechless, no words: 
RESPECT!
Great the support for Huckepack by Branadic, finally! :-)
Another dream who come true!: RESPECT!!! :-)

Nochmals vielen Jörg H., Branadic an alle Unterstützer des Projekts 
Welec!
Sie sind alle wirklich großen: KLASSE!

Mit freundlichen Grüßen,

Luc

von Jörg H. (idc-dragon)


Lesenswert?

Ein Update:

Am Wochenende habe ich erste Gehversuche mit der frisch integrierten 
Capture-Hardware vom Alex gemacht. Er hat mich auch höchstpersönlich 
unterstützt, was sehr hilfreich war. Ich denke, mittlerweile habe ich 
verstanden wie das arbeitet. (Bis auf die Filter, die sind nicht zu 
verstehen ;-)

Beim Interruptteil hatte ich noch einen Bug eingebaut, und die Kopplung 
für das 2. FPGA ist nun vorbereitet.

Die Hardware scheint nun wie vorgesehen zu arbeiten, ich sehe erstes 
Wellengezappel. Sprich, es geht!

Ich würde eine Sache noch gerne ändern, das Format der Speicherung im 
FPGA. Derzeit wären die Capture-Daten etwas ineffizient zu kopieren, 
Byte- oder Wortweise in teils mehreren Durchgängen, statt linear mit 32 
Bit Zugriffen.

Dann gibt es noch einiges in der Software zu tun. Trigger und Zeitbasis 
einbauen, eine andere Samplespeicherverwaltung, die berücksichtigt das 
es im FPGA nun einen gemeinsamen Speicher für beide Kanäle gibt.

Jörg

von Guido (Gast)


Lesenswert?

Leider kann ich dir nur virtuell auf die Schulter klopfen,
gute Arbeit!

Jörg H. schrieb:
> (Bis auf die Filter, die sind nicht zu  verstehen ;-)

Ja, geht uns doch allen so, man muss nicht alles im Detail
verstehen, solange es funktioniert. Alex wird sicherlich
niemals vergessen wie das geht. ;-) Ich wollte mir vor
kurzer Zeit eigentlich nur mal die Mathematik dazu ansehen,
ist schon sehr aufwendig und momentan nicht zu machen.

Es ist aber schön zu sehen, dass Alex Arbeit nicht umsonst war.

Grüße, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Jetzt mal was ganz Anderes, mit Bezug auf meinen Beitrag weiter oben

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Ich habe jetzt mal versucht mit den beiden Justierschrauben den 
Unterschiedlichen Pegel richtig einzustellen. Dazu habe ich mir im 5V 
Bereich ein Rechteck mit 100 KHz und 10Vpp eingestellt. Bei 100ns und 
bei 50ns kann man ziemlich gut sehen ob die Pegel der einzelnen Kanaäle 
übereinstimmen. Wichtig ist, dass man vorher das Channel Delay richtig 
einstellt. Bei mir hat es sich auch als hilfreich erwiesen den Noise 
Filter auf Smooth zu stellen.

Man nimmt sich einen Kanal als Referenzkanal und richtet die Anderen 
daran aus. Man muß mit beiden Einstellern etwas spielen bis es stimmt, 
dann kriegt man die Signale aber total deckungsgleich. Zum Einstellen 
habe ich einen Kunstoff-Schraubendreher verwendet der bei meinen 
TEK-Tastköpfen dabei war.

Das zeigt auch, dass die Justierung bei Wittig eher lieblos war, wenn es 
denn überrhaupt eine gab. Wer also bei sich auch feststellt, dass seine 
Kanäle nicht deckungsgleich sind sollte da mal selbst nachjustieren.

Aber Vorsicht! Man muß das bei abgenommener Rückwand machen und kann 
sich da am Netzteil gehörig einen wegholen wenn man unachtsam ist!

Auf dem Screenshot sieht man nur noch einen kleinen Channel Delay, aber 
die Pegel und die Kurvenform sind identisch. Beim W2014A sieht es jetzt 
genauso gut aus.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Und hier noch mal das W2014A nach dem Abgleich. Man sieht ziemlich 
deutlich den Unterschied zu vorher. Ich habe übrigens das Signal einfach 
ohne Abschlüsse mit vier gleich langen Meßleitungen und diversen 
T-Stücken direkt angeschlossen. Das angezeigte Signal ist natürlich aus 
meßtechnischer Sicht nicht brauchbar, aber zum Abgleichen der Kanäle 
untereinander durchaus gut zu gebrauchen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja noch ein kleiner Tip, der untere Einsteller beinflußt das 
negetive Teilsignal am meisten und der obere Einsteller das positive 
Teilsignal.

Guats Nächtle

Hayo

von Michael D. (mike0815)


Lesenswert?

@Hayo
> Wichtig ist, dass man vorher das Channel Delay richtig
> einstellt.
Wie meinst du das denn? Den 1. Kanal als Referenz nehmen, quasi "0ns" 
Delay, den 2.Kanal nachziehen z. B. "2-3ns" Delay und dann abgleichen, 
oder beide auf "0"ns (Software technisch)stehen lassen?

Gruß Michael

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Also erstmal braucht man ein Signal mit möglichst steiler Flanke. Mein 
Rechteck hat ca. 30ns Risetime. Das ist jetzt nicht so superschnell, 
aber reicht dafür locker aus. Die Aussteuerung sollte möglichst so bei 6 
Div-pp liegen, damit man auch was erkennen kann.

Die Signalfrequenz selbst ist eher unwichtig. Ich habe ca. 100KHz 
verwendet. Pretrigger auf Bildschirmmitte stellen. Normal oder 
Combi-Trigger einstellen, so dass die Flanke schön ruhig in der 
Bildmitte steht. Die Timebase sollte mindestens auf 100ns stehen, besser 
50ns, da hier erst die Frequenzeinflüsse des Signals richtig sichtbar 
werden.

Dann sieht man schon ob die Kanäle ein Delay haben (Bild Delay01). Das 
Delay so einstellen, dass die Flanken möglicht in Deckung sind(Bild 
Delay02).

Wenn das erledigt ist, kann man sich um die Einstellung mittels der 
kleinen Einsteller unter der Abschirmung kümmern. Dieser Abgleich dient 
der Frequenzkompensierung des Eingangs! Das ist also nicht für 
Gleichspannungen oder langsame Signale gedacht. Das ist vergleichbar mit 
der Abstimmung eines Tastkopfes.

Beim Vergleich mit meinem anderen Oszi schien mir Kanal 1 am ehesten der 
richtigen Signalform zu entsprechen, daher habe ich dann die anderen 
Kanäle so abgestimmt, dass sie mit Kanal 1 deckungsgleich wurden.

Mit dem unteren Einsteller beeinflußt man die negative Halbwelle, mit 
dem oberen Einsteller die positive Halbwelle.

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

ok, wenn man Kanal 1 als Referenz nimmt, dann muß ja wohl an dessen C's 
nicht geschraubt werden, es wäre also nur Kanal 2 einzustellen. Sehe ich 
das richtig?

Gruß Michael

EDIT: Uff, du hast 31,6V P-P ?

von Blue F. (blueflash)


Lesenswert?

Michael D. schrieb:
> ok, wenn man Kanal 1 als Referenz nimmt, dann muß ja wohl an dessen C's
> nicht geschraubt werden, es wäre also nur Kanal 2 einzustellen. Sehe ich
> das richtig?

Ja richtig. Es sei denn der ist auch so verbogen, dass man beide Kanäle 
richten muß. Halte ich aber für nicht so wahrscheinlich.

> Gruß Michael
>
> EDIT: Uff, du hast 31,6V P-P ?

Jupp mein uralter HP3310B Generator hat soviel raus.

Hayo

von Blue F. (blueflash)


Lesenswert?

Sollte natürlich heißen "haut soviel raus"

Hayo

von Nicki (Gast)


Angehängte Dateien:

Lesenswert?

Erstmal Dank an alle, die in den beiden W2000A-Foren (Hardware und 
Firmware) so produktiv arbeiten. Vor einigen Tagen habe ich mein W2022a 
aus der Ecke geholt und statt der Welec 1.3 die BF 6.3 drauf gebracht, 
ich war begeistert. Nach ein paar erfolgreichen Testtagen ist das Gerät 
leider ausgefallen, es zeigt nur noch eine mit senkrechten Pixelstreifen 
überlagerte Anzeige oder gar keine. Die Tasten reagieren nicht mehr, bis 
auf die beiden linken unter dem Display, die das Loaden/Flashen 
erlauben. Testweise habe ich noch 6.4 geflasht, das Logo erscheint auch, 
ansonsten die Störung ist geblieben (vgl. Foto). Ich gehe von einem 
Hardware-Problem aus. Bevor ich jedoch das Gerät entsorge (täte weh), 
die Frage: hat jemand einen Hinweis zur möglichen Lösung des Problems?
Bitte entschuldigt, dass ich das hier poste, aber das ist wohl noch die 
einzige Stelle, wo Expertise zum W2000 vorhanden ist.
Vielen Dank im voraus!   Nicki

von Wolfgang (Gast)


Lesenswert?

Nicki schrieb:
> hat jemand einen Hinweis zur möglichen Lösung des Problems?

Kein Grund sich vom Gerät zu trennen - heiz schon mal den Lötkolben an.
Mein Tip wäre eine schlechte Lötverbindung beim RAM. Damit gab es schon 
öfter Probleme. Die Experten sehen bestimmt aus dem Photo gleich, 
welcher Baustein der schuldige ist.

von Blue F. (blueflash)


Lesenswert?

Jupp, Wolfgang hat Recht, das ist das RAM. Das Display ist ins RAM 
gemappt und wenn da einer oder zwei Pins schlechten Kontakt haben, gibt 
es diese typischen Streifen. Es gibt eine zweistufige Lösung. Da es zwei 
RAM Bausteine gibt, würde ich erst den am leichtesten Zugänglichen in 
Angriff nehmen. Dazu brauchst Du nur den rückwärtigen Deckel mittels der 
drei Schrauben zu lösen, und dann hast Du den ersten RAM-Chip schon vor 
Dir. Es ist der Chip direkt am Display-Stecker unterhalb der ersten vier 
ADCs. Da einfach mit der Spitze des Lötkolbens auf alle Pins einmal 
drauftippen und dann nochmal testen, ob es weg ist. Wenn nicht....der 
zweite Chip ist direkt unter diesem Chip auf der Rückseite. Dazu mußt Du 
die Hauptplatine ausbauen.

Oberteil vom Netzteil abschrauben (vier Schrauben), dann die beiden 
Steckerchen abziehen, die von der Netzteilplatine ans Display gehen. Als 
nächstes den Displaystecker lösen und die Befestigungsschraube der 
Hauptplatine. Die Drehknöpfe auf der Frontseite müssen leider auch ab. 
Die sitzen zum Teil sehr fest und lassen sich mit einem sehr kleinen 
Schraubendreher abhebeln gegen den Rand auf der Achse, wo der 
abgeflachte Achsenteil anfängt.

Die Muttern der BNC-Anschlüsse lösen und die Hauptplatine ist raus. Bei 
dem zweiten RAM-Baustein ebenfalls die Pins nachlöten. Das sollte es 
gewesen sein. :-)

Gruß Hayo

p.s. Wie Ihr schon gemerkt habt gibt es hier an der Ski-Piste WLAN - 
welch Glückes Geschick, tirili...

von Michael D. (mike0815)


Lesenswert?

> p.s. Wie Ihr schon gemerkt habt gibt es hier an der Ski-Piste WLAN -
> welch Glückes Geschick, tirili...
Das glaub ich doch jetzt nicht...der Hayo fährt mit dem Laptop Ski, da 
freut sich Petra bestimmt ;-)

von Blue F. (blueflash)


Lesenswert?

Jo mann, Stimmung ist gut!!!

von Nicki (Gast)


Lesenswert?

Danke Wolfgang und Hayo für den guten Zuspruch und die unglaublich 
schnelle Hilfe. Ich hab den Kasten aufgemacht und bin zu dem Schluss 
gekommen, dass ich ohne Lupe und spezielle Spitze besser nicht an die 
SMT-Lötstellen rangehe. Sobald ich ein Ergebnis habe, melde ich mich 
zurück. @Hayo: WLAN an der Piste, wie hat man sich das vorzustellen? Auf 
den Brettern, Ski-Handschuhe ausgezogen und dann mit dem Smartphone... 
;-)
Grüße, Nicki

von Blue F. (blueflash)


Lesenswert?

Haha, ja das wär cool. Nein, ist ganz einfach, wir wohnen in einer 
Pension direkt neben der Piste und die hat WLAN. Ist also nur halb so 
spektakulär.

Aber noch ein Tip zum Probieren: Es kann sein, dass es schon reicht beim 
Hochfahren leichten Druck auf den RAM-Chip auszuüben. Möglicherweise 
geht es dann schon wieder und Du weißt dass es an diesem Chip liegt.

Gruß Hayo

von Nicki (Gast)


Lesenswert?

Leider waren alle Versuche negativ. Löten mit 300°C Spitze die 
RAM-Beinchen sekundenlang angetippt, schließlich das ganze 
auseinandergebaut und auch die andere Seite behandelt. (Danke für den 
Tipp mit den Drehknöpfen!) Letztendlich zeigen sich im Moment keine 
Streifen mehr, aber auch sonst gar nichts ;-). Weiterhin reagiert das 
Scope nur noch auf die beiden linken unteren Tasten. Bildschirm hell, 
dann dunkel. Ein paar LEDs leuchten dabei mal, mal so... Erstmal ein 
schöne Tage im Schnee! Hast Du Dir verdient! Grüße, Nicki

von Andreas W. (andiiiy)


Lesenswert?

Nicki schrieb:
> Letztendlich zeigen sich im Moment keine
> Streifen mehr, aber auch sonst gar nichts ;-)

Hallöchen,

auch dabei möchte ich Dich ermutigen, da ich das Gleiche durchmachen 
musste. Du hast beim Löten ggf. 2 Beinchen kurzgeschlossen. Bei waren es 
ausgerechnet die 3,3 V ca. in der Mitte des Bausteines.

Bitte löte noch einmal alles mit VIEL Flussmittel nach!

Gruß Andiiiy

von Nicki (Gast)


Lesenswert?

Ausfall meines W2022A:
Danke für den Zuspruch. Ich hab noch mal einen Anlauf genommen und alle 
Pins an dem RAM Baustein nachgelötet.
Ergebnis unverändert. Flashen per WelecUpdater scheint noch zu gehen. 
Der Bildschirm bleibt aber dunkel. Ich werfe das Handtuch.
Grüße, Nicki

von Vorn N. (eprofi)


Lesenswert?

Willst Du ihn mir verkaufen?
Bitte teile mir mit, wie ich Dich erreichen kann.

von Andreas W. (andiiiy)


Lesenswert?

Nicki schrieb:
> Der Bildschirm bleibt aber dunkel. Ich werfe das Handtuch.

Hallöchen,

ich kann aus eigener Erfahrung sagen, dass es sich schon lohnt etwas zu 
warten. Solche Fehler müssen etwas reifen ... (bei mir ca. 6 Monate) ... 
und dann geht es in 5 Minuten wieder! Die Freude ist dann um so größer 
...

Da es in absehbarer Zeit das neue Design geben wird, wäre ein gänzliches 
Aufgeben nicht so sinnvoll.
(Jörg ich möchte Dich nicht antreiben -;)

Grüße Andi

von Blue F. (blueflash)


Lesenswert?

Hi, bin wieder im Lande. Hier gibt es ja mehr Schnee als in den Alpen - 
das braucht ja Keiner!

Zu Deinen RAMs: Wenn der Verdacht besteht, dass es Kurzschlüsse zwischen 
den Beinchen gibt kann Entlötlitze helfen. Einfach quer über die 
Pinreihe legen und dann die Reihe mit der Lötspitze abtupfen. Dadurch 
wird alles was an überflüssigem Lötzinn haltlos rumwabert von der 
Entlötlitze abgesogen, und nur der Teil bleibt übrig, der vom Übergang 
Pin zu Pad gebunden wird.

Gruß Hayo

von Nicki (Gast)


Lesenswert?

Hallo, ich hab alle benachbarten Pins an den zwei RAM Chips gemessen. 
Kein Kurzschluss.
Gibt's noch andere Ideen? Grüße, Nicki

von Blue F. (blueflash)


Lesenswert?

Also als Erstes müssen wir mal feststellen, was noch geht. Dazu mit der 
üblichen Prozedur die aktuelle Firmware flashen. Dann das Gerät wieder 
ausschalten. Jetzt ein Terminal mit den bekannten Einstellungen 
(Anleitung liegt im doc Verzeichnis) starten und danach das DSO starten. 
Anhand dessen, was jetzt ausgegeben wird (oder auch nicht) kann man 
schon mal abschätzen ob zumindest die Firmware läuft. Wenn die normale 
Startausgabe erscheint, kann man versuchen einige Remotefunktionen 
aufzurufen. Eine ganz einfache Testmöglichkeit ist der Frame-Counter, 
den man mit Shift + K aufrufen kann.

Gruß Hayo

p.s. Beim Nachlöten ohne Lötzinn kann es sein, dass sich beim Erhitzen 
das eine oder andere Beinchen etwas angehoben hat und dadurch der 
Kontakt zum Pad ganz unterbrochen wurde. da müßte man dann mit etwas 
Lötpaste nachhelfen. Die Lötpaste hat auch den Vorteil, dass sie sehr 
viel Flußmittel enthält, was einem sauberen Verlauf sehr entgegen kommt. 
Dein Problem ist mit großer Sicherheit eines oder mehrere der 
RAM-Beinchen. Sobald diese wieder richtig auf den Boden der Tatsachen 
zurückgebracht werden (sprich aufs Pad) sollte die Kiste auch wieder 
laufen.

von Jörg H. (idc-dragon)


Lesenswert?

Ich melde mich auch mal wieder...

Während Hayo sich im Skizirkus vergnügte war ich letzte Woche schwer 
grippekrank. Üble Sache, für die Zukunft empfehle ich impfen.

Am Wochenende davor hatte ich Alex' Samplespeicher überarbeitet, so das 
er für die Software besser zu benutzen ist und in allen Situationen die 
volle Kapazität nutzbar ist. Wir nicht mehr 16K pro Kanal, sondern 32K 
pro FPGA. Wenn man nur einen der 2 Kanäle eines FPGAs benutzt, dann 
steht doppelte Speichertiefe zur Verfügung.

Erst hatte ich da falsch gedacht, aber mit einem etwas anderen Ansatz 
funktioniert es. Die Daten müssen beim Auslesen leider meist byteweise 
umformatiert werden, aber neuerdings immerhin cache-freundlich. Sie beim 
Reinschreiben in voller Breite richtig zu drehen wäre leider sehr 
aufwändig, eventuell könnte ein späterer Umkopier-DMA-Controller aber 
sowas leisten.

Na gut, ich lasse das mit den Details. Ansonsten schaut es gut aus mit 
der neuen Hardware, "eigentlich" ist sie für den 2Kanäler bereits 
fertig.

Letztens WE habe ich, wieder genesen, die Softwareseite bearbeitet. Der 
gemeinsame Speicher erfordert ein deutlich unterschiedliches Konzept. 
Damit bin ich noch nicht zuende.

Jörg

von Jörg H. (idc-dragon)


Lesenswert?

Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden) 
kam uns eine Idee:

Es müßte eigentlich ein Leichtes sein, dem Welec einen VGA-Ausgang 
nachzurüsten. Das interne Display hat VGA-Auflösung und -Timing. Wenn 
die Sync-Impulse noch nicht ganz passen sollten, so könnte ich das 
zumindest beim neuen Design passend einstellen.

Man muß die 3 Bits pro Farbe über Widerstände R2R-mäßig zusammenführen, 
um je eine Spannung draus zu machen. Die Syncsignale müßten bereits 
passen. Bauteileaufwand im Minimum also 9 Widerstände und eine 
VGA-Buchse.

So ähnlich wie dieser Kollege sein Board verdrahtet hat:
http://www.pyroelectro.com/tutorials/fpga_vga_resistor_dac/schematic.html

In schönerer Ausführung könnte man eine Platine mit Zwischenstecker für 
den LCD-Anschluß machen. Dazu noch Treiberstufen, damit ESD an der 
VGA-Buchse nicht bis ins FPGA blitzt...

Ich brauche allerdings keinen VGA-Ausgang. Damit mögen sich gern andere 
beschäftigen. Dies nur als kleiner Projekttipp. ;-)

Jörg

von Nicki (Gast)


Lesenswert?

W2022 Ausfall: SMDs löten ist offensichtlich nicht mein Ding. Nach dem 
letzten Nachbesserungsversuch an den RAMs zeigt nun auch das Drücken der 
beiden "linken Tasten" keine Reaktion mehr. Langer Rede kurzer Sinn: 
Damit noch etwas Sinnvolles mit dem Gerät geschieht (Ersatzteillager 
etc.) würde ich es gern einem  "Aktivisten" hier in der Gruppe schenken. 
Hayo, hast Du evtl. Interesse? Ich würde mich dann per PN melden. Grüße, 
Nicki

von Jörg H. (idc-dragon)


Lesenswert?

Ich wollte demnächst mal einen Gesuch-Aufruf nach einem hoffnungslos 
defekten Gerät starten, bzw. eigentlich reicht uns die Hauptplatine.

Der Hintergrund davon ist, das wir nicht 100% sicher sind, alle 
FPGA-Verbindungen zu kennen, ob die Hardware vielleicht noch unbekannte 
Möglichkeiten hat, die das neuen FPGA-Design nutzen könnte. Dazu müßte 
man von einer "Opferplatine" das (erste, beim 4Kanäler) FPGA auslöten, 
und den USB-Chip. In der Firma haben wir geeignete Infrarotlöttechnik. 
Aber wieder zusammenbauen ist schwierig, mühsam und nicht ohne Risiko 
(erfordert FPGA-Reballing), deshalb lieber mit einer Opferplatine.

Nicki, ich glaube aber nicht das dein Gerät das gesuchte Opfer ist, das 
hat bestimmt nur ein kleineres Problem. (Es sei denn, du hast bei deinen 
Lötversuchen alles zerbrutzelt.)

Jörg

von Blue F. (blueflash)


Lesenswert?

Hi Nicki,

ja klar, ist eine Idee. Ich sehe mir das mal an. Vielleicht ist es nicht 
so schlimm. Wenn es mit wenig Aufwand wieder herzustellen ist kannst Du 
es danach auch gerne wieder haben oder wir stellen es als Testgerät den 
Hardware-Spezis zur Verfügung, oder einem anderen armen Schwein dessen 
Gerät nicht mehr so richtig will.

Schick mir mal ne PN.

Hayo

von Nicki (Gast)


Lesenswert?

@Hayo: OK, danke für den Vorschlag, ich melde mich. Nicki

von Andreas W. (andiiiy)


Lesenswert?

Jörg H. schrieb:
> Ich wollte demnächst mal einen Gesuch-Aufruf nach einem hoffnungslos
> defekten Gerät starten, bzw. eigentlich reicht uns die Hauptplatine.

Ich glaube auch nicht das dieses Gerät defekt ist.

Sollte es aber wirklich am Ende sein - gebe ich Jörg recht - wäre es ein 
optimales Opfer für den Schaltplan. Erste wichtige Fragmente sind nun 
auch schon digital im Eagle-Format.

Grüße Andi

von Johannes S. (demofreak)


Lesenswert?

Jörg H. schrieb:
> Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden)
> kam uns eine Idee:

Ach? Da würde ich doch glatt mal ein Bier mit trinken. ;-)

/Hannes

von Jörg H. (idc-dragon)


Lesenswert?

Johannes S. schrieb:
> Jörg H. schrieb:
>> Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden)
>> kam uns eine Idee:
>
> Ach? Da würde ich doch glatt mal ein Bier mit trinken. ;-)
>
> /Hannes

Da müssen wir uns beeilen, ich habe heute den letzten Feierabend vor 
Ort!

Jörg

von Johannes S. (demofreak)


Lesenswert?

Na dann eben nächstes Mal. :)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier mal ein Screenshot von der neuen BF.6.5 - zur Zeit noch beta. 
Man sieht hier den neuen Peak Detect Modus an dem ich seit einiger Zeit 
arbeite.

Aber jetzt denkt Ihr bestimmt - wie offtopic  hier im Hardwarethread. 
Nein, falsch, ich wollte eigentlich nicht die neue Firmware vorstellen.

Was völlig Anderes - der Screenshot ist gemacht mit Nickis DSO, das 
heute bei mir angekommen ist. Eigentlich wollte ich erst am Wochenende 
ran, dann hat es mir aber doch keine Ruhe gelassen. Tatsächlich waren 
einige Pads von den Bahnen abgerissen und es etwas gefummel unter dem 
Mikroskop um das wieder hinzukriegen.

@Nicki

Willst Du das Ding wieder haben?

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

Hallo Hayo,
wo wird "Peak-Detect" aktiviert und was hat damit auf sich?
BtW. wenn du schon dabei bist...
Im Quickmeasure zickt die Rise u. Fall-Time Messung. Es wird ab u. zu 
statt "µs" nur "s" angezeigt und natürlich wird dann auch kein Wert 
angezeigt bzw. 0s.
Kannst du mir folgen?
Vielleicht schaust du mal nach, bevor du die neue Version raus bringst?

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Hi Michael,

ich vermute Du hast für die Rise/Fall-Timemessung eine zu kleine 
Zeitbasis eingestellt. Dann reichen ihm die Punkte zur Messung nicht 
mehr aus.

Mach mal einen Screenshot - aber dann im Firmwarethread.

Gruß Hayo

p.s. zu Peak Detect sag ich noch was, muß erst mal die beste aller 
Ehefrauen bekochen. Ist wegen der Bastelei etwas spät geworden.

von Michael D. (mike0815)


Lesenswert?

ich hatte verschiedene Zeitbasen benutzt. Zwischen ms und ns wurde eben 
s angezeigt und nur mal sporadisch µs, also fehlt doch was zwischen ms 
u. ns, oder? Also Nanosekunden wurden ja wieder gemessen.
Mache dann ein paar Shots... muß jetzt auch erstmal was essen

Gruß Michael

von Nicki (Gast)


Lesenswert?

@hayo: mir fällt ein Stein vom Herzen. Ich hatte das  W2022 schon 
halbwegs abgeschrieben, aber die Hoffnung stirbt zuletzt! Danke!!! Unter 
diesen Umständen möchte ich das Gerät gerne weiter benutzen.  Über den 
Rest schreibe ich eine PN.
Grüße, Nicki

von Guido (Gast)


Lesenswert?

Gute Arbeit Hayo,

wieder einen Mensch glücklich gemacht!

Grüße, Guido

von Blue F. (blueflash)


Lesenswert?

Mal wieder ein kurzer Bericht aus dem WELEC Forschungslabor:

Ich habe die Gelegenheit Nickies DSO hier zu haben mal dazu genutzt 
Vergleiche anzustellen. Dabei habe ich festgestellt, dass es anscheinend 
zwischen den verschiedenen Hardwarerevisionen Performanceunterschiede 
gibt.

Ich habe mit gleicher Firmwarversion und identischen Einstellungen den 
Framecount bei verschiedenen Funktionen gemessen (Trigger NORMAL, 
200mV). Jedes mal mit vergleichbaren Ergebnissen. Zum Vergleich hier die 
Ergebnisse für Zweikanalbetrieb bei 200ns/Div, alle Filter aus.

Mein W2022A - 8C7.0G:    1320 Frames/min
Nickies W2022A - 8C7.0F: 1213 Frames/min
Mein W2014A - 8C7.0L:    1116 Frames/min

Alle Messungen mehrfach durchgeführt mit Schwankungen von +/- 4 Frames.
Wenn ich die neue Firmware fertig habe, würde mich mal interessieren 
welche Werte da bei Euch rauskommen. Mit der "alten" BF.6.4 C6 läßt sich 
das leider nicht vergleichen, da ich in der neuen Version einige 
Performanceverbesserungen vorgenommen habe und diese daher schneller 
ist.

Ich kann mir die Unterschiede momentan nicht so richtig erklären. 
Mögliche Ursachen könnten Bauteiletoleranzen sein z.B. beim Schwingkreis 
der den Takt für den FPGA vorgibt, oder FPGA-interne Unterschiede.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Der Oszillator kann es nicht sein, weil du das Gerät mit sich selber 
mißt. Es ist ja keine weitere "neutrale" Zeitquelle an Board.

Ich könnte mir vorstellen, das ein Gerät mehr rauscht und schneller 
triggert?

(Davon ab finde ich persönlich das Mysterium eher uninteressant, alte 
Hardware, Frames pro Minute, hihi)

Jörg

von Blue F. (blueflash)


Lesenswert?

Jörg H. schrieb:
> Der Oszillator kann es nicht sein, weil du das Gerät mit sich selber
> mißt. Es ist ja keine weitere "neutrale" Zeitquelle an Board.

Das würde ich so nicht sagen, denn die neutrale Zeitquelle ist die 
Stoppuhr mit der ich die Die Meßintervalle ausmesse. Es könnte also rein 
theoretisch auch der Oszillator sein und das würde sich auch auf das 
neue FPGA-Design auswirken.

ZUm Messvorgang:

Ich Starte die Messung mit Shift + K und beende sie nach genau einer 
Minute wieder ebenfalls mit Shift + K (via Terminalprogramm). Die 
Zeitmessung mache ich mit einer Stoppuhr. Der Framecounter wird bei 
jeder Bildschirmausgabe um eins hochgezählt. Bei Shift + K wird der 
aktuelle Stand auf dem Bildschirm ausgegeben und der Zähler wieder 
zurückgesetzt.

Kann also jeder bei seiner Kiste selbst testen.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Ach so, du mißt das von Hand, davon war ich jetzt nicht ausgegangen.

Jörg

von Blue F. (blueflash)


Lesenswert?

Ja, ich brauchte eine einfache schnelle Möglichkeit die Wirkung von 
Performanceoptimierungen zu testen. Da war das die beste Möglichkeit - 
und es kann jeder auch an seiner Kiste selbst testen ohne in einen 
speziellen Testmodus schalten zu müssen.

Btw. es wird ja immer so über das WELEC geschimpft, aber ich muß an 
dieser Stelle auch mal was Positives sagen. Auch wenn die Schwächen 
allseits bekannt sind kann man mit dem DSO sehr schön auf Fehlersuche in 
defekten Geräten gehen.

Aktuelles Beispiel:
Ich habe mir gerade einen 100MHz Pulsgenerator in der Bucht geschossen 
um besser an unserem DSO herumtesten zu können. Wie das Leben so spielt 
ist das Teil leider defekt. Ich bin dann erstmal mit dem analogen 
Tek2465A (dessen Qualitäten ja bekannt sind) rangegangen um die 
Signalwege durchzumessen. War etwas mühselig. Ich habe dann mein W2014A 
genommen und mir dann das Signal der triggernden Taktquelle auf Kanal 4 
gelegt, und dann die Messpunkte der anderen Stufen auf die andern 
Kanäle. Das Ganze bei 80 - 100 MHz wohlgemerkt.

Man konnte schön alles im Überblick sehen und das Problem war schnell 
eingekreist. Ersatzteile sind bestellt...

Ich benutze das WELEC ja eigentlich nur zum Programmieren, aber da war 
ich doch angenehm überrascht.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Neues von WELEC:

Angeregt durch Nicki habe ich mal die Bucht durchforstet nach Angeboten 
zu unserer Kiste. Und siehe da, Wittig verkauft tatsächlich wieder 
W2022A Modelle für 190 Euronen. Anscheinend jetzt unter neuem 
Verkäufernamen wscop. Wie ich den Bewertungen entnommen habe ist unsere 
Gemeinde potentiell um 9 Mitglieder angewachsen :-)

Btw. kommt jemand aus der Region Berlin? Dort macht gerade einer seinen 
Keller leer und haut seinen ganzen Bastelbestand in einem Rutsch raus. 
Unter anderem ist auch ein W2022A dabei. Leider wegen der Menge nur mit 
Selbstabholung. War schon am überlegen....aber 300 Km hin und nochmal 
300 zurück...

Gruß Hayo

von marndra (Gast)


Lesenswert?

Hi,

ich bin so einer der bei der Bucht für 190 ein W2022 direkt bei Herrn 
Wittig gesteigert hat.

Was meint Ihr, ist das jetzt ein Reinfall?
Wenn nein, was würdet Ihr mir empfehlen?
Wie soll ich vorgehen, muss ich jetzt erst den FPGA flashen?
Und dann die Firmware?
Und wenn ja,  was ist die am weitesten fortgeschrittenste?

Blick das ganze hier noch nicht ganz, muss ich auch was an der HW was 
tun?

LG Martin

von Blue F. (blueflash)


Lesenswert?

Hallo Martin,

nein kein Reinfall. Das Gerät hat zwar einige Schwächen und die 
originale Firmware ist schlicht Schrott (praktisch nicht benutzbar) aber 
mit einem Update wird das Gerät zu einem praktischen Helfer im 
heimischen Labor.

Wenn Du vor SMD-Löten nicht zurückschreckst bieten sich auch noch einige 
Hardwareverbesserungen an.

Am FPGA mußt Du erstmal nichts machen, das ist ein Projekt das noch in 
den Anfängen steckt und nochmal deutliche Verbesserungen verspricht. 
Weiterhin arbeiten wir auch noch an einer neuen Plattformunabhängigen 
Firmware die sich ebenfalls noch im Entwicklungsstadium befindet. Der 
Thread ist hier ->

Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Du lädst Dir am Besten erstmal die aktuelle Firmware runter (BF.6.4.C6), 
die findest Du im Firmwarethread ->

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

oder bei sourceforge net. Auf der Wiki-Seite findest Du alles Wichtige:

http://sourceforge.net/apps/trac/welecw2000a/

Downloads hier:

http://sourceforge.net/projects/welecw2000a/?source=navbar

In dem doc-Verzeichnis des Firmwaredownloads findest Du genauere 
Anleitungen und Infos.

Oder auch hier:

http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload


In Kürze:

- Du brauchst einen RS232 Anschluß an Deinem Rechner! Die 
USB-Schnittstelle wird nicht unterstützt (zu langsam)!

- das originale Flashprogramm von WELEC kann man nicht verwenden!

- es gibt ein Windowsprogramm (WELEC-Updater), das aber sehr langsam 
ist.

- bessere Wahl ist, Dir Perl zu installieren (Windows -> active Perl) 
bei Linux ist es ohnehin an Bord.
Weiterhin brauchst Du den seriellen Porttreiber Win32-SerialPort.
Damit kannst Du dann sowohl unter Linux als auch unter Windows das 
mitgelieferte Perlscript benutzen, welches den Upload in 180 Sekunden 
erledigt (statt 20 - 40 Minuten)

- Eine Flashsequenz wird immer eingeleitet, in dem das Gerät in den 
Monitormodus gebracht wird.

- Gerät einschalten

- ganz linke Funktionstaste drücken und gedrückt halten. Jetzt 
zusätzlich kurz die zweite Funktionstaste von links drücken und wieder 
loslassen. Jetzt die ganz linke F-Taste loslassen. Der Monitor leuchtet 
kurz hell auf und wird dann schwarz - der Upload kann beginnen.


Wenn Du weitere Fragen hast, dann poste das einfach im Firmwarethread. 
Wenn Dein Upload geklappt hat, berichte mal ob es Dir gefällt oder was 
Du an Verbesserungsvorschlägen hast.

Viel Spaß

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja, noch ein kleiner Nachschlag.

Wenn Du erst mal nur probieren möchtest, dann kannst Du statt zu flashen 
auch die Firmware einfach nur ins RAM laden mit der Datei TomCat.ram 
bzw. dem Script ramloader.bat (oder .sh unter Linux). Wenn Du das Gerät 
ausschaltest, ist beim nächsten Start alles wieder wie vorher.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Wie ich gerade in meinen Mails lese hat Nicki sein DSO inzwischen wieder 
zurück und ist zufrieden.

Daher noch ein kleiner Hinweis für alle Neubesitzer eines WELEC DSOs. 
Zwei kleine und einfache Hardwaremodifikationen sind auf jeden Fall 
empfehlenswert. Materialaufwand:

- eine selbstschneidende Blechschraube ungefähr 4 x 10mm
- ein Tesafilmstreifen ca. 10cm lang

Es muß nur der rückwärtige Deckel mittels der drei Schrauben abgenommen 
werden.

Mit der Blechschraube wird jetzt der Blechrahmen im Gerät an der Ecke 
beim Ein/Ausschalter festgeschraubt. Bohrung und Aufnahme sind schon 
vorhanden, Wittigs haben einfach nur mit der Schraube gegeizt. Durch das 
Festschrauben wird beim Drücken der Netztaste und der Funktionstasten 
der Rahmen nicht mehr so nach innen gedrückt.

Die zweite Modifikation ist hier beschrieben und sorgt für bessere 
Belüftung:

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/

Datei Optimizing Thermal Design.

Wer mehr möchte kann sich vom zweiten Teil inspirieren lassen.

@Nicki

Ich war so frei bei Dir die Modifikation ungefragt vorzunehmen.

Gruß Hayo

von felixh (Gast)


Lesenswert?

kurze frage an hayo:
Warum dürfen sich die Kühlkörper nicht berühren?
Die oberfläche der ADCs ist doch eh nicht leitfähig... und kontakt zu 
Metall haben die doch auch nicht?

von Michael D. (mike0815)


Lesenswert?

@Hayo
jaja, diese dämliche Schraube hatte ich mal gesucht weil ich dachte, sie 
wäre runter gefallen, dabei war die nie vorhanden...

@felixh
Weil die ADC's nicht alle plan aufliegen und deswegen, der eine oder 
andere, keine richtige Verbindung mit dem Kühlkörper hätte.

Gruß Michael

von Nicki (Gast)


Lesenswert?

@Hayo: Danke! Und: Ich bin   m e h r   als zufrieden!
Gruß, Klaus

von Andreas W. (andiiiy)


Lesenswert?

Hallo Klaus,

ich freue mich, dass Du in unserer kleine Fangemeinde erhalten bleibst.
Ja ich war auch einige Zeit am Zweifeln ... genau diesen Fehler hatte 
ich auch!

Grüße Andiiiy

von Blue F. (blueflash)


Lesenswert?

felixh schrieb:
> Warum dürfen sich die Kühlkörper nicht berühren?

Wie Micheal schon schrieb ist der Oberflächenkontakt nicht optimal wenn 
man einen großen Kühlkörper drauf klebt. Aber was noch problematischer 
sein kann ist bei Erwärmung die unterschiedliche Ausdehnung der Platine 
unter den ADC und des Kühlkörpers auf den ADCs. Da kann es durch die 
Verspannungen passieren, das sich die Beinchen der ADC nach einiger Zeit 
von den Lötpads lösen und man kalte Lötstellen bekommt die mal 
funktionieren und mal nicht - so einen Fehler zu finden ist schon eine 
Herausforderung. Also auf jeden Fall auf jeden ADC einen eigenen kleinen 
Kühlkörper kleben auch wenn es etwas mehr Mühe macht. Nicht vergessen, 
die Oberfläche des ADC etwas anzuschleifen (Sandpapier) und mit Spiritus 
zu entfetten, damit der Sekundenkleber gut hält. Wenn sich der 
Kühlkörper löst und irgendwas kurzschließt ist der Jammer groß...

Gruß Hayo

von marndra (Gast)


Lesenswert?

Hi Hayo,

vielen Dank für diesen tollen "Empfang" hier in diesem Forum.

Die neue FW 1.2.BF.6.5 habe ich direkt mit deiner .bat 
aufgespielt.(Perl)
(hab nen USB/seriell Adapter genommen)
KEIN VERGLEICH ZU VORHER ! ! - - -RESPEKT- - -

Auch den kleinen HW Mod hab ich grad gemacht.

Software soweit mal durchgetestet, vor allem das neue Peak Detect 
gefällt mir. Min Max Points -> Super :-)

Hatte auch gleich nen Einsatz. (Hatte vorher kein Scope)
Mein Netbook Aspire One hatte immer geschwächelt wenn ich den USB Port 
benutzte im Akkubetrieb. Im Netzbetrieb ging's immer.
Mit dem w2022 konnte ich das mal schön nachweisen :-) Genial

Nur wie kann ich das jetzt dokumentieren?
Ich hab da so ein w2000a Screenshot Tool probiert, er sagt aber meine HW 
8C7.0E sei veraltet? Ich solle updaten...

Wie mache ich also ein Screenshot, bzw wie transferiere ich die Daten 
zum PC?

gruß Martin

von Blue F. (blueflash)


Lesenswert?

Ich antworte mal im Firmwarethread, damit das hier nicht zu offtopic 
wird...


Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

von Martin H. (marndra)


Lesenswert?

Danke für den Tipp mit der Verbindung fürn Screenshot, ja es ist 
vermutlich so, dass ich das DSO danach aktiviert habe. Ich probiers heut 
Abend nochmal.

Jetzt warum ich hier schreibe.
Was kann ich alles tun um HW zu verbessern.
habe was gelesen von nem Piggypack um die Auflösung zu verbessern?

Auch in SW Setup mit dem Widerständen?
Wo muss ich die Umlöten und vor allem was bewirken die 
Widerstandsunterschiede?
Woher bekomme ich diese?
Typ 605? Toleranz 1% ?

Sorry für die vielen Fragen, bin noch nen Noop ;-)

gruß Martin

von Blue F. (blueflash)


Lesenswert?

Martin Haßlöcher schrieb:

> Was kann ich alles tun um HW zu verbessern.
Oh da gibt es Einiges. Angefangen bei größeren Lüftern, Kühlkörpern auf 
den ADC, LEDs für die Triggeranzeige, Änderungen an der 
PWM-Signalgenerierung für den externen Trigger, die Addon Eingangsstufe 
oder die Widerstandsbestückung am Eingangsverstärker.

> habe was gelesen von nem Piggypack um die Auflösung zu verbessern?
Das ist etwas aufwändiger und wurde bislang meines Wissens erst von zwei 
oder drei Leuten implementiert. Meine Platinen liegen hier auch noch und 
warten auf den Einbau...

> Auch in SW Setup mit dem Widerständen?
Das ist eine relativ einfache Möglichkeit den Frequenzgang des Gerätes 
gerade zu biegen und das Verhalten bei höheren Frquenzen zu verbessern. 
Es gab eine Zeit lang unterschiedliche Widerstandskombinationen die 
ausprobiert wurden, daher ist im Hardwaremenü noch ein weiterer Eintrag 
vorhanden. Empfohlen ist aber die Kombination 2 x 24,9 Ohm / 1 x 174 
Ohm.
Originalbestückung ist 2 x 0 Ohm / 150 KOhm. Ich habe bei mir statt der 
174 Ohm einen 180 Ohm Widerstand mit Tendenz zu 178/179 Ohm eingebaut, 
da ich hiervon eine 5000er Spule rumliegen habe.

> Wo muss ich die Umlöten
Rückseite der Hauptplatine. D.h. Du mußt diese ausbauen. Kurze 
Ausbaubeschreibung hier:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

> Woher bekomme ich diese?
Ich kann Dir welche zuschicken, brauche dafür Deine Adresse...

> Typ 605? Toleranz 1% ?
0603 / 1%

> Sorry für die vielen Fragen, bin noch nen Noop ;-)
Kein Problem, dafür haben wir diesen Thread ja - und waren wir nicht 
alle mal Einsteiger?

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Aus gegebenem Anlaß noch ein Hinweis zur Löterei an den 
SMD-Widerständen.

Die Dinger sind so klein, dass man schon etwas spezielle Ausrüstung für 
die Bearbeitung braucht.

- ein geregelter Lötkolben mit sehr feiner Spitze sollte es schon sein. 
Die Temperatur sollte bei ca. 315 Grad liegen. Die Chinaboys bieten da 
mittlerweile ganz anständige Lötstationen an. Mit einer Dachrinnenlöte 
richtet man unter Umständen ziemliche Schäden auf der Platine an.

- sehr empfehlenswert ist die Verwendung von Lötpaste mit einem 
Flußmittel welches hinterher nicht entfernt werden muß. Bei mir hat sich 
CR 44 bewährt.
Wenn man Bauteile verwendet die man von Teileträgern abgelötet hat kann 
es auch ohne gehen, bei neuen Bauteilen geht es nur mit Lötpaste.

- auch wenn ihr sonst keine Brille tragt - hier ist eine optische Hilfe 
fast unumgänglich. Eine starke Lupenbrille (Uhrmacher) kann schon gehen, 
besser ist ein Auflichtmikroskop. Da gibt es das günstige 
USB-PC-Mikroskop das hier einige benutzen oder auch ein richtiges 
Standmikroskop welches ich bevorzuge. Nur mit solchen Hilfmitteln kann 
man wirklich alle Details beim Löten erkennen. Zum Thema USB-Mikroskop 
gibt es ( im 1. Teil) einige Beiträge.

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"


Hab bei der Gelegenheit auch gleich den Hinweis zur Lage der Widerstände 
gefunden:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Hallo, mich gibt's auch noch, oder wieder!

Ich habe einen ziemlich stressigen Arbeitseinsatz hinter mir, der meine 
Freizeit deutlich eingeschränkt hat. Aber nun feiere ich Überstunden ab 
und kann mich mal intensiver unserem Projekt widmen.

Hayo W. schrieb:
> Am FPGA mußt Du erstmal nichts machen, das ist ein Projekt das noch in
> den Anfängen steckt und nochmal deutliche Verbesserungen verspricht.

Kleiner Protest, die Hardware ist 'eigentlich' fertig, zumindest für den 
2Kanäler. Bei Osoz gibt es noch einiges zu tun, wegen der 
unterschiedlichen Organisation des Samplespeichers, bzw. allgemein mehr 
Möglichkeiten. Die alte Hardware hat getrennte Speicher für jeden Kanal, 
die neue einen gemeinsamen pro FPGA. Mit der alten Hardware hatten wir 
im 'Normalfall' nur 4K Speichertiefe (Abtastrate <= 250MSa), weil beim 
erstebenswerten Betrieb mit nur einem ADC blöderweise 3 von 4 Bytes 
ungenutzt bleiben. Die neue Hardware hat (bei 8 Bit Auflösung) immer die 
vollen 16K, schaltet man einen Kanal ab kann der andere dessen Speicher 
mitnutzen und so kommen wir sogar auf 32K.

Heute habe ich für die Nios II Hardware eine Speichertest-Software in 
Assembler geschrieben, die in die 512 Bytes des Boot-ROMs paßt. (Mit Ach 
und Krach, nach viel Getüftel sind noch 2 Bytes frei.) So kann ich den 
gesamten Speicher testen, denn das Testprogramm selbst steht nicht im 
SRAM.
Es schreibt den Speicher mit Pseudo-Zufallszahlen voll und überpüft in 
einem zweiten Durchgang den Inhalt, macht Ausgaben auf RS232 und 
rudimentär mit den LEDs. So ein Durchlauf dauert nur 0,2 Sekunden (ich 
habe einen coolen Zufallsgenerator gefunden, der nur 3 Befehle braucht, 
ein LFSR), das Programm macht das in Endlosschleife mit immer neuen 
Werten.

Bisher keine Vorkommnisse, läuft stundenlang ohne Fehler, es sei denn 
man provoziert Kurzschlüsse am SRAM. Ich wollte 'schon immer' mal 
getestet haben, ob ich meinem Businterface trauen kann. Bisher mache ich 
das gedanklich für alle auftretenden gelegentlichen Instabilitäten 
verantwortlich, aber ich muß mir wohl einen neuen Schuldigen suchen! 
(Z.B. Software-Bugs?)

So long,
Jörg

von Blue F. (blueflash)


Lesenswert?

Hi Jörg,

ich meinte mit den Anfängen auch eher den Gesamtstatus des Projektes. 
Dass die FPGA-Seite schon recht weit fortgeschritten ist wollte ich 
natürlich nicht unter den Tisch kehren. Nachdem ich jetzt in der 
aktuellen BF Firmware eigentlich alles implementiert habe was die 
Hardware noch so hergibt könnte ich eigentlich mal Funktionen für 
Hardwareunabhängigen Teil von OSOZ schreiben. Bräuchte nur mal eine 
Einweisung in den aktuellen Stand. Für den Anfang kannst Du mir auch 
einfach sagen was wir brauchen und wo ich das implementieren soll.

Gruß Hayo

von Ben L. (elecblu)


Lesenswert?

mal zurück zu meinem Spike Problem 
(Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)").
Habe endlich etwas Zeit gefunden und konnte das ganze mit Eisspray 
tatsächlich auf die ADCs vom 2. Kanal eingrenzen (20°C Raum -> Spikes, 5 
Minuten warmlaufen -> keine Spikes, Eis auf ADC Chip -> Spikes 2. Kanal 
z.B. 200mV).
Leider brachte Nachlöten aber keine Abhilfe.
Das ganze tritt jetzt wie gesagt auch bei normaler Raumtemperatur und 
den entsprechenden Zeitbasen "immer" auf, also ohne aufwärmen geht da 
nichts mehr. Wie ich eingangs schon schrieb, das war vor einem Jahr 
nicht der Fall, das wäre in diesem Maße definitiv aufgefallen. (Weswegen 
ich ein Timing Problem in der Software/ FPGA Design ausschließe). 
Übrigens brauchte wie zu erwarten war das Einspielen des Original- FW 
Dump keine Besserung.
@sar brachte das bei dir wirklich Dauerhaft Abhilfe? Weil ansonsten 
waren unsere Probleme fast identisch.
Werde jetzt mal als nächstes die ADC Bausteine tauschen.

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Ben,

nein, tu dir das nicht an, die ADCs sind unschuldig, es ist wirklich ein 
Timing-Problem.
(Mal davon ab braucht es eine Infrarotlötanlage um sie zu wechseln, die 
haben unten drunter ein großflächiges Thermopad. Ist nicht ohne Risiko.)

Ich hatte die Spikes am Anfang auch weniger, jetzt mehr, und zudem bei 
hohen Abtastraten auch Bildstörungen.
Mit dem neuen FPGA-Design ist der Spuk verschwunden, alles sauber.

Das Originaldesign hat eine haarsträubende Architektur, der Signalteil 
arbeitet mit den vollen 250 MHz, was das FPGA klar überfordert. Das neue 
Design arbeitet mit halbem Takt und doppelter Breite. So bleibt das 
Timing in legalen Grenzen.

Jörg

von Ben L. (elecblu)


Lesenswert?

aber die ADCs sind doch auf 250Mhz spezifiziert (zugegeben, Maximum) und 
auch nur an denen habe ich einen thermischen Einfluss. Das FPGA kann ich 
abkühlen wie ich will.
Warum entsteht ein Timing Problem zwischen September (Oszi funktionierte 
OHNE jegliche Spikes) und Dezember (siehe Beiträge).
Habe doch auch mittlerweile rausgefunden, dass es jetzt auch bei 20°C 
auftritt und auch OHNE Signal Spikes auf der Nulllinie vorhanden sind 
(Kanal 2).
Alterung oder Defekt des ADC Chips daher für mich nicht auszuschließen 
(Mit Heissluft geht das Auslöten, klar ein Risiko hat man immer).

von Jörg H. (idc-dragon)


Lesenswert?

Die Temperatur beeinflußt natürlich das Timing, verschiebt es in 
gewissen Grenzen. Das heißt aber nicht, daß das Bauteil was du gerade 
abkühlst/erwärmst und wo sich ein Effekt zeigt auch defekt ist.

Das originale Gesamttiming ist halt völlig kritisch. Ich kann dir nur 
von meinen Erfahrungen berichten...
Die ADCs sind zwar für 250 MHz, dabei bleibt es auch mit dem neuen 
Design, aber das FPGA nur in der Theorie (in einzelnen Bereichen), 
praktische Designs erreichen das nicht.

Vor irgendwelchen Hauruck-Aktionen würde ich an deiner Stelle mal das 
neue FGPA-Design ausprobieren. Dazu brauchst du Quartus, oder auch nur 
die Standalone-Programmer Software von Altera, und entweder den 
Slog-Treiber oder einen USB-Blaster.

Nochmal zur Löterei:

Mit Heißluft alleine würde ich da nicht dran. Da muß man den Chip schon 
arg überhitzen damit auch die Unterseite und die Platine dort heiß genug 
wird, es besteht die Gefahr das die Platine im offenen Bereich überhitzt 
und "Blasen schlägt", sich die Lagen trennen, Durchkontaktierungen 
aufreißen.

Mit einer Anlage die zusätzlich Unterhitze kann schon eher.

Jörg

von Luc (Gast)


Lesenswert?

Guten Morgen, Ben L.,Jörg H. und all jene die an dem Projekt beteiligt 
sind Welec!

@Ben L.

Ich glaube, dass Jörg richtig ist, der ADC sind unschuldig.
Mir ist auch aufgefallen Probleme, zufällige Spitzen, die vollständig, 
aber nichts war gebrochen.
Das Problem äussert sich mehr oder weniger stark nach den Situationen.
Firmware Hayo entwickelt haben sich enorm verbessert, das Problem, aber 
es hat nicht gelöst komplett.
In der Tat, als er Jörg schreibt und andere vermuten, die gleiche Sache, 
es Fehler in der Konstruktion des FPGA (Timing) sein.
Ich weiß auch nicht empfehlen, mit dem Schweißgerät zu intervenieren.
Es wäre gefährlich und wahrscheinlich vergebliche.
Viel besser, zu versuchen das neue FPGA Design von Jörg & C. und sehen, 
was passiert, dann werden wir sehen, ob er nicht mit Schweißgerät 
eingreifen.
Würden Sie immer pünktlich zu sein, nichts überstürzen.

Frohe Ostern an alle!

Mit freundlichen Grüßen,

Luc

von Andy R. (andreas_r68)


Lesenswert?

Auch ich habe bei WSCOP auf eBay ein W2022A erstanden. Da ich mich hier 
im Forum schon informiert hatte wusste ich ungefähr was ich zu erwarten 
hatte. Tatsächlich ist das Gerät Dank Hayos Software eine feine Sache 
und ich freue mich zu lesen, dass die Entwicklung weiter geht.
Es ist schon ein großer Schritt von meinem 70er Jahre HM207 mit HZ36 
Vorsatz zu einem echten 2-Kanal Gerät. Nur an das Rauschen auf den 
Signalen muss ich mich noch etwas gewöhnen.

Hier die Daten des Geräts das ich erhalten habe:
Model: W2022A
Hardware Version: 8C7.0E
FlashID: C293

Im Moment läuft 1.2.BF.6.4.C6 und das erfreulich geschmeidig.

Ich habe etwas weiter oben in Thread die Tipps an Martin gelesen, dazu 
anderswo auch Vorschläge für zusätzliche Abschirmung.
Gibt es im Forum einen W20xxA Noob-Thread, damit wir Einsteiger nicht 
immer in die produktiv-Threads reingrätschen?

Viele Grüße
Andy R.

von Blue F. (blueflash)


Lesenswert?

Hallo Andy,

willkommen an Bord.

> Gibt es im Forum einen W20xxA Noob-Thread, damit wir Einsteiger nicht
> immer in die produktiv-Threads reingrätschen?

Nein sowas gibt es nicht, aber es wäre eine Idee. Vielleicht mag ja 
einer der frischen W2000A Besitzer so einen Thread anlegen und den Link 
hier posten? Ich beantworte da auch gerne alle Fragen die einen als 
Neubesitzer so beschäftigen, unter anderem auch zu den zusätzlichen 
Funktionen die unsere alternative Firmware so bietet.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Und hier ist der Link zum WELEC Einsteiger-Thread, den Andy 
freundlicherweise ins Leben gerufen hat:

Beitrag "Wittig(welec) DSO W20xxA Einsteiger"

Hayo

von Blue F. (blueflash)


Lesenswert?

Wie im Einsteiger-Thread angekündigt bin ich zur Zeit eher 
hardwarelastig am arbeiten und suche eine Möglichkeit das Rauschen in 
den Griff zu bekommen. Soviel zu diesem Zeitpunkt schon mal vorweg - ich 
habe eine Möglichkeit gefunden, die recht einfach zu realisieren ist und 
das Rauschen deutlich reduziert.

Um das Ganze noch rund zu machen arbeite ich im Augenblick an einer 
Frequenzgangkorrektur die den Frequenzgang glattbügelt. Ohne die 
Korrektur steigt die Amplitude ab 50MHz um etwa 10% an.

Ich werde meinen Mod demnächst mit einer angepassten Firmware hier 
vorstellen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hmmh, 10 % in der Amplitude ist doch unter 1 dB. Übertreib mal
nicht, das rächt sich meist an anderer Stelle. ;-) Ein
Präzisionsinstrument wird das Welec sicher nicht werden.

Grüße, Guido

von Luc (Gast)


Lesenswert?

Schönen Sonntag, Hayo und all jene, die an dem Projekt beteiligt sind 
WELEC.

Hayo W. schrieb:
>Um das Ganze noch rund zu machen arbeite ich im Augenblick an einer
>Frequenzgangkorrektur die den Frequenzgang glattbügelt. Ohne die
>Korrektur steigt die Amplitude ab 50MHz um etwa 10% an.

Hayo, meinst du ein Software-Update für Geräte, die noch den 
ursprünglichen Widerstände Fabrik?
Es scheint mir, dass mit den neuen Widerstände 24,9/174 Ohm, und bereits 
mit denen von 24,9/150 Ohm Frequenzgang im Durchlassbereich flach sogar 
übertraf 50MHz.

Mit freundlichen Grüßen,

Luc

von Blue F. (blueflash)


Lesenswert?

Hi Luc,

You are right, but due to my newest hardware modification there is a 
little failure in the frequency response. it is not so bad but I have an 
idea to compensate it. I will present this solution in detail in some 
days, but so far I can say it is working well and the noise is much 
better with it.


Regards

Hayo

von Luc (Gast)


Lesenswert?

Gut Nachmittag, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.

Hayo W. schrieb:
>but due to my newest hardware modification there is a
>little failure in the frequency response.

Do you mean the change of the resistors?
What is frequency where you detect the greater inconsistency?
And, how great is it?

Hayo W. schrieb:
>it is not so bad but I have an idea to compensate it.

All that who it can help to improve our DSO is welcome, so thank You for 
the aid!

Hayo W. schrieb:

>I will present this solution in detail in some
>days, but so far I can say it is working well and the noise is much
>better with it.

Okay Hayo, we will see.
However, about the noise matter, I think a good solution already is the 
pickaback developed by Branadic.
But like I wrote before all that who it can help to improve our DSO is 
welcome, so thank You for the aid!
But like I wrote before all things who can improve our DSO are welcome. 
;-)

Have a good afternoon Hayo.

Mit freundlichen Grüßen,

Luc

von Blue F. (blueflash)


Lesenswert?

Luc schrieb:
> However, about the noise matter, I think a good solution already is the
> pickaback developed by Branadic.

Yes indeed, but for all those who didn't get one or those who prefer a 
simple solution with good result this may be an interesting possibility 
to modify the DSO for a better result. This solution only needs a few 
SMD resistors and 2 or 4 SMD capacitors.

The only requirement is the eqipment for soldering SMD parts.

So long

Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Für alle die den made-from-scratch Thread nicht lesen, ich habe jetzt 
eine erste Version des neuen FPGA-Designs und passende Alpha-Software 
veröffentlicht:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Viel Spaß beim Ausprobieren!
Jörg

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Da es hier ja momentan ziemlich ruhig ist, gibt es von mir wieder einige 
Vorabinfos zur Hardwaremod. - Stand der Dinge:

Die Dimensionierung für die neue Verstärkung ist jetzt entgültig. Es muß 
nur ein einziger Widerstand zusätzlich geändert werden und der ist ganz 
in der Nähe der anderen beiden 0 Ohm bzw. 24.9 Ohm Widerstände.

Die neue Verstärkung nutzt jetzt den zur Verfügung stehenden Bereich 
optimal aus, ohne in den nichtlinearen Bereich des letzten AD8131 zu 
kommen der die ADC-Eingänge treibt. Die obersten und untersten 38 Stufen 
bleiben außerhalb des sichbaren Bereichs. Der Skalierungsfaktor ist 
jetzt deutlich günstiger und das Rauschen insbesondere bei den 
ungeliebten 1er und 2er Spannungsbereichen erheblich weniger.

Die Screenshots zeigen einen meiner Tests: Das SDS8102 dient als 
Referenz, das W2014A läuft noch mit der normalen 24.9/180 Ohm 
Bestückung, das W2022A hat die neue BF Mod drin und auch schon eine 
Frequenzgangkompensation, die schon gut funktioniert (sieht man am 
Überschwinger). Leider setzt diese noch zu früh ein, da mir der passende 
Kondensator (4.7pF) fehlt und ich einen etwas größeren Wert nehmen 
mußte. Ist aber bestellt und kommt Anfang nächster Woche.

Die Frequenzgangkompensation ist optional, da der Amplitudenfehler mit 
maximal 10% nicht allzu schwer ins Gewicht fällt. Ohne Kompensation muß 
nur ein Widerstand ausgelötet werden, mit Kompensation muß dieser 
Widerstand und ein Kondensator ausgetauscht werden.

Jetzt werde ich mal die Doku in Angriff nehmen und die Firmware 
überarbeiten.

Gruß Hayo

von Lothar M. (lme)


Lesenswert?

Thumbs up!

Super, Hayo!
Das sieht seeeehr gut aus.

Lothar

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hallo Allerseits,

während das Essen so vor sich hinköchelt noch der Stand der Dinge an der 
Analogfront. Während die Dimensionierung für die 200 MHz Geräte fertig 
ist und ich sehr zufrieden bin mit dem Rauschen und dem Amplitudengang, 
macht mir die 100Mhz Serie etwas zu schaffen.

Wie man auf dem Amplitudengang sehen kann ist das W2022A schön linear 
mit nur geringen Abweichungen. Zum Vergleich habe ich das SDS8102 mit 
vermessen. Sieht auch nicht besser aus. Das W2014A mit identischer Mod 
stürzt aber bei 15MHz steil ab und durchschlägt bei 70MHz die -3dB 
Grenze (3dB = 50%)

Da die aktiven Bauteile in beiden Geräten die Gleichen sind, haben 
Wittigs hier wohl an einer schwer zu findenden Stelle einen Tiefpass 
eingebaut. Den versuche ich zur Zeit zu finden. Sachdienliche Hinweise 
sind willkommen.

Zur Aufheiterung mal ein Blick auf meinen Messplatz :-)


Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Hayo W. schrieb:
> Da die aktiven Bauteile in beiden Geräten die Gleichen sind, haben
> Wittigs hier wohl an einer schwer zu findenden Stelle einen Tiefpass
> eingebaut. Den versuche ich zur Zeit zu finden. Sachdienliche Hinweise
> sind willkommen.

Wie gesagt, ich halte das FPGA-Design selbst für verdächtig, die 
mögliche Filterei da drin. Bitte versuche das mit dem Nios II Design, 
denn da wissen wir woran wir sind.
Wenn du im Aquire-Menü (der Button mit dem Rechtschreibfehler ;-) den 
Aliasfilter ausschaltest sieht du in allen Bereichen die echten Samples.

Jörg

von Blue F. (blueflash)


Lesenswert?

Ok das ist ein Ansatz. Bevor ich mir da unter dem Mikroskop einen Wolf 
suche werde ich mal das neue Design checken. Kann man den Signalpegel 
irgendwo anpassen? Das erspart mir die Umrechnerei.

Gruß Hayo

von Jörg H. (idc-dragon)


Lesenswert?

Was meinst du mit "Signalpegel anpassen"?
Es gibt die üblichen Vertikalablenkungen.

Ferner kannst du die rohen Samples auf RS232 rausschreiben lassen.

Jörg

von Blue F. (blueflash)


Lesenswert?

Es gibt doch eine Skalierung, bzw. Skalierungsfaktoren, die müßten wegen 
der abweichenden Verstärkung angepasst werden. Ein Vergleich ist 
natürlich auch so möglich, da es ja nur um den relativen Frequenzgang 
geht. Da der Signalgenarator selbst auch nicht ganz linear ist, kann man 
mit absoluten Werten etwas genauer arbeiten, aber um zu prüfen ob der 
Abfall auch schon bei 15 MHz losgeht reicht es natürlich locker aus.

Hayo

von Blue F. (blueflash)


Lesenswert?

Übrigens - etwas offtopic - habe ich festgestellt, dass die Einsteller 
(Kondensatoren) unter der Abdeckung alle (alle 8 Stück) auf einer Seite 
nicht richtig verlötet waren. Das äußerte sich beim Einstellen darin daß 
das Signal manchmal mit einem Schlag eine andere Form hatte.

Dabei fällt mir ein, dass ich neulich in einem meiner Beiträge gesagt 
hatte, dass die beiden Einsteller oberes und unteres Teilsignal 
beeinflussen. Stimmt aber nicht. Es wirkt sich immer nur auf den oberen 
Signalteil aus - allerdings der obere Einsteller für die 5er Bereiche 
und der untere für die 1er und 2er Bereiche. Es funktioniert wie beim 
Tastkopf, wenn das Rechtecksignal gut aussieht ist es ok. Heißt keine 
Zacken nach oben und auch keine runden Ecken.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, nachdem ich mir einen Wolf gesucht und gemessen habe haue ich hier 
mal eine Verschwörungstheorie raus ;-)

Ich konnte den Verursacher des starken Abfalls im Frequenzgang eindeutig 
als OPA656 ausmachen, oder zumindest das Bauteil das sich als solcher 
ausgibt. Direkt am Eingang gemessen ist der Amplitudengang wie er soll. 
Direkt am Ausgang gemessen fällt er stark ab (-3dB bei 70 MHz). Alle in 
der Nähe befindlichen Bauteile habe ich geprüft, da ist nirgends ein 
Tiefpass versteckt.

Meine konspirative Vermutung ist, dass sich unter der Haube des mit B56 
gelabelten Bauteils etwas anderes verbirgt. Auffällig ist, dass das 
Gehäuse nicht wie das normale TI Gehäuse in meinem 200 MHz Gerät 
aussieht, sondern eher grob behauen mit einer grünen Lackmarkierung und 
der Schriftzug ist eingraviert und nicht gedruckt (siehe Bilder).

Das wirkt auf mich eher wie ein Chinateil.

Ich bin jetzt am Überlegen ob ich mal bei RS oder bei Digikey einen 
OPA656 oder wenn möglich einen OPA653 bestellen und den ersatzweise 
einbaue.

Hat jemand Erfahrung mit Bestellungen bei Digikey? Kann man da 
problemlos als Privatperson einzelne Teile bestellen?

Gruß Hayo

von Michael (Gast)


Lesenswert?

Hayo W. schrieb:
> Hat jemand Erfahrung mit Bestellungen bei Digikey? Kann man da
> problemlos als Privatperson einzelne Teile bestellen?

Lange nicht mehr gemacht, sollte aber funktionieren. Allerdings sind die 
Versandkosten mit 18€ etwas happig, wenn man unter 65€ bestellt, so dass 
es lohnt, sich für Kleinkram an eine Sammelbestellung ranzuhängen.
http://www.digikey.de/de/de/mkt/how-to-order.html (ganz unten)

von Blue F. (blueflash)


Lesenswert?

Ach ja,

interessant wäre zu erfahren ob andere bei ihren Geräten das Gleiche 
beobachten konnten bzw. können, nämlich bei den 200er Geräten die 
normalen bedruckten Bauteile und bei den 100ern die Bauteile mit 
gefrästem Schriftzug und grünem Punkt.

Wer also seine Kiste auseinandernimmt kann ja mal gucken und Rückmeldung 
geben.

Hayo

von Klaus D. (Gast)


Lesenswert?

also... bei meinem 2012A sind auch die laserbeschrifteten OPAs verbaut, 
wobei der Punkt auch gelasert aber nicht farblich markiert ist.

Gruss Klaus

von Blue F. (blueflash)


Lesenswert?

Ahh, danke für die Info. Ich werde wohl einfach mal einen bestellen und 
austauschen, dann haben wir Gewissheit.

Hayo

von Klaus D. (Gast)


Lesenswert?

Hier unter http://www.ti.com/product/opa656 kannst Du problemlos 3 
Samples bestellen. Wir werden bei dem OPA656 bleiben müssen, weil nur 
der für eine Verstärkung von 1 geeignet ist.

Gruss Klaus

von branadic (Gast)


Lesenswert?

Klaus D. schrieb:
> Wir werden bei dem OPA656 bleiben müssen, weil nur
> der für eine Verstärkung von 1 geeignet ist.

Kann man so nicht stehen lassen, der OPA659 ist pinkompatibel, wurde 
seinerzeit ebenfalls diskutiert und ist auch unity gain stable.
Allerdings und das ist auch der Grund warum die neue Eingangsstufe 
entwickelt worden ist, ist das Konzept der Verstärkung im Welec 
ungünstig konzipiert.
Das da ein als OPA656 gelabeltes IC mit anderem Inhalt in den 100MHz 
Geräten arbeiten soll kann ich mir nicht vorstellen, das würde ja schon 
an Produktfälschung grenzen.
Mir ist aber nicht verständlich warum man versucht die Hardware zu 
verschlimmbessern, wenn es doch seit Ewigkeiten eine fertig entwickelte 
Alternative gibt. Absolut unklar.

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:
> Mir ist aber nicht verständlich warum man versucht die Hardware zu
> verschlimmbessern, wenn es doch seit Ewigkeiten eine fertig entwickelte
> Alternative gibt. Absolut unklar.

Ganz einfach, weil es darum geht mit einfachen Mitteln eine akzebtable 
Alternative zu bieten. Die von mir demnächst vorgestellte Lösung ist 
bedeutend einfacher zu realisieren (als die Addon Platine) und günstiger 
mit durchaus gutem Resultat. Zudem ist die Addon Platine auch nur 
begrenzt verfügbar soweit ich das mitgekriegt habe.

Die originale Eingangsstufe ist eigentlich gar nicht so schlecht 
konzipiert, nur wurde im Detail gepfuscht und dadurch ein schlechtes 
Ergebnis erzielt. Der OPA656 ist eigentlich eine gute Wahl und immer 
noch fast konkurenzlos was das Rauschen bei einem JFET-Eingang angeht. 
Näheres in der Doku. Einzige interessante Alternative wäre der OPA653, 
leider ist der aber etwas schwer zu beschaffen.

Gruß Hayo

p.s. danke für den Tip mit den Samples Klaus, das werde ich mal 
probieren.

von branadic (Gast)


Lesenswert?

Hayo W. schrieb:
> Ganz einfach, weil es darum geht mit einfachen Mitteln eine akzebtable
> Alternative zu bieten.

Was du als akzeptable Alternative anpreist nenne ich verschwendete Zeit, 
die Hardware ist selbst für ein 8bit Scope vollkommen falsch konzipiert 
worden.

Hayo W. schrieb:
> Zudem ist die Addon Platine auch nur
> begrenzt verfügbar soweit ich das mitgekriegt habe.

Die Sourcen sind frei verfügbar und die Leiterplatte kann von jedem 
jederzeit reproduziert werden.


Hayo W. schrieb:
> Die originale Eingangsstufe ist eigentlich gar nicht so schlecht
> konzipiert, nur wurde im Detail gepfuscht und dadurch ein schlechtes
> Ergebnis erzielt.

Dann hast du das Konzept eines Eingangsverstärkers für ein DSO offenbar 
noch nicht verstanden und welche Teile das Rauschen in welchem Maße 
bestimmen. Auch nicht welche Maßnahmen notwendig sind, um das Rauschen 
zu begrenzen und wie man einen flachen Frequenzgang realisiert.
Eine große Hobbykasse und gutes Equipment ersetzt das notwendige KnowHow 
eben doch nicht.

Hayo W. schrieb:
> Der OPA656 ist eigentlich eine gute Wahl und immer
> noch fast konkurenzlos was das Rauschen bei einem JFET-Eingang angeht.

Auch das ist so nicht richtig, aber ich lass dich in deinem Glauben. 
Vielleicht studierst du das Datenblatt noch einmal richtig und 
vergleichst mit anderen Bausteinen.

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> Was du als akzeptable Alternative anpreist nenne ich verschwendete Zeit,
> die Hardware ist selbst für ein 8bit Scope vollkommen falsch konzipiert
> worden.
Wenn man mit weniger als 5 Euro und etwas Bastelaufwand einen geraden 
Frequenzgang mit wenig Rauschen bekommt sehe ich das schon als 
Alternative.

> Die Sourcen sind frei verfügbar und die Leiterplatte kann von jedem
> jederzeit reproduziert werden.

Stimmt, aber der Aufwand ist erheblich höher bei der Herstellung und 
beim Einbau und nicht jeder kann oder will diesen Aufwand treiben. Es 
sollen ja auch beide Lösungen unterstützt werden und nicht als 
Konkurrenz gesehen werden.

> Dann hast du das Konzept eines Eingangsverstärkers für ein DSO offenbar
> noch nicht verstanden und welche Teile das Rauschen in welchem Maße
> bestimmen. Auch nicht welche Maßnahmen notwendig sind, um das Rauschen
> zu begrenzen und wie man einen flachen Frequenzgang realisiert.
Dazu nimm Dir doch einfach die Zeit und lies mal die Doku sobald ich sie 
fertig habe. Wie immer bin ich für konstruktive Kritik in jeder Form 
empfänglich. Sollte das was ich da zusammengetragen habe nicht stimmen, 
lasse ich mich gerne eines Besseren belehren.

> Eine große Hobbykasse und gutes Equipment ersetzt das notwendige KnowHow
> eben doch nicht.
Deine Antworten entbehren nicht eines gewissen Charmes :-). Aber 
natürlich stimmt das auch. Ich kann Dir aber versichern, dass ich mich 
als diplomierter Elektroingenieur im Bereich 
Datentechnik/Nachrichtentechnik schon mit diesen Themen näher 
auseinandergesetzt habe. Wie gesagt meine Ausführungen zu diesem Thema 
sind in Kürze verfügbar und dann kann jeder für sich beurteilen ob das 
eine Alternative ist oder nicht.

> Auch das ist so nicht richtig, aber ich lass dich in deinem Glauben.
> Vielleicht studierst du das Datenblatt noch einmal richtig und
> vergleichst mit anderen Bausteinen.
Ist geschehen, und die Konstruktion mag nicht das Optimum darstellen, 
ist aber nicht so schlecht wie man angesichts des momentanen Ergebnisses 
vermuten könnte. Es ist durchaus möglich mit leichten Änderungen ein 
Ergebnis zu erzielen, welches für ein Oszi in dieser Preisklasse 
durchaus ganz respektabel ist. Ich denke es ist allen klar hier, dass 
ein Vergleich mit High End Geräten im Kilo-Euro Bereich auch nicht 
angemessen ist.

Als Schlußsatz möchte ich nochmal sagen, dass die Addonplatine eine 
interessante Möglichkeit darstellt und konstruktiv der originalen Lösung 
auch vermutlich überlegen ist, aber der direkte Vergleich mit meiner 
einfachen Lösung könnte schon interessant sein.

Gruß Hayo

von branadic (Gast)


Lesenswert?

Ich will hier keine Schlammschlacht vom Zaun brechen, aber gewisse 
Dingen müssen einfach mal gesagt werden.
Über Jahre hinweg entsteht für mich der Eindruck als wolltest du dich 
mit dem Welec "unsterblich" machen und alles was dir dabei in den Weg 
kommt wird entweder aktiv boykottiert oder man sitzt die Sache so lange 
aus, bis die Stimmen wieder verschwinden.
Wenn dem so sein sollte, dann frage ich mich warum du das nicht ganz 
klar hier auch so schreibst und warum du dir dafür eine öffentliche 
Plattform wähltst und nicht eine eigene "Heil dir Hayo"-Plattform 
aufsetzt. Ein Projekt lebt nun einmal davon das alle eine gemeinsame 
Lösung vorantreiben und nicht jeder sein Ding durchzieht. Da bleiben 
persönliche Interessen nun mal zum Teil auch auf der Strecke.
Das was hier passiert ist, dass sämtliche nicht Hayo-Lösungen 
schlichtweg unter den Tisch gekehrt werden. Du schreibst zwar, dass du 
Alternativen generieren möchtest, Fakt ist aber, dass du deine Lösung 
und nur deine damit nach vorn treibst und das, das unterstelle ich ganz 
öffentlich, hat System. Variantenbildung ist bis zu einem gewissen Grad 
vertretbar, dieser ist hier allerdings schon lange überschritten. Aber 
schauen wir uns das doch mal historisch an:

Zunächst entstand die BF-Firmware, von dir.
Nach einiger Zeit wurde eine neue Eingangsstufe von einer anderen Gruppe 
entwickelt. Dann ging es darum die neue Eingangsstufe in die BF-Firmware 
zu impementieren. Die Hardwareentwicklung hat dir dazu sogar fertig 
aufgebaute Platinen zukommen lassen, die bis heute irgendwo bei dir ihr 
Dasein fristen. Jemand anderes hat sich dann der Implementierung 
angenommen.
Dann ging es um die Abschlusswiderstände, auch hier wurde klar die 
Bestückung vorgegeben. Was aber macht Hayo? Er bildet Varianten, nur um 
sich von den anderen abzusetzen.
Osoz entstand, ein Konkurrent zu deiner BF-Firmware, mit einigen neuen 
Möglichkeiten. Hayo hilt an seiner Entwicklung fest.
Bald wurde ein neues FPGA-Design aufgesetzt. Du hast zwar beteuert in 
diesem Zug Osoz aktiv zu unterstützen und BF auf Eis zu legen, das hast 
du bis heute aber nicht konsequent umgesetzt und verfolgst weiterhin 
deinen Weg mit altem Design und deiner Firmware.
Jetzt nimmst du dich der Hardware an, wohl wissend das es eine deutlich 
bessere Lösung bereits gibt, die jedoch nicht von dir stammt.
Und nun sag mir, dass du "nur Alternativen" schaffen willst. Ist es 
nicht langsam mal an der Zeit an einem gemeinsamen Strang zu ziehen?

Denn sind wir mal ehrlich, wer in der Lage ist an der Hardware herum zu 
löten ist auch in der Lage die Huckepackplatine einzubauen. Zudem hätte 
man sich zusammen tun können und Platinen fertigen und bestücken lassen 
können. Das wurde meines Wissens nach auch mal diskuiert. Der Einbau ist 
reine Fleißarbeit und selbst da hätte man sich, bei Leuten die das nicht 
hinbekommen, arrangieren können.
Genug Huckepackplatinen wurden jedenfalls seinerzeit versendet, nur da 
von der Softwarefraktion keine Unterstützung kam dürften viele 
Bauteilsätze noch in irgendwelchen Schubladen liegen.

Dein Ingenieurstitel hin oder her, den habe ich davon mal ab auch, 
analoge Schaltungstechnik hin zu HF-Technik und rauscharme 
Signalvorverarbeitung sind ein eigenes Themengebiet. Wenn das nicht 
vernüftig konzipiert und umgesetzt wird ist alles zu spät und kann auch 
auf der digitalen Seite nicht mehr rekonstruiert werden, da sind wir uns 
doch hoffentlich einig?

Das man, gerade heutzutage, mit dem Welec keinen Preis mehr gewinnen 
kann brauchen wir nicht zu diskutieren, dafür ist die Hardware 
mittlerweile zu sehr veraltet und nicht mehr zeitgemäß. Daher will auch 
niemand das Gerät mit einem modernen Midrange DSO vergleichen. Aber wenn 
schon substanzielle Schaltungsteile einfach in ihrer Struktur falsch 
konzipiert worden sind, dann muss man doch einsehen, dass man sich von 
diesem Konzept verabschieden muss und der besseren und auch bezahlbaren 
Lösung vorziehen.

Aus irgendeinem Grund hast du in diesem Projekt eine Guru-Rolle 
zugeschrieben bekommen und in dieser Rolle ignorierst du alles was nicht 
von dir kommt anstatt dem Teamgeist entsprechend die beste Lösung voran 
zu treiben. Stattdessen werden unzählige Varianten geschaffen und 
niemand gebietet dem Einhalt. Das kann einfach nicht im Sinne eines 
Projektes sein.
Aus heutigem Standpunkt muss man klar sagen, dass einiges hätte besser 
laufen können, wenn man sich, entsprechend dem Projektmanagement, 
gemeinsame Ziele definiert hätte.
Wenn man aber den Verlauf aus der "One Man Show"-Perspektive betrachtet 
ist alles richtig gelaufen, denn genug Mitstreiter sind zwischenzeitlich 
abgesprungen, sicherlich auch vornehmlich aus den von mir genannten 
Gründen.

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:
> Ich will hier keine Schlammschlacht vom Zaun brechen

Mein lieber branadic, genau das tust Du hier aber. Wenn ich nicht so 
zurückhaltend reagieren würde hätten wir hier längst eine solche 
Schlammschlacht.

Um es aber auf den Punkt zu bringen: Wir gehen da wohl von zwei völlig 
verschiedenen Voraussetzungen aus! Ich mache die Sachen hier einfach 
deswegen, weil ich Spaß daran habe an technischen Lösungen zu tüfteln 
und an elektronischen Geräten zu basteln. Ich behalte mir dabei 
ausdrücklich vor, mir zu den Sachen eigene Gedanken zu machen und eigene 
Lösungen auszuarbeiten.

Meine Lösungen sehe ich dabei keinesfalls als das einzig Wahre an und 
ich will auch keinesfalls andere Lösungen herabwürdigen oder verdrängen. 
Wenn das mein Anliegen wäre, würde ich den Support in der Firmware 
einfach rausnehmen.

Wie ich in der Vergangenheit schon mehrfach sagte, behalte ich mir aber 
vor, wo ich meine Prioritäten setze, wenn ich in meiner Freizeit an 
Software oder Hardware entwickle. Dass viele Andere von den 
Entwicklungen die ich gemacht habe profitieren freut mich sehr, aber das 
ist eigentlich nur ein schöner Nebeneffekt und kein Selbstzweck. Über 
anerkennende Worte freue ich mich dabei genauso wie über konstruktive 
Kritik.

Speziell zum aktuellen Hardware-Mod frage ich mich wo Dein Problem 
liegt.

Hast Du schon mal daran gedacht, dass der Eine oder Andere weder das 
Geld noch den Aufwand in Kauf nehmen möchte die anspruchsvolle Lösung 
mit der Addonplatine umzusetzen, aber mit dieser einfachen Modifikation 
evtl. die Möglichkeit hat aus seinem Gerät noch etwas herauszuholen.

Beide Varianten werden in der Firmware unterstützt und jeder kann sich 
selbst anhand der zur Verfügung stehenden Informationen überlegen welche 
Lösung er bevorzugt.

Deine Angst, dass sich keiner mehr für die Addon Platine interessiert, 
halte ich für unbegründet. Da beide Lösungen auf unterschiedliche 
Ansprüche und Möglichkeiten zugeschnitten sind sehe ich das Eine als 
Ergänzung zum Anderen und es werden sich für beide Varianten 
Interessenten finden.

Ich würde mich freuen wenn Du, trotz Deiner Vorbehalte, meine 
Ausführungen sobald ich sie hier zur Verfügung stelle, objektiv bewerten 
würdest. Konstruktive Kritik oder Hinweise zu Fehlern sind dabei auf 
jeden Fall erwünscht.

Ich wünsche einen schönen restlichen 1. Mai

Hayo

von Blue F. (blueflash)


Lesenswert?

Klaus D. schrieb:
> Wir werden bei dem OPA656 bleiben müssen, weil nur
> der für eine Verstärkung von 1 geeignet ist.

Ich habe da noch den OPA653 im Auge. Der Frequenzgang gefällt mir sehr 
gut und er hat ebenfalls einen JFET-Eingang. Er hat noch weniger 
Eingangsrauschen als der OPA656 und eine extrem schnelle Anstiegszeit. 
Die Verstärkung ist zwar mit 2 fest vorgegeben, aber das würde mit 
wenigen Änderungen zu meiner Mod passen.

Ich habe, Deinem Tip folgend, gleich mal 3 OPA656 und 3 OPA653 bestellt. 
Da gibt es dann wieder schön was zu experimentieren. Ich werde 
berichten...

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier wie angekündigt die Doku zu meiner Hardwaremodifikation. Es war 
doch etwas mehr Arbeit als ich dachte, alle Informationen zusammenzu 
tragen und in eine ansprechende Form zu bringen. Die beste aller 
Ehefrauen war schließlich noch so nett alles zu überlesen und 
Verbesserungsvorschläge beizusteuern.

!-------------------------------------------------------------------
Dear english speaking DSO-owners, the english version of this docu is 
still under construction, but will be available soon.
!-------------------------------------------------------------------

In der Vergangenheit wurden verschiedene Änderungen vorgenommen und 
teilweise quasi auf Zuruf Bauteile getauscht ohne dass der Grund für 
alle offensichtlich war. Mit dieser Dokumentation möchte ich etwas Licht 
ins Dunkel bringen, damit jeder selbst abwägen kann welche Änderung für 
ihn sinnvoll ist und welche nicht.

Zum Anderen biete ich hier einen Dimensionierungsvorschlag an, der bei 
mir recht gute Resultate gezeigt hat. Sollte ich in der Doku irgendwo 
einen kapitalen Bock geschossen haben bitte ich um entspechende 
Hinweise.

Konstruktive Kritik oder weiterführende Ideen sind jederzeit willkommen.

Leider führt die Begradigung des Frequenzganges bei den 100MHz Geräten 
zu einer weiter reduzierten Bandbreite. Ich prüfe zur Zeit noch wie die 
Begrenzung der Bandbreite auf 100MHz zu beseitigen ist. Besitzer eines 
solchen Gerätes sollten daher vielleicht noch etwas abwarten bevor sie 
in Erwägung ziehen an ihren Geräten Änderungen vorzunehmen.

Viel Spaß beim Lesen und evtl. beim Löten

Hayo

von Michael D. (mike0815)


Lesenswert?

Hallo Hayo,
schicke Doku und nicht so steril verfasst ;-)

...bis hierher bin ich schon mal gekommen:
"Original findet sich hier ein 1.5KΩ
Widerstand (Kennzeichnung 154)."
Der Abschlußwiderstand müsste da wohl den Wert 150k(154) entspricht 
15+4x0=150000 Ohm, haben...

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Hi Michael,

Du hast natürlich Recht, da ist mir doch tatsächlich eine Null abhanden 
gekommen. Der resultierende Lastwiderstand zusammen mit den parallel 
liegenden ADC-Eingängen ergibt sich dann korrekterweise aus 150K||1.1K 
was dann mit 1.09K so ziemlich dem Eingangswiderstand der vier ADC 
entspricht. Das werde ich mal korrigieren bevor die englische Fassung 
rausgeht. Wenn Euch noch mehr auffällt gleich raus damit, damit ich das 
auch noch vorher geradeziehen kann.

Danke

Hayo

von Rainer W. (rawi)


Lesenswert?

Hallo Hayo,

sehr schön gemacht :-)

Beim ersten Durchstöbern deiner Doku ist mir aufgefallen, dass in Bild 1 
und 5 die Widerstände vor dem MAX gar keine Namen abbekommen haben - 
Absicht?

Gruß
Rainer

von Blue F. (blueflash)


Lesenswert?

Jein,

der Abschlußwiderstand hat in dem Schaltplan auf den ich mich beziehe 
tatsächlich keinen Namen, ich nenne ihn daher im Text einfach RA, die 
beiden Längswiderstände R31 und R32 habe ich tatsächlich vergessen zu 
beschriften.

Werde ich aber auch nachholen, soll ja nett aussehen.

Danke
Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, hier auch gleich die korrigierte Fassung.

In der Zwischenzeit habe ich auch von einem Mitstreiter das Angebot 
bekommen die Übersetzung zu übernehmen, was ich sofort dankend 
angenommen habe.

Dadurch kann ich mich jetzt um die Aktualisierung der Firmware kümmern, 
die dann in Kürze verfügbar sein wird.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja,

was mir jetzt nachträglich aufgefallen ist - ich bin gar nicht weiter 
auf den genutzten Auflösungsbereich eingegangen. Im 5V Bereich wird die 
verfügbare Auflösung bis zum Anschlag ausgenutzt.

Wem das zu progressiv ist und wer lieber etwas Reserve haben möchte, der 
kann beim Abschlußwiderstand RA auch 300 Ohm oder 270 Ohm bestücken. Der 
kleine Unterschied in der Verstärkung läßt sich im Hardwaremenü mit dem 
Gain-Regler einfach ausgleichen.

Das werde ich in die nächste Version des Dokuments mal mit aufnehmen.

Hayo

von reingasmann (Gast)


Lesenswert?

Gibts es einen Phasengang von vorher/nachher?

Gruß

von Blue F. (blueflash)


Lesenswert?

Nein, den habe ich ehrlich gesagt nicht gemessen. Das wäre aber eine 
Idee den ebenfalls zu prüfen. Bislang wurde die Priorität da mehr auf 
den Amplitudengang gelegt. Aber auf jeden Fall nicht unberechtigt die 
Frage.

Gruß

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier die überarbeitete Fassung mit den Erklärungen zur Auflösung im 
Ergebnisteil.

Hayo

von Martin H. (marndra)


Lesenswert?

Hallo Hayo,

danke für diese tolle Anleitung!
Werde das mal machen, die 24,9Ohm von dir kann ich ja dann direkt 
verwenden.
Müssen denn alle Widerstände 1% Tol haben?
Ev. solte man das in der Anleitung ergänzen?

Jetzt frag ich mich nur wie ich das Kalibrieren machen soll, hab kein 
Frequenzsimulator?(800 Euro sind mir dafür doch etwas zuviel)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Martin Haßlöcher schrieb:

> Müssen denn alle Widerstände 1% Tol haben?
Nein, aber bei der von mir verwendeten Dimensionierung ist der 5er 
Bereich soweit ausgequetscht, dass man evtl. bei größeren Toleranzen 
insbesondere bei R14 damit rechnen muß, dass die Auflösung von 256 
Stufen nicht mehr den ganzen Bildschirm nutzt. Dann würde ein voll 
ausgesteuertes Signal nicht mehr den Gridrand erreichen. Ist nicht 
schlimm, aber eigentlich nicht das was wir wollen.

Beispiel:

Wenn R14 mit 200 Ohm 5% Toleranz hat, kann der Wert 190 Ohm betragen 
aber auch 210 Ohm. In diesem Fall wäre der höhere Wert auf jeden Fall 
besser, denn die Verstärkung ist V = 1 + (187 Ohm / R14).

Also bei 210 Ohm -> V = 1.89 und bei 190 Ohm -> V = 1.98

Bei 190 Ohm wäre also die Verstärkung auf jeden Fall zu hoch. Man kann 
natürlich die Widerstände ausmessen (habe ich auch gemacht) und nur 
welche mit geeigneten Werten nehmen. Weiterhin muß man damit rechnen, 
dass bei größeren Toleranzen auch Unterschiede zwischen den Kanälen 
entstehen. Je kleiner die Toleranzen bei den Widerständen, desto 
akkurater das Ergebnis, wobei egal ist, ob man das selbst ausmisst oder 
gleich Bauteile mit kleinen Toleranzen verwendet.

> Jetzt frag ich mich nur wie ich das Kalibrieren machen soll, hab kein
> Frequenzsimulator?(800 Euro sind mir dafür doch etwas zuviel)

Also die Siganlform kann man notfalls auch mit einem ganz kurzen Draht 
von der BNC-Buchse zum Probe Comp einstellen (siehe Bild). Das ergab bei 
mir ein sauberes Signal, auch wenn es etwas verwegen aussieht. Also 
möglichst kurz und keine Abschirmung.

Den Signalpegel kann man mit einer Gleichspannungsquelle und einem 
Voltmeter prüfen und gegebenenfalls mit dem Gain-Regler einstellen (dran 
denken den Kanal auf DC zu stellen).

Hayo

von Daniel G. (Gast)


Lesenswert?

Hallo Hayo,

da werd' ich mir wohl bei der nächsten Teile-Bestellung ein paar 0603er 
SMD Bauteile mit einpacken.

Danke für die Mühe und die hervorragende Dokumentation.

Für deine Bemühungen in Sachen Firmware kann man dir ja sowieso schon 
kaum genug danken.

von Blue F. (blueflash)


Lesenswert?

Danke für die Blumen :-)

Die englische Version ist dank der Hilfe von Andy auch schon fast fertig 
und wird hier in Kürze erscheinen.

The english version is nearly finished and will be available soon. 
Thanks to Andy who helped with his really good english.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier die nochmals überarbeitete deutsche Fassung,

auch hier zu finden:

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/?

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...and the english version. Thanks to Andy for the translation. The file 
can also be downloaded here:

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/?

Hayo

von Blue F. (blueflash)


Lesenswert?

Chaka!

Hatte ich doch recht! Der OPA656, der in den W201xA (100MHz Welecs) 
werkelt ist ein Fake. Damit wäre die angezogene Handbremse gefunden.

Gestern kam die langersehnte Post von TI. Drin waren 3 x OPA656 und 3 x 
OPA653 die ich als kostenlose Samples bestellt hatte.

Also gleich drangesetzt und gelötet und dann Messreihen gefahren - 
Ergebnis:

Mit dem neuen OPA656 von TI ist mein W2014A jetzt ein W2024A. Die 
Besitzer von 100MHz Geräten können sich also freuen, da durch einfaches 
Tauschen der OP-Amps ein Upgrade möglich ist.

Weiterhin habe ich mein W2022A mit den OPA653 bestückt. Nach Anpassung 
der Firmware lief auch das völlig problemlos. Details und Doku zu beiden 
Mods  kommt natürlich noch...

Schöne Pfingsten

Hayo

von Rainer W. (rawi)


Lesenswert?

Hayo W. schrieb:
> Hatte ich doch recht! Der OPA656, der in den W201xA (100MHz Welecs)
> werkelt ist ein Fake. Damit wäre die angezogene Handbremse gefunden.

Das ist allerdings ein ziemlicher Hammer. Herzlichen Glückwunsch :-)
Da werden sich einige freuen und ein neues Typenschild aufbringen müssen 
;-)

Schöne Pfingsten, Rainer

von Michael D. (mike0815)


Lesenswert?

Inwiefern ist dieser ein Fake? Wird er als OPA656 bezeichnet bzw. was 
sagt der Aufdruck, oder ist es einfach nur ein anderer OPAmp-Typ ?

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Der Schriftzug auf dem Bauteil (B56) weist es als OPA656 aus. Die 
technischen Daten passen aber nicht dazu. D.h. es ist einfach ein 
anderer umgelabelter OP mit weniger Bandbreite, oder irgendein 
China-Nachbau mit entsprechend schlechten Kenndaten. Die Bandbreite 
dieses OP's liegt bei ca. 70 - 80MHz, während der originale OPA656 je 
nach Verstärkung (V = 2 bis 1) 200 - 500MHz Bandbreite hat.

Ich bin auch etwas erstaunt über diese Methode die Bandbreit künstlich 
zu beschneiden. Ich hätte da eher mit einem versteckten Hochpass 
gerechnet, der die Verstärkung beschneidet. Ich habe auch keine Ahnung 
wie man an solche umgelabelten Bauteile kommt.

Gruß Hayo

von felixh (Gast)


Lesenswert?

Vieleicht haben die einfach nur Billige Bauteile gekauft, und so 
versucht den Schaden in Grenzen zu halten ;)

von Michael D. (mike0815)


Lesenswert?

na ja, ich finde es schon eine Frechheit etwas zu verbauen, was drauf 
steht aber nicht drin ist!

von Blue F. (blueflash)


Lesenswert?

Die Idee ist ja nicht neu, identische Geräte künstlich zu bremsen um 
mehrere Preissegmente zu bedienen. Die Chinesen machen das mit einem 
programmierbaren Eingangs-OP. Da kann man per Firmware einstellen welche 
Bandbreite das Gerät haben soll. Leider ist die Firmware nicht 
zugänglich...

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo zusammen,

hab eben mein W2012A lt. LB-Mod umgebaut.
Das das Gerät etwas rauschärmer wird, kann ich bestätigen. Z.B. tanzt 
die QM Pk-Pk Anzeige nicht mehr so stark wie vorher.

Hayo W. schrieb:
> Chaka!
>
> Hatte ich doch recht! Der OPA656, der in den W201xA (100MHz Welecs)
> werkelt ist ein Fake. Damit wäre die angezogene Handbremse gefunden.

Das kann ich leider ohne Messungen nicht so ohne weiteres bestätigen :-(
Die zwei OP656 im W012A sind in "guter",normaler Farbe beschriftet. Die 
hab ich deshalb erstmal drin gelassen. Vielleicht wurden die Geräte 
zunächst doch durchgemessen und dann in 100MHz/200MHz aussortiert?
Das kann ich erstmal nicht nachvollziehen mangels Messtechnik.
Bei Farnell (und TI) gibt es z.B. auch 2 Versionen des OP656. Eine N und 
eine NB Version, die sich aber wohl im Rauschen, aber nicht in der 
Bandbreite lt. Datenblatt unterscheiden sollen...

Beim 2-Kanaler gibt es in den SW-Versionen ab 6.0 noch ein paar kleine 
Probleme. Ich zaehle mal einfach auf:
- Default Setup geht erst mit dem 2. Mal drücken
- Kanal1 und teilweise Kanal2 zeigen falsche Nulllinien an.
- Nach Gerät aus und wieder ein, klemmt Kanal 1 auch am oberen Anschlag. 
Es sieht so aus, als ob die D/A-Wandler mit dem Einschalten nicht 
gesetzt werden. Die Anzeige CH1 kommt erst mt Betätigen von CH1 
Auflösung oder CH1 Lage auf seine Nulllinie zurück.
Beim W2024 tritt dieser Effekt nicht auf.

Gruß
Jürgen

von Jürgen (Gast)


Lesenswert?

Habe mein W2024A jetzt auch auf LB-Mod umgebaut. Soweit so gut.

Aber, schöne Sch....
Alle vier OPA's mit grünem Punkt. Was heißt das nun wieder? :-(

Schönen Feiertag noch!

Gruß
Jürgen

von Blue F. (blueflash)


Lesenswert?

Hallo Jürgen,

danke für die Rückmeldung. Also zu Deinem ersten Beitrag:

> Das kann ich leider ohne Messungen nicht so ohne weiteres
> bestätigen :-(   Die zwei OP656 im W012A sind in "guter",normaler
> Farbe beschriftet. Die hab ich deshalb erstmal drin gelassen.
> Vielleicht wurden die Geräte zunächst doch durchgemessen und dann in
> 100MHz/200MHz aussortiert?

Dazu war bei mir der Unterschied einfach zu groß. Die Bandbreite der 
originalen TI-Bauteile ist mehr als doppelt so groß! Eine solche 
Streuung kann sich kein renomierter Hersteller leisten.

> Bei Farnell* (und TI) gibt es z.B. auch 2 Versionen des OP656.
> Eine N und eine NB Version, die sich aber wohl im Rauschen,
> aber nicht in der Bandbreite lt. Datenblatt unterscheiden sollen...

Ja, ich habe die NB Variante bestellt.

> Beim 2-Kanaler gibt es in den SW-Versionen ab 6.0 noch ein paar kleine
> Probleme. Ich zaehle mal einfach auf:
> - Default Setup geht erst mit dem 2. Mal drücken
> - Kanal1 und teilweise Kanal2 zeigen falsche Nulllinien an.
> - Nach Gerät aus und wieder ein, klemmt Kanal 1 auch am oberen
> Anschlag.
> Es sieht so aus, als ob die D/A-Wandler mit dem Einschalten nicht
> gesetzt werden. Die Anzeige CH1 kommt erst mt Betätigen von CH1
> Auflösung oder CH1 Lage auf seine Nulllinie zurück.

Diese Probleme sind bei mir auf keinem meiner Geräte reproduzierbar. 
Kann es sein, das Dein Gerät ein Hardwareproblem hat?

> Beim W2024 tritt dieser Effekt nicht auf.

Das würde meine Vermutung erklären...


Zu Deinem zweiten Beitrag:

> Aber, schöne Sch....
> Alle vier OPA's mit grünem Punkt. Was heißt das nun wieder? :-(

Mach mal ein Bild von den Teilen. Wenn die genau wie die originalen 
TI-Bauteile aussehen, muß der grüne Punkt nichts heißen. Wenn nicht...

Ich halte es durchaus für möglich, dass hier ebenfalls die Billigteile 
eingebaut wurden. Sicher kann man natürlich nur sein wenn man das 
meßtechnisch überprüft. Hast Du evtl. jemanden im Bekanntenkreis mit 
einem Frequenzgenerator? Ansonsten vielleicht mit einem Quarz einen 
einfachen Generator selbst bauen.

Zu der LB-Mod:

Löte mal die Schirmbleche noch nicht wieder drauf. Ich prüfe gerade eine 
andere Bestückungsvariante. Bei meinen Tests mit den OPA653 (sehr 
vielversprechend!) habe ich festgestellt, dass der 330 Ohm 
Abschlußwiderstand anscheinend den Frequenzgang des letzten AD8131 immer 
noch etwas abschneidet. Bei Versuchen ohne Abschlußwiderstand (also 
komplett auslöten) hatte ich deutlich mehr Bandbreite als vorher. Dafür 
müssen aber dann die Verstärkung und evtl. die Frequenzgangkorrektur 
angepasst werden.

Also erst mal abwarten, ich bin arbeite dran...


Hayo

p.s. Ohne die Abdeckungen fängt sich Kanal 1 gerne ein übergelagertes 
Störsignal ein (vom Netzteil). also möglichst mit Kanal 2 testen. 
Ansonsten wenn vorhanden, das Messingschirmblech verwenden, (hatten sich 
ja einige hier besorgt) das hilft dagegen.

Falls jemand schon an seinen OPA's rumlöten will:

Nicht vergessen, dass diese einen FET-Eingang haben. Also auf jeden Fall 
statische Aufladung verhindern durch Erdung der Platine und der Hand die 
die Pinzette hält!

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi,

hier noch mal ein Bild der beiden Bauteile im Vergleich. Die 
Originalteile sehen immer genau so aus. Wenn Eure Teile anders aussehen 
ist es ziemlich sicher kein richtiger OPA656.

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

Hayo W. schrieb:
>> Eine N und eine NB Version, die sich aber wohl im Rauschen,
>> aber nicht in der Bandbreite lt. Datenblatt unterscheiden sollen...
>
> Ja, ich habe die NB Variante bestellt.
>

Ich habe auch zwei mal NB neu hier. Die wollte ich in das W2012A 
einbauen...

>> Es sieht so aus, als ob die D/A-Wandler mit dem Einschalten nicht
>> gesetzt werden. Die Anzeige CH1 kommt erst mt Betätigen von CH1
>> Auflösung oder CH1 Lage auf seine Nulllinie zurück.
>
> Diese Probleme sind bei mir auf keinem meiner Geräte reproduzierbar.
> Kann es sein, das Dein Gerät ein Hardwareproblem hat?
>

Warum geht es dann aber nach dem ersten Betätigen  des Lagereglers CH1 
ganz normal. Ich meine mit dem Betätigen über die erste Raste des 
Offsetreglers springt die Anzeige auf die richtige Nulllinie zurück und 
läßt sich dann ordentlich verstellen. Bei einem Hardwarefehler sollte es 
dann auch nicht funktionieren, da der Datenweg der gleiche wie bei der 
Initialisierung ist.
Ich habe testweise sogar nochmal die originale V1.4 programmiert, um 
auszuschliessen, daß irgendwelche Stammdaten verschüttet gegangen sind. 
Kein Erfolg. Mit der BF5.10 war alles i.O.
Vielleicht hat aber auch die Hardwareversion einen Einfluss?
Mein 2024 hat 8C7.0H, das 2012 hat 1C9.0L. Inwieweit haben die 
Osoz-Optimierungen darauf vielleicht einen Einfluß?

>> Beim W2024 tritt dieser Effekt nicht auf.
>
> Das würde meine Vermutung erklären...
Ev. meine auch :-) Das hat aber erstmal Zeit!

Habe beide Geräte schon wieder mit Abdeckblechen usw. zusammengebaut :-(
Ich mache später mal Fotos von den OPA's. Bin aber die nächste Woche 
dienstlich stark eingespannt und das WE ist auch schon ausgebucht.
Ich werde mir einen Frequenzgenerator organisieren und dann wohl messen 
müssen, um die Unterschiede zu testen.

Jürgen

von Jörg H. (idc-dragon)


Lesenswert?

Hayo W. schrieb:

> hier noch mal ein Bild der beiden Bauteile im Vergleich. Die
> Originalteile sehen immer genau so aus. Wenn Eure Teile anders aussehen
> ist es ziemlich sicher kein richtiger OPA656.

Hmm, ist das auch nicht vertauscht?
In meinem W2024 sind die mit den grünen Punkten und der größeren 
Schrift, in Guidos W2012 die ohne Punkt und mit kleinerer Schrift.

Generell ein interessanter Fund. Ich wußte gar nicht, das tatsächlich 
ein Unterschied in Hardware besteht, hätte auf längst ausnivellierte 
Softwareunterschiede getippt. Eigentlich unfaßbar, daß das so lange 
unentdeckt blieb...

Jörg

von Guido (Gast)


Lesenswert?

Jörg H. schrieb:
> Eigentlich unfaßbar, daß das so lange
> unentdeckt blieb...

Naja, wer hat schon Zugriff auf zwei verschiedene Geräte? Aber
schon sehr interessant, Sherlock Holmes bei der Arbeit. :-))

von Blue F. (blueflash)


Lesenswert?

Jörg H. schrieb:
> Hmm, ist das auch nicht vertauscht?
> In meinem W2024 sind die mit den grünen Punkten und der größeren
> Schrift, in Guidos W2012 die ohne Punkt und mit kleinerer Schrift.

Die Samples die TI mir geschickt hat, sehen genauso aus wie die Teile in 
meinem W2022A. Das Original auf dem Bild ist übrigens aus dem W2022A. Da 
würde ich mal sagen, dass einige von Euch mit falsch gelabelten Geräten 
ausgestattet sind. Traue ich den Wittigs ohne weiteres zu. Die haben 
vermutlich einfach die Billighardware in die 200 Mhz Gehäuse gepackt um 
den höheren Preis nehmen zu können. Wenn man das nicht so haargenau 
untersucht wie wir, kommt man ja auch nicht drauf. Und wenn ich nicht 
den direkten Vergleich beider Geräte gehabt hätten, wäre ich wohl auch 
nicht drauf gekommen - insofern hat Guido durchaus recht.

Übrigens sind bei mir nicht nur die Kanäle mit Fakes bestückt, sondern 
auch der externe Trigger. Beim W2014A war hier ebenfalls ein Chip mit 
grünem Punkt (-> gelber Müll ;-)) verbaut, während beim W2022A ein 
originaler Chip drinsteckt.

Übrigens, falls sich jemand mit dem Gedanken befasst die Chips 
auszutauschen - besorgt Euch den OPA653. Der hat wirklich gute 
Ergebnisse bei mir gezeigt. Geschätzte Bandbreite meines modifizierten 
Gerätes ~300MHz. Leider hört mein Generator bei 140 MHz auf. Bis dahin 
hat die Kennlinie aber keinen Abfall, sondern läuft unterhalb von 5% 
Abweichung Richtung höherer Frequenzen. Die Schätzung mit den 300 MHz 
entnehme ich den Kennlinien der AD8131 und des OPA653. Beide laufen 
ziemlich linear bis über 400MHz.

Das läuft bei mir schon soweit sehr gut, ich arbeite nur noch an einer 
Dimensionierung, die eine gemischte Bestückung OPA656/OPA653 erlaubt. 
Kombiniert mit den neuen NIOS II FPGAs dürften unsere DSOs ungeahnte 
Qualitäten erreichen.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Übrigens, wer auf die Schnelle mal prüfen will welchen Chip er da 
verbaut hat muß nicht extra die Hauptplatine ausbauen. Es reicht wenn 
man den Deckel hinten abnimmt und dann beim USB-Anschluß nachsieht. Dort 
ist der Eingang des externen Triggers, der mit dem gleichen Bauteil 
bestückt ist. Kann man mit einer Lupe ganz gut erkennen.

Hayo

von Michael D. (mike0815)


Lesenswert?

da ist eine Diode überbrückt, was hat das zu bedeuten?

von Blue F. (blueflash)


Lesenswert?

Das ist der Mod für den externen Trigger, den Jörg mal vor einiger Zeit 
hier vorgestellt hat. Leider gibt es keine Doku als PDF soweit ich weiß. 
Vielleicht hat Jörg ja noch Unterlagen dazu? Müßte sonst auch hier im 
Thread zu finden sein, irgendwo weiter hinten...

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, da ich im Augenblick nicht an der Hardware rumlöten kann, hab ich 
mal eine Doku zum Upgrade geschrieben.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Michael D. schrieb:
> da ist eine Diode überbrückt, was hat das zu bedeuten?

Ich habe noch mal gesucht und festgestellt, dass ich selbst eine kleine 
Bilderdoku gemacht habe. Ich stelle die hier noch mal rein.

Der Effekt der Mod ist, dass der externe Trigger deutlich besser 
funktioniert.

Nebenbei kann man den OPA656 ganz gut erkennen, es ist hier das 
Original.

Hayo

von Blue F. (blueflash)


Lesenswert?

Die Lötstation ist gestern angekommen und ich konnte dank des besch... 
Wetters weiter testen.

@Jürgen

Du kannst Deine Kiste lassen wie sie ist. Beim OPA656 hat es keinen 
Einfluß auf die Bandbreite, ob der 330 Ohm Abschluß drin ist oder nicht. 
Der begrenzende Faktor ist da der OPA656 selbst. Nur bei OPA653 bringt 
es was, da dieser mehr Bandbreite mitbringt und die Gesamtbandreite 
dadurch größer wird.

Hayo

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

Hayo W. schrieb:
> Du kannst Deine Kiste lassen wie sie ist. Beim OPA656 hat es keinen
> Einfluß auf die Bandbreite...

Danke für die Rückmeldung. Bin aber sowieso noch nicht dazu gekommen.

Hayo W. schrieb:
> Ich habe noch mal gesucht und festgestellt, dass ich selbst eine kleine
> Bilderdoku gemacht habe. Ich stelle die hier noch mal rein.
>
> Der Effekt der Mod ist, dass der externe Trigger deutlich besser
> funktioniert.

Ich habe vor einiger Zeit schonmal den Plan überarbeitet und die neuen 
Bauelementewerte eingezeichnet sowie die Verbindungen lt. Erkenntnissen 
der alten SW-Anpassung korrigiert (war auf dem Originalplan mit Symbolen 
eine falsche Pinbelegung U18).
Das sollte hier auch weiter vorn zu finden sein. Trotzdem nochmal als 
.png

Gruß,
Jürgen

von Blue F. (blueflash)


Lesenswert?

Danke Jürgen,

ich habe in den letzten Tagen übrigens diverse Variationen von 
Bauteilkombinationen getestet, aber die Bauteilempfehlung aus der LB-Mod 
hat einfach immer die besten Messergebnisse. Ich habe jetzt meine 
Abschirmungen auch wieder draufgelötet.

An dieser Stelle sei noch einmal darauf hingewiesen, dass dem Abgleich 
nach der Modifikation eine entscheidende Bedeutung zukommt.

Als kleines Beispiel:

Wenn Ihr bei einem 1KHz Rechteck einen kleinen Überschwinger von 10% an 
der Ecke der Flanke habt, heißt das, dass ihr bei einem 1MHz 
Rechtecksignal über die komplette Signalbreite einen Level mit 10% 
zuviel Amplitude habt. Also wirklich genau abgleichen, sonst könnt Ihr 
Euch die Frequenzgangkompensation schenken!

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Die Arbeiten an der OPA653-Mod sind abgeschlossen. Zur Zeit schreibe ich
noch die Doku. Quasi als Nebenprodukt ist noch eine kleine Verbesserung
zur Wärmeabfuhr an den FPGAs abgefallen für alle die lieber mit Bohrer
und Feile hantieren als mit dem Lötkolben (oder beides gerne machen).

Gruß Hayo

von wirehead (Gast)


Lesenswert?

Völlig OT aber da es mir grade wieder einfällt:
wo bekommt man denn solche Litze womit im Welec die Fädelverbindungen 
gemacht wurden? Hatte letztens einen Sie*ens Stromrichter bei dem auch 
nicht mit Fädellitze gegeizt wurde. Das Zeug verarbeitet sich um längen 
besser als Teflon oder PVC Litze.

von Kurt B. (kurt)


Lesenswert?

Hallo Leute!

Es gab ja mal eine Sammelbestellung für den Netzschalter. Sind davon 
noch vieleicht noch welche übrig? Einer würde mir schon reichen ;-)

Mfg,
Kurt

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Kurt,

man kann die auch bei Reichelt bestellen.
Ich meine es war dieser hier:
http://www.reichelt.de/Drucktaster-Druckschalter/MAR-1682-1101/3//index.html?ACTION=3&GROUPID=3277&ARTICLE=108198&SHOW=1&START=0&OFFSET=500&;
(Bestellnummer "MAR 1682.1101", falls der Link nicht geht.)

Ich hatte mal zwei bestellt, einen für mich (beim nächsten größeren 
Öffnen einzubauen), einen für jemand anders. Liegen zur Zeit noch rum, 
wenn's pressiert könnte ich dir einen schicken und bei nächster 
Reicheltbestellung wieder ergänzen.

Jörg

von eProfi (Gast)


Lesenswert?

Hallo zusammen!
Kurt, dann bestell am besten gleich einen NTC (z.B. 33 Ohm) mit, dann 
halten Schalter und Gleichrichter ewig.
Ich finde bei Reichelt keine passenden.
Bürklin schon: z.B. 120 Ohm  3,5A  80E6712  Epcos B57364S0121M000  2,80

von Michael D. (mike0815)


Lesenswert?

Ich fasses nicht. Damals hatte Reichelt die noch nicht im Programm, dann 
mußte ich die beim Conrad (20 Stck.) ordern, abgeholt und natürlich auch 
den Preis dafür bezahlt :-(((

http://www.conrad.de/ce/de/product/700252/Marquardt-Druckschalter-250-VAC-12-A-Serie-1680-16821101-2-x-EinAus

Sind noch welche da, jedoch wie das so ist, hatte sich die hälfte der 
Besteller nie mehr gemeldet...

Gruß Michael

von Kurt B. (kurt)


Lesenswert?

Danke für das Angebot Jörg, aber es eilt nicht. Ansonsten würde ich 
Michael um einen Schalter erleichtern.
Auf die Jagd nach dem NTC werde ich mich auch machen.

Mfg,
Kurt

von Guido (Gast)


Lesenswert?

Da hänge ich mich gleich mal ran: Michael du bekommt Post.

NTCs hatte ich bei Conrad mal ausgesucht, ist aber lange her,
wahrscheinlich ein, zwei Threads früher.

Grüße, Guido

von Blue F. (blueflash)


Lesenswert?

Ich hätte ebenfalls Interesse an zwei NTCs

Gruß Hayo

von Alessandro C. (musashi)


Angehängte Dateien:

Lesenswert?

Hello,
I've originally posted my problem in the einsteiger section, but now 
repost it here seems more correct.

My oscilloscope (W2012A) had begun to constantly show (in the second 
channel)a sinusoid wave.
Even without the probe connected.
When I press "Quick Meas" I get 500Hz 27,8V pk-pk
What could be the cause of the problem?

Model: W2012A
HW Version: 8C7.0C
SW Version: 1.2.BF.6.7

Hardware settings are:

ADC Setup - Factory
Pre Gain - Factory
Gain - 1.000
ADC Driver - Assembler

Calibration done with open inputs, channel 1 working correctly

von WWWelec (Gast)


Lesenswert?

Hello Alex,

I see very weird trigger setting in top of the screen, could be better 
anything else but pulse mode.
Trust me, try with other selection for trigger, it's better.
I guess and maybe it is possible that it could be the problem.

Another weird thing is about open inputs for calibration, indeed it 
should be performed short-circuiting them, never with open ones.
My two cents.

Victor

von Stefano M. (Gast)


Lesenswert?

Hi people.
I'm a new Welec user and as such trying to retrieve informations about 
my Welec 2012A Google send me here.
I read a lot of interesting things and I would to make the bandwidth 
modification, but I have some questions.
OPA 656 or OPA 653?, what is the better?
Somewhere I read about adesive copper sheets used in order to improve 
noise's shield, what is their correct name and where can I get them?
I guess they are condictive copper on one side and insulated adesive on 
the other, I'm able to find only uninsulated version but I don't know 
their correct name and the manufacturer (3M?).
Also I would to install the new fpga design but before of that I'd like 
to know how save the original one as safety backup.
Can somebody help me?
Discussions seem to me almost death but I hope there will be a recovery, 
missing very little to the finish ribbon, cheer up!
Me and my 2012A never give up!
Thanks.

Stefano

von Blue F. (blueflash)


Lesenswert?

Hi Stefano,

congratulations to your new DSO. I will try to answer your questions.

First point: discussions are not dead - this is only the "summer hole". 
When the days are shorter in the darker time of the year, the creative 
time is coming...

The bandwidth mod: The OPA653 is the better choice with more bandwidth. 
But these parts are more difficult to get. I ordered three of them as 
free sample from Texas Instruments (via homepage of TI).

Unfortunately the documentation for the OPA653 mod is not ready up to 
now due to lack of time. If you are interested in the OPA653 mod I can 
support you with some schematics, photos and instructions how to do it.

The copper shield I bought at Conrad, you can find under this link:

http://www.conrad.de/ce/de/product/529532/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CLSsoM6lsroCFcZd3godXigARQ

It is adhesive on one side and without insulation on the other side. It 
can be soldered without any problems.

The new FPGA design is just under construction and at this time not 
usable for productive purposes. Chief engineer for this project is Jörg. 
His ideas and the project progress can be observed in this thread:

Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Further interesting links are:

http://sourceforge.net/apps/trac/welecw2000a/wiki

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/


Regards

Hayo

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Happy to see something is moving here.
I imagined that OPA653 was better.
I wonder if resistors are the same either for OPA656 than OPA653 or they 
are different.
I read some documents which described the modification using OPA656 but 
never using OPA653.
The modification who I know consist in 200ohm 1% SMD -0603 1 piece 
resistor, 100ohm 1% SMD -0603 1 piece resistor, 24.9ohm 1% SMD -0603 2 
pieces resistor, 330ohm 1% SMD -0603 1 piece resistor and 10pF 10% SMD 
-0603 1 piece capacitors for OPA656.
By the way, I wonder if the capacitor must to be a NP0 or C0G, rather 
than 5YV, X7R and so on in order to reach better results.
And again, I'd like to know about the resistors' tollerances, ie if 1% 
is enought or 0,05% and so on will be better.
Before I purchase the new operational amplifiers I'd like to know what 
other components  I need and where I have to place them, in orde to get 
an idea about the kind of work I will have to do.
Thank you for the hint about the adesive copper foil, I get it, I ever 
find type conductive on both sides.
And CONRAD is also near where I live!
I will take a look at the links you wrote, hoping also Jörg restart as 
soon to write about the new fpga design.
Me and my 2012A now are most happy, thanks.
I look forward.

Saluti,

Stefano (ITALY)

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
I forgot some things.
I have been in the TI web site in order to take a look at the data sheet 
of the OPA 653.
I  have seen several of the same component with different package 
(OPA653IDBVR, OPA653IDBVT, OPA653IDRBR, OPA653IDRBT).
Which one should I buy?
In the document "Optimizing_Thermal_Design_Part3.pdf" I read about 
thermo pad for the two fpga.
What is it exactly?
Which must be the size?
I guess the thickness is important, isn't so?
Grazie!

Stefano

von Blue F. (blueflash)


Lesenswert?

Ciao Stefano,

the OPA653 is a IDBVT type. The further components you need are 
different from the OPA656 mod. You need less components (because some of 
them are integrated in the OPA), and some of the old components have to 
be desoldered because they are not needed anymore. Before you buy the 
OPA653 (about 5 - 8€ per part at digikey) try to order free samples. 
That was no problem in my case (I wrote that I need them for school 
purposes).

1% tolerance for the resistors is ok. If you take more tolerance (5%), 
the quality of the result might vary. If you take less it is ok but I 
think it is not necessary.

Although the documentation of the OPA653 mod is not complete yet, I can 
post the schematic and the components you need if you are interested in.

The thermo pads I used for the FPGAs are from an old power device which 
I disassembled. It is about 1 - 1,5mm thick and looks a bit like a 
stripe of plastic with foam in the core. A little bit more thickness 
seems to be no problem, because it is flexible and can be compressed a 
little bit. It has a low thermal resistance - that makes it able to 
transport the heat from the FPGA to the metal chassis. I don't know if 
you can buy it anywhere.

Saluti from Hamburg
to bella Italia

Hayo

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Ok, OPA 653 have to be IDBVT type.
I will try to follow your suggestion, TI web site is under maintenance 
right now.
I am surely interested on the mod, so I would be happy to know all about 
it.
Until now I have read about the ones for OPA656 devices, never about 
changed operational amplifiers with the different OPA 653.
I have read documentations and measures about the changed components on 
OPA 656 devices and changed fake to good OPA 656, it seems to reach a 
great result among the real 200MHz bandwidth.
Also I read somewhere about the possibility to change the operational 
amplifiers in order to get more bandwith, something as about ~300MHz, 
and I need bandwidth (my hobby is ham radio) so I'd like to try it.
Somewhere else I have read of some little board developed by some user 
of the forum that improves the performances of the Welec.
If I'm not wrong the boards are discontinued and they aren't supported 
by firmware yet.
What was their bandwidth?
Somewhere in the forum I have read who the ADC831 are in the 400MHz 
bandwidth range just as the OPA 656 (500MHz bandwidth), so I guess that 
boards could reach at least ~350MHz, do you know?
OK, if 1% range for the tollerances of the resistors are good, then I 
will put an order of those.
But what about the capacitor?
C0G, NP0, X7R, Y5V or any else in order to compensate temperatures?
Please let me know.
However without I know all the components in the list I can not order 
anything, so I wait for an answer.
Sorry but I do not understand well about the thermo pads who I should 
buy.
Are they adhesive?
Otherwise how I stuck them on the fpga?
Do you think I could get something of them from a broken computer power 
supply?
Using a piece of metal stucked by thermal adhesive could be a good idea?
May be it is not because if the piece of the metal fall inner the Welec 
it could make short circuit.
I am sorry for the big amount of the questions!

Buon fine settimana,

Stefano

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Stefano,

the capacitors are NPO/COG types, like this one:

http://www.conrad.de/ce/de/product/457926/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CKmzuMeHtboCFcJb3godpRsAFA

These are the only ones that are suitable for our high frequency 
purposes.


The main factor for the bandwidth is the first OPA of the input stage 
(OPA656 in the original circuit layout).

The OPA656 has a bandwidth of 200MHz at the gain of ca. 2 which we are 
using. The OPA653 has a bw of 500MHz at a gain of 2. So the input stage 
is not longer the limiting factor, but the AD8131 cascade. A Bandwidth 
of 300 - 350MHz for our WELEC may be possible with the OPA653, but I 
don't have the test equipement to examine it. My Leader 3216 only makes 
140MHz maximum. My tests with a 100MHz puls generator look promising and 
the results where much better than with the original circuit layout.

The result with the add on board may be interesting also, but the OPA653 
mod is much cheaper and easier to realize. I will try to post all 
interesting informations for the mod here (I have to search first...).

The thermo pad - it is not adhesive and it is flexible like a piece of 
rubber. It will be fixed on the FPGA by the pressure of the metal 
chassis. A piece of metal is not a good choice, because it will be 
difficult to get the right thickness. If it is too thick, the metal 
chassis will press too hard on the FPG, and if it is too thin, there 
will be no thermal flow.

Power supplies may be a good source for these pads. They are offen used 
for cooling the power transistors. On the picture you can see some pads 
which I found in old power supplies.

E buona serata

Hayo

von reingasmann (Gast)


Lesenswert?

Hi,
hattest du mal zeit einen Phasengang zwichen einem modifizierten und 
einem orginalkanal aufzunehmen?

Gruß
Niels

von Blue F. (blueflash)


Lesenswert?

Hallo Niels,

nein leider nicht. Ich habe auch keinen Origanalkanal mehr. Mein W2014A 
habe ich mit der Low Budget Mod beglückt und dem Upgrade (also zum 
W2024A gepimpt). Meinem W2022A habe ich die OPA653 Mod verpasst. Somit 
lässt sich ein vorher nachher Phasengang bei mir nicht mehr durchführen. 
Da müsste sonst jemand ein originales Gerät beisteuern. Ich glaube ein 
Freund von mir hat noch zwei, das wäre also eine Möglichkeit. Evtl. kann 
ich da mal Vergleichsmessungen anstellen.

Diese Messungen sind auch nicht ganz einfach, da man dafür Leitungen an 
die Messpunkte anlöten muß um im laufenden Betrieb messen zu können.

Gruß Hayo

: Bearbeitet durch User
von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
OK for the capacitors who have to be 4,7pF in value and NP0/C0G and 
+/-0,25pF as type and tolerance for the OPA 653 hardware modification.
So I guess also for the modification of the OPA 656 based Welec the 
capacitors have to be of the same kind, then 10pF/50V C0G or NP0.
Very well.
~300-350MHz of bandwith would be fine for me, honestly also the 200MHz 
range of the OPA 656 would be nice.
Sadly my 2012A have the fake OPA 656 so needing to change it and needing 
me more bandwidth I can get, would be better for me to use OPA 653 
modification.
Good to know about your measurements.
What I don't understand is when you wrote about the 100MHz pulse 
generator.
I need one in order to calibrate my Welec after its 
modification?(correct the distortions of the input stage using 5xx/div 
and 1xx-2xx/div trimmer capacitors).
And why are 100MHz enought for a instrument who if that goes wrong is in 
the 200MHz range of bandwhidt?
Sorry, I don't understand it.
I knew that the bandwidth of the oscilloscopes is checkable with a radio 
frequency calibrated sine wave generator.
OK for the thermo pads, I get it now, thank you.
I think I know where I can get some of those, very well.
Now I'm very impatience to see and understand the whole modification.

Buona Domenica.

Stefano

von Blue F. (blueflash)


Lesenswert?

Ciao Stefano,

only short reply because I have to make the dinner.

Stefano M. schrieb:
> So I guess also for the modification of the OPA 656 based Welec the
> capacitors have to be of the same kind,

Yes this is correct, COG and NPO are two different names for the same 
part.

For the pulse generator 100MHz is only the main frequency. The sub 
frequencies (hidden in the rectangle signal) go up to 500MHz and the 
rise time which is an important parameter of our dso, is 2.4ns. With 
your original dso the pulse will look more like a sinus wave than a 
rectangle. With more bandwidth the form becomes more and more a 
rectangle. And that is what happens with all signals that are not only a 
sinus signal. They become distorted if the bandwidth is too small.

More information for the 653 mod will come soon...

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, here is the OPA653 Mod.

The part numbering is the same as in the Low Budget Mod. You have to 
desolder C12, R22, R21, Ra, U3 (optional, but recommended). Following 
Parts have to be exchanged with new values:

R13 = 390 KOhm
R14 = 100 Ohm
R31/R32 = 24.9 Ohm

OPA656 -> OPA653


Regards

Hayo

: Bearbeitet durch User
von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Thank you alot, interesting mod.
Only few things.
1)
In previous posts there has been talk about a 4,7pF NP0/C0G capacitor.
Since the net formed by C12, R22 and R21 has been removed also that 
capacitor has been deleted, so by now we need no any capacitor when 
doing the modification, is it right?
Why has it been removed?
We do not need any compensation element like in the case of modification 
with OPA 656?
2)
Again in previous posts there has been explained the importance to 
correctly close the ADC8131's output on the right impedance value so 
there was it as Ra.
By now Ra is missing, why?
3)
For the mod is supposed to use one piece OPA 653 for each channel of the 
oscilloscope, so 2 or 4 depending from the model.
Actually we need to change also the operational amplifier in the EX 
Trigger circuitry, but how we have to do the modification there?
Need we only to replace OPA 656/fake OPA 656 with the new OPA 653 or are 
there also need some modifications?
I guess isn't so good improve input channels leaving out the EX Trigger 
input, isn't so?

Grazie e alle prossime.

Stefano

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ciao Stefano,

a lot of questions....ok, here we go:

> so by now we need no any capacitor when
> doing the modification, is it right?

Yes correct, no capacitor is needed for the OPA653 mod. You only need 
some for the mod with the OPA656.

> Why has it been removed?
> We do not need any compensation element like in the case of modification
> with OPA 656?

C12, R22 and R21 are not needed anymore, because:

1. The feedback resistor is integrated in the OPA653 (R21)
2. The frequency response of the OPA653 is much better than the OPA656s. 
So we don't need any compensation (R22/C12 - see attached diagramms).

> By now Ra is missing, why?
The reason is described in the Low Budget Mod on page 4. In short: Ra is 
reducing the bandwidth of the last AD8131. This has been done in the 
past to correct the bad frequency response of the OPA656. In the LB-Mod 
this is done by the compensation network R22/C12.
For the OPA653 there is no compensation needed and we want to use so 
much bandwidth as possible given by the AD8131.

> Need we only to replace OPA 656/fake OPA 656 with the new OPA 653 or are
> there also need some modifications?
For the external trigger we only need to replace the fake against the 
original OPA656. This works good because in this case it is not so 
important to get all spectral components. For special triggering as 
searching for spikes it recommended to use the internal trigger.

Saluti da Hamburg

Hayo

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Grazie for the informations.
So the capacitor of which we was talking about was refered to be one for 
the OPA 656 modification, but should not it be 10pF?
We were talking about a 4,7pF capacitor , so is require OPA 656 
modification a 10pF or 4,7pF?
Or again you mean 9,4pF as parallel of two 4,7pF capacitors should be 
better than single 10pF?

Ok for the missing of the C12, R22, R21 net, now I understand it.

Interesting the matter about Ra because actually it is one of the 
culprits in the lack bandwidth cause AD8131 can't reach its 
specification.
I get it, before I knew nothing about that.

Ultimately only way to improve EX Trigger in Welec which they have fake 
OPA 656 it is to change fake with good, there isn't any way to put OPA 
653 that perhaps improve performances even there.
I get it.

Grazie mille!

Stefano

von Blue F. (blueflash)


Lesenswert?

Ciao Stefano,

Stefano M. schrieb:
> We were talking about a 4,7pF capacitor , so is require OPA 656
> modification a 10pF or 4,7pF?

That was only an example. It was the first one I found in the catalogue 
with the correct type without paying attention to the value.

The correct values you can find in the LB-Mod (OPA656 Mod) on the last 
page.

> there isn't any way to put OPA
> 653 that perhaps improve performances even there.

May be it is possible, but the result is not in proportion to the 
effort. So I decided to take the OPA656.


Saluti

Hayo

: Bearbeitet durch User
von Errico (Gast)


Lesenswert?

Thanks Hayo, for your information, I have already asked as sample 
3xOPA653 at TI web page.
I have Welec2022A already with low budget mod inside and latest 
firmware.

I understand that need to change (R13) to 390 kohm, R14 to 100 ohm & 
remove Ra and R21, R22, C12 and U3.

I don't understand the effects of this OPA653 upgrade on the external 
trigger. (I have original external trigger circuit)

von Blue F. (blueflash)


Lesenswert?

Hi Errico,

this seems to be a misunderstanding. There is no need to change the 
trigger circuit if you have an original OPA656 build in. As I wrote this 
is working properly. The only case in which I would recommend a 
replacement is if your OPA656 has a green point in one corner of the 
case (that is the sign for the fake).

In my W2022A are also working two OPA653 for the channels and one OPA656 
in the external trigger circuit.

If you want to improve your external trigger, there are some other parts 
that have to be exchanged (some capacitors, and one diode to bypass). 
The idea is from Jörg if I remember right, but there are some 
descriptions from me here in the hardware thread.

Regards

Hayo

: Bearbeitet durch User
von Errico (Gast)


Lesenswert?

Ok Hayo, I did not know that there is an op656 in the trigger circuit, 
I'm going to check if it is "good" or a fake device.

It seems to me (I'm not sure, mmmm) to have seen the component with the 
green dot in the two channels circuit, however I will replace these with 
the OP653's soon as they arrive from the USA ...

And yet I thought the fake version of OP656 should be present only in 
the 100 MHz DSO and not in the 200 MHz.

Ciao

Errico !

von Jörg H. (idc-dragon)


Lesenswert?

The green dots are not a reliable indication for bandwidth limited "fake 
chips".
The chips in my W2024 have green dots, too, but it's not limited. (At 
least I think so, I'm pretty sure I would have noticed.)

Jörg

von Blue F. (blueflash)


Lesenswert?

Errico schrieb:
> And yet I thought the fake version of OP656 should be present only in
> the 100 MHz DSO and not in the 200 MHz.

That is not for shure! The original TI-devices don't have a green dot 
and the case looks very different from the case of the fakes. So my 
suspicion is, that there are also 200MHz devices that have these faked 
parts with limited bandwidth (think they are cheaper and WELEC thought 
that no one will realize it).


@Jörg
Did You measure your frequency response? It might be interesting...


Hayo

: Bearbeitet durch User
von WWWelec (Gast)


Lesenswert?

Hello Jörg,

You are right but I suspect it may be due lack in the production line of 
the fake chips so someone it's better than other, they are fake though.
I have seen some 2012 that had inside what we can suppose to be fake 656 
(green dot) and their effectively bandwidth wasn't so bad compared to 
the non fake.
The problem I verified with them was in sensitivity, not in the bandwith 
limit.
When performing high frequency measures I  got smaller amplitude of the 
signal using 2012 (green dot 656) than 2022 (genuine 656), but bandwith 
was pretty close one another.
In short I have seen 2012 where their related bandwidth behaviour was 
pretty similar to 2022, only difference it was on the amplitude of the 
signal even with high frequencies near 200MHz where the attenuation 
would be greater talking about  ~100MHz devices.
My two cents.

Victor

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ich habe die Doku für die OPA653 Mod mal in eine anständige Form 
gegossen. Falls noch Fehler oder so drin sind bitte ich um Rückmeldung.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The english version is under construction and will be available soon.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Hayo

: Bearbeitet durch User
von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

moin Hayo,

("ans", statt "an das"?) :-)

Was ist das denn für eine zerknitterte Folie auf den Schirmblechen, 
bringt das was?

Sehr schöne Anleitung!!!

Gruß Michael

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Moin Michael,

das ist selbstklebende Kupferfolie. Etwas weiter oben habe ich einen 
Link zur Bezugsquelle gepostet (Conrad). Ich habe den Analogteil beider 
Geräte komplett abgeschirmt. Größere Lücken habe ich mit Blechen 
überbrückt, kleinere mit der Kupferfolie. In teureren Geräten ist sowas 
Standard, da der Analogteil sonst zum Radioempfänger mutiert. Es sieht 
nur etwas zerknittert aus, da ich die Folie für die Modifikation ja 
wieder entfernen mußte. Da kommt dann schon die eine oder andere Falte 
rein. Tut der Funktion aber keinen Abbruch. So wie auf dem Bild sieht es 
jetzt nach der OPA653 Mod aus. Zum Vergleich die Abschirmung meines 
W2014A mit Low Budget Mod.

Hayo

von Blue F. (blueflash)


Lesenswert?

Michael D. schrieb:
> "ans", statt "an das"?) :-)

Ahh, jetzt hab ich auch verstanden was Du meinst. Den Teil habe ich wie 
auch einige andere Passagen aus der LB-Mod übernommen ohne groß nach 
Fehlern zu suchen. Da steht es auch so drin. Naja etwas Umgangssprache 
lockert das Ganze etwas auf...

Hayo

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Well done!
What about the brass shield toward the power supply?
I have already read about it but I have been always unable to know its 
dimension, do you know them?
Good idea also the metal shield toward the serial connector.
I was thinking of doing such a thing.
For the serial side connector it would not be difficult while for that 
in the power supply side would be more complicated without knowing the 
size.
I would risk dangerous short circuits, that isn't good.
Buona Domenica.

Stefano

von Blue F. (blueflash)


Lesenswert?

Ciao Stefano,

information about the brass shield to the power supply is available 
here.

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

and in the wiki:

http://sourceforge.net/apps/trac/welecw2000a/wiki/Modifications

If I am informed right, there are no more parts left, so you have to 
build your own.

Hayo

: Bearbeitet durch User
von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, as promised here is the english version of the OPA653 modification.
All documents can also be downloaded on SFN:

http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/

Have fun with Your Mod

Hayo

von falcogiallo (Gast)


Lesenswert?

hi guys
in my opinion welec weakness is trigger not bandwidth
don't care bandwith when trigger is unusable
somebody confirm after this mod trigger become better usefull?
i understand it calm down also noise issue but if things are like before 
dso is pretty unusable
first need to fix trigger, then other things
i believe there aren't way to fix it because otherwise somebody did it 
already
sorry this in my opinion, play can't pay a candle

von Blue F. (blueflash)


Lesenswert?

Hi,

the normal trigger is working fairly well and is quite usable. Only the 
external trigger has some problems. It is not the OPA656 that is 
responsible for that. It is a combination of bad analog circuit design 
and a horrible FPGA implementation.

Jörg provided some modifications in the analog circuit of the external 
trigger to improve the sensitivity. Only some passive components have to 
be changed.


A comment to LB and OPA653 mod:

The improved bandwidth of my two devices combined with much less noise 
make them much more usable. For hobby purposes a nice and cheap 
equipment.

Regards Hayo

von falcogiallo (Gast)


Lesenswert?

good night
normal trigger works?
like with combi, auto and others set, signal is always dancing on the 
video and it is for the noise
unstable for noise on signal expecially with small signals and 1-2 
range, but also range 5
like is now is hard to use also for hobby
no matter how many megahertz bandwhidth, most important it is trigger 
stability
perhaps with few megaherts it is less dancing and usable but dance again 
there
sorry for the english is not my tongue, I asking about this dance of the 
signals on the screen
because is noise i know adc conversion can work better with the new mod 
that i ask if less noise help stability and stop the dance of the 
signals on the video
signal is not steady and also signals rappresentation is crude, very 
crude compared other instruments
you aspect sine when measure it and video show something is far to sine, 
a triangle at most
you only barely guess real shape
enought precision of the shape is only for slow megaherz and add filter, 
then bandwidth is limited, you do not need bandwidth but improved 
trigger and better shape
better shape not more like less noisy but like better draw of the 
signals
less noise is requested to stop signals dancing on the video who is 
annoying
you must put trigger level very high and amplitute depend on how much 
high it is
no other dso works like welec
amplitude do not depend on the trigger level and also the shape draw on 
video is not crude like welec
you must know i grateful for all improvements you made, i'm not a 
thankless
now the dso is very fast compared to before
now i know way to avoid spike with new design, improve bandwidth with 
mod, improve features with free software, improve ex trig with mod, but 
trigger is not stable enough and signal dance on the video
some things improve much better and are working fairly, but no trigger
all the things can not help if before trigger became steady, play can't 
pay a candle
this is my opinion
thanks

von Stefano M. (Gast)


Lesenswert?

Ciao Hayo.
Because I have purchased only OPA 653 I need OPA 656 now.
I can't understand exactly which though, because there are different 
types and IDBVT signature can't help me in the choice this time.
What exactly is the genuine OPA 656 inside Welec?
Which one should I buy?
Grazie!

Stefano

von Blue F. (blueflash)


Lesenswert?

Ciao Stefano,

the parts are labeled with "OPA656NB/250" on the package.

Hayo

von Luc (Gast)


Lesenswert?

Guten Abend Hayo und alle Unterstützer des Projekts WELEC!
Today I spent the afternoon modifying my Welec W2012A with OPA653 
operational amplifiers.
Here is my short notes about that.
Short because my Marconi 2019A is blew up during tests measure and by 
now I need a new ones and short also because sadly I am a bit hurry now: 
not so hurry, though. ;-)
OPA656s inside my W2012A were genuine OPA656s for channel 1 and 2, while 
it was fake OPA656 (green dot) for EXT-Trigger's circuit.
This confirm some of my previous measures because W2012A performances 
were close to W2022A ones, only few differences maybe due the not 
rightly compensated channels' input stages: I had found BW-3dB@ ~170MHz 
for W2012A and BW-3dB@ ~191MHz for W2022A both with first hardware 
improvement 24,9/150ohm and genuine OPA656.
Today after I finished I tried to repeat the measures, but sadly my 
Marconi 2019A get severe hardware failure while performing them.
For the little I could see noise is much reduced in range 5 and in range 
1 and 2 too.
Very impressed, by that also trigger stability is so much improved.
Now You do not have to worry about trigger level because amplitude drawn 
on the screen is indipendent by it.
Trigger level is still important in order to get steady waveforms on the 
screen though.
This is because even  if noise is little now, when waveforms's amplitude 
is not so much there it can interfere with the trigger stability.
I say well, very well Hayo: RESPECT!!!!!!
Talking about the analog bandwidth side, due hardware failure of my 
leveled signal generator I can only base my observations upon what I 
actually have been able to measure.
Maybe I am wrong, to be sure I must to wait the new leveled signal 
generator, but seems to me the real analog bandwidth using OPA653 
instead of OPA656 is now BW-3dB@ ~220MHz (~218MHz using a 300ps pulse 
generator with 0,35 Gaussian conservative value).
Unluckily even with new OPA653 I get the same issue I have already 
described in the past:

www.mikrocontroller.net/topic/133766#2535781

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Using new OPA653 not only the scale factor is wrong, even amplitude 
drawn on the screen it is so, I view and read roughly 4Vpp instead 
roughly 15Vpp who is the real value I have checked with high bandwidth 
calibrated DSO.
I also found a couple of weird things who I will not write here in the 
hardware forum.
I will report them in the firmware forum.
Make the modification it is easy, at least for me that I am accustomed 
to do similar things to work.
The hard part of the work is if You want to drill the metal chassis in 
order to get a  thermal improvement.
An other much important thing is the input stage's compensation.
I made it using my old Lyons Instruments PG-2B pulse generator who is 
maximum 10MHz and its rise/fall time is minimum 10ns.
In order to turn the capacitive trimmers I used a not inductive plastic 
screwdrive after having found that the small screwdrivers for the 
probes' compensation I own were too big.
Said this I think perhaps before apply the modification would be better 
wait others feedback, because seems to me only few people did it.
Low budget mod is easiest and perhaps it performances are not so far of 
the OPA653 modification ones.
Perhaps the residual noise with the Low Budget Mod is mildly higher than 
with the new OPA653 modification, so the latter is better but I do not 
sure about this.
Sadly I have not measure on Low Budget Mod, sorry about that.
Of course I have all necessary component for do it, but since I mainly 
work high-frequency I preferred the OPA653 modification.
Hayo, still again I have to thank You very much for all You do for the 
Welec community: RESPECT!!!!!!!
Keeping in touch.

Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des
Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Luc (Gast)


Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.
Letzte Nachrichten.
Heute habe ich einen neuen HF-Generator, es ist noch ein Marconi 2019A.
Ich war in der Lage, die Maßnahmen weiter und die Reaktion ist die 
folgende:
W2012A mit OPA653 aufgerüstet hat eine echte Bandbreite BW-3dB von 
~180MHz.
Von dem, was ich in der Lage, vor der Änderung zu messen nicht gibt es 
eine signifikante Erhöhung der Bandbreite Inbetriebnahme, wenn OPA653 
gelötet.
Wahrscheinlich Low Budget Mod kehrt das gleiche Ergebnis und ist viel 
einfacher.

So sadly there is not a real -3dB bandwidth improvement putting OPA653 
instead OPA656.
The W2012A on which I have been measured after changes it kept constant 
its original bandwidth ~ 170/180MHz, hard to exactly say due the shape 
drawn on the screen.
For your information I remember you that the W2012A I have modified 
already had the not fake OPA656 for channel 1 and 2.
Probably the Low Budget Mod returns the same results with less effort, 
it should be instrumentally verified.
BW-3db@ ~180MHz are not bad, but perhaps there you could expect more.
As always all I wrote is not intended as criticisms but only for 
knowledge.

Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des
Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Blue F. (blueflash)


Lesenswert?

Hi Luc,

nice to hear from you!

I will try to comment your posting:

> OPA656s inside my W2012A were genuine OPA656s for channel 1 and 2, while
> it was fake OPA656 (green dot) for EXT-Trigger's circuit.
Interresting combination. Seems that Wittigs choose their components as 
they are available...

> Unluckily even with new OPA653 I get the same issue I have already
> described in the past:
I think this is caused by the input stage adjustment which I described 
in the OPA656 mod. If the channels are not adjusted correctly (must be 
the same for 1/2/5 ranges), the amplitude of short signals as pulses may 
be wrong. This can be seen at the overshot of rectangle Signals too.

> Using new OPA653 not only the scale factor is wrong, even amplitude
> drawn on the screen it is so, I view and read roughly 4Vpp instead
> roughly 15Vpp who is the real value I have checked with high bandwidth
> calibrated DSO.
May be the same problem as above or the hardwaresettings are wrong or 
something went wrong with the mod (wrong resistances, too much 
tolerance?).
My DSOs have both correct Amplitudes.

> So sadly there is not a real -3dB bandwidth improvement putting OPA653
> instead OPA656.
On my DSOs there is a big difference between the OPA656 and the OPA653 
input stage. Don't forget, that the 3dB bandwidth of the original design 
is caused to the bad amplitude response with a much too high amplitude 
in the middle of the bandwidth (which leads to signal distortion). The 
actual mods have a much better Amplitude response. So bandwidth and 
bandwidth are two different things in this case.

Kind regards

Hayo

von Luc (Gast)


Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.
Nur als Referenz und zu Ihrer Information.
Gleiche wie vorher Marconi 2019A HF-Generator.
Dieses Mal habe ich gemessen der W2022A-date mit 24,9/150Ohm (alte edit) 
und das Ergebnis ist die folgende:

W2022A-date mit 24,9/150ohm aufgerüstet hat eine echte Bandbreite BW-3dB 
von ~191MHz.

Die W2022A haben die keine gefälschten OPA656.
Erneut verifiziert ich, dass die Gauß-Impulsantwort gibt den richtigen 
Wert der Bandbreite ohne die Notwendigkeit, ein HF-Generator.
Also studiere ich ein sehr einfaches Gerät und einfach zu bedienen, um 
die Bandbreite zu überprüfen.
Jim Williams Lawine Pulsgenerator, wie er in der Linear Application Note 
47 beschrieben, es ist leicht zu bauen, aber es ist vielleicht 
kompliziert, es braucht viele Komponenten und sogar eine 
Hochspannungsversorgung.
Ich bin auf der Suche nach etwas einfacher, wir werden sehen...;-)

Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des
Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Luc (Gast)


Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.

Glad to meet You again Hayo!

Hayo W. schrieb:
>Interresting combination. Seems that Wittigs choose their components as
>they are available...

I agree with You.

Hayo W. schrieb:
>I think this is caused by the input stage adjustment which I described
>in the OPA656 mod. If the channels are not adjusted correctly (must be
>the same for 1/2/5 ranges), the amplitude of short signals as pulses may
>be wrong. This can be seen at the overshot of rectangle Signals too.

Maybe it is so.
The point is I have tuned the compensation of the channels the best that 
I could do with 10ns rise/fall time square wave provided by my Lyons 
Instruments PG-2B pulse generator.
Perhaps the PG-2B pulse generator ran too fast due the fact it can 
generate pulse and do not generates continuous square waves, only 
impulses' sequences.
For this I was thinking to make a simple sub-nanosecond square wave 
generator.
Now I have the issue in all the range (1/2/5), in the past when I had 
first modification I had the problem only down the 500mV/div in range 1 
and 2 as I wrote in some post here in the hardware and firmware forum.

Hayo W. schrieb:
>May be the same problem as above or the hardwaresettings are wrong or
>something went wrong with the mod (wrong resistances, too much
>tolerance?).
>My DSOs have both correct Amplitudes.

Components are sure good and fine.
They are 1% resistors and originals TI OPA653.
Weldings are OK, no defective in any point, modestly I'm pretty good at 
soldering, I do it for work.
I could not do wrong welding or mistake placing of the components.
However I already check it more and more time, nothing is wrong.
We will see!  ;-)

Hayo W. schrieb:
>My DSOs have both correct Amplitudes.

Me too, I have it only with very fast rise/fall/span signals, for 
instance the Jim Williams' 300ps avalanche pulse generator described in 
AN47 by Linear.
As I know You need a such kind of thing in order to experience it.

Hayo W. schrieb:
>On my DSOs there is a big difference between the OPA656 and the OPA653
>input stage. Don't forget, that the 3dB bandwidth of the original design
>is caused to the bad amplitude response with a much too high amplitude
>in the middle of the bandwidth (which leads to signal distortion). The
>actual mods have a much better Amplitude response. So bandwidth and
>bandwidth are two different things in this case.

I have performed measures on W2012A and W2022A who they have the first 
modification (24,9/150ohm).
Their bandwidth response was almost flatness and both the Gaussian's 
response and Marconi 2019A was BW-3dB@ ~170MHz for W2012A not fake 
OPA656 and BW-3dB@ ~191MHz for the W2022A.
W2012A modified inserting OPA653 increase its bandwidth to BW-3dB@ 
~180MHz
That it is what I measured.
Perhaps I have to improve tuning compensation in the input channels' 
stages.
Because for what I know better would be perform it at 1MHz, and sadly my 
signal generator have unsuitable 100ns rise/fall time square wave as its 
better.
It is capable go up 2 MHz maximum and it is a very cheap equipment.
Here is not even a better amplitude's response for what I experienced, 
but again may be due a failure in the correct tuning of the input 
channels' stages.
I need to investigate it further.
Hayo, as I already stated, I wrote what I experienced and it is only for 
knowledge, never and nothing for criticism.

Also in this occasion, as always, I thank You very much Hayo for all 
your contributions and hard work You share with us, RESPECT!!!!!!!
See You later, keep in touch. ;-)
Nochmals vielen Dank Hayo!!!

Mit freundlichen Grüßen,

Luc

von Luc (Gast)


Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.
Bad luck haunts me, before RF generator get damage and now the computer 
has an hard disk failure.
Due the hardware problem of my computer now I am here through a very 
little netbook so I can not go into details, sorry about that.
However as I had anticipated yesterday, today I made a simple but 
efficient sub-nanosecond square wave generator.
It consist of few components and its heart is the LTC6905-133 
EconOscillator produced by Linear.
I choice  LTC6905-133 because due its high frequency it is suitable for 
bandwidth tests and it provide a sub-nanosecond rise/fall time square 
wave with roughly 50% duty cycle too.
It is also cheap and small because in SMD TSOT 23 package, so I put it 
togheter with one SMD 78L33 voltage regulator, two LESR electrolytic 
capacitors, two ceramic 0603 capacitors, two 1N4148 diodes and one 1% 
metal film resistors, inside a old Tektronik's BNC connector I have 
recovered emptying a faulty probe.
I even added a jumper with which I can choose three frequencies: 
133,333MHz, 66,666MHz and 33,333MHz.
As power supply I use a 9V transistor type dry battery.
When correctly it closed and matched through a 50ohm pass through load 
the waveform is good, pretty good flatness and very fast rise/fall time 
edge below 1ns (typically it is 500ps).
Of course the device is also suitable for tune the compensation of the 
input stage of the channels.
The amplitude of the output's square wave is roughly 145mV when closed 
on 50ohm keeping itself almost constant on all three switchable 
frequencies.
I retested the bandwidth of some known equipments and the results are 
identical to those that I get with the Marconi 2019A and from the 
Gaussian response using the Jim Williams' 300ps avalanche pulse 
generator that I own.
The simple and cheap device that I made it is a real 500ps rise/fall 
time for true, no joke.
Sadly this time I can not put screenshots and not even schematic diagram 
of the device, sorry about that.
You can get an idea of the performances and see the basic schematic 
diagram in the LTC6905-xxx datasheet on page number 8 
(http://cds.linear.com/docs/en/datasheet/6905xfa.pdf).
My design is just slightly different though.

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Luc (Gast)



Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.

I have partially repaired my computer, so here You go documentation 
about the device I have formerly described.
Due the fact in the past someone requested full informations about 
components, I add that in part list, even if I guess it is not so really 
important.
For me the only mandatory components are LowESR type for C2 and C4, X7R 
type for C5 and 1% metal film for R1.
About R1 in my design I chosen 1000ohm instead 950ohm because I had it 
to hand and because the power supply that I used in the device is not 
leveled and calibrated.
So does not matter if I divide it by 20(950ohm) or 21(1000ohm) because I 
can not know its exact value.
Using 1000ohm for R1 I get roughly 150mV for the output level.
For what I could see it works well.
Using it I have easily evaluated the bandwidth range of some device 
comparing the results I got using the Marconi 2019A sine generator which 
I have and it is a leveled and calibrated instrument.
Sadly my square wave generator is not suitable for tune the input stage, 
though.
This is what I experimented today.
It is not good for that because I guess it is too fast both as frequency 
than as rise/fall time.
Turning the variable capacitors in the input stage I could not get 
variations on the screen waveforms, nothing happens, so definitely it is 
not suitable in order to tune the channels' input stage.
Sadly again, no screenshot, sorry about that, it is for the hardware 
failure in my computer which I have not been able to completely fix: I 
should install the camera driver in order to take some pics of the 
screen of my 150MHz Hameg analog oscilloscope which is my reference here 
at home.
However the device's performances I achieved are identical at those 
descibed in the datasheet of the LTC6905-133 where you can see some of 
its waveforms.
Please, take a look also at pag 5 of AN98 
(http://cds.linear.com/docs/en/application-note/an98f.pdf)

Going beyond, I have not been able to find a solution for the behaviour 
of my W2012A who I have upgraded with OPA653.
I have checked again the modification but I do not found anything weird, 
so I have performed some measures on my W2022A in order to compare it, 
but sadly nothing again.
Only thing I got is that even in my W2022A OPA656 welded in the 
EXT-TRIGGER circuit is the fake green dot version.
So actually my W2012A was already a W2022A like the instrument I have 
which it is factory labeled as W2022A.
This explains to me why in my previous measurements the performances 
among my two instruments were pretty similar.
The greatest differences are in the level more than in the bandwidth and 
maybe it was due mismatch in the input stage tuning.
Indeed I wrote in the past about the mismatch among the channels 
amplitude and shape of the waveforms on each of them.

Hayo W. schrieb:
>On my DSOs there is a big difference between the OPA656 and the OPA653
>input stage.

Maybe because You had the fake OPA656 in W2014A.
I had the good ones in my W2012A, so I have to play with a minor 
difference, even if OPA653's performances are almost twice compared the 
good OPA656.
I do not know how to think about that.
From what I can measure on my two instruments seems to me the bandwidth 
decrease fast after about the 160MHz.
I can see it using the Marconi 2019A, the Jim Williams' 300ps pulse 
generator and now also with my homemade 500ps rise/fall time 
133/66/33MHz square generator.
And I see it both with OPA653 and OPA656 inside the instrument, namely 
on W2012A using OPA653, W2012A using not fake OPA656 and last the W2022A 
using not fake OPA656.
Of course talking about measures performed on modified units 
(24,9/150ohm and OPA653 upgrade), not factory ones.
I am confident in my instruments, especially on Marconi 2019A which is a 
leveled and calibrated equipment.

Hayo W. schrieb:
>I think this is caused by the input stage adjustment which I described
>in the OPA656 mod. If the channels are not adjusted correctly (must be
>the same for 1/2/5 ranges), the amplitude of short signals as pulses may
>be wrong. This can be seen at the overshot of rectangle Signals too.

Returning on this, today I performed some verifications without finding 
a reliable solution.
Seems You are right, effectively it can improve a bit with the accurate 
tuning of the inputs stages.
I tried also on W2022A which have original hardware and only 24,9/150ohm 
modification, but sadly I have not come to anything.
All things being equal the perfomances of the W2022A with the original 
not fake OPA656 performs slightly better than the 2012A with the OPA653 
modification.
Slightly but there is a difference.
I wonder what is wrong.
Weird, really weird.
Could the OPA653s be broken?
I do not know.
I am pretty sure they are TI's parts, not fake ones.
Please, take care on the fact I am not blaming anybody nor I want to 
criticize or argue, I'm just stating the facts.
As always it is only for knowledge, not criticism.
I hope to have been understandable, thanks.

Vielen Dank an alle Unterstützer des Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Luc (Gast)


Lesenswert?

Gute Nacht, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.

@Hayo
I need your help, so here some questions for You.
In order to better understand the matter I have looked again at your 
documents about Low Budget Mod and OPA653 Mod.
Inside them there are drawings which show the trend of the frequency 
response, namely the behaviour of the devices under test at different 
frequencies and hence their bandwidth.
W2022A and W2014A with the Low Budget Mod both behave in a similar way 
and this is obvious.
Of course SDS8102 remains unchanged for both diagrams, it is for 
reference only.
Have been both the diagrams obtained with the same zero line gain 
adjustment?
In order to set the correct offset I guess You have adjusted the 
instruments with a known frequency and level sine wave generated by 
Leader 3216, what were they (frequency value and its level)?
I want try to sample the same frequencies with my Marconi 2019A in order 
to plot my own diagram and compare it with the your.
I suspect I could have an offset problem due the fact I have a lack in 
the gain's regulation, so I would like to repeat the measurements using 
the your settings.
Thanks in advance Hayo.

Nochmals vielen Dank Hayo und Vielen Dank an alle Unterstützer des
Projekts Welec!

Mit freundlichen Grüßen,

Luc

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Mal zur Info:
Für die OPA653 Modifikation habe ich diesen mal bei TI geordert.
Den gibt es in 2 verschiedenen Gehäusen mit 8Pin und 5Pin.
Wer das Welec noch nicht offen hatte, sollte vorher unbedingt hier 
nachschauen:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

damit man das richtige Gehäuse ordert!

Das Gehäuse nennt sich DRV Package SOT23-5
Die Partnumber von TI lautet dann OPA653IDBVT

Einen guten Start ins neue Jahr, wünsche ich allen

Gruß Michael

EDIT: Damit es nicht langweilig wird, 2Pics im Anhang

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Viel Erfolg beim Umbau. Ich bin gespannt wie Du das Ergebnis bewertet.

By the way - um noch einmal Missverständnissen vorzubeugen:

Das primäre Ziel der Mod ist nicht die Vergrößerung der Bandbreite. Es 
ist möglich, dass diese tatsächlich größer ist hinterher, aber hierzu 
habe ich keine wirklich verlässlichen Messungen gemacht. Die technischen 
Eckdaten der Bauteile lassen jedoch vermuten, dass sich hier eine 
Verbesserung ergibt.

Die primären Ziele sind:

- deutliche Verbesserung des SNR (Signal- Rauschabstand)
- Linearisierung des Frequenzgangs

Ich denke diese Ziele wurden angesichts des relativ geringen Aufwandes 
recht gut erreicht.

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

> Viel Erfolg beim Umbau. Ich bin gespannt wie Du das Ergebnis bewertet.
Danke! ;-)
> By the way - um noch einmal Missverständnissen vorzubeugen:
Für mich war/ist das verständlich...


> Die primären Ziele sind:

> - deutliche Verbesserung des SNR (Signal- Rauschabstand)
> - Linearisierung des Frequenzgangs
Das ist der Plan!

> Ich denke diese Ziele wurden angesichts des relativ geringen Aufwandes
> recht gut erreicht.
Der Luc (glaube ich) hat das bestätigt!

Gruß Michael

Mal sehen, wann die Teile eintreffen.
Nach der MOD. werde ich dann mal vorher/nachher Pics einstellen, wenn 
das klappt ;-)

von Welecfan (Gast)


Lesenswert?

Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber
trotzdem immer noch Schrott.

von Jörg H. (idc-dragon)


Lesenswert?

Hallo,

mein Welec ist seit Jahren erstmals wieder zu. (Rächt sich auch prompt, 
der LCD-Stecker hat einen Wackelkontakt, aber das ist ein anderes 
Thema.)

Wo ich schon mal am Schrauben war hat das Gerät noch ein paar Mods 
abbekommen:

Den JTAG habe ich durch einen Lüftungsschlitz unauffällig in die 
Griffmulde rausverlängert. So ist der auch bei geschlossenem Gerät 
zugänglich. Es geht zwar auch über USB, den internen Chip zu einem 
Blaster zu machen, aber der echte ist schneller.

Ich habe die Drehgeber (bis auf die für Amplitude und Zeitbasis) durch 
vernünftige Modelle von Alps ersetzt. Fühlt sich gut an, nicht mehr 
wabbelig. Für die Offsetregler habe ich welche ohne Rastung genommen 
(Poti-Feeling), für die anderen zart rastende mit zusätzlicher 
Tastfunktion. Die Taster habe ich an freie Eingänge des letzen 
Frontpanel-Schieberegisters angeschlossen, das neue FPGA-Design kann die 
abfragen. Ist bestimmt mal nützlich.

Was mir auch immer ein Dorn im Auge war: ich habe die LEDs des 
Frontpanels nun auf etwa gleiche Helligkeit getrimmt. Die hatten alle 
den gleichen Wert von Vorwiderstand, ungeachtet der Farbe. Grün war zu 
dunkel, und blau (beim 4Kanäler) viel zu dunkel. Mit 220 Ohm parallel 
draufgelötet bei Grün und 100 Ohm bei Blau sieht es prima aus. Die 
Ströme sind noch im zulässigen Bereich, keine Sorge. Mit dem neuen FPGA 
könnte ich euch eine PWM-Helligkeitssteuerung spendieren, es gibt da 
einen ungenutzten Enable-Eingang der auf alle Ausgänge wirkt. Sprich, 
die LEDs wären global einstellbar, aber nicht individuell.

Muß ich wohl alles noch dokumentieren...

Jörg

: Bearbeitet durch User
von Michael D. (mike0815)


Lesenswert?

Ich bins... ;-)

Ich habe hier ein paar FTDI-Module mit TTL-Pegel Ausgang rumliegen und 
würde eines gerne als Ersatz für die am Welec vorhandene RS232 
Schnittstelle verwenden.
Die RS232 vom Welec bekommt ja vom PC Anschluß einen höheren Pegel.
Wie kann ich das mit dem TTL-Pegel realisieren?

Gruß Michael

von Jürgen (Gast)


Lesenswert?

Hallo zusammen,

ich habe mein W2024A mit Hayo's LB-Mod umgerüstet.
Hayo hat seine Kanalabschirmungen ja mit selbstklebender Kupferfolie 
verbessert. Das Zeuch ist mir aber zu teuer.
Deshalb habe ich mir aus Weißblech (Konservendose) kleine Abschirmhauben 
mit der Breite der vorhandenen Abschirmhauben
über die freiliegenden Mittelanschlüsse der BNC-Buchsen gelötet. (Schräg 
von Oberkante vorhandene Abschirmhaube zum Platinenrand)
Zumindest bilde ich mir ein, daß das Signal dadurch noch ruhiger 
geworden ist :-)

Ein kleiner Fehler im Bild 11 der Doku zur LB-Mod:
Wenn ich den Stromlaufplan der Eingangsstufen richtig lese, ist die 
Aufteilung der Bereiche zum Abgleich der C's unter den Abschirmhauben 
10,20,50mV , 100,200,500mV und 1,2,5V.
Das bedeutet, daß 10mV(20mV,50mV) Bereich an den KOndensatoren nichts 
abzugleichen ist. Danach wird mit C7 (obere Abgleichöffnung) der 100mV 
Bereich abgeglichen. Zum Schluss wird
an C1 (untere Abgleichöffnung) der 1V Bereich abgeglichen, ohne am 
oberen wieder etwas zu verstellen!
Die Beschriftung sollte in Bild 11 also eher sein: oben 100mV - Bereiche 
und unten 1000mV - Bereiche.

Die Wirksamkeit der LB-Mod hat sich jedenfalls vollauf bestätigt!

Gruß
Jürgen

von Jürgen (Gast)


Lesenswert?

noch eine kleine Ergänzung zu einem Problem mit der DAC-Ansteuerung aus 
dem letzten Jahr an meinem W2012A.
Ich hatte hier

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Fehler in der Software Versionen ab 6.0 angesprochen.
Hayo konnte dies aber nicht bestätige.
Darauf habe ich das Gerät von 1C9.xx  auf Verson 8C7.0H umprogrammiert.
Damit waren die oben genannten Probleme verschwunden!
Das zeigt den großen Einfluß unterschiedlicher FPGA-Versionen.

VG
Jürgen

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hallo Jürgen,

schön zu hören, dass der Umbau bei Dir erfolgreich war. Die FPGA-Version 
1C9.xx hatte meines Wissens auch heftig mit Spikeproblemen zu kämpfen. 
Die
8C7.xx Versionen sind da wohl etwas stabiler.

Was die Abgleichkondensatoren angeht - der Abgleich hat so wie in der 
Anleitung beschrieben bei mir gut funktioniert. Kann aber sein, dass Du 
recht hast. Ich hatte einfach etwas ausprobiert und nach Ursache und 
Wirkung dann ein für mich brauchbares Ergebnis eingestellt.


> Deshalb habe ich mir aus Weißblech (Konservendose) kleine Abschirmhauben
> mit der Breite der vorhandenen Abschirmhauben
> über die freiliegenden Mittelanschlüsse der BNC-Buchsen gelötet.

Ich habe ebenfalls noch freie Bereiche auf der Analogseite mit 
Abschirmblechen überdeckt. Das bringt sicherlich in besonders 
Störungsbelasteten Bereichen des Arbeitstisches einen Vorteil bei der 
Messung. Auf dem Bild bei meinem W2022A.

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

hm, habe ich da jetzt was dämliches gefragt, oder wurde ich nur 
übersehen?

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Hi Michael,

nein, nicht übersehen (zumindest nicht von mir). Nur konnte ich nichts 
sachdienliches beisteuern. Aber was mich interessieren würde - warum 
willst Du die austauschen?

Hayo

von Michael D. (mike0815)


Lesenswert?

Die Seriellen Schnittstellen werden bei den heutigen Computern immer 
rarer! Laptops haben gar keine mehr. Die RS232 Adapter mit 9V Pegel am 
Ausgang, sind nicht billig, dazu noch sperrig. Die PL2303 (für "kleines" 
sind meistens Fakes) und jetzt habe ich die Nase voll.
Das FTDI-Modul ist winzig klein, kostet etwas über 1€ beim Chinamann, 
funzen einwandfrei und würde da wunderbar reinpassen...deswegen.

Gruß Michael

EDIT: Das da noch keiner drauf gekommen ist, wundert mich etwas.
Mit der JTAG-Alternative für das FW-Proggen, kann man ja keine 
Screenshots machen, oder?

von Luigi (Gast)


Lesenswert?

Hello everyone.
I did the OPA653-mod but I have a problem now: I'm unable to adjust 
inputs.
First, maybe I haven't the right screwdriver but turning the capacitive 
trimmers nothing happens, waveforms on the screen are still as before 
the adjustment.
Is here somebody who can show what kind of screwdriver or tool he used 
in order to perform the adjustment?
Explain the dimensions or better provide part number, brand or 
commercial type of what he use and which fit well with Welec?
I'm pretty sure the capacitor's armors turn when I adjust them but 
nothing happens.
I know what Jürgen wrote about mismatch between Welec's schematic 
diagram and OPA653-mod's manual for the correct sequence to be observed 
in order to get good results, but still no change.
For the adjustment I have a VC2002 Function Generator from Victor which 
perhaps is not suitable for that job due its not optimal rise/fall time 
characteristic, though some change should still be noticeable.
Isn't so?
I'd like to spend part of my holiday by repairing my old dso.
Can somebody help me?
Grazie!

Luigi (ITALY)

von Blue F. (blueflash)


Lesenswert?

Hi Luigi,

today I'm a little bit out of time, because I'm sailing in the ionian 
sea (greece), but I will try to help you as good as I can. First, the 
screwdriver I used is from Tectronix and made of plastic. Did you 
resolder the contacts of the adjusting capacitors? They seem to be 
solderd not very good. Then the next points:

- you have to use the right signal -> square with rise time 15 - 10ns
- use the correct timebase, play a little bit with the settings until 
you see an overshooting on the rising edge

I will be online again tomorrow if the next harbor has WIFI.

Regards Hayo

von Luigi (Gast)


Lesenswert?

Hello Hayo.
You are very lucky if as I understand you are cruising around the ionian 
sea near Greece.
Instead for me it's the usual busman's holiday.
OK for the Tektronix's plastic screwdriver.
I know somebody wrote here about something like that.
Me too I have that kind of tool but seems it doesn't fit into the head 
of the Welec's capacitive trimmers in my 2012A.
Maybe those inside my Welec are slightly different, I don't know.
I'd like to see one pictures of the screwdriver so that I can get an 
idea, or even just know  their part number.
The welding of the adjusting capacitors in my unit were already OK, I 
tried to re weld them but nothing happened, though.
I have read about that issue for the adjusting capacitors and it isn't 
the case for me.
As I already knew my Victor is unable to do the job correctly, it's only 
a cheap 100ns R/F time device.
Grazie e buona crociera!
(Thanks and have you a good cruise!)

Luigi

von Errico (Gast)


Lesenswert?

Hello! I am looking for a text with external trigger mod, there is also 
a BOM ?
Thanks
Errico

von Blue F. (blueflash)


Lesenswert?

Hi Errico,

I tried to find some documentation describing the external trigger mod. 
The mod has been published by Jörg as a post in this thread (if remember 
right) and a little bit later I provided some pictures. But this is a 
little time ago. Do you know those pictures? I marked and labeled the 
parts which have to be changed in this pictures.

If needed I can post them here again. Let me know...

Hayo

von IZ2EIB (Gast)


Lesenswert?


von Errico (Gast)


Lesenswert?

Many thanks Hayo, grazie Fabio !
The references are very precise, sometime ago I made the mod with OPA653 
and it works very well and I installed also the latest firmware 6.8.
Now, however, I wanted to measure the delay between two events (few ms) 
using the two channels and external trigger, but it does not work as it 
should. I can not lock the track to the second event. It seems to me 
that the original external trigger does not work at all, I used DC 
coupling (ext). The trigger pulse was a signal of 12v

Many thanks Hayo and others for your efforts
Errico

von Blue F. (blueflash)


Lesenswert?

Aahh, Fabio thanks for the links. Those posts I ment. And I can confirm 
that the external trigger is working much better with this mod. So if 
you need to use the external trigger more often I would recommend to do 
the mod.

Hayo

von Max M. (vcc)


Lesenswert?

Hallo zusammen,

ich versuche grade mich durch die zahlreichen Beiträge zu den Welec-DSO 
durchzuwurschteln, weil ich ein Problem mit meinem W2022 (ohne A) habe. 
Mein Problem ist, dass das Ding nicht so funktioniert wie es eigentlich 
zu erwarten wäre - also wie ein DSO. Deswegen habe ich ihn auch so 
selten verwendet.

Nun - die Ursache des Problems weiß ich inzwischen - es liegt wohl 
daran, dass das Gerät noch im ORIGINAL-Zustand ist!!! So ein Dreck...

Was ich bisher gelesen habe - Hayos FW soll um einiges besser sein als 
die originale. Es gibt auch HW-Umbauten, die den Frequenzgang verbessern 
etc... Hayo und überhaupt die ganze Community hat bei diesen Geräten 
super Arbeit geleistet!!! Respekt!

Ich schwanke gerade zwischen der Entscheidung ihn bei iBäi reinzustellen 
oder eben zu verbasteln und weiter zu "benutzen". Equipment/Ausstattung 
und das können für die Umbauten hätte ich wahrscheinlich...

a) Kann man denn das Modell W2022 (ohne A) überhaupt FW-updaten?
b) Kann man denn das Modell W2022 (ohne A) überhaupt HW-upgraden?
c) Wenn ja - welche Änderungen wären möglich?
d) Wo kann ich Update/Upgrade-Infos bekommen, die mein DSO betreffen?
e) Was ist der Unterschied zwischen Geräten mit und ohne A?

Ich habe mir die ganzen Threads augedruckt (Ja - auf Papier!), aber es 
ist einfach zu viel - ich steige allein nicht durch...

Hoffe ihr könnt mir helfen und verhindern, dass ich den Skop verhökere.
Danke im voraus und Grüße
vcc

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Hallo Max,

ja Du hast recht, die Threads zu diesem Thema sind wirklich sehr lang. 
Die haben sich über mehrere Jahre aufgebaut und sind daher etwas 
unübersichtlich. Um dem abzuhelfen wurden extra ein Wiki dazu 
eingerichtet in dem auch beschrieben wurde was zu tun ist wenn man 
Besitzer eines W20xx ohne A ist. Leider scheint dieses Wiki seit einiger 
Zeit offline zu sein.

Ich gebe hier also mal das zum Besten was ich noch zu dem Thema weiß. 
Evtl. kann einer der anderen alten Hasen hier genauere Infos beisteuern.

Also erstmal: die Version ohne A kann nicht einfach mit der BF-Firmware 
upgedatet werden. Das führt zu einem nicht mehr funktionierenden Gerät.

Also bitte nicht ausprobieren!

Grund ist der Inhalt des FPGA. Die Register und Hardwareadressen stimmen 
anscheinend noch nicht mit der späteren A-Version überein.

Diesem Umstand kann man mit einem Update des FPGA abhelfen. Ob noch 
weitere Eingriffe an der Hardware selbst nötig sind weiß ich leider 
nicht mehr. Auf jeden Fall wurden wohl einige Geräte auf diese Art und 
Weise in den Kreis der A-Versionen befördert. Ich muss mal in meinen 
Unterlagen stöbern ob ich die Anleitung noch finde.

Wenn Du das Gerät behalten möchtest ist das die einzige sinnvolle 
Möglichkeit um das Gerät benutzbar zu machen. Neben den zahlreichen 
Hardwareverbesserungen die hier im Thread vorgestellt wurden bietet der 
Update auf die selbstgeschriebene Firmware einen echten Mehrwert. Das 
Gerät verfügt dann über zahlreiche neue (und korrigierte alte) 
Funktionen.

Gruß Hayo

von Max M. (vcc)


Lesenswert?

Hallo Hayo,

danke für die schnelle Antwort.
Ich würde daran gern rumbasteln, daran solls nicht scheitern.
Habe in einem russischen Forum folgende Anleitung gefunden
natürlich vom mikrocontroller.net ;)

http://www.mikrocontroller.net/attachment/55261/Upgrade_W2012_auf_W2012A.pdf

Laut dieser Anleitung ist der Upgrade nicht schwer.
Scheint als ob ich für dafür den Flash-Inhalt vom FPGA eines W2022A 
bräuchte - in diesem Fall also die Datei EPC16_W2022A.jic
Das ganze Altera-Zeuch habe ich da.
Allerdings sind die Daten vom google groups wohl futsch... Schade.
Kein Plan wo ich das runterladen kann.

von Blue F. (blueflash)


Lesenswert?

Ach ja, eine Frage die ich eigentlich sonst immer gleich stelle, aber 
diesmal irgendwie vergessen habe:

Bist Du Dir sicher, dass Dein Gerät eine Version ohne A ist?
Denn auf dem Gehäuse steht auch bei den A-Modellen kein A drauf (bei den 
meisten jedenfalls nicht). Meine beiden Geräte haben auch ein 
Gehäuselabel ohne A.

Wenn ich mich recht erinnere war ein Unterschied zwischen den Modellen, 
dass die F1/F2-Tasten bei den alten Modellen ohne A nicht bzw. anders 
belegt waren.

Das könntest Du also mal ausprobieren. Die Kombination F1 halten und F2 
kurz drücken sollte den Monitormodus starten (Bildschirm wird kurz weiß 
und dann schwarz). Die Kombination F2 halten und F1 kurz drücken sollte 
einen Reset auslösen, so dass das Gerät neu startet. Wenn diese 
Funktionen nicht bei Dir vorhanden sind hast Du ziemlich sicher eine 
Version ohne A.

Gruß Hayo

von cc (Gast)


Lesenswert?

Hallo,

kann man eines dieser DSOs noch irgendwo kaufen? Bzw. gibt es noch 
andere, bessere DSOs mit Open Source firmware?

Danke

von Blue F. (blueflash)


Lesenswert?

Ah, Du hast in der Zwischenzeit auch gepostet, ja genau die Beschreibung 
meinte ich. Im Wiki standen glaube ich noch einige Kleinigkeiten, aber 
das Wesentliche war diese Anleitung.

Den Inhalt der Chips kannst Du auf jeden Fall auch hier von einem von 
uns bekommen. Hier gilt es die richtige Hardwareversion zu nehemn, da 
einige spätere Versionen extreme Probleme mit Spikes hatten. Als recht 
brauchbar haben sich die 8C7.xx Versionen erwiesen. Ich kann Dir gerne 
die Dateien meines W2022A(8C7.0G) zur Verfügung stellen.

Gruß Hayo

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

dann will ich mal schnell aushelfen.
Hier eine Sicherheitskopie von meinem W2022, ist fast genau 2MB groß !

viel Spass damit ;-)

Hayo, du lebst ja noch, viele Grüße in den Norden

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

cc schrieb:

> kann man eines dieser DSOs noch irgendwo kaufen?
Zwischenzeitlich tauchten diese DSOs immer wieder als Neugeräte bei Ebay 
auf. Die Firma Welec hat wohl immer noch Restbestände. Also immer mal 
wieder suchen.

Ansonsten habe ich die auch oft schon gebraucht dort gesehen. Einige 
wissen nicht, dass es bessere Firmware für das Gerät gibt, sind 
frustriert und verkaufen das Gerät günstig :-)


> Bzw. gibt es noch
> andere, bessere DSOs mit Open Source firmware?

Mir sind keine bekannt.

Hayo

von Blue F. (blueflash)


Lesenswert?

Michael D. schrieb:

> Hayo, du lebst ja noch, viele Grüße in den Norden
>
> Gruß Michael

Moin, moin ;-)

Auch wenn ich momentan nicht an der Firmware arbeite habe ich die 
Threads hier ständig im Blick. Evtl. geht es ja auch bei Jörg irgendwann 
weiter.

Ich selbst habe als sehr interessantes Thema zur Zeit für mich den nicht 
ganz bestimmungsgemäßen Gebrauch von DVB-T Sticks entdeckt (Stichwort 
SDR). Es ist schon erstaunlich was man damit alles anstellen kann. 
Alleine damit könnte ich schon wieder einen neuen Thread füllen...

Gruß Hayo

von IZ2EIB (Gast)


Lesenswert?

Hi Max,

Max M. wrote:
> a) Kann man denn das Modell W2022 (ohne A) überhaupt FW-updaten?
> b) Kann man denn das Modell W2022 (ohne A) überhaupt HW-upgraden?
> c) Wenn ja - welche Änderungen wären möglich?
> d) Wo kann ich Update/Upgrade-Infos bekommen, die mein DSO betreffen?
> e) Was ist der Unterschied zwischen Geräten mit und ohne A?

please carefully follow what Hayo wrote.
Once you are sure your DSO isn't the "A" type, then you can go ahead.
Michael D. has provided you with the needed .jic file in order to 
upgrade the FPGA.
You already have one document which explain how you have to proceed.
However here you go also what is remaining now of the Wiki which 
describes what you need to do, what you need as extra and how use all 
those things:

http://web.archive.org/web/20120119061851/http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade

After doing the upgrade, if you wish it,  you can surely deal with the 
other hardware modifications described in the forum.
Good luck!

Regards,

Fabio

von IZ2EIB (Gast)


Lesenswert?

Ciao Errico,

Errico wrote:
> I made the mod with OPA653 and it works very well and I installed also
> the latest firmware 6.8.

I fully agree.
Me too I did it.
Sadly I had trouble with the capacitive trimmers.
Indeed actually no one of them worked in my instrument.
The armors were blocked.
When turning their philips screw head nothing happened and in the end 
they are all broken so I haven't been able to perform input stage 
compensation.
Now I'm waiting for the spare parts in order to fix the DSO.

Errico wrote:
> I wanted to measure the delay between two events (few ms)
> using the two channels and external trigger, but it does not work as it
> should. I can not lock the track to the second event. It seems to me
> that the original external trigger does not work at all, I used DC
> coupling (ext). The trigger pulse was a signal of 12v

In my humble opinion, surely after the modifications the EXT Trigger 
work better than before and ever, but honestly it worked well even 
without modifications, just it was more tricky to use.
From my experiences with Welec better results are achieved using normal 
trigger.
Pulse trigger too works better using that kind of setting.
So please try it, even if it's maybe possible you are dealing with low 
and noisy signals which aren't easily managed by Welec EXT Trigger 
without hardware modifications.

Regards,

Fabio

von IZ2EIB (Gast)


Lesenswert?

Hi Dr. Engineer  Hayo,

Hayo W. wrote:
> I can confirm  that the external trigger is working much better with this
> mod.

Me I fully confirm it too!

> So if you need to use the external trigger more often I would recommend
> to do the mod.

I fully agree.

Hayo W. wrote:
> Ich selbst habe als sehr interessantes Thema zur Zeit für mich den
> nicht ganz bestimmungsgemäßen Gebrauch von DVB-T Sticks entdeckt
> (Stichwort SDR). Es ist schon erstaunlich was man damit alles anstellen
> kann.
>Alleine damit könnte ich schon wieder einen neuen Thread füllen...

A kinda OT here.
I can't do anything else but agree also with this.
Indeed as radio-amateur I know pretty well what you are talking about.
DVB-T Sticks are an easy and cheap way to achieve instruments like 
Automatic Noise-Figure Meter, Spectrum Analyzer, and of course wide band 
multi mode receivers and scanner receivers.
That kind of devices lend themselves to a variety of applications, 
especially those that can be unlocked via software, so that in the end 
they are a paradise for those who know how to program.
Sadly I'm not so good like programmer, so I find myself in hell rather 
than in heaven.
But I know you also love analog receivers and me too I love them!
Apologize me for the OT.

Regards,

Fabio

von Max M. (vcc)


Angehängte Dateien:

Lesenswert?

Danke euch allen für eure Hilfe! Ihr seid supergeil ;)
Also folgendes möchte ich berichten:

Hayo W. schrieb:
> Bist Du Dir sicher, dass Dein Gerät eine Version ohne A ist?
> Denn auf dem Gehäuse steht auch bei den A-Modellen kein A drauf (bei den
> meisten jedenfalls nicht). Meine beiden Geräte haben auch ein
> Gehäuselabel ohne A.

Tatsächlich ist mein Skop mit A, obwohl auf dem Gehäuse die Nummer ohne 
A steht (s. Fotos). Habe mich auf die schnelle täuschen lassen. Habe 
dann natürlich sofort BF Update gemacht (vorher natürlich komplett dump) 
und es läuft!!!
Hab auf die schnelle paar Funktionen ausprobiert - es ist tatsächlich 
nicht zu vergleichen mit der Original-FW - viel besser!!!

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Noch besser. Der Link zum Webarchiv zeigt eigentlich schon alles.
(@Fabio - Mille grazie for the link to the web-archive)

Du hast also alles was Du brauchst. Ich bringe das hier noch mal auf den 
Punkt:

- Erst mal sicherstellen, dass Du wirklich ein altes W2022 ohne A hast
- dann die Datei von Michael mittels Altera Tools ins Gerät brennen. 
Wenn Du den Altera Blaster Dongel hast (gibt es bei Ebay für wenige 
Euros als Nachbau) brauchst Du nicht den Blaster Driver von Slog zu 
installieren sondern kannst den Dongel direkt auf der Platine in die 
Pfostenleiste einstecken. Bilder und Anleitung gibt es auch hier in 
einem der Foren. Ich glaube in Jörgs Thread "Made from the Scratch".
- wenn das FPGA auf dem aktuellen Stand ist, sollen wohl die Pins 15/16 
der Schieberegister (U21/U23 - MC14094B) verbunden werden, zu entnehmen 
aus dem Schaltplan. Ich habe mal die aktuellere Version mit hochgeladen.
Wenn Du zum Vergleich Fotos von der Platine eines W2022A brauchst - kein 
Problem

Jetzt solltest Du ein W2022A haben und kannst die BF-Firmware aufspielen 
und auch alle weiteren Hardwaremods durchführen. Den Firmware Update 
aber nicht mit dem originalen WELEC Tool durchführen sondern über die 
RS-232 mit den mitgelieferten Kommandozeilen-Tools. Anleitung liegt dem 
Firmwarepaket bei.


Gruß Hayo

: Bearbeitet durch User
von Max M. (vcc)


Angehängte Dateien:

Lesenswert?

Hier das zweite Bild mit BF!
Den Blaster usw. habe ich alles, hat sich aber wohl erledigt.

Danke euch noch mal!
Wenn ich irgendwie mit der Entwicklung helfen kann, steht mein Skop 
natürlich zur Verfügung

Grüße
vcc

von Blue F. (blueflash)


Lesenswert?

Na da habe ich ja wieder parallel gepostet. Macht nix, dann haben wir 
aber die Anleitung jedenfalls parat falls noch jemand danach fragen 
sollte. Für Dich ist es dann ja sehr einfach gelaufen.

Ich weiß nicht, ob Du schon alles ausprobiert hast, aber da sind diverse 
Anleitungen und Beschreibungen mit im Paket drin. Unter Anderem zur 
Nutzung der Screenshot-Funktion, die mir schon sehr oft nützliche 
Dienste geleistet hat.

Viel Spaß Hayo

von Max M. (vcc)


Lesenswert?

Hayo W. schrieb:
> Na da habe ich ja wieder parallel gepostet. Macht nix, dann haben wir
> aber die Anleitung jedenfalls parat falls noch jemand danach fragen
> sollte. Für Dich ist es dann ja sehr einfach gelaufen.

Ja - habe ich auch eben gesehen...
Da ich das nun angefangen habe, würde ich nun auf jeden Fall auch die 
HW-Mods machen. Habe deine Dokus überflogen und seh ich das richtig, 
dass der OPA653-Umbau für die 100MHz-DSOs gedacht ist und meinen nicht 
betrifft?

Dann würde ich wg. Rauschverhalten und Amplitudengang den LB-Mod machen.
Danach dann die thermische Verbesserung.

Gruß
vcc

von Blue F. (blueflash)


Lesenswert?

@Fabio

Although it is a little bit OT here - I had some very interesting 
projects with DVB-T sticks with E4000 and R820 chips. I built devices 
with upconverters for LW/MW/SW and also I realized a low budget ADS-B 
flight radar which is working as good as a much more expensiv device. 
I'm monitoring the hole northern germany flight movements with the free 
adsbSCOPE software and a DVB-T stick :-)

Hayo

von Blue F. (blueflash)


Lesenswert?

Max M. schrieb:
> Habe deine Dokus überflogen und seh ich das richtig,
> dass der OPA653-Umbau für die 100MHz-DSOs gedacht ist und meinen nicht
> betrifft?

Nein, das ist so nicht ganz richtig. Bei einem 100MHz Gerät ist der 
Gewinn nur einfach sehr viel größer als bei einem 200MHz Gerät. Es 
bringt aber auch eine ganze Menge. Mein W2022A ist auch mit OPA653 
ausgerüstet.

Ich würde Dir empfehlen die OPA653 als kostenlose Samples zu bestellen. 
Hat bei einigen hier super geklappt.

Gruß Hayo

von Max M. (vcc)


Lesenswert?

Hayo W. schrieb:
> Nein, das ist so nicht ganz richtig. Bei einem 100MHz Gerät ist der
> Gewinn nur einfach sehr viel größer als bei einem 200MHz Gerät. Es
> bringt aber auch eine ganze Menge. Mein W2022A ist auch mit OPA653
> ausgerüstet.

OK, dann mache ich das auch.
Existiert eigentlich ein richtiger bzw. kompletter Schaltplan von den 
Geräten? Wenn ja, kann man den irgendwo bekommen?

von IZ2EIB (Gast)


Lesenswert?


von IZ2EIB (Gast)


Lesenswert?


von IZ2EIB (Gast)


Lesenswert?


von IZ2EIB (Gast)


Lesenswert?

Hi Max,

take a look at these.
Maybe there is what you are looking for and you need:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Regards,

Fabio

von Max M. (vcc)


Lesenswert?

Thx!
Now i got collected all possible docs about the mods ;)

von Max M. (vcc)


Angehängte Dateien:

Lesenswert?

Guten Morgen zusammen!

Habe den OPA653-Mod gemacht (anleitung von Hayo V4.0), allerdigs zeigt 
mir das Skop bei kleineren Frequenzen Blödsinn an. Die einzige 
Abweichung von der Anleitung - Abschluksswiderstände habe ich 24Ohm 
statt 24,9Ohm eingesetzt. Wieso verändert sich das Signal zu kleinerern 
Frequenzen so bis zur dermaßen? Was könnte verkehrt sein? Aktuelle BF-FW 
ist drauf.

Grüße
vcc

von Max M. (vcc)


Lesenswert?

Wo kann ich denn an der unteren Grenzfreuenz überhaupt drehen?
Fehlt bei diesem Umbau nicht eine Gegenkopplung beim OPA653?

von Blue F. (blueflash)


Lesenswert?

Fragen über Fragen...

Ich fang mal mit dem Einfachen an.

> Fehlt bei diesem Umbau nicht eine Gegenkopplung beim OPA653
Nein, die ist im OPA653 schon integriert. Das hat den Vorteil, das die 
Gegenkopplung schon auf günstigen Frequenzgang und auf geringes Rauschen 
optimiert wurde. Daher können wir die externe Gegenkopplung auf der 
PLatine einfach weglassen.

> Habe den OPA653-Mod gemacht
Du bist aber schnell. Wo hast Du denn so kurzfristig die OPA653 her?

> Abweichung von der Anleitung - Abschluksswiderstände habe ich 24Ohm
Das sollte kein Problem sein. Eventuelle Abweichungen in der Verstärkung 
lassen sich in den Hardwareeinstellungen via Gain Adjustment 
nachjustieren.

> Wieso verändert sich das Signal zu kleinerern Frequenzen
Das ist jetzt etwas schwierig nur anhand der Bilder zu beurteilen. Frei 
nach dem Motto "Wer misst, misst Mist" kann das verschiedene Ursachen 
haben. Erstmal ist da die Frage nach dem Messaufbau. Welche 
Signalquelle, wie ist das DSO angekoppelt (Tastkopf oder Messleitung mit 
50Ohm Abschluss), welche Form, Frequenz und Amplitude hat das 
Originalsignal (Referenzmessung mit anderem Oszi möglich?)

Das mittlere Bild lässt mich vermuten dass es ein Abgleichproblem ist, 
da hier die typischen Entladerampen einer Kapazität zu erkennen sind. 
Hast Du denn wie empfohlen abgeglichen? Auch gern genommen ist falsche 
Abtastung (zu langsame Timebase), was zu Aliasingfehlern führt die 
zunächst aussehen wie ein verformtes Signal.

> Wo kann ich denn an der unteren Grenzfreuenz überhaupt drehen?
Wie ist das denn gemeint? Die untere Grenzfrequenz ist DC

Gruß Hayo

: Bearbeitet durch User
von Max M. (vcc)


Lesenswert?

Hayo W. schrieb:
> Nein, die ist im OPA653 schon integriert.

stimmt - habe ich vergessen...

Hayo W. schrieb:
> Wo hast Du denn so kurzfristig die OPA653 her?

Samples von TI.

Hayo W. schrieb:
> Erstmal ist da die Frage nach dem Messaufbau.

Signalquelle ist ein 40MHz-Funktionsgenerator.
--> Ausgang 50_Ohm, Rechteck, 1 Vpp, Freq z.B. 1kHz
Verbindung über 50_Ohm handelsübliches BNC-kabel.

Hayo W. schrieb:
> Referenzmessung mit anderem Oszi möglich?
Ja - 500MHz Tek, volle Bandbreite aktiv, bei > 1MHz z.B. sehen beide 
Skops gleich aus. Die Dachschräge beim W2022A fängt bei ca. < 1Mhz an 
und wird immer schräger mit sinkender Frequenz.

Hayo W. schrieb:
> Auch gern genommen ist falsche
> Abtastung

Die Time base passt, hatte auf aliasing geachtet.


Ich denke auch, dass es was mit Kapazitäten zu tun hat, allerdings weiß 
ich nicht an welcher Stelle in der Messkette.

von Blue F. (blueflash)


Lesenswert?

> Verbindung über 50_Ohm handelsübliches BNC-kabel

Ich frag mal ganz blöd - an den 50 Ohm Abschlusswiderstand hast Du aber 
gedacht. Ist mir nämlich auch schon passiert bei Vergleichsmessungen mit 
meinem Tek das ich das vergessen hatte, da im Tek die 
Abschlusswiderstände schon mit eingebaut sind und man keinen externen 
braucht wie beim WELEC.

Ansonsten wie schon gesagt auf jeden Fall abgleichen, so wie es in der 
Low Budget Mod beschrieben ist.

Gruß Hayo

von Alessandro C. (musashi)


Angehängte Dateien:

Lesenswert?

Hello, after a lot of time I’ve resumed my W2012A from the garage. Last 
time I wrote here I asked for help in troubleshooting my scope.
Of course the problem is still there so I asking again if some kind soul 
can help me.

I post here a discussion with Hayo and Victor that I’ve made last year 
and some shot (the third one is taken with the test signal on):


Alessandro
  Goodmorning everyone
  My oscilloscope (W2012A) had begun to constantly show (in the second
  channel)a sinusoid wave.
  Even without the probe connected.
  When I press "Quick Meas" I get 500Hz 27,8V pk-pk
  What could be the cause of the problem?

Hayo
  Alessandro,
  which hardware- and software version?
  Did you ever change something in your device?

Alessandro
  I have only updated the firmware
  Model: W2012A
  HW Version: 8C7.0C
  SW Version: 1.2.BF.5.7 C2

Hayo
  Hi Alessandro,
  at first I would recommend to update Your firmware to the latest 
version
  1.2.BF.6.7

  If the problem does not disapear, we have to check the settings:
  - which voltage range (or all ranges affected?)
  - which hardware settungs in the hardware menu etc.
  - acquisition mode
  - triggering
  and so on.
  Some screenshots may be helpful.
  Regards
  Hayo

Alessandro
  I've updated to 1.2.BF.6.7 but the problem is the same...
  The problem is present for every voltage range
  Hardware settings are
  ADC Setup - Factory
  Pre Gain - LB-Mod
  Gain - 1.000
  ADC Driver - Assembler
  Attached a screenshot
  Could it be an hardware problem?

Hayo
  That is possible but I can't say it for shure. By the way - your
  hardware setting should be (for an unmodified device):
  ADC Setup - Factory
  Pre-Gain - Factory
  Hayo

Alessandro
  Ok, thanks!
  I've adjusted the pre-gain setting
  Where do you suggest to look in the schematic for faulty components?

Hayo
  Did you make a default setup and a calibration with open (or 
shortened)
  inputs?
  Channel 1 is working completely normal?
  Hayo

Alessandro
  Yes I've done both but nothing changes..
  The first channel works normally


And here the reply from Victor
  Hello Alex,
  I see very weird trigger setting in top of the screen, could be better
  anything else but pulse mode.
  Trust me, try with other selection for trigger, it's better.
  I guess and maybe it is possible that it could be the problem.
  Another weird thing is about open inputs for calibration, indeed it
  should be performed short-circuiting them, never with open ones.
  My two cents.
  Victor

I’ve tried changing the trigger but nothing changes…

If this is not the right place to post this please tell me

von IZ2EIB (Gast)


Lesenswert?

Hi Alessandro,

really weird your problem.
You wrote that you have simply performed a firmware update on your 
oscilloscope.
What have you used?, the normal upgrade or the fast one?

Ok you have those alike sine wave, is it while you are probing valid 
signals or only when nothing is probing?
What I mean is.
Omitting the weird sine waveform on the screen, when you are performing 
measures then is something, even if meaningless, drawn on the screen?

Maybe it's noise from fan circuitry which is know to be a problem.
Have you inspected the path of the fan wires inside the instruments?
It's better keep the fan's cable far from the electronic boards.
You could try opening the instrument and see what happens moving the 
fan's wires.
A T T E N T I O N !
Be careful doing that because near there are high voltages, I warn you!
Take all the precautions of the case, pay attention on what you are 
doing!
Inside the instrument there are hazardous voltages!

Another possible cause of noise, even more troublesome, could be TFT 
lamp's inverter circuitry.
Applies as said above for the fan.

Maybe it isn't your case because only one channel is affected by the 
problem, but you must consider that one of the input channels could be 
closer to the source of the interference than the other, hence be more 
disturbed.

One other attempt could be try to downgrade the DSO to the original 1.4 
Welec firmware and then performing upgrade with the Hayo's one.
You have to follow Welec instructions in order to reload Welec's 
firmware, so you need to do it using the WelecUpdater software paying 
attention to what you are doing.
It would be strange that this solves but it costs nothing to try.
If I'm not wrong in the past someone who have experimented a similar 
weird behaviour solved his problem performing downgrade to original 
Welec's fimware and then upgrading to Hayo's version.

Regards,

Fabio

von Alessandro C. (musashi)


Lesenswert?

Thank you, I'll try your suggestions and let you know!

Unfortunately I don't think I can find the original FW anywhere on my 
computer (the old HD is gone), is it downloadable online?

von IZ2EIB (Gast)


Lesenswert?

Hi Alessandro,

would have been better that you had made ​​a backup before upgrading 
your instrument, however try this:

http://www.mikrocontroller.net/attachment/42473/W2012_Vers_1.4.rar

Good luck!

Regards,

Fabio

von Alessandro C. (musashi)


Lesenswert?

I did, but unfortunately the HD is gone..
Should I use the WelecUpdater to install this?
Is the welec site completely offline?

thanks

von IZ2EIB (Gast)


Lesenswert?

Hi Alessandro,

here you go:

http://sourceforge.net/projects/welecw2000a/files/PC%20software/WelecUpdater/

And yes, sadly the Welec website is no longer on line.

Regards,

Fabio

von Blue F. (blueflash)


Lesenswert?

Hi Alessandro,

there is no need to go back to WELECs original firmware. But the idea to 
restore the internal flash is not bad. I could provide you with some 
complete flash backups of different firmware versions. The flashing 
procedure can be done with our normal RS232 tools (perlscript etc.). But 
only in the not compressed form. So it may take a little time for the 
restore.

Let me know if you need a backup file to restore your DSO - I will post 
it here or on SFN.

Hayo

von IZ2EIB (Gast)


Lesenswert?

Hi Hayo,

that's only like an attempt.
If I'm not wrong some people who have had weird behaviours with their 
Welec then fix it in that way.

Rather, looking for the culprit perhaps could be useful connect channel 
1 to channel 2 in order to see if the so called "interference" can be 
catch by the working one.

In my opinion when using original Welec firmware, it doesn't matter that 
you can then fix reflashing the device, long time for long time it's 
better use WelecUpdater instead of other like perlscript, etc, etc.
This is because WelecUpdater is generally more simple to setup and less 
machine dependant, simply unpack an running it.
Other ways need you install and configure a bit of things which could be 
not so easy to reach.
All this even if you never run the risk to bricking your Welec because 
"germans loader" can not be accidentally erased.
Simply using WelecUpdare it introduces less variables than other.
Due the problems all us know may be it possible that actually the 
culprit is a defective weld.
Has already happened before even though with different symptoms.

Regards,

Fabio

von Blue F. (blueflash)


Lesenswert?

> If I'm not wrong some people who have had weird behaviours with
> their Welec then fix it in that way.

Hi Fabio,
you are not wrong! Let me explain what I mean:

Flashing the old WELEC firmware is a little bit like restoring the 
flash, but only a little bit! With this flashing only some sectors in 
the upper part of the flash chip are overwritten and when switching the 
DSO on some further parts (data storing) in the flash will be affected. 
The rest of the flash - including the new data storing areas and the 
lower parts are not overwritten. Sometimes this helps but you can not be 
sure it does!

What I suggested is to take the complete flash memory of a (known) good 
working device and transfer it to the device with the problems (I always 
used this method when my DSOs had problems after experimenting with the 
memory).

If the device has still problems after that you can be shure, that it is 
not a software problem.

It is the fastest and the simplest method to be sure the firmware is ok!

Hayo

von Alessandro C. (musashi)


Lesenswert?

>Let me know if you need a backup file to restore your DSO - I will post
>it here or on SFN.

Yes this would be great!

>The flashing procedure can be done with our normal RS232 tools (perlscript 
>etc.). But only in the not compressed form.

Can you remind me how this is done? As I said it's been sometime since 
my last use of the DSO.

Thank you both for your help

von IZ2EIB (Gast)


Lesenswert?

Hi Hayo,

I agree.
I have suggested that way because the purpose was to get wipe the whole 
flash.
Actually I know in one occasion you provided a special firmware which 
can perform the whole erasure of the flash.
If I'm not wrong and that piece of software exists it could be one 
solution.

Regards,

Fabio

von Blue F. (blueflash)


Lesenswert?

@Alessandro

Give me a moment, I will build a rescue package for you with all you 
need including some help texts. What you need to have installed on your 
pc is active perl and the module Win32|Device::Serialport (if you are 
using Windows) as described in the docu "how to upload via shell script" 
which is included in every firmware package. But I guess you installed 
it already for the normal firmware update.



@Fabio

> Actually I know in one occasion you provided a special firmware
> which can perform the whole erasure of the flash.

The complete erasure of the flash is automatically done while restoring 
the flash with the backup file.

Hayo

: Bearbeitet durch User
von vcc (Gast)


Lesenswert?

Max M. schrieb:
> Guten Morgen zusammen!
>
> Habe den OPA653-Mod gemacht (anleitung von Hayo V4.0), allerdigs zeigt
> mir das Skop bei kleineren Frequenzen Blödsinn an. Die einzige
> Abweichung von der Anleitung - Abschluksswiderstände habe ich 24Ohm
> statt 24,9Ohm eingesetzt. Wieso verändert sich das Signal zu kleinerern
> Frequenzen so bis zur dermaßen? Was könnte verkehrt sein? Aktuelle BF-FW
> ist drauf.
>
> Grüße
> vcc

FYI

Fehler lange gesucht und gefunden!
Im OPA653-Mod versehentlich R13 mit 390 Ohm statt mit 390k bestückt.
Jetzt ist alles gut.

Grüße
vcc

von Blue F. (blueflash)


Lesenswert?

Freut mich zu hören, dass jetzt alles läuft. Dann mal viel Spaß mit dem 
Gerät und immer eine gute Erdung!

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok Alessandro, here we go!

- unpack the file to your PC (assuming that you are using Windows and 
active perl and the win32 serial port module is installed).

- open the file restore.bat with a text editor and check if the COM port 
(preset is COM1) is correct. If not, change it to the COM port to which 
you will connect your DSO and save the file.

- connect your DSO to the COM port.

- activate the GERMS-monitor at your DSO (hold F1 and press F2 shortly)

- start restore.bat from the restore directory.

The flashing process may take up to 1 hour. So go and take some coffee 
meanwhile. After flashing switch off your DSO and restart. The DSO 
should start now with a green grid layout and channel 1 + 2 in 2V/div 
range at 100KSa/s.

- Go to the hardware menu and change the pre gain to your hardware setup 
(actual it is ADC -> Factory, Pre Gain -> OPA653, ADC Driver -> 
Assembler).

- After done so, go back to the utility menu and calibrate offsets.

Hope that will fix your problems

Hayo

von Alessandro C. (musashi)


Lesenswert?

Thank you Hayo!

Only one question, is it possibile to do the process, with a notebook 
via a USB->RS232 adapter? (if not I'll use the desktop pc at work...)

I'll tell you if this has worked out the problem

von Blue F. (blueflash)


Lesenswert?

USB->RS232 adapter sometimes work and sometimes not. I'm using a no name 
adapter for my notebook which works very well. But I also heard from 
adaptors that don't work. So you have to try.

Hayo

von Alessandro C. (musashi)


Lesenswert?

When opening .bat I get:
Error: Unsupported mode parameter, please specify <r>ead or <w>rite!

Should I insert w than enter?

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Sorry,

I took an old version of the perl script. Please use the script 
attached.

Hayo

von Alessandro C. (musashi)


Angehängte Dateien:

Lesenswert?

I'm getting this (look at the screenshot)

Currently I'm trying with an adapter:
http://www.digitus.info/en/products/archiv/digitus-usb-to-serial-adaptor-usb-20/

So maybe this is the problem...

von Blue F. (blueflash)


Lesenswert?

Yes, I agree. Looks like an adaptor problem. Did you enter the correct 
COM port? The adaptors often use COM 5 - 7. Be shure the COM port number 
is correct.

Otherwise try an original COM port on a pc.

Btw. - you can use the old perl script too but then you have to delete 
the -d parameter. Looks like that:

perl GERMSloader.pl COM1 -w flash_compl_6_8.flash

: Bearbeitet durch User
von Alessandro C. (musashi)


Lesenswert?

Nothing, same errors!
I've tried with a desktop PC with serial port doing this:

- install ActivePerl-5.18.2.1802-MSWin32-x64-298023.msi
- Restart the pc
- Extract Win32-SerialPort-0.19(1).tar.gz
- Copy the files in SerialPort-0.19 to C:\active perl...
- Open Makefile.pl
- Running the test I can see between the lines some failed statement 
(the windows closes automatically
- Cheking that COM1 is the one connected to DSO
- Connecting DSO, powering it up, started the germloader by holding down 
the first button near the power one, and pressing rapidly the second 
button nearby (the screen goes grey)
- Open restore_flash.bat

I get the same error posted above....

von Alessandro C. (musashi)


Lesenswert?

It seems like activeperl 5.18 and win32-serialport 0.19 doesn't work 
fine together...

I've installed activeperl 5.12 and win32-serialport 0.22 and now the 
process is started... I'll let you know how it goes!

von Alessandro C. (musashi)


Lesenswert?

Great!
Process ended in 18 minutes... and now the ch2 seems to work fine!
Only thing I've noticed is Oscope info now says W2022A, mine is a 
W2012A, can this create problems?

Thank you!

von Blue F. (blueflash)


Lesenswert?

Great news! Congratulations to your upgrade :-)

Don,t worry about the W2022 - the only difference is the transistor of 
the input stage. All firmware functions are the same.

von Alessandro C. (musashi)


Lesenswert?

Not so good...
I have restarted the DSO now end it acts again as before!!!
what the hell!!

von Alessandro C. (musashi)


Lesenswert?

I have opened the DSO and started it up keeping the fan cable far from 
the boards (as Fabio suggested).
Nothing changes

von IZ2EIB (Gast)


Lesenswert?

Hi Allessandro,

bad what you wrote.
Anyway, I'm a little dumb but I don't understand if while performing 
measures with the bad channel some kind of waveform change or overlaps 
on the previous drawn over the screen.

While channel 1 is connected to channel 2 (by cable, probes or anything 
else), is the weird waveform drawn on the bad one drawn also on the good 
one?
Would be better perform the verify by setting channels' input "x1" 
rather than other even if that depend by the kind of connections you are 
using.
It is surely possible switch to other settings in order to see what 
possibly happens like it's even surely possible to use the good channel 
in order to collect informations from the board simply by comparing the 
same points on the channel 1 and channel 2 looking at the schematic 
diagram.
This to start.

Regards,

Fabio

@Hayo
Thanks for the rescue firmware.

von Alessandro C. (musashi)


Lesenswert?

Thanks Fabio
I'll try what you suggest, measuring some test signal with ch2 (last 
time I tried nothing happened)!

How can I set channels input to "x1"?
I'll try to connect ch1 via probe to ch2, and see what happens.

About testing the board, I need to find a way to hold all the boards, 
outside of the case, stable and connected while doing the tests.

I can't find the schematics of my W2012A on my computer and on 
http://sourceforge.net/projects/welecw2000a looking under files... do 
you have links?

von IZ2EIB (Gast)


Lesenswert?

Hi Allessandro,

Alessandro Cardelli wrote:
> How can I set channels input to "x1"?

I meant setting to x1 the probe's attenuation for the channels just like 
you do when select for x1/x10 probes.
In this case in order to better detect any anomalies you need to set x1 
especially for the bad channel, the good one depend on what kind of 
connections you choose.
Not mandatory but in the start would be better do in that way, after you 
can even change it if you need.
Actually it doesn't matter so much how is the attenuation, anyway 
starting in that way: x1.
There may be many variations though.

Alessandro Cardelli wrote:
> I can't find the schematics of my W2012A

Try here:

http://web.archive.org/web/20120119053915/http://sourceforge.net/apps/trac/welecw2000a/wiki/Hardware

Good luck!

Regards,

Fabio

von Alessandro C. (musashi)


Lesenswert?

Yesterday evening I have redone the update with the file given by Hayo.
Al went good as before, I turned off the DSO.
This morning I have restarted the DSO and all seems ok. How much will it 
last?
I'm confused!

von Blue F. (blueflash)


Lesenswert?

Sounds a little bit like a hardware problem (contact problems at some 
soldering pads).

I guess this is caused by poor soldering points which have changing 
contact depending on thermal conditions in the device.

We had those problems at one of the RAM chips. Some Owners could fix the 
problem by resoldering the RAM. Typical failure in this case are 
vertical stripes on the screen.

Maybe your problem affects another chip or component in the signal path. 
Not so easy to find!

von Alessandro C. (musashi)


Lesenswert?

But when the problem is present, it's there from the start up of the 
device.
When it's still cool...

von Blue F. (blueflash)


Lesenswert?

We have to consider which parameters and physical influences are 
affecting our DSO. That can be:

- temperture as first candidate for any (temporary) problem
- vibrations when moving the device
- mechanical forces when turning the range adjusters
- mechanical forces when pushing any buttons

Temperature as failure source is difficult to proove. Vibrations can be 
tested during operation with little shocks (knocking on the case or 
shaking the DSO hardly). Range adjusters can be turned forwards or back 
multiple times during operation and also buttons can be pushed multiple 
times to check if any reaction can be seen.

Soldering problems can be found by optical checks (with microscope or 
magnifier) and/or by measuring on the PCB. Measuring while running the 
DSO is a little bit difficult, because most of the components are 
reachable only after disassembling the device.

The firmware is surly not the problem.

: Bearbeitet durch User
von IZ2EIB (Gast)


Lesenswert?

Hi Allessandro,

I agree with Hayo, surely it isn't firmware issue.
Like he wrote, most likely it's bad weld matter.
Somewhere one or more component does or doesn't make contact.
You have to chase the problem by looking for bad or suspicious welds 
over the whole boards, each single component hoping it isn't the FPGA or 
any else thing hard to weld there inside the DSO.
Take a try using at least a simple magnifier lens.
Good luck!

Regards,

Fabio

von Jörg H. (idc-dragon)


Lesenswert?

Hallo Leute,

mich gibt's auch noch, bin so etwas im Hintergrund tätig.
Die letzten Tage habe ich mich mit dem Phänomen des verschwundenen Wiki 
beschäftigt. Sourceforge hat im Juni die "hosted apps" eingestellt:
https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/
Angeblich gab es dazu Vorwarnungen, ich habe aber nichts bekommen. (Für 
ein anderes Projekt hingegen schon.)
Zu den "hosted apps" gehört auch "trac", dem wir bisher unser Wiki 
überantwortet hatten. Sourceforge war immerhin so nett, vor dem 
Abschalten noch ein Backup anzufertigen und abzulegen. Das habe ich mir 
gezogen und nun die Datenbank und trac neu aufgesetzt, uff. Es gibt dazu 
eine Anleitung, die so direkt aber nicht funktionierte und einige 
Transferleistung erfordert:
https://sourceforge.net/p/forge/community-docs/Migrating%20Trac%20from%20Hosted%20Apps/
Sourceforge selbst rät davon ab, ich weiß nicht recht warum.
Derzeit ist die svn-Anbindung noch kaputt (dem Python bei Sourceforge 
fehlt anscheinend das Package "subversion-python", keine Ahnung wie ich 
das als rechtloser User dort nachrüsten könnte) und Login funktioniert 
auch nicht. So kann man die Seiten nicht editieren. Aber immerhin, es 
ist nun alles noch/wieder da und lesbar:

http://welecw2000a.sourceforge.net/cgi-bin/trac.cgi

Grüße,
Jörg

PS: Demnächst mehr im made-from-scratch Thread.

von WWWelec (Gast)


Lesenswert?

Hello,

I don't want to hijack the thread, but something is weird here:

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

When rise time of the signal under measure comes close to that of the 
oscilloscope it is necessary to subtract the latter (and if used the 
probe’s) rise times geometrically from the rise time as seen on the 
screen.
The true signal rise time will become:

Ta=√Ttot² - Tosc² - Tp²

whence

Ttot = √Ta² + Tosc² + Tp²

Where

Ttot is the rise time seen on the screen

Ta is the true signal rise time of the signal

Tosc is the scope’s own rise time (2,3ns for a 150MHz bandwidth 
oscilloscope because Tosc in nanoseconds = 350/Bandwidth in MHz hence it 
is equal to 350/150 = 2,3ns)

Tp is the rise time of the probe/cable, e.g. 2 ns.

So for instance reading 2,4ns on the screen of an 150MHz bandwidth 
oscilloscope and knowing the rise time of the probes/cables equal to 
2ns, it is:

Ttot=√2,4² + 2,3² + 2² = 3,9ns

If the signal’s rise time is equal or more than 10x times that of the 
instrument one, then its value and that of the probe/cable rise time may 
be neglected.
2,3ns for Tosc isn't negligible in this case and even optimistically 
assuming Tp equal to 0 nanoseconds, it will be:

Ttot=√2,4² + 2,3² + 0² = 3,3ns

So if you read 2,4ns on the screen as described in your picture, the 
instrument's rise time must to be negligible.
Your W2022A have to be at least 400MHz bandwidth like for the Tektronix 
2465A, that makes no sense in the real world.
Based on the fact the specifications for your not faulty TR-0307 is 
2,5ns rise/fall time and assuming the same considerations for your 
Tektronix 2465A which is a 400MHz bandwidth oscilloscope, we have the 
following.
Since if not faulty the Tektronix 2465A is a true 400MHz bandwidth 
instrument, then its own risetime is as you correctly wrote 0,8 
nanoseconds (800 picoseconds).
Doing some calculation this is the result assuming Tp equal to 0 
nanoseconds.

Ttot = √Ta² + Tosc² + Tp²

or

Ttot=√2,4² + 0,8² + 0² = 2,5ns

Also in this case 0,8ns for Tosc isn't negligible being only three times 
smaller compared to the true rise time of the signal, but now the result 
makes sense and sounds good in contrary that for the W2022A.
Something is wrong.
W2022A isn't a 400 MHz bandwidth instrument, neither the 2,4ns captured 
mean that it is a 140-150MHz DSO.
Simply 2,4ns is too slow in order to test the bandwidth in that way, you 
need something much faster.
As rule of thumb you need at least a waveform five times faster than the 
instrument under test.
So for a 200MHz bandwidth oscilloscope which is a 1,75ns rise/fall time 
(350/200MHz=1,75ns) you need at least a 0,35ns rise/fall time waveform 
(1,75ns/5= 0,35ns=350ps)
My two cents.

Victor

von Blue F. (blueflash)


Lesenswert?

Hi Victor,

You are right in all points. The resulting rise time always consists of 
Tosc + Ta (and of course Tp if used).

And the rise time of the signal (~2.5ns) is not fast enough to make a 
reliable statement about the DSO risetime. It is only an approximate 
estimate.

Hayo

von 김사백 (Gast)


Lesenswert?

Victor: too much math for my taste.
~
Hayo: then how did you get the same value and why it is so?
Is perhaps QM wrong on rise time?
Otherwise OWON SDS8102 is worst than W2022A that I don't think so.
~
So long,
400

von Alessandro C. (musashi)


Lesenswert?

Hello Hayo!
I don't understand this

> Now we connect the normal signal output via T-piece adapter to channel 1
> and the end of the wire terminated with 50 Ohm to the antenna.

Say I wan't to test an RC filter,
do I connect the sweep sync to channel 2, the sweep signal to the filter 
input and the filter output to channel 1?

thank you

von Blue F. (blueflash)


Lesenswert?

Hi Alessandro,

sorry for the little confusion. Yes you are right. In normal case (like 
a RC filter) the signal generator out has to be connected to the input 
of the tested system and the output to channel 1 of the DSO.

In case of the resonance circuit (loop antenna) input and output are the 
same. But this is a special case.

If you have any nice results, please post it here.

Hayo

von Alessandro C. (musashi)


Lesenswert?

Thanks Hayo,

I've made some confusion too, and posted this in the hardware section...

Unfortunately I don't have a signal generator with the sweep sync 
output...

Is there a PC software with this function?

Is it the same generating the sweep with channel 1 of the signal 
generator and a square wave with half wave equal to the sweep duration 
with channel 2?

von WWWelec (Gast)


Lesenswert?

Hello Jörg,

Good idea but IMHO it's a mere exercise in style if what we'll get on 
the screen is the same of today.
Make no sense the effort to upgrade from a DSO to a DPO if then the 
waveforms on the screen will be crude (drawn rappresentation) and not 
stable (poor hardware trigger) like it is right now.
My two cents.

Victor

von CB (Gast)



Lesenswert?

Ciao people.
Help!
I find the trimmer for compensation in my W2012A are broken both C1 and 
C7.
I find some other new named:

muRata TZC3P200A110
Cmin= 5.0pF +50/-0%
Cmax= 20.0pF +50/-0%
TC= N1200±500ppm/°C
Q= 300min. at 1MHz, Cmax.
Rated Voltage= 100Vdc
Withstanding Voltage= 220Vdc
Stator/Case Color= Red

It is good for substitutions?
It is the more similar I find, no other I see.
Perhaps 100Vdc are few in that location (300Vrms).
Please help me.
Thanks and sorry for my english, I'm from Italy.
Carlo

von Blue F. (blueflash)


Lesenswert?

CB schrieb:
> It is good for substitutions?

Ciao Carlo, that seems to be perfect!

CB schrieb:
> Perhaps 100Vdc are few in that location (300Vrms).

No problem I think. The voltage is divided by the voltage 
divider(R2/R3/R4 DC and C1/C2/C3 AC). That should be ok. I don't think 
that the original parts have better parameters. So I would suggest to 
take them.

Hayo

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

CB schrieb:
> Ciao people.
> Help!
> I find the trimmer for compensation in my W2012A are broken both C1 and
> C7.

Are you shure they are defect? In my DSO I only had to resolder the pads 
and then they worked ok.

Hayo

von CB (Gast)


Lesenswert?

Ciao Hayo, grazie!
Lucky that trimmer can substitute that broken chipped.
I suspect original trimmer are glue and move they are chipped broken 
because I see they are well before touch.
Soldering is well.
You are right R2/R3/R4 and C1/C2/C3 do divider and voltage is no 
problem, I have not see the component.
Now I see better and I have a doubt.
Perhaps C1 and C7 are use only with high range over 1V, under 1V range 
they are not use because relay exclude they.
I want buy also component for do modify.
I think LB is more easy of OPA653 for me.
Performance are much different use one or other?
Perhaps I read trigger is better with OPA653 mod.
Buona sera.
Carlo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

CB schrieb:
> Performance are much different use one or other?

No, performance is not much different. I'm using both modifications. My 
W2014A is a LB-Mod and my W2022A is a OPA653 Mod. When using the DSO in 
normal frequency ranges up to 50 MHz there is no difference. Only 
measuring signals with very fast rise time (like my 100MHz pulse 
generator) will show any difference. The overshot at the rising edge on 
the LB-Mod is a little bit more flat than on the OPA653 Mod. In normal 
use there is no difference.

Hayo

von CB (Gast)


Lesenswert?

Ciao Hayo, grazie!
Beautiful picture.
LB mod pay back similar OPA653 also if LB picture have linear and OPA653 
picture have sin(x)/x.
I want do LB mod because OPA653 is more difficult for me.
LB mod is also more cheap of OPA653.
I buy component for substituition of the broken trimmer and for LB mod
Thank you.
Carlo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

CB schrieb:
> also if LB picture have linear and OPA653 picture have sin(x)/x.

I switched between linear and sin(x)/x - there was no difference.


CB schrieb:
> LB mod is also more cheap of OPA653.

Indeed, that is the charme of this mod :-)

Before you make the mod check your OPA656! If they have a green point on 
the case it may be the BW limited version (fake version). Then you have 
to upgrade first on a real OPA656. See also the document "Upgrade". I'm 
sorry that it is available only in german until now. But the pictures in 
it may help a little bit.

Hayo

: Bearbeitet durch User
von CB (Gast)


Lesenswert?

Ciao Hayo.
Lucky only in trigger there is OPA656 with green point.
I must substitute?
Is difficult do it for me.
Thank you.
Carlo

von 김사백 (Gast)


Lesenswert?

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" : Jörg, interesting 
post.
Any news?
~
My Welec is plagued by spikes problem.
I know some people have units which are more spikes resistant because of 
the inside FPGA implementation, so there are some FPGA NIOS revision 
which are better than other.
Now I wonder if putting one of that revision in my DSO can help to 
improve spikes immunity in it.
I know nothing about NIOS, Altera, JTAG, USB-Blaster and so on.
Before starting I'm looking a safe and easy way to obtain a safety 
backup of the original NIOS in my W2012A just in case I load a worse one 
in place of that is already there.
I also need to know what is the better Welec's NIOS that is possible to 
put in W2012A because I don't know it.
Would be possible to use the NIOS taken from a W2014A in a W2012A?
And in case if it turns out that the best immunity at spikes is for 
W2022A/2024A, would be possible to use the NIOS taken from a 
W2022A/W2024A in a W2012A?
Is there a document on how to use USB-Blaster in order to backup the 
original NIOS of a Welec DSO?
~
So long,
400

von Blue F. (blueflash)


Lesenswert?

김사백 schrieb:
> so there are some FPGA NIOS revision
> which are better than other.

There are two main versions (8C7 and 1C9), both original from WELEC. The 
8C7 seems to be the better one. 2 or 4 channel version are the same, 
only difference is the second FPGA. If you want to check it out you have 
to invest the 5 - 10 Euro for the Altera Blaster (or use the Blaster 
driver from slog). As I wrote before - a backup is not necessary because 
you can load the FPGA design temporarily. After restarting the DSO it is 
all like before.

So you can test without any risk. Backup of the original core is very 
easy if you want to backup nevertheless.

If something goes wrong, you can get any version you want from here.

> Is there a document on how to use USB-Blaster

Yes there we had a document in our wiki, but it is gone now. Maybe it 
can be found in the web archive, or someone has the download on his PC.

So what you have to do is to download the Altera Quartus Web Edition 
(for free) and order an Altera Byte Blaster (made in china). Then you 
can check if it may solve your problem.

Hayo

: Bearbeitet durch User
von Guido B. (guido-b)


Lesenswert?

Hayo W. schrieb:
> Yes there we had a document in our wiki, but it is gone now. Maybe it
> can be found in the web archive, or someone has the download on his PC.

Jörg made a copy at SFN and posted the link for the docs:

http://welecw2000a.sourceforge.net/cgi-bin/trac.cgi

von 김사백 (Gast)


Lesenswert?

Hayo:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~There are two main versions (8C7 and 1C9), both original from WELEC.
~The 8C7 seems to be the better one.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mine is already 8C7 but spikes annoy me alot.

Hayo:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~2 or 4 channel version are the same, only difference is the second 
FPGA.
~If you want to check it out you have to invest the 5 - 10 Euro for the
~Altera Blaster (or use the Blaster driver from slog).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Actually I have been able to take an original USB-Blaster by Altera 
although I don't know to use it.
So right now my problem isn't buy or find original or clone USB-Blaster, 
but be able to do the job without run in the risk to damage my Welec.

Hayo:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ As I wrote before - a backup is not necessary because you can load the
~FPGA design temporarily. After restarting the DSO it is all like 
before.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do you mean for testing I can temporarily put something like the 1C9 or 
other version in my Welec which have the 8C7?
That would be daebak!

Hayo:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Backup of the original core is very easy if you want to backup
~nevertheless.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Anyway I want to make the backup just in case, for safety issue.

Thanks for the reply.

~

guido-b:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~http://welecw2000a.sourceforge.net/cgi-bin/trac.cgi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

guido-b jjang!
That is daebak!,
Really useful, thanks!

~
So long,
400

von Guido B. (guido-b)


Lesenswert?

김사백 schrieb:
> Do you mean for testing I can temporarily put something like the 1C9 or
> other version in my Welec which have the 8C7?
> That would be daebak!

He really means that! Using Blaster, only configures the FPGA without 
any
savings. Only writing to flash does lasting changes.

von 김사백 (Gast)


Lesenswert?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sandro: I saw the 1KHz 760Vpp that you used for channels compensation, 
nice picture.
I don't understand some things though.
1) filter is on that makes difficult evaluate overshoot.
I adjusted mine trying to get a shape where the overshoot peak is same 
like amplitude to the flat top of the square wave taking care that also 
the bottom follow the same principle.
Though now I think that was wrong.
The right way should be to tune getting something like this

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How did you do?
I'd like to see better details of the overshoot taken by you with filter 
off and reduced time base.
Thanks.
~

Sandro: now I only own the 3 frequencies square wave generator described 
somewhere in the forum.
Unluckily it's only 150mV, then another question related with your 
picture.
From here:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ "Die markierten Überschwinger lassen sich trotz bestmögl.
~ Abgleich des Probes (C's im Body des Probes) nicht vermeiden,
~ auch eine geräteinterne Kompensation durch die C's in Nähe der
~ Relais ist nicht möglich- diese sind in 10mV/Div nicht zugeschalten."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If that is correct, namely also the schematic is, then it's needing to 
be over the 1V range in order to get right compensations.
I couldn't use that square wave generator.
It's only 150mV so I can't use it and not even I can see overshoot, so I 
tried using 1kHz probe compensation but also it isn't in the volt range 
even if it has overshoot.
Finally I reached adjustment using 12V CMOS square wave.
Even if with slow rise time I have had overshoot that I used in bad way 
as I guess now.
Time after I brought my Welec at school and there with the help of the 
teacher I have adjusted the inner compensation with a leveled square 
generator.
Though unluckily I still used the same wrong way as before.
Aish!~
What do you think?
~

My W2012A already modified 33/150Ω in the past, last year at school I 
further improved with OPA653 mod.
With the help of the teacher I have measured 165MHz after the OPA653 
modification.
Mine is a W2012A no like your W2022A.
Unluckily now I don't go anymore to that school and I'd like retune in 
the right way the compensation of my Welec but I haven't the necessary 
instrumentation.

Thanks.

So long,
400

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Bin gerade dabei unsere Mods zu dokumentieren und habe mal angefangen 
mit der Trigger LED Modifikation. Da gab es ja nur einzelne Posts und 
Bilder. Jetzt habe ich das mal zu einer griffigen Anleitung 
zusammengefasst. Ich war so frei auch "fremde" Bilder aus den Posts zu 
verwenden (Dank an Michael)

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Wie ich den Downloads entnehme erfreut sich die Doku anscheinend 
allgemeiner Beliebtheit. Mit so viel Interesse hatte ich gar nicht 
gerechnet. Daher hier der nächste Beitrag in der Dokureihe. Die Beste 
aller Ehefrauen war auch hier wieder so nett mein technisches Geschwafel 
in eine angenehmere Form zu bringen.


Hayo

: Bearbeitet durch User
von Michael D. (mike0815)


Lesenswert?

Moin Hayo,
sehr schön gemacht!
Nur mal so als Vorschlag...
Für die D2 würde ich lieber einen 0 ohm Widerstand nehmen(anstatt einer 
Brücke), wenn man schon dabei ist.

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Du hast natürlich recht. Auch wenn die Elektronen sich nicht drum 
scheren, sieht es schon ordentlicher aus. Beim nächsten Mod gelobe ich 
Besserung ;-)

Hayo

von Michael D. (mike0815)


Lesenswert?

> Du hast natürlich recht. Auch wenn die Elektronen sich nicht drum
> scheren,
die nicht, aber die Augen ;-)
> sieht es schon ordentlicher aus. Beim nächsten Mod gelobe ich
> Besserung ;-)
alles klar :-)))

Sehr praktisch und vor allem, übersichtlicher mit den "Büchlein"
Für jede Modifikation eine Doku und es kämen weniger Fragen auf.
Bei Bedarf hätte man immer das richtige in  der Hand, je nach dem, was 
man gerade in Angriff nehmen möchte.
Hast du die bisher erstellten Werke ins Wiki gesetzt?
Es sind ja schon ein einige Dokus vorhanden, aber irgendwie verschüttet 
gegangen.
Das meiste habe ich ja auf Platte, aber die neuen User nicht

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Wie meinst Du das mit Wiki? Es gibt doch wenn ich das richtig verstanden 
habe nur die Kopie von Jörg, die aber nicht editierbar ist. Ich lege 
alles immer ganz ordentlich hier ab:

http://sourceforge.net/projects/welecw2000a/files/

Die Dokus sind unter /Hardware/Modifications/ zu finden.

Das ist doch immer noch die aktuelle Ablage oder?

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

Ok, mein Fehler...dachte da wäre noch was auf auf Wiki.
Danke für den Link, sehe ich das erste mal.
Auf Sourceforge ist es sehr schwierig, da immer das richtige zu finden, 
was hatte ich mir da schon einen Wolf gesucht...

Gruß Michael

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Jetzt wollte ich mal den georderten USB-Blaster mit dem Quartus
Programmer testen, habe das Board vor mir liegen...da sind ja 2
Pinheader. Welcher ist es denn, der linke oder der rechte Header und
wohin muß der 10 Polige Steckerpöppel gucken, nach oben oder unten, bzw.
wo ist dann Pin1 ?
Foto vom Board im Anhang!

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

Hi Michael,

habe hier im Urlaub leider nur mein kleines Lappy, daher ist die Suche 
etwas unkomfortabel. Ich meine ich hätte hier oder im "made from the 
scratch" Forum ein Foto gepostet auf dem zu erkennen ist wie es 
angeschlossen werden muss.

Gruß aus den Dolomiten

Hayo

von Andiiiy (Gast)


Lesenswert?

Hallo Micha,

auf dem Bild vom Hayo ist das zu erkennen ...

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Grüße Andiiiy

von Andiiiy (Gast)


Lesenswert?


von Michael D. (mike0815)


Lesenswert?

Au man, unglaublich! Habe über eine Std. im Netz und auf der Festplatte 
gesucht, bevor ich hier nachfragte :-(
Wäre ich mal gleich auf die Einsteigerseite...wie peinlich!
ha, der Andy hatte dieselbe Frage, ich schmeiß mich weg.

Danke Andy, danke Hayo (wo du wieder rumeierst :-)  ) !!



Gruß Michael

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

Hallo Leute, erstmal wünsche ich ein chices neues Jahr!

Ich habe mein W2022 geöffnet um den neuen USB-Blaster anzuschliessen und 
zu testen. Das verlief auch reibungslos und funktionierte einwandfrei, 
das Backup sowie das wieder einspielen mit dem Quartus Programmer. Es 
ist zwar etwas "Tricki", wegen dem ECPS16, aber dazu später...

Da ich das Teil schon mal offen hatte, dachte ich mir, gleich den 
LB-Mode in Angriff zu nehmen. Gesagt, getan! Also die 0R gegen die 24R9, 
dann R14 270R gegen 200R und RA 150k gegen 330R getauscht. Alles 
durchgemessen, damit mir keine Kurzschlüsse unterlaufen sind, auch alles 
hübsch!
Jetzt wollte ich vorab schonmal testen, ob das Welec noch hochfährt, 
bevor ich mich an die Abschirmbleche mache und siehe da, es bootet nicht 
mehr :-(((

Zu sehen, sind ein paar graue Felder und sonst nüscht. Da zog ich das 
Frontpanel ab und siehe da, es bootet! Frontpanel wieder aufgesteckt und 
der Bilschirm wird wieder Hellgrau. Das Panel auf eventuelle 
Kurzschlüsse überprüft, war jedoch negativ. Spannungen (12V, 8V und 3x 
6,18V-Maxim5081) vom Netzteil kommend, brechen beim aufstecken auch 
nicht zusammen.
Kann mir das jemand erklären, bzw. hat das schon jemand gehabt?

Anbei die Pics vom LB-Mod der Platine und dem Frontpanel, bzw. Monitor, 
wenn das Frontpanel nicht aufgesteckt ist.

Gruß Michael

EDIT: Ganz vergessen...die LEDs des aufgesteckten Frontpanels leuchten 
auch nicht!

: Bearbeitet durch User
von WWWelec (Gast)


Lesenswert?

Hello Michael,

there aren't green dots on the OPA656s in your DSO therefore they
aren't fake, they are the good ones.
I guess the mod has nothing to do with the defect that you describe.
Could be defective contacts on the pin header.
Me too I had your same problem in the past when I tore down my
DSO the first time.
I solved simply disconnecting and reconnecting the boards taking care of
don't tighten too much the screw that holds them.
On that occasion I noticed that the board was deformed because of
that screw too tight although there is a spacer on it.
My two cents.

Victor

von Blue F. (blueflash)


Lesenswert?

Hi Michael,

ich stimme Victor zu. Da Du am analogen Eingang rumgelötet hast, kann 
das nicht diese Reaktion am Bildschirm verursacht haben. Es müsste 
zumindest einen schwarzen Bidschirm geben und die Buttons mit Menü.

Was Du da hast deutet eher auf einen Fehler beim Zusammenbau hin oder 
einen Wackelkontackt, der durch das Ausbauen/Einbauen entstanden bzw. 
zur Geltung gekommen ist. Also wieder auseinandernehmen, sorgfältig 
zusammenbauen und nochmal schauen. Wenn es immer noch so aussieht mal an 
einigen Stellen rumdrücken. Besonders verdächtig ist wie immer der 
RAM-Chip.

Ebenfalls potentielle verdächtige sind die Steckverbindungen z.B. die 
zum Mainboard oder der große Pfostenstecker am Netzteil bei dem man 
gerne mal um eine Reihe verrutscht.

Weitere Testmöglichkeiten: RSS232 verbinden, Terminal starten und mal 
sehen ob die Firmware startet (Textausgabe im Terminal).

Viel Erfolg + Happy new year to all

Hayo

von Michael D. (mike0815)



Lesenswert?

Hallo Victor, Hayo(Bist wieder im Lande?).

Ihr habt natürlich Recht! Die Pimperei hat nichts mit dem bestehenden 
Fehler zutun.
Ich hatte in der Vergangenheit sehr oft das Scope zerlegt und nie gab's 
Probleme nach dem zusammenbauen. Jetzt ist die Kacke am dampfen!
Die Pinheader vom Frontpanel, habe ich nachgelötet.
Die beiden Ramchips, hatte ich auch mit Flussmittel nachgebessert.
Anbei mal die Fotos von den "ISSIS".
Daran hat es aber leider nicht gelegen :-(
Vielleicht sollte ich die Pfostenstecker vom Netzteil mal bearbeiten...
Versteckt hatte ich mich nicht, da bin ich sehr pissig, was das betrifft 
und kontrolliere sowas 2-3mal nach!

Die Software lässt sich nach wie vor, sichern und wieder aufspielen(auch 
mit aufgestecktem Panel), sonst müßte der Quartus-Programmer ja einen 
Fehler ausgeben, denke ich.

Wenn das Panel abgezogen wird, startet der Bilschirm sofort die 
Software, wie man auf den Bildern sieht.
Das letzte Foto zeigt den Pinheader. Sobald ich den mit rot 
gekennzeichneten Pin berühre, wird ein Reset ausgelöst, bzw. der Monitor 
wird grau. Sobald ich wieder loslasse, wird wieder gebootet.

Gruß Michael

EDIT: Ich habe im Metallgehäuse eine Aussparung für den darunter 
befindlichen Quarz gebohrt, da dieser auf das Blech drückt und die 
Platine anhebt. Evtl. könnte man dazu eine kleine Doku verfassen, wenn 
nicht schon vorhanden.

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Michael D. schrieb:
> Evtl. könnte man dazu eine kleine Doku verfassen, wenn
> nicht schon vorhanden.

siehe "Optimizing Thermal Design Part 3"

Hayo

p.s. jupp, bin wieder im Lande

: Bearbeitet durch User
von mark (Gast)


Lesenswert?

Trying to improve trigger's stability I have spent some spare time doing 
OPA653 upgrade.
Trigger and noise are improved a lot but now with low frequencies I have 
same distortion  like somebody other here.
OPA653 itself performs very well and would be good for me but very often 
I mess with filter circuits (photosensors) where I need to analyze low 
frequencies and that distortion annoy me so much.
I don't know any solution that putting things as before the upgrade.
Perhaps one solution exists, it's low budget mod.
I'm pretty sick to open and reopen my oscilloscope running the risk to 
damage it and I need it for my job.
Is here somebody who have done the low budget mod and could say if even 
there are distortions?
I'd like to know this so I can understand if there is a chance or if I 
have to return to the factory design.
My problems are on trigger and noise side, no bandwidth.
I don't need to work with high frequencies, in most cases I mess with 
low frequencies.
I think the low budget mod could be fine for my purposes, of course if 
there aren't any distortions.
Otherwise I'll return to the factory design.
Thanks guys.

mark

von Blue F. (blueflash)


Lesenswert?

Hi Mark,

please help me to understand your problem in detail. Can you describe a 
typical measurement that leads to your problem? Settings, frequency, 
levels (screenshots would be helpful) to redo the measurement with my 
own devices.

This would give us the possibilty to compare the results.

Hayo

von mark (Gast)


Lesenswert?

Hello Hayo, thanks for the help.
Typical measures I do are on 1,5ms pulses at frequency of 100Hz and 
amplitude of 7V (photosensor's filter and strobe watchdog).
Are perfectly square waveforms there as I saw and see using other 
oscilloscopes.
Before of the OPA653 upgrade even my Welec showed perfectly square 
waveforms.
I had to try the upgrade because with factory design and standard mod 
(24 and 150 ohm resistors) I have to set trigger almost on the top of 
the pulse in order to evaluate its real amplitude, after OPA653 upgrade 
that isn't necessary anymore because amplitude is pretty independent 
from trigger setting.
In other scenario (keyboard scan) I need to check 3V square pulse and 
there with factory design I have trigger instability due noise that I 
haven't with OPA653 upgrade.
I my case I don't benefit the digital filters so I need hardware upgrade 
like OPA653 or low budget mod.
My oscilloscope had already updated the trigger circuitry.
I wonder if low budget mod is the right answer at my problems.
Thanks.

mark

von mark (Gast)


Angehängte Dateien:

Lesenswert?

Sorry, I forgot some screenshots.
Here they come.
Thanks.

mark

von Thomas (kosmos)


Lesenswert?

JPG vor PNG?

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hello Mark,

I did the measurement like you described with my W2014A (LB-Mod) and my 
W2022A (OPA653 Mod). I can confirm the problem with the OPA653 Mod. The 
LB-Mod is not affected. It is not the timebase (or samplerate), but the 
pulse width of the signal. Up to 1.5ms it is all ok. With increasing 
width the distortion becomes more and more. It seems to be a capacitor 
charging curve. I'm not shure where the problem is located. I'm working 
on that. Thanks for reporting.

Hayo

p.s. it is not an adjustment problem, I checked that also

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

...and for sure it has be written sure not shure...  ;-)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, got first results with some tests. The problem seems to be the RC 
relation of R13/R14 with C11. I had to change R13/R14 because of the 
zerolevel correction. This seems to lead to an interaction with C11. For 
testing I changed C11 from original 22nF to 120pF on channel 1 but left 
channel 2 unchanged. The result can be seen on the screenshot. In the 
next step I will try a greater value and I hope this will solve the 
problem.

Hayo

: Bearbeitet durch User
von mark (Gast)


Lesenswert?

Hello Hayo, thanks for the answer.
Also I have checked for adjustment problem and surely it isn't.
Even to me it seemed a problem of capacitors.
I saw that you are already close to a solution, very well.
It is fortunate for me even if I'm still happy because low budget mod is 
not plagued by that issue.
Where did you find the schematic diagram?
I'd like take a look to it.
Thanks.

mark

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

I used this schematic as basic information.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok Benedikt,

weiter geht's. Ich sehe schon die Schraube links oben mit der der 
Metallrahmen am Kunststoffgehäuse verschraubt ist. Die ist nicht 
original, aber auf jeden Fall empfehlenswert, da sich sonst beim 
Betätigen des Schalters das Chassis verwindet (da wurde bei WELEC 
gespart). Unten mittig ist direkt am Displaystecker einer der beiden 
RAM-Bausteine (Aufschrift ISSI...) zu sehen. Der hat gerne mal kalte 
Lötstellen und dann gibt es Streifen oder andere Muster auf dem Display. 
Du kannst ja mal mit einer Lupe checken ob da nachgelötet wurde.

Ob vollwertige Bauteile in Deinem Gerät verbaut wurden, kannst Du in 
einer ersten Sichtprüfung erkennen wenn Du rechts oben bei der 
USB-Buchse die Bauteile direkt dahinter mit einer Lupe ansiehst. Dort 
befindet sich die Eingangsschaltung für den externen Trigger. Der 
Eingangsverstärker OPA656 (Kennzeichnung B56) ist der gleiche wie bei 
den normalen Kanälen. Wenn ein grüner Punkt drauf ist, dann ist das ein 
eher schlechtes Zeichen, da damit normalerweise die 100MHz Versionen 
gekennzeichnet sind. Weitere Überprüfungen sind erst möglich wenn Du das 
Board ausbaust und Dir die Rückseite ansiehst. Dazu must Du die 
nachgerüstete Schraube lösen, die Drehknöpfe von der Front abziehen 
(achtung nicht zu stark ziehen wenn diese festsitzen, sondern mit einem 
kleinen Schraubi abhebeln - Details findest Du in der Anleitung 
Ext_Trigger_Mod). Dann kann man den Rahmen mit Platine herausnehmen. Die 
Verschraubung der BNC-Buchsen lösen und zum Schluss die eine Schraube 
neben den Stiftleisten (JTAG) mit der die Platine am Rahmen verschraubt 
ist (Auf Deinem Bild mitte unten).

Wenn Du die Platine herausnimmst und umdrehst hast Du die wichtigsten 
Teile der Eingangsschaltungen der Kanäle vor Dir.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier nochmal die Schritte im Bild...

Wenn man etwas Übung hat und das 20 - 30 Mal am Tag macht (beim Tüfteln 
an der Hardware) braucht man etwa 1 bis 1,5 Minuten für das Zerlegen des 
ganzen Gerätes.

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Hello Mark,

unfortunately I "landed" in the wrong thread with my answer. So you will 
find it here a little bit offtopic...

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Sorry

Hayo

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

mark schrieb:
> Maybe it isn't relevant but looking at the schematic R19 (9080ohm) is
> 1/100 of the size of the original R13 (908kohm).

I know what you mean, but balance is mainly influenced by R13 and R14. 
R14 has to be 100 Ohm for correct gain of OPA653. So we have to find the 
optimal value for R13.

> Anyway was your screenshot obtained with the original value for C11
> (22nF)?

Yes it was. This value has to be unchanged. I changed it only for 
analysis and understanding the function.


> If the better value for R13 is roughly 300kohm, then putting a resistor
> of roughly 1,3Mohm on the already welded 390kohm the result will be
> precisely +/-300kohm.

that's correct, but don't forget the tolerances of the parts. It may be 
difficult to find exact matching values for all channels. 5% of 1.3M is 
65K!

> I understand the zerolevel side but what would happen by putting a more
> common 270kohm resistor instead of a 300kohm?

we have to find the perfect balance. 270K leads to a falling signal top 
(discharge) and 330K leads to a rising signal top (charge). I think the 
optimal value will be in the range between 300K and 310K. I will check 
it by combining the 300K resistor with additional resistors of 1K - 10K.

Hayo

: Bearbeitet durch User
von mark (Gast)


Lesenswert?

> I know what you mean, but balance is mainly influenced by R13 and R14.
> R14 has to be 100 Ohm for correct gain of OPA653. So we have to find
>  the optimal value for R13.

If I'm not wrong due the value used for R14 and that's inside the OPA653 
itself(160ohm) gain is now 1,61.

> that's correct, but don't forget the tolerances of the parts. It may be
>  difficult to find exact matching values for all channels. 5% of 1.3M is
> 65K!

I wrote 1,3Mohm thinking precision resistors (undr 1%) because in my job 
often I use them with size 1206 (not suitable for Welec).

> we have to find the perfect balance. 270K leads to a falling signal top
> (discharge) and 330K leads to a rising signal top (charge). I think the
> optimal value will be in the range between 300K and 310K. I will check
> it by combining the 300K resistor with additional resistors of 1K - 10K.

Since you have a beautiful Tek 2465A you'll be able to evaluate what is 
better to use simply compared the shape of the square wave on the Tek 
versus what will be shown on the Welec screen.
Of course Tek must be the reference there. ;-)
Thanks.

mark

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok Mark, I got it.

Combining 300K with a 4K7 Resistor results in ~305K. Channel 1 shows the 
corrected signal, channel 2 with 390K. I think this value fits optimal.

Unfortunately this value is available only in the E192 series (0,5%). So 
we have to decide wether we combine different resistors or try to get a 
305K resistor.

Next I will correct the firmware with new factors.

Hayo

von mark (Gast)


Lesenswert?

IMHO 305kohm EIA E192 series should be the better choice, much than 
combine different resistors.
Maybe it's a my own impression but the bottom of the square wave seems 
to not be so flat though that may depend on several factors.
I'd like to know how the same signal is seen on the Tek.
Now awaiting for the new firmware.
Good job, thank you!

mark

von Blue F. (blueflash)


Lesenswert?

I've been working on the firmware until now. The new factors are 
determined and programmed. The bug in the Save/Recall function (came 
with 7.7/7.8) is found and fixed.

Tomorrow I'm a little bit busy, so the new version may need a few days 
before I can release it.

Hayo

von luigi (Gast)


Lesenswert?

Hello,
till now I found 0603 305K .5% avalaible at mouser, do you know other 
vendors?

luigi

von luigi (Gast)


Lesenswert?

Hello,
till now I found 0603 305K .5% avalaible at Mouser, do you know other 
vendors?

luigi

von Blue F. (blueflash)


Lesenswert?

No, I only found 300K at ebay

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Here the new version of the OPA653 Mod manual. Also available on SFN.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Und auch noch die deutsche Version.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

As you can see on the pictures I combined two resistors for R13. The 
300K resistors I found on old boards measured with 300.3K for channel 1 
and 301.4K for Channel 2. Combined with 4.7K(ch1) and 3.9K(ch2) it is 
working good enough for me.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

And keep in mind when you are measuring, that there is still a little 
discharge when you are using AC coupling! But this is the same with the 
original factory implementation and also with LB-Mod.

So if you want to measure frequencies below 200Hz it is recommended to 
use DC coupling. Ultra slow timebases (USTB roll and shift modes) are 
not affected.

Hayo

von mark (Gast)


Angehängte Dateien:

Lesenswert?

OK, resistor R13 (390kohm) changed with 305kohm 0.1% EIA E192.
It works and this is good for me, thank you Hayo.

mark

von Bruno A. (bruno_a586)


Lesenswert?

I have somes questions concerning hardware modification. I'm not sure if 
I can perform the  OPA653 modification with the Welec 2014A ?
If I understand well after the modification, the bandwidth will be 200 
MHz and the SNR will be better ?

von Blue F. (blueflash)


Lesenswert?

Hi Bruno,

unfortunately your email went into my spam folder, so I will answer here 
today.

Yes! The OPA653 mod and also the LB-mod is suitable for all Welec "A" 
models.
Due to the needed firmware version the non "A" models have to be 
upgraded first before any further mod can be done.

And yes, the bandwidth, the SNR and the linearity of the frequency 
characteristic is much better than in original. There is only one 
problem. As I heard from some others, it might be a little bit difficult 
to get the OPA653. It seems to be that the samples are restricted now 
(only for schools, universities and manufacturers).

Hayo

von Bruno A. (bruno_a586)


Lesenswert?

Hi Hayo,

I order 4 OPA653 on the webstore of TI  in USA. I'm waiting...

To solder which pencil solder is necessary to solder them on the PCB ?

von Blue F. (blueflash)


Lesenswert?

Bruno Allain schrieb:
> which pencil solder is necessary

Hi Bruno, don't know exactly what you mean. My solder paste is CR44 and 
I use temperature controlled soldering irons (two of them) with very 
fine tips at 315°C. Desoldering is much easier with two irons. The 
soldering paste can be allocated with a needle.

And don't forget to prevent electrical discharge when operating with the 
OPAs - dead or disfunction of the OPAs may occure otherwise.

Hayo

von Bruno A. (bruno_a586)


Lesenswert?

Hi Hayo,

I have no experience in CMS soldering. May be it's difficult for an 
inexperienced person to use C44 with a controlled temperature soldering 
iron, even with a very small tips, on youtube I saw a such operation 
with hot air or in a furnace.

Bruno

von Blue F. (blueflash)


Lesenswert?

It is not so difficult as it seems. You can just try it with some old 
boards to get some experience (that is what I did). A good magnifiing 
glas or better a microscope is recommended.

Hot air is also possible but that's more for equipping new boards.

von Bruno A. (bruno_a586)


Lesenswert?

Hi Hayo,

I ordered 4 OPA653 IDBVT from TI, but I'm disapointed because today I 
received four SOT23 with the marking BZW ?? I'll ask TI what it means ?


Regards
Bruno

von Bruno A. (bruno_a586)


Lesenswert?

Hi Hayo,

It seemsI received the good component. Do you know a store where I can 
buy resistor. With Mouser the DELIVERY CHARGE: 40,00 euro ! More over 
they haven't 305 kOhm resistor.

Kind regards

Bruno

von Benedikt K. (benek)


Lesenswert?

So dann melde ich mich hier mal wieder.
Ich habe folgendes Problem mit meinem W2014A: Und zwar funktioniert (DSO 
war ist aus zweiter Hand, korrekt funktioniert hat es noch nie) das 
Display nicht mehr. Anfangs war das nur ein Wackelkontakt, wobei ich mir 
das auch nicht ganz sicher bin (rumgedrücke am Gehäuse hat meist 
gerreicht um das Display wieder in Gang zu setzen) am Datenkabel 
zwischen Mainboard und Display. Jetzt funktioniert es allerdings gar 
nicht mehr, egal was ich mache. Ich habe die Vermutung bzw. die Sorge 
das das Problem allerdings nicht am Kabel liegt sondern am Connector auf 
der Platine, da es beim Kabel einmal durchpiepen keine Auffäligkeien 
gab.

Hatte schonmal jemand ein ähnliches Problem? Jemand eine Idee wo ich 
suchen muss? Wo bekomme ich ein Ersatzkabel oder ein Ersatzconnector 
(obwohl es mir jetzt schon davor graust den auszulöten bzw. einzulöten). 
Oder liegt das Problem am Display an sich?

MfG Benedikt

von Blue F. (blueflash)


Lesenswert?

Hi Benedikt,

ja das ist ziemlich wahrscheinlich der RAM-Baustein. Selbiger sitzt 
gleich neben dem Display-Anschlussstecker (ein s zuviel?). Die Beinchen 
dieses Chips haben schon wiederholt Kontaktprobleme gehabt. Das äußert 
sich in rosa-violetten Streifen auf dem Schirm bis hin zu Totalausfall. 
Einfach mit einem Lötkolben mit feiner Spitze die Beinchen vorsichtig 
nachlöten (einfach kurz heiß machen sollte reichen). Evtl. vorher etwas 
in Alkohl aufgelöstes Kolofonium draufpinseln - als Flussmittel. Auf 
keinen Fall mit einer Dachrinnenlöte drangehen (so einen Fall hatte ich 
auch schon hier auf dem Tisch). Danach ging es bei den Meisten wieder 
einwandfrei.

Gruß Hayo

von Benedikt K. (benek)


Lesenswert?

Hayo W. schrieb:
> Hi Benedikt,
>
> ja das ist ziemlich wahrscheinlich der RAM-Baustein. Selbiger sitzt
> gleich neben dem Display-Anschlussstecker (ein s zuviel?). Die Beinchen
> dieses Chips haben schon wiederholt Kontaktprobleme gehabt. Das äußert
> sich in rosa-violetten Streifen auf dem Schirm bis hin zu Totalausfall.
> Einfach mit einem Lötkolben mit feiner Spitze die Beinchen vorsichtig
> nachlöten (einfach kurz heiß machen sollte reichen). Evtl. vorher etwas
> in Alkohl aufgelöstes Kolofonium draufpinseln - als Flussmittel. Auf
> keinen Fall mit einer Dachrinnenlöte drangehen (so einen Fall hatte ich
> auch schon hier auf dem Tisch). Danach ging es bei den Meisten wieder
> einwandfrei.
>
> Gruß Hayo

Hi Hayo,
danke für die schnelle Antwort. Hab jetzt mal die Pins nachgelötet. 
Ergebnis: Display funktioniert wieder, Oszi springt aber nicht mehr an, 
sprich Display leuchtet auf und Run/Stop Taste leuchtet. Ich habe so das 
dumpfe Gefühl, dass ich trotz geregelter Lötstation den Chip endgültig 
gegrillt habe :(. Hast du dazu noch eine Idee?

MfG Benedikt

von Blue F. (blueflash)


Lesenswert?

Benedikt K. schrieb:
> Ich habe so das
> dumpfe Gefühl, dass ich trotz geregelter Lötstation den Chip endgültig
> gegrillt habe

Glaube ich nicht. Dann würde wohl nichts mehr gehen. Ich vermute eher, 
dass entweder eine kleine Lötbrücke zwischen den Beinchen entstanden 
ist, oder noch eines der Beinchen keinen Kontakt hat. Hast Du eine gute 
Lupe oder ein Aufsichtmikroskop? Das ist immer sehr hilfreich um das 
genauer zu inspizieren. Manchmal sitzen die Beinchen auch leicht 
versetzt auf den Pads und ziehen den Lötzinn dann zum Nachbarpad hin. 
Kaputt ist meistens nichts so schnell.

Gruß Hayo

von Sigi (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe einen kleinen VHDL/Qsys-Rahmen geschrieben,
mit dem ich kleine Anwendungen bzw. Tests erstellen
kann. Im ZIP-File ist eine Anwendung zum Test der
Buttons (bzw. auch LCD als Textausgabe). Wenn alle
Testen funktionieren, dann liegt es wahrscheinlich
am SRAM.

von Sigi (Gast)


Lesenswert?

P.S.: zum Starten der Anwendung:
1. NiosII-Shell öffnen
2. Files in ein Verzeichnis kopieren
3. ./load_sof.sh  (=> FPGA-Design laden)
4. ./load_elf.sh  (=> Anwendung laden)

von Benedikt K. (benek)


Lesenswert?

Danke für eure Tipps! Allerdings habe ich heute gemerkt, dass SMD löten 
wirklich nichts für mich ist... Habe den Chip jetzt endgültig mit meiner 
Lötstation ins Jenseits geschickt, indem ich es geschafft mehrere 
Lötpads gleichzeitig von der Platine abzulösen :(. Fragt mich bitte 
nicht wie man so intelligent sein kann ...

... Falls jemand im Moment gerade ein weiteres W2xxx Osi günstig 
abzugeben hat, weiß er jedenfalls jetzt wo er sich melden kann...

MfG Benedikt

von Benedikt K. (benek)


Lesenswert?

Danke für eure Tipps! Allerdings habe ich heute gemerkt, dass SMD
löten
wirklich nichts für mich ist... Habe den Chip jetzt endgültig mit meiner
Lötstation ins Jenseits geschickt, indem ich es geschafft mehrere
Lötpads gleichzeitig von der Platine abzulösen :(. Fragt mich bitte
nicht wie man so intelligent sein kann ... Nach einer Stunde hab ich es 
jetzt aufgegeben die Verbindungen mit Draht wiederherzustellen.

... Also falls jemand im Moment gerade ein weiteres W2xxx Osi günstig
abzugeben hat, weiß er jedenfalls jetzt wo er sich melden kann...

MfG Benedikt

von Jörg H. (idc-dragon)


Lesenswert?

Benedikt,

hast du die Anschlüsse wieder geflickt bekommen?
Was macht dein Oszi denn jetzt?

Du kannst auch mein Speichertest-Design ausprobieren. Das ist ein .sof 
File mit einem Spezial-Osoz, was laufend das komplette SRAM testet. Das 
LCD ist dabei auch aktiv, man sieht die Patterns auch im 
Bildschirmspeicher.
Siehe hier:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"

Falls sich gar nichts retten läßt, oder auch wer anders ein hoffnungslos 
defektes Gerät hat:
Ich suche noch eine "Opferplatine", bei der ich mindestens das FPGA und 
den USB-Chip auslöten kann. Ich würde gerne rausfinden, ob unser Pinout 
vollständig ist.
(Möchte hier aber nicht als Aasgeier erscheinen, es sollte schon darum 
gehen das Gerät von Benedikt wieder flott zu kriegen.)

Grüße,
Jörg

von -gb- (Gast)


Lesenswert?

Hallo, mich interessiert das Gerät weil ich es gerne als schnellen ADC 
verwenden möchte.
Ich will ein Signal von 0 bis 10 V digitalisieren. Das sind gaußförmige 
Impulse je 10us Dauer. Ich brauche die Fläche unter diesen Impulsen. Im 
FPGA ist das einfach, man macht eine Triggerschwelle und wenn das Signal 
drüber ist summiert man auf und wenn es wieder drunter fällt gibt man 
das Ergebnis aus. Dazu reicht dan ein UART.

Wie einfach ist das bei diesem Gerät ohne CPU die ADCs und Verstärker 
und Eingabeknöpfe vom FPGA aus anzusprechen? Ich würde das nur in VHDL 
machen. Bildschirm ist auch super weil ich dann die Signalform und die 
Triggerschwelle anzeigen könnte.

Danke!

von Blue F. (blueflash)


Lesenswert?

Hallo gb,

wie man die Peripherie vom FPGA aus anspricht kann Dir Jörg sicher 
sagen. Evtl. könntet Ihr Euch zusammen tun und die FPGA-Logik 
weiterentwickeln. Das wäre dann quasi eine win - win Situation für alle.

Grundsätzlich würde ich allerdings vermuten, dass Deine Aufgabenstellung 
einfacher zu lösen ist, wenn Du auf Firmwareebene aufsetzt. Soll heißen, 
dass Du die vorhandene Firmware für Deine Zwecke umbaust. Da sind ja 
schon jede Menge Funktionen drin die Du einfach verwenden kannst. Du 
schmeißt dann einfach raus was Du nicht brauchst und reduzierst den 
Ablauf auf Deine Aufgabenstellung. Das dürfte die Performance auch ganz 
schön verbessern.

Für Fragen diesbzgl. stehe ich gerne zur Verfügung.

Gruß Hayo

von -gb- (Gast)


Lesenswert?

OK vielen Dank! Wie ist das mit der Firmware, muss man da irgendwelchen 
Assembler können oder so? Und wie schnell ist das Oszi wenn man das mit 
Firmware im NIOS macht, also wenn da das Triggerereignis stattfindet, 
wie lange dauert es bis man wieder triggern kann? Das würde ich gerne 
möglichst schnell können. Also ein Impuls kommt, wird erkannt, dauert 
10us das sind dann 10000 Samples bei 1gsps und danach möchte ich 
möglichst sofort wieder triggern.

von Blue F. (blueflash)


Lesenswert?

-gb- schrieb:

> muss man da irgendwelchen
> Assembler können oder so?
Oder so ist richtig. 99% der Firmware ist in C bzw. ziemlich C-nahem C++ 
programmiert. Einige spezielle Hardwarefunktionen sind in NIOS-Assembler 
geschrieben. Die für Dich wichtigen Routinen gibt es doppelt, einmal in 
C und einmal in Assembler (ADC-Ansteuerung). Da helfe ich auch gerne 
weiter. Der NIOS Assembler ist gut dokumentiert (Doku frei 
herunterladbar), meine Assembler-Routinen sind ebenfalls gut 
dokumentiert im Code. Die Entwicklungsumgebung ist für Linux frei 
erhältlich.

Und wie schnell ist das Oszi wenn man das mit
> Firmware im NIOS macht, also wenn da das Triggerereignis stattfindet,
> wie lange dauert es bis man wieder triggern kann?
Das kann ich jetzt nicht so eindeutig sagen, da das von mehreren 
Faktoren abhängt. Der Ablauf ist grob beschrieben so:

Eine Endlosschleife pollt ein Flag, welches durch die Interruptroutine 
des ADC nach erfolgreicher Acquisition gesetzt wird. Wenn dieses Flag 
gesetzt ist werden die Daten aus dem schnellen RAM ausgelesen und 
weiterverarbeitet.

Je nachdem wie viele Kanäle gleichzeitig verarbeitet werden (1 - 4) 
variert auch die Geschwindigkeit. Es gibt auch etliche zusätzliche 
Komfort und Triggerfunktionen, die man für spezielle Aufgaben 
wegoptimieren könnte. Die Bildschirmausgabe samt Aufbereitung und 
Extrafunktionen ist ebenfalls sehr zeitaufwändig. Vielleicht benötigst 
Du hier vieles nicht, das würde ebenfalls alles beschleunigen. Du 
brauchst ja auch nur 10000 Samples, dann musst Du nicht die volle Länge 
von 16 K auslesen, also nochmal eine Beschleunigung.

: Bearbeitet durch User
von -gb- (Gast)


Lesenswert?

Ui danke! Generell will ich möglichst keinen einzigen Impuls verpassen. 
Das mache ich derzeit mit FPGA und ADC. Als Aufgabe hab ich einen 
schnellen UART und VGA. Limitierende ist derzeit der ADC mit <100MSpS da 
wäre schneller besser genauso wie ein Frontend das gut aufgebaut ist.
Trigger mache ich im FPGA also digital das geht sehr einfach.

Wie schwer ist es denn die ADCs so anzusprechen und den Analogteil? Gibt 
es da Pinbelegungbund so? Und die Drehknöpfe ... ist das irgendwie 
"schön" gemacht?

von Blue F. (blueflash)


Lesenswert?

Die derzeitige FPGA-Implememtierung ist leider alles Andere als schön. 
Ich würde das eher als experimentell bezeichnen. Das war wohl auch mit 
der Grund warum die Firma pleite gegangen ist. Das Pinout ist relativ 
gut durch die "Gemeinde" und im Speziellen durch Jörg dokumentiert. Die 
NIOS(I) Implemetierung ist auch wegen schlechten Designs langsamer als 
sie sein müsste. Deswegen hat Jörg angefangen eine neue Implementierung 
mit NIOS II Core zu entwickeln. Die ist pfeilschnell und kränkelt auch 
nicht an den Problemen der originalen Implementierung. Die erzielbare 
Performance ist schon sehr beeindruckend. Da alles in der Freizeit neben 
der Arbeit entwickelt wird, ist das momentan etwas ins Stocken geraten. 
Mit etwas Unterstützung wäre er aber vermutlich sofort wieder mit dabei.

von -gb- (Gast)


Lesenswert?

Hm danke. Das ist so dass ich zwar schon ne Zeit lang Zeug mit FPGAs 
mache, aber kein Profi bin. Dieses ganze Bussysteme und so kann ich 
nicht, das baue ich mir je nach Anforderung immer selber. Muss mir jetzt 
sowieso mal dieses AXI von Xilinx angucken und dann vielleicht nochmal 
ordentlich VHDL lernen. Also ich glaube nicht dass ich da eine Hilfe 
bin, aber ich würde da gerne was selber basteln wenn das halbwegs 
dokumentiert ist das Gerät und die Komponenten nicht allzu schwer 
anzusteuern sind.

von Jörg H. (idc-dragon)


Lesenswert?

Hallo,

ich bin wegen aktueller Arbeitsauslastung zumindest in diesem Monat 
keine Hilfe.

Bitte mit svn diesen Sourcetree auschecken:
https://svn.code.sf.net/p/welecw2000a/code
Unter fpga/nios2/altera liegt mein FPGA-Design.
Im Unterverzeichnis ip sind die von mir geschaffenen Komponenten. Die 
sind auf der einen Seite für den Altera-spezifischen Busanschluß (SOPC 
Builder) ausgelegt, aber ich denke es ist gut sichtbar wie die Hardware 
angesteuert wird. Ähem, ist bis auf den (für dich irrelevanten) Teil von 
Alex in (System) Verilog geschrieben.

Für dich interessant:
W2000_Keypanel für die Tastatur
W2000_LCD_Controller für das Display, ist aber schon recht speziell, 
liest aus dem SRAM
W2000_LED für die LEDs auf der Frontplatte
W2000_Rotary für die Drehknöpfe
W2000_Sample ist eine einfache Variante der ADC-Datenabnahme, aktuell 
nicht mehr verwendet
W2000_SPI zur Ansteuerung der Kanalschalter und was so am SPI hängt, 
kann verschiedene Signalformen generieren

Grüße,
Jörg

von -gb- (Gast)


Lesenswert?

Danke! Ich hatte ja doch VHDL erwartet und was ist .sv ? Jedenfalls 
sieht es übersichtlich aus aber ein paar Fragen habe ich:

Wie sind die Bedienelemente angeschlossen? Jeder Knopf/Encoder einzeln 
oder ist da ein Stein mit dem man SPI redet?
Was muss man ganz grob machen um Daten von den ADCs entgegenzunehmen? 
Also jeweils 4 um 90° verschobene Clocks und dann noch das analoge 
Frontend steuern, ist das schwer?
Das LCD ist wohl einfach VGA?

Werde demnächst sowieso mal mit Altera anfangen (Stratix 2 DSP) und dann 
auch Quartus und so lernen.

von Sönke P. (snke_p)


Angehängte Dateien:

Lesenswert?

Hallo,

bei meinem Welec 2022 habe ich nun auch einen Defekt.

Nach dem Anschalten wurde der Bildschirm kurz einmal hell, dann wurde 
nichts mehr angezeigt.
Aufgrund der Beschreibungen mit den Lötstellen an den RAM-Bausteinen 
habe ich diese nachgelötet.

Nun wird nach dem Anschalten wenigstens wieder was angezeigt. Aber die 
Anzeige ist fehlerhaft (sh. Foto) und es ist keine sinnvolle Funktion 
vorhanden. Easyloader geht und das Gerät reagiert irgendwie auf 
Tastendrücke.

Aufgefallen ist mir, dass bei einem RAM-Baustein ein Pad sehr erodiert 
aussieht. Ich kann nicht erkennen, ob es an dem nebenliegenden Via 
angeschlossen sein muss oder nicht (sh. Foto).

Kann mir jemand sagen, welche Pins der RAM-Bausteine mit welchen Vias 
verbunden sein müssen bzw. hochauflösende Fotos posten?

Ich bin kurz davor, das Teil endgültig in die Tonne zu treten, weil das 
von Anfang an ein Schrottprodukt war und ich mich eigentlich jedesmal 
ärgere, wenn ich das sehe...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Moin Sönke,

wir wollen mal sehen ob wir das wieder in den Griff kriegen. Dein Pad 
ist nicht erodiert, sondern anscheinend beim Nachlöten etwas heiß 
geworden und dann beim Draufdrücken nach hinten verrutscht. Hab ich 
schon öfter gesehen. Die Verbindung zum Via ist dabei abgerissen (Ja, 
dort muss eine Verbindung sein - siehe Fotos). Das ist nicht so schlimm, 
das kann man brücken. Übler ist es wenn eine unter dem Chip liegende 
Verbindung verloren geht...


Wenn Du mehr Bilder brauchst - sag Bescheid!

Viel Erfolg
Hayo

von Sönke P. (snke_p)


Lesenswert?

Hallo Hayo,

die Bilder haben mir sehr geholfen!
Den Pad habe ich nun mit einem Draht ans Via gelötet.

Das Oszi funktioniert nun wieder.
 Vielen Dank für die Hilfe!

PS:
Die Qualität deiner Platine sieht besser als bei mir aus (vgl. z.B. 
Auflösung der Pin-Beschriftung A15 auf dem Cu-Layer).

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Das ist doch super!

Ja ich habe auch das Gefühl, dass es da unterschiedliche Ausführungen 
gibt (evtl. bei unterschiedlichen Firmen gefertigt) und das eine der 
Ausführungen regelmäßig zu Problemen führt.

Auf jeden Fall ist das Wochenende gerettet :-)

von Oliver (Gast)


Lesenswert?

Zunächst mal: Toll, daß es um diese Oszilloskop-Reihe eine so agile 
Community gibt, die auch nach 7? Jahren noch aktiv bemüht ist, ein 
brauchbares Meßgerät aus dem Ding zu machen. Vielen Dank an Hayo und 
alle anderen, die die Entwicklung betreiben, schon soviel über das Gerät 
herausgefunden und somit die Welt vor etlichen Tonnen Elektroschrott 
bewahrt haben...

Ich habe meins 2008 gekauft (glaube ich), die derzeit aktuelle 
BlueFlash-Firmware installiert und das Gerät danach im Schrank 
verschwinden lassen (Praktisch, das es so schön klein ist). Dann hatte 
ich etliche Jahre keine Zeit fürs Hobby, stattdessen ein 60er-Jahre-Haus 
kernsaniert...

Vor einigen Tagen habe ich das Gerät wieder ans Tageslicht geholt, 
festgestellt, daß sich unfassbar viel in der Zwischenzeit getan hat, die 
aktuelle BlueFlash installiert und ein wenig in den möglichen 
Hardware-Mod-Pdfs geschmökert.

Die passenden OPA653 habe ich derweil organisiert (danke, TI, auch für 
das Anheben der Sample-Stückzahl auf 5), jetzt fehlen mir aber zum 
Wochenende ein paar Widerstände: Kann jemand sagen, ob bei der 
OPA653-Mod der Widerstandswert von 24,9 Ohm vor dem ADC kritisch ist, 
oder kann ich da auch 27 Ohm nehmen?

Alternativ könnte man ja einen 33 Ohm und einen 100 Ohm-Widerstand 
übereinanderlöten, was etwa 24,8 Ohm ergibt. Den 305k könnte man 
erhalten, wenn man auf den vorhandenen 390k-Widerstand ein "Dach" aus in 
Reihe geschalteten 1M und 390k schaltet, das sollte um die 304,5k 
ergeben.

Ist das machbar, mal von mechanischen Problemen abgesehen (Habe noch nie 
zwei Pfefferkörner als Dach auf ein drittes gelötet...), oder hole ich 
mir da zuviele Induktivitäten und parasitäre Kapazitäten ins Scope, die 
mir den Frequenzgang und die Linearität versauen?

Und nebenbei: Mein Lieblings-Oszilloskop, ein Mitte-der-80er Jahre 
Hitachi-DSO hat bereits einen Inkrementalgeber für Cursor-Messungen und 
alle möglichen anderen Einstellungen, bei dem man das Gefühl hat, an 
einem Alps-Potentiometer zu drehen: Keine spürbaren Rastungen, absolut 
analoges Verhalten auf dem Bildschirm. Ich meine, irgendwo mal was vom 
Austausch der knartzigen Inkrementalgeber gelesen zu haben. Hat das 
schon jemand gemacht und: Lohnt sich das?

von Jörg H. (idc-dragon)


Lesenswert?

Oliver schrieb:
> Ich meine, irgendwo mal was vom
> Austausch der knartzigen Inkrementalgeber gelesen zu haben. Hat das
> schon jemand gemacht und: Lohnt sich das?

Ja, ich habe das gemacht, alle durch Alps-Geber ausgetauscht. Am 
Zweitgerät habe ich auch den A/B-Vergleich.
Ist jetzt nicht sooo der Knaller, aber fühlt sich schon wertiger an, die 
Achsen sind besser geführt.

Ich habe verschiedene Typen eingesetzt, mit hohem Rastmoment für die 
großen Knöpfe, kleines Rastmoment für die kleinen, so ist das 
ausgewogen. Für die Offsetregler habe ich Geber ohne Rastung genommen, 
hat Poti-Feeling. Ich hätte eine leichtgängigere Variante nehmen sollen, 
meine fühlen sich noch etwas "teigig" an.

Vor allem habe ich bei Trigger, Multifunktion und Horizontalposition 
welche mit Taster genommen. Die habe ich mit je einem Pullup-Widerstand 
an noch freie Pins des letzten Schieberegisters angeschlossen. Das 
originale FPGA kann die Pins nicht lesen, aber mein neues ist dafür 
vorbereitet. So sind Sonderfunktionen denkbar.

Die Alps-Geber muß man etwas nachbearbeiten, damit die Knöpfe passen. 
Die Abplattung der Achse muß noch weiter runter reichen. Sind vielleicht 
2mm mit einem Dremel wegzuschleifen.

Grüße,
Jörg

von Blue F. (blueflash)


Lesenswert?

Oliver schrieb:
> Dann hatte
> ich etliche Jahre keine Zeit fürs Hobby, stattdessen ein 60er-Jahre-Haus
> kernsaniert...

Ja das habe ich auch schon hinter mir. Oder besser gesagt - ich bin seit 
15 Jahren dabei. Im Moment sitze ich hier mit völlig verstaubten Haaren 
weil ich mal ne kleine Pause brauche vom Mauer-Durchbrechen :-)

> Kann jemand sagen, ob bei der OPA653-Mod der Widerstandswert von
> 24,9 Ohm vor dem ADC kritisch ist, oder kann ich da auch 27 Ohm nehmen?

Auf die messtechnischen Eigenschaften bezogen ist es nicht kritisch. 
Aber es gibt zwei Werte (Faktoren) in der Firmware die genau auf diesen 
Widerstandswert eingestellt sind. Der eine ist der DAC-Faktor, der 
Einfluss hat auf die Nulllage des Signals wenn man den Nullpunkt an den 
oberen oder unteren Rand des Bildschirms kurbelt. Der andere Faktor ist 
die Signalverstärkung (Amplitude). Diese kann im Hardwaremenü 
gegebenenfalls angepasst werden. 27 Ohm machen wahrscheinlich keine 
ernstzunehmende Abweichung. Probier's einfach mal für einen Kanal aus. 
Die Widerstände sind eigentlich recht gut erreichbar auf der Unterseite 
des Mainboards.

> Den 305k könnte man erhalten, wenn man auf den vorhandenen
> 390k-Widerstand ein "Dach" aus in Reihe geschalteten 1M und 390k
> schaltet, das sollte um die 304,5k ergeben.

Gegen "Dachkonstruktionen" spricht eigentlich nichts. Ich habe bei mir 
die 305K (R13) aus einem "Dach" mit 300K und 4,7K gebaut (wie in der 
Anleitung beschrieben). Das wäre auch meine Empfehlung hierfür. War 
etwas Gefummel, aber mit der entsprechenden Vergrößerungsoptik und 
feiner Lötspitze (evtl. sogar zwei Lötkolben) kriegt man das hin.

Wenn ich das richtig interpretiere hast Du auch schon die Version 2.0 
der Mod-Doku, korrekt?

Viel Spaß beim Umbau! Halt uns mal auf dem Laufenden!

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja, bevor ich wieder rausgehe und mich in Zementstaub hülle - ich 
habe hier noch ca. 90 Stück 24.9 Ohm Widerstände liegen. Wenn Du willst 
schicke ich Dir welche, musst mir nur Deine Adresse zukommen lassen.

Hayo

von Oliver D. (ollinoscope)


Lesenswert?

Hallo Hayo,

ich hoffe, ich habe dich nicht all zu sehr vom Wände einreissen 
abgehalten, indem ich erst heute wieder ins Forum schaue...

Das mit den staubigen Haaren kenne ich auch, aber nur wenn man Bauschaum 
in den Haaren hat, weiß man, das man alles gegeben hat...

Ich habe mich am Sonntag erstmal mit grobmotorischem Gedremel vergnügt 
und einen vernünftigen Lüfter eingebaut. Dabei habe ich zum ersten Mal 
den Warnhinweis entdeckt, daß man tunlichst nicht mehr als 42VDC Peak an 
den Eingang legen sollte... Hätte ich wahrscheinlich durchaus mal 
ausprobiert, ich hoffe ich denke im richtigen Moment dran...

Auf das Angebot mit den Widerständen komme ich gerne zurück, ich werde 
dir gleich mal meine Anschrift schicken...

@Jörg: Kannst du dich zufälligerweise an die Typenbezeichnungen 
erinnern? Das Poti-Feeling hätte ich auch gerne :-)

Viele Grüße,

Oliver

von Olaf (Gast)


Lesenswert?

Oliver schrieb:
...
>
> Die passenden OPA653 habe ich derweil organisiert (danke, TI, auch für
> das Anheben der Sample-Stückzahl auf 5), jetzt fehlen mir aber zum
> Wochenende ein paar Widerstände...
Das Welec-Problem hat sich bei TI scheinbar herumgesprochen, ich bekam 
aufeinmal gleich 10Samples.
Ich werde mein gutes Welec nun auch aufrüsten und hoffe auf viele Jahre 
mit guter Zusammenarbeit.

von Blue F. (blueflash)


Lesenswert?

Da ist nicht übel!

Da könnte man ja auf die Idee kommen noch ein paar DSOs für kleines Geld 
in der Bucht zu schießen und dann aufzurüsten :-)

Wenn Du Frage wegen des Umbaus hast - nur keine Hemmungen.

Gruß und viel Erfolg

Hayo

von Guido S. (backslash)


Lesenswert?

Jörg H. schrieb:

> Das hier ist das mit Abstand vollständigste Design:
> TomCat-CII_2006_02_23.zip
> https://anonfiles.com/file/6c0d44ac02012bb14dbec405dadaae0a

> TomCat-CII_2004_06_24.zip
> https://anonfiles.com/file/0238b1032ca321333a850bed47e94e8c
> TomCat-CII_2006_10_26.zip
> https://anonfiles.com/file/7ae427ba9b7dc8ab471fabc3072ca1d3

Hallo,
nun bin ich seit ein paar Tagen ebenfalls Bezitzer eines Welec
und interessiere mich daher fuer die Innereien.
Leider habe ich auch gleich ein technisches Problem,
bei dem mir die Files von Joerg vielleicht  helfen koennten.

Leider kann man die Files nicht mehr herrunter laden.
Koennte mir daher jemand diese noch einmal zukommen lassen.
Waere echt nett !!

Gruss,
Guido

von Jörg H. (idc-dragon)


Lesenswert?

Kann ich tun (sorry daß ich auf deine PM noch nicht geantwortet hatte), 
aber was versprichst du dir davon?
Das ist unvollständig und "broken by design". Kann höchstens als 
schlechtes Beispiel dienen, wie man es nicht machen sollte (schematic 
entry statt HDL, keine Timinganalyse), bzw. dokumentieren warum Hayo 
sich mit diversen Problemen herumschlagen mußte.
Wenn dir nach FPGA-Design zumute ist (eine durchaus spannende Sache!), 
dann würde ich stattdessen sehr das neue Design von Alex und mir 
empfehlen, siehe Sourceforge. Ich kann dir auch beliebig viel dazu 
erklären, und was ich noch für Ideen habe.

Grüße
Jörg

von Blue F. (blueflash)


Lesenswert?

Hallo Guido,

schildere doch mal Dein Problem, vielleicht können wir etwas empfehlen 
oder anders weiterhelfen.

Gruß Hayo

von Guido S. (backslash)


Angehängte Dateien:

Lesenswert?

Hallo Jörg, Hallo Hayo,

danke für eure schnelle Antwort!

Wie schon gesagt, ich habe das Welec erst seit ein paar Tagen
und habe gleich die letzte Firmware von dir Hayo eingespielt.
Leider habe ich kein Backup gemacht, da ich zu spät gelesen habe,
dass man ein File selektieren muss, um ein Backup mit dem
WelecUpdater machen zu können.

Nun habe ich aber folgendes Problem auf Kanal 1 (siehe Bilder).
Abhängig vom Offset bzw angelegte Spannung habe ich ein periodische
Störung (250MHz) auf Kanal 1.
Diese Verschwindet auch bei geänderter Zeitbasis (>= 100ns).

Meine Vermutung ist, dass einer der ADCs von Kanal 1 bzw dessen 
Anbindung
an das FPGA Probleme macht. Es werden ja nur alle ADCs bei den schnellen
Messungen genutzt. Es könnte daher eine der Datenleitungen gestört sein
und nur bei Spannungen an denen diese Leitung einen anderen Pegel
haben sollte, fällt es auf.
Nun suche ich nach Möglichkeiten diesen ADC zu lokalisieren,

Wie sehr ihr es ? Könnte es auch etwas anderes sein ?

Mein Welec ist noch(!) nicht modifiziert.

Gruß,
Guido

PS.: Wie steht es eigentlich mit der NIOS2 Version ?
Gibt es schon einen Firmware Sourcecode für beide Implementierungen
(original und NIOS2) ? Das wäre doch wirklich sinnvoll.

PPS.: Ich habe nocht nicht alles zum Welec lesen können.  :-(
Sorry.

von Blue F. (blueflash)


Lesenswert?

Hi Guido,

also das fehlende Backup ist kein Problem. Den Originalzustand kannst Du 
jederzeit wieder mit Hilfe einer von uns bereitgestellten Datei 
wiederherstellen - aber glaub mir, das möchtest Du nicht. So zu Deinem 
Problem:

Evtl. kannst Du den Firmwareupload mit der aktuellen BF-Firmware noch 
einmal wiederholen, um sicher zu sein, das alles korrekt angekommen ist.

Dann auf jeden Fall das Hardwaresetup richtig einstellen! Hier können 
diverse Parameter geändert werden, die sich auch auf die ADC auswirken. 
Hier muss Folgendes bei Dir ausgewählt sein (ruhig noch mal neu 
einstellen):

ADC Setup : Factory
Pre Gain  : Factory
Gain      : 1.000
ADC Driver: Assembler

Im Darüber liegenden Menü das Delay erstmal auf 0ns einstellen, dann 
"Default Setup" drücken und dann "Calibrate Offsets".

Trigger:
Mode: Combi
Holdoff: Off

Trigger Submenü:
Pre Trigger: Trace Middle
Trig Level: Fix Position

Acquire:
Logic: Off
Average: Off
Noise Filter: Off
Interpolation: Linear
Peak Detect: Off

Poste mal deine Hardwareversion (8C7 oder so)

Probier das mal und sag Bescheid

Hayo

: Bearbeitet durch User
von Guido S. (backslash)


Lesenswert?

Hallo Hayo,

die Hardware Version ist 8C7.0H.

Ich habe die deine Firmware erneut eingespielt.
Das Ergebnis ist aber das gleiche.
Auch deine Vorgaben zu den Einstellungen habe ich überprüft.
Auch daran lag es leider nicht.

Nun habe ich gesehen, das bei 100ns eine Samplerate von 1GSA/s
auf dem Bildschirm angezeigt wird.
Dies würde bedeuten, dass alle 4 ADCs bei 100ns aktiv sind.
Da sich hier das Problem nicht zeigt, ist meine Theorie
mit den Daten-Leitungen wohl hinfällig.

Hast du noch eine Idee ?

Und vielen Dank noch einmal !!

Gruß,
Guido

von Blue F. (blueflash)


Lesenswert?

Hallo Guido,

nur nicht verzagen, wir arbeiten uns Stück für Stück ran an das Problem. 
Ob alle ADC richtig arbeiten kannst Du sehen, wenn Du von der 50ns 
Timebase mit den Störungen auf die 10ns Timebase hochschaltest. Da 
werden ebenfalls alle 4 ADC ausgewertet, aber es werden immer 4 Punkte 
zwischen jedem Sample interpoliert. Wenn hier keine Störung auftritt ist 
mit den ADC alles ok.

Jetzt erstmal zu den genauen Umständen unter denen die Störungen 
auftreten.
Wie ich gesehen habe ist der Eingang auf 5V/Div eingestellt, die 
Timebase auf 50ns.

Hast Du ein Signal anliegen?

Wie sehen die Kanaleinstellungen aus?
- Coupling
- BW Limit
- Invert

Welcher Kanal ist Triggersource?

Wie ist der Pretrigger eingestellt?

Tritt das Problem auch auf wenn die anderen Kanäle aus sind?

Was ist wenn Du durch das Memory scrollst, bleibt das dann konstant?

Tritt das nur im warmen Gerätezustand auf oder auch gleich nach dem 
Einschalten?

Fragen über Fragen...

Gruß Hayo

von Guido S. (backslash)


Lesenswert?

Hallo Hayo.

Hayo W. schrieb:
> Ob alle ADC richtig arbeiten kannst Du sehen, wenn Du von der 50ns
> Timebase mit den Störungen auf die 10ns Timebase hochschaltest. Da
> werden ebenfalls alle 4 ADC ausgewertet, aber es werden immer 4 Punkte
> zwischen jedem Sample interpoliert. Wenn hier keine Störung auftritt ist
> mit den ADC alles ok.

Die Störung existiert für alle Timebases <= 50ns
und für alle ist die Frequenz der Störung 250MHz.

Wird für Timebase > 100ns und 1GSa/s eine Mittelwert/Dämpfung
durchgeführt ? Dann könnte es ja doch ein ADC sein.

> Hast Du ein Signal anliegen?
Es liegt kein Signal an.
Ich habe aber auch schon ein Netzteil angeschlossen,
um zu sehen, ob es nicht nur vom Offset sondern auch von
der angelegten Spannung abhängt. Was auch der Fall ist.


> Wie sehen die Kanaleinstellungen aus?
> - Coupling
DC

> - BW Limit
aus und ein hat keinen Einfluss.

> - Invert
Die Störung wird mit invertiert

> Welcher Kanal ist Triggersource?
Kanal 1, habe es aber auch schon auf Kanal 2 umgestellt.
Es hatte keinen Einfluss.

> Wie ist der Pretrigger eingestellt?
linke Flanke

> Tritt das Problem auch auf wenn die anderen Kanäle aus sind?
Ist unabhängig von den Einstellungen der anderen Kanäle.

> Was ist wenn Du durch das Memory scrollst, bleibt das dann konstant?
Ja

> Tritt das nur im warmen Gerätezustand auf oder auch gleich nach dem
> Einschalten?
Gleich nach dem Einschalten.


Besteht die Möglichkeit sich die Raw-Werte der einzelnen ADCs
mit einer langsammen Frequenz anzeigen zu lassen ?
Ein 'Maintenance' Menue Punkt mit dieser Option waere echt nett.

Gruß,
Guido

von Blue F. (blueflash)


Lesenswert?

Moin Guido,

nach der aktuellen Beschreibung scheint da tatsächlich ein ADC aus der 
Reihe zu tanzen. Noch eine Frage, Du sagst es tritt abhängig vom Offset 
auf, was meinst Du damit?

Tritt es nicht auf wenn der Nullpunkt in der Bildschirmmitte liegt, oder 
wie ist das gemeint?

> Besteht die Möglichkeit sich die Raw-Werte der einzelnen ADCs
> mit einer langsammen Frequenz anzeigen zu lassen ?
> Ein 'Maintenance' Menue Punkt mit dieser Option waere echt nett.

Aber ja, das gibt es natürlich auch. Hier gibt es sogar verschiedene 
Möglichkeiten. Die einfachste Variante ist die Übertragung der Werte an 
den PC über die RS232. Das geht über das Print-Menü in Kombination mit 
dem beigelegten Programm w2000a-screenshot. Damit werden die ADC-Werte 
als *.csv Datei ausgegeben. (siehe auch ...\doc\How to make a 
screenshot.txt)

Die andere Möglichkeit ist es sich über die RS232 via Terminal zu 
verbinden und die internen Diagnosefunktionen zu benutzen. Bei mir hat 
sich dazu Teraterm sehr bewährt. Ich kann Dir auch eine eigene 
Diagnosefunktion schreiben wenn wir da weiter ins Detail gehen wollen. 
Wie man das mit dem Terminal macht findest Du in ...\doc\How to use a 
terminal.txt

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier als Beispiel die Ausgabe der Diagnosefunktion 10 via Terminal. Wird 
ausgelöst mit "Shift A". Hier kannst Du jeden einzelnen ADC-Wert sehen. 
Bei mir gemacht mit allen vier Kanälen an ohne Signal bei 50ns/Div. Also 
so wie auf Deinem ersten Bild.

Gruß Hayo

von Guido S. (backslash)


Lesenswert?

Ok, Diagnose Funktion 10 werde ich heute abend ausprobieren.
Ich bin gespannt.

Mit Offset meine ich die vertikale Verschiebung des Signals -
Wenn ich also die vertikale Position durch den Drehknopf
unter dem Kanal-1 Druck-Knopf verändere,
verändert sich auch das Maß der Störung.
Es gibt vertikale Positionen bei offenem Eingang,
an denen die Störung gar nicht zu sehen ist.

Wenn ich es richtig im Kopf habe, wird diese vertikale Position
durch den DAC, der einen Offset auf das Signal gibt, verändert.
Den gleichen Effekt habe ich, wenn ich bestimmte Spannungen
auf den Eingang lege.

Mein Vermutung ist nun, dass eine Datenleitung D5 oder D6 oder ...
eines der ADCs vom 1. Kanal gestört ist - also immer auf 0
oder auf 1 ist.
Das würde erklären, dass bei bestimmten Einstellungen/Spannungen
das Signal ok ist. Dies ist immer dann, wenn diese Daten-Leitung
bzw dieses Datenbit eben auch 0 oder auch 1 sein müßte.

In den Raw ADC Werten dieses gestörten ADCs müßte es daher
ein Bit (D5 oder D6 ...) geben, das sich nie ändert.

Eine Maintenance Funktion, die die Datenübertragung überprüft,
indem sie den DAC Wert verändert und dabei überprüft,
ob die einzelnen Bits der Raw ADC Werte sich auch verändern,
wäre hilfreich.
Wäre zum Beispiel D0 gestört, würde man es so vermutlich gar nicht 
sehen,
da sich die Auflösung nur verschlechtern würde.
Diese Maintenance Funktion würde es aber gleich zeigen.

Eine binäre Ausgabe der Raw ADC Werte wäre aber auch schon hilfreich. 
:-)

Gruß,
Guido

von Blue F. (blueflash)


Lesenswert?

Guido S. schrieb:
> Eine binäre Ausgabe der Raw ADC Werte wäre aber auch schon hilfreich.
> :-)

Kann ich einbauen, kein Problem


> Eine Maintenance Funktion, die die Datenübertragung überprüft,
> indem sie den DAC Wert verändert und dabei überprüft,
> ob die einzelnen Bits der Raw ADC Werte sich auch verändern,
> wäre hilfreich.

Lässt sich auch machen, ist aber etwas aufwändiger. Ich würde daher 
erstmal die Binärausgabe implementieren.

Hayo


p.s. Wenn das nur bei bestimmten Offsets auftritt, ist aber sicher kein 
Hardwaredefekt vorhanden. Dass die Störungen auf dem Signal mit der 
DAC-Lage variieren ist auch bekannt, aber in dieser Größenordnung ist 
das bisher noch nicht aufgetreten. Kannst Du mal ein definiertes Signal 
anlegen mit nachvollziehbarem Signallevel? Dann kann man schon mal sehen 
ob die Verstärkung stimmt.

: Bearbeitet durch User
von Guido S. (backslash)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

hier meine Diagnose 10 Ausgabe, Calibrate Offset, Diagnose 10 Ausgabe.

Kannst du mir etwas zur Bedeutung/Berechnung der
CH1 ADCx Voltage Offsets sagen.
Koennte es dort ein Problem geben ?
Bei jeder Calibrate Offset springen die Werte uebrigens zwischen
den beiden Zustaenden (siehe File: 1. und 2. Diagnose 10 Ausgabe)
hin und her.

Meine eigene Vermutung bezueglich der gestoerten Datenleitung kann ich
glaube ich fallen lassen. Es sei denn man sieht nicht die wirklichen
Raw ADC Werte.

Gruss,
Guido

von Blue F. (blueflash)


Lesenswert?

Hi Guido,

sorry bin dabei die Binär-Diagnosefunktion zu schreiben und war etwas 
nachlässig mit dem Thread hier...

Also als erstes fällt mir ins Auge, dass der ADC 2 von Kanal 1 ziemlich 
abweicht. Das ist schon erheblich.

Die Offset-Kalibrierung versucht die ADC auf den gleichen Wert zu 
bringen. Soll heißen, dass jeder ADC eine gewissse Ungenauigkeit hat, so 
dass trotz gleicher Eingangsspannung unterschiedliche Werte 
herauskommen. Das führt in der Anzeige zu einem üblen Gekräusel des 
Signals - auch als Rauschen interpretiert, da es genauso aussieht. Um 
das Signal schön glatt zu kriegen muss man diese fixen Unterschiede 
zwischen den ADC errmitteln und die gemessenen Werte entsprechend 
korrigieren. In der Regel sollte dieser Unterschied nicht größer als 3 
sein.

Was Du da siehst sind die korrigierten Werte - also nur bedingt Raw.

Gruß Hayo

von Guido S. (backslash)


Lesenswert?

Hallo Hayo,
die binäre Darstellung macht nur Sinn, wenn man wirklich die Werte
der ADCs nimmt. Nur an diesen kann man Datenleitungsprobleme sehen.

Wie werden die einzelnen ADC Offset-Werte bestimmt ?
Es sollte doch immer von den Raw ADC Werten ausgegangen werden
und so immer die gleichen Offset Werte herraus kommen,
wenn man den Offset Abgeich bei gleicher Einstellung wiederholt ?
Hier ist es aber nicht der Fall.

Sorry, fuer meine vielen Fragen, aber ich versuche das System
zu verstehen.

Mit großem Dank,
Guido

von Guido S. (backslash)


Lesenswert?

Hallo,

in anbetracht der Tatsache, dass wohl einer meiner ADCs
ordentlich aus der Reihe tanzt,
spiele ich mit dem Gednaken ihn auszutauschen.

Nun habe ich irgendwo gelesen, dass mal von einer guten Seele
ein defektes Gerät zum Auschlachten/Untersuchen frei gegeben wurde.
Meine Fragen wären nun:
Gibt es das noch ? Und falls ja, wäre es möglich, dass ich mir einen der
ADCs auslöten dürfte ?

Gruß,
Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Guido,

hier die zweite Compilation der 7.13 mit überarbeitetem Servicemenü. Mit 
der Funktion 31 (einfach Minus drücken) bekommst Du Deine Binärausgabe 
schön nach ADCs sortiert. Ausgegeben werden alle Werte im DSO-Screen 
Bereich, auch die, dezimierten Werte die nur im Speicher stehen aber 
nicht ausgegeben werden. Bei 50ns ist das aber 1:1. Das Terminalfenster 
schön weit aufziehen, die Ausgabe ist sehr breit.

Damit Du auch wirklich Raw-Werte kriegst kannst Du vorher mit Funktion 
32 (das ist das Ausrufezeichen Shift + !) alle ADC Offsets auf Null 
setzen.


Zu der Analyse des Problems. Wenn diese Störung nicht auftritt bei 
Nullpunkt in Bildschirmmitte (das hattest Du ja angedeutet), dann ist 
der ADC in Ordnung. Dann gibt es vielmehr ein Problem beim Auslesen der 
ADC-Register. Die FPGA-Programmierung ist ja bekanntermaßen ziemlich 
schlecht. Hier würde ich Dir eher empfehlen andere Versionen ins FPGA zu 
laden und zu prüfen wie es damit läuft. Hierfür brauchst Du einen Altera 
USB-Blaster (ca. 10,-).

Aber bevor Du das machst bitte mal im Hardwaremenu mit unterschiedlichen 
Einstellungen experimentieren. Da kannst Du z.B. mal den Standard ADC 
Driver nehmen statt Assembler und du kannst im ADC-Setup mal High-Frequ 
auswählen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja noch von Interesse wäre:

Tritt das nur im 5V Bereich auf oder auch im 2V/1V Bereich?




edit: Ok hat sich erledigt. An Deiner Auswertung habe ich gesehen, dass 
es auch in den anderen Bereichen auftritt. Allerdings wird die 
Kalibrierung in der Schirmmitte durchgeführt - da sollte eigentlich 
keine Störung sein, scheinbar aber doch.

: Bearbeitet durch User
von Guido S. (backslash)


Lesenswert?

Danke Hayo,

echt nett von dir!
Ich werde es heute abend ausprobieren.

Aber noch einmal zu meinen Fragen:
Wie werden die einzelnen ADC Offset-Werte genau bestimmt ?
Es sollte doch immer von den Raw ADC Werten ausgegangen werden
und so immer die fast gleichen Offset Werte herraus kommen,
wenn man den Offset Abgeich bei gleicher Einstellung wiederholt ?
Hier bei mir ist es aber nicht der Fall.

Wenn man sich die ADC Werte anschaut, so sind die Werte des
einen ADCs zwar aus der Reihe aber doch konstant.
Eine wiederholte 'Calibrate Offset' sollte daher immer
ähnliche ADCs Offsets bringen.
Dies ist aber bei mir nicht der Fall.

Den USB-Baster habe ich schon hier liegen.
Will ihn aber erst noch mit so einem billigen Cyclon2 Board
testen. Das ist aber noch nicht eingetroffen.

Gruß,
Guido

von Blue F. (blueflash)


Lesenswert?

Die Offsetkalibrierung funktioniert so:

- Nullpunkt in Bildschirmmitte setzen (ADCs sollten hier 128 ausgeben)
- pro ADC 500 Werte lesen (also insgesamt 2000)
- Mittelwerte bilden um das Rauschen herauszurechnen
- ADC mit dem kleinsten Wert ermitteln
- ADC-Korrekturwerte so berechnen dass alle ADC den Wert des vorher 
gefundenen ADC haben.

Beispiel:

- gefundene Mittelwerte 129  132  131 130
- ADC 1 hat den niedrigsten Wert mit 129
- Korrekturwerte 0  3  2  1

Die Abweichung von 128 wird dann im nächsten Schritt von der 
DAC-Korrektur beseitigt.


Bei der Acquisition wird jetzt im ADC-Treiber der Wert verrechnet

129 - 0 = 129
132 - 3 = 129
131 - 2 = 129
130 - 1 = 129

Der Wert sollte natürlich immer konstant sein, aber das Rauschen lässt 
sich nur bei einem Mittelwert mit unendlich vielen Werten 100%ig 
eliminieren. Das haben wir natürlich nicht. Daher kann es mal zu 
Abweichungen kommen. In der Regel passt es aber ganz gut.

Hayo

von Guido S. (backslash)


Lesenswert?

Könnte es sein, dass in den 500 Werten die pro ADC gemessen werden,
noch der alte, letzte ADC Offset Ausgleich mit drinnen ist ?
Das würde bei mir der das Springen der ADC Offsets bei jeder
neuen Offset Kalibrierung erklären.
z.B. Kanal1 ADC2 Offset  ~20 <-> ~0

Vor der Offset Kalibrierung und der eigentlichen Messung der Werte,
müßten die ADC Offsets auf Null gestetzt werden
oder zumindest in der Berechning berücksichtigt werden.

Guido

von Guido S. (backslash)


Lesenswert?

Oder liegt es an der DAC Korrektur ?
Wird die DAC Korrektur auf 0 gesetzt vor der
Offset Kalibrierung ?

Gruß,
Guido

von Blue F. (blueflash)


Lesenswert?

Guido S. schrieb:
> Könnte es sein, dass in den 500 Werten die pro ADC gemessen werden,
> noch der alte, letzte ADC Offset Ausgleich mit drinnen ist ?

Nein, der wird natürlich vor der Kalibrierung zurückgesetzt damit 
tatsächlich die RAW Werte ausgewertet werden. Ansonsten gäbe es ja eine 
Rückkopplung.



Guido S. schrieb:
> Wird die DAC Korrektur auf 0 gesetzt vor der
> Offset Kalibrierung ?

Nein, das ist für den Offset Abgleich der ADC nicht nötig. Es hängen ja 
alle 4 ADC an einem DAC und sind deshalb relativ gesehen auf dem 
gleichen Level.

Hayo

von Guido S. (backslash)


Lesenswert?

Hayo W. schrieb:

> Nein, das ist für den Offset Abgleich der ADC nicht nötig. Es hängen ja
> alle 4 ADC an einem DAC und sind deshalb relativ gesehen auf dem
> gleichen Level.

Verstehe. Da bei mir der ADC2 aufgrund eines defekts abhaengig
vom Offset ist, kommt es zu diesem Springen.

Und Danke Hayo !!!

Gruss,
Guido

von Guido S. (backslash)


Lesenswert?

Hallo,

meine Untersuchung hat ergeben, dass D4 am ADC2 fast immer auf 0 liegt,
obwohl sie nach den anderen ADCs auf 1 liegen sollte.
Fuer bestimmte Spannungen am Eingang des ADCs gibt er allerdings
korrekte 1 an.

Ich denke daher, dass es nicht die Verbindung zum FPGA ist,
sondern der ADC selbst. Er muesste getauscht werden.

Nun meine Fragen:
Welcher der ADCs auf der Platine ist ADC2 am Kanal 1 ?

Wurde das schon einmal gemacht ? Gibt es Erfahrung damit ?

Und gibt es vielleicht eine defekte Platine,
die ich auschlachten koennte ?

Fuer jede Hilfe waere ich dankbar.

Gruss,
Guido

von Blue F. (blueflash)



Lesenswert?

Hallo Guido,

bevor Du den ADC auslötest - die WELEC DSOs haben bekannterweise bei 
einigen Chargen schlechte Verlötungen. Das machte sich in der 
Vergangenheit meistens beim RAM-Chip bemerkbar. Um sicherzugehen, dass 
es bei Dir nicht auch evtl. eine kalte Lötstelle ist würde ich erstmal 
die ADC nachlöten. Die ADC sind thermisch sehr aktiv, wenn da ein Pin 
nicht richtig verlötet ist, kann es da schon zu wechselnden Übergängen 
kommen.

Anbei zwei Bilder mit den ADC. Der Viererblock der am dichtesten am 
Netzteil ist, gehört zu Kanal 1. Welcher der ADC jetzt welchem Bit 
zugeordnet ist kann ich leider nicht sagen. Vielleicht hat das jemand 
anders hier schon mal herausgefunden?

Gruß Hayo

von Guido S. (backslash)


Lesenswert?

Hallo Hayo,

das mit dem Nachloeten werde ich auf alle Faelle machen.

Ich habe mir ueberlegt, dass ich mir die D4 Signale anschaue.
Ich kann den Offset so stellen, das D4 am ADC2 auf 0 liegt
und an allen anderen auf 1.
Daran muesste man ihn erkennen.
Schoener waere natuerlich jemand haette das schon herraus bekommen. :-)

Etwas dumm ist, dass die ADCs eine verloetet Groundflaeche
auf der Unterseite haben.
Das heisst, alles was schmelzen koennte, muss vorher entfernt werden.
Auch die Patch Kabel auf der einen Seite. Gruml, gruml ...

By the way, hat noch jemand 4 Huckepack Platinen uebrig ?

Gruss,
Guido

von Blue F. (blueflash)


Lesenswert?

Ja da kann man nur hoffen, dass das Nachlöten Ahilfe bringt. Ansonsten 
kommst Du an einer Heißluftlötstation nicht vorbei. Ich hab mir sowas 
deshalb mal bei Zeiten zugelegt. Heikel ist das aber trotzdem. Da heißt 
es die Umgebung gut gegen Wärme abschirmen...

Guats Nächtle

Hayo

von BRUNO ALLAIN (Gast)


Lesenswert?

Hi Hayo,

Many thanks for you fast answer. I found this resistor 305k 0,1% Package 
0805 
(http://www.digikey.it/product-detail/en/TNPW0805305KBEEN/541-1892-1-ND/4271761). 
Do you think that this package is too big?


Regards

Bruno

von Blue F. (blueflash)


Lesenswert?

Hi Bruno,

yes I think that is a little bit too big - the pads are made for 0603. 
So the 0805 will cover the pads and it will be difficult to solder.

I took some 300K from an old board and measured them. One of them had 
301K. So I took a 3K9 and then soldered them as upside down "V" on the 
pads as shown on the pictures above. This works fine - although it looks 
a little bit funny.

Hayo

von Olaf (Gast)


Lesenswert?

Hallo,

ich werde bald den Umbau mit OPA653 vornehmen, habe sowohl 2 als auch 
ein 4Kanalgerät mit Fake-OPs und grünen Punkten.
Ein Schmandl SG1000 ist in Reichweite, ein DSA 815 habe ich schon und 
werde dann über den Frequenzgang berichten, falls Nachfrage da ist?

von Blue F. (blueflash)


Lesenswert?

Hallo Olaf,

ja auf jeden Fall berichten. Wenn Du Fragen hast oder auf Probleme stößt 
unterstütze ich auch gerne.

Gruß Hayo

von Olaf (Gast)


Lesenswert?

Hallo,

ja Danke, bitte noch etwas Geduld, habe den Schomandl SG1000 (gebraucht 
für 500€) gerade bekommen, bin noch am Testen,scheint ein zwar älteres 
aber gutes High-Tech-Gerät zu sein, die Frequenz-Abweichung bei 999MHz 
beträgt mit dem Spektrumanalyzer Rigol 815DS 18Hz! Die Amplitude ist 
noch schlecht, muss mir ein geeignetes Kabel organisieren, zur Zeit nur 
RG58 mit BNC und freien Drähten. Aber das Gerät funktioniert mit den 
ersten Tests, scheint aus einer Mobilfunkanlage zu kommen.

von Olaf (Gast)


Lesenswert?

Mein Meguro MSG2560B ist der Käfer, der SG1000 der Mercedes, Rigol 815 
ist auch nicht schlecht.

von Michael R. (mreck)


Lesenswert?

Hallo zusammen,
habe hier ein W2024A, das habe ich mal geschenkt bekommen, und mir das 
Ding genauer angeschaut. Da es mit der Original-Firmware nicht wirklich 
toll war habe ich die lezte Blueflash-Firmware draufgetan. Damit kann 
man für meine Zwecke ganz gut damit arbeiten, ich mache jetzt nix mit 
HF, eher ein wenig PIC-Programmieren und mal Fehlersuche in 
RS485-Netzwerken.

Was mir aufgefallen ist: Das Gerät misst die Spannung falsch. Auf jedem 
Kanal und in jeder Spannungsskalierung zeigt es mir nur ca. 4/5 vom Wert 
an, also bei 2V/div bin ich bei 5V ziemlich genau an der zweiten 
Linie...

Gibt es eine Möglichkeit das zu kalibrieren?

Danke & Gruß
Michael

von Michael R. (mreck)


Lesenswert?

Okay, hab es gefunden, hab den Gain entsprechend angepasst, jetzt stimmt 
es :-)

von Michael D. (mike0815)


Lesenswert?

Utility--> More --> Hardware --> Pre Gain --> "Factory" (wenn du keine 
Hardwaremodifikation hast)
kannst da auch noch ein wenig in diesem Menu rumspielen, wenn du 
möchtest.
Ansonsten könnte auch dein Tastkopf den Fehler verursachen

Gruß Michael

: Bearbeitet durch User
von Michael D. (mike0815)


Lesenswert?

Da war ich ja gar nicht so verkehrt. Welchen Wert hatte den dein Gain, 
bzw. hat er jetzt?

von Blue F. (blueflash)


Lesenswert?

Ja genau!

Oder hier mal kurz schauen, da hatte ich das auch erklärt - in Englisch.

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"

Wenn alles richtig eingestellt ist, sollte Gain 1,000 ziemlich genau 
passen.
Wenn Du da größere Abweichungen hast ist noch irgendwas falsch 
eingestellt.
Und natürlich die Autokalibrierung durchlaufen lassen. Am Besten, wenn 
das Gerät schon etwas warm ist.

Evtl. ist da eine frühe Mod mit dem Abschlusswiderstand drin (24Ohm oder 
33Ohm). Die wird nicht mehr unterstützt, da nicht so wirksam. Es gibt 
aber noch eine Einstellung für 24Ohm mit 180Ohm Querwiderstand.

Gruß Hayo

: Bearbeitet durch User
von Michael R. (mreck)


Lesenswert?

Hallo zusammen,

danke, das ging ja super-schnell. Ich hatte 1,26 drin, da war beim 
Pre-Gain nicht Factory drin sondern LB Mod. Mit Factory passt es mit 1 
beim Pre-Gain wieder... das kommt davon wenn man auf alle Knöpfe drückt 
;-)

Gruß
Michael

von Michael R. (mreck)


Lesenswert?

Ich muss mich mal in die Threads einlesen, jetzt hab ich bei 1V/div mehr 
Rauschen drauf als mit 500mV/div, aber ich glaube das ist Thema einer 
der Umbauten, oder?

von Blue F. (blueflash)


Lesenswert?

Jupp,

der 1V und 2V Bereich haben mehr Rauschen, weil der ADC hier ungünstiger 
ausgesteuert wird als im 5V Berreich. Es gibt einige Mods, die da 
weiterhelfen können. Kennst Du den Download Link auf Source Forge? Dort 
liegen die Umbauanleitungen.

https://sourceforge.net/projects/welecw2000a/files/

Gruß Hayo

Beitrag #5326683 wurde vom Autor gelöscht.
von Josef F. (jofri)


Lesenswert?

Hallo Hayo,
Mein laut Typenschild W2012 / 100MHz hat mir, nicht zuletzt Dank deiner 
Software, in den vergangenen Jahren wertvolle Dienste geleistet. Die 
Genauigkeit war, für meine Hobbyprojekte auch ohne Hardware-Umbauten 
bisher ausreichend
Da ich mich derzeit mit Power-Mosfet beschäftige und 
Flanken-Anstiegzeiten vermesse, habe ich doch eine Hardware-Verbesserung 
in Erwägung gezogen.
Bevor ich endgültig alles zerlege hätte ich, trotz deiner sehr 
ausführlichen Umbauanleitungen noch ein paar Fragen.

Bei der Initialisierung werden folgende Daten ausgegeben.

Model:      W2012A
Hardware Version:  8C7.0E
Software Version:  1.2.BF.7.14
Serial Number  :  09115302C7
Flash ID:    C293

Wenn man den OPA656 - Umbau macht, wird dann als Model ein W2022A 
erkannt.
Kann man den OPA656 für die ext. Trigger Eingangsschaltung auch 
verwenden, oder ist zwingend ein 653 einzusetzen.
Ist eine Firmware-Änderung bei FPGA auch erforderlich.

recht herzlichen Dank für deine Mühe

Josef

von Blue F. (blueflash)


Lesenswert?

In Häppchen:

- Die Erkennung kann nicht von der Firmware selbst erfolgen. Man kann 
aber per Terminal im Flash die Kennung umsetzen. Eine kurze Anleitung 
habe ich auch in einer der Doku-Dateien hinterlegt (müsste ich noch mal 
schauen).

- Der Unterschied zwischen der W2022A und W2012A Version ist ein - sagen 
wir mal - Fake-Transistor. Laut Aufdruck sind sie identisch, aber in der 
Messung weichen sie stark voneinander ab. Der "schlechtere" ist am 
grünen Punkt zu erkennen. Offiziell gibt es diese schlechteren 
Transistoren gar nicht zu kaufen. Keine Ahnung woher Wittig die hat 
(Chinaversion?). Ein Austausch der OPA656 gegen originale Bauteile kann 
also in diesem Falle Einiges bewirken.

- Der externe Triggereingang lässt sich ausschließlich mit dem OPA656 
bestücken. Hier passt der OPA653 wegen seiner internen Beschaltung 
leider nicht. Aber die Bestückung mit dem originalen Bauteil ist auch 
hier von Vorteil.

Wenn Du noch Fragen hast oder Tips für die Umrüstung brauchst - nur zu.

Gruß Hayo

von K-H J. (k-h)


Lesenswert?

Hallo zusammen,

habe gelesen das einige hier ganz fit sind mit dem Update der Welec
Oszilloskope.
Wir haben ein 4 Kanal 2024A bei uns rumstehen. Da hat irgendwann mal der
Netzschalter gestreikt und wir haben diesen überbrückt damit es noch
funktionierte. Das Gerät wird nur selten genutzt.
Würde jemand aus dem Forum in das Gerät gegen ein kleines Entgelt wieder
einen Hauptschalter einbauen und ein Softwareupdate aufspielen.

Wäre nett wenn sich jemand meldet.

Gruss

K-H

von Blue F. (blueflash)


Lesenswert?

Moin,

war leider etwas busy die letzen Tage, daher die späte Antwort. Der 
Netzschalter ist als Schwachpunkt bekannt. In frühren Hardwarebeiträgen 
ist über den Austausch und die Bezugsquelle baugleicher aber 
höherwertiger Schalter berichtet worden. Der Austausch ist relativ 
einfach (meine beiden Geräte haben auch schon einen neuen Schalter). Das 
Zerlegen des Oszi ist ebenfalls in etlichen Unterlagen (siehe Source 
Forge Download) und Beiträgen gut erklärt.

Für das Firmware-Update brauchst Du nur einen PC mit RS232 Schnittstelle 
oder einen entsprechenden Adapter. Ist also echt easy. Geht auch ohne 
den neuen Netzschalter, wenn Du den Alten überbrückt hast.

Traust Du Dir das nicht zu, oder hast Du einfach keine Zeit dafür? Bei 
Bedarf gebe ich auch gerne noch weitere Hilfestellung zu beiden Themen.

Gruß Hayo

von Slava Y. (gnsrl)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

Recently I've got two defective oscilloscopes Wittig W2012 (without 
letter "A"). First of all I fixed two cold solder on RAM (interesting 
that both osci had exactly the same problem chip and the same problem 
pins). What I performed after:

- wrote FW to ESCP16 for HW version 2022A
- added letter "A" to label 2012 (guess that I performed it in a right 
way, because I did not find clear instructions how to do it)
- performed LB-mod
- performed Ext-trig-mod
- performed LED-mod
- wrote FW 1.2.BF.7.15
- virtually thanked to the people who worked at the forum before (now I 
can just in one click get a lot of information and SW)

What I have now. Two good oscilloscopes with admissible noise level, 
operating external trigger and good FW. I performed a lot of test 
procedures and what I figured out. Practically oscilloscopes operate 
normally up to 5-10 MHz. If I apply signal with higher frequency I watch 
some interference. Independently of time base and time offset 
interference is approx 15-20 ns duration. Thе higher the frequency  the 
more often appeares interference. For example with 5 MHz signal 
interference appeares approx one time per 2-3 seconds. With 30 MHz 
signal interference appeares approx 2-3 times per seconds. And so on. 
Interference appeares on both channels simulteneously and has approx the 
same shape on both channels. Interference did not (!) appeares in Free 
Run mode or Ext Trig. Interference appears when synchro mode are channel 
1,  channel 2, auto or combi.

What is interesting. I whatched signal at ADC (MAX1121) input with 
another oscilloscope. There were no any interferences! But on the screen 
they are present. And one more. Both channels have the same problem. And 
both oscilloscopes have the same problem.

For me quite difficult to understand the problem because I don't know 
was it before repairing and modifications or not.

Questions to experts. What is the principle of synchronization from 
signal itself (I mean from channel 1 or 2)? Where I can find diagram for 
internal synchronization (at the forum I found diagram just only for 
external synchronization)?

Best regards
Slava

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Slava - congratulation - well done!

Which hardware version did you choose for your upgrade? The 8C7.x.x 
seems to be the better one. Just for information and help, which RAM 
(the inner one  or the RAM near the display connector) and which pins 
exactly were the problem pins?

The distortion at Signal beginning is a result of bad trigger 
implementation in the FPGA. As you can see on the screenshots it occurs 
on my devices also. Here for comparison:

- 8C7.0.J -> the unmodified W2022A
- 8C7.0.G -> OPA653 Mod (W2022A)
- 8C7.0.L -> LB Mod (W2024A)

It is all the same - with one difference: The unmodified 8C7.0.J is 
bothered with mighty spikes during the warm up time. After warming up 
they disappear.

Kind regards
Hayo

: Bearbeitet durch User
von Slava Y. (gnsrl)


Angehängte Dateien:

Lesenswert?

Hello Hayo,

Concerning RAM problem. There were two cold soldered pins (pin 43 A16 
and pin 44 A17) on the inner chip (see photo). They are corner pins. I 
think this is common technological problem of soldering or overheating 
point. Unfortunatelly or not, but I found information about RAM problem 
at the forum after fixing the problem. I did a lot of experiments to 
figured out what is with RAM and what are the pins exactly broken. Even 
wrote software for Windows to analyze RAM through GERMS-monitor. If it 
is needed for somebody I can share it in someway. However now I 
understand that much simplier way just solder all the pins than analyze 
RAM pattern to define exact pins :).

Concerning HW version. Unfortunatelly, I don't know exactly what HW 
version I have. I downloaded from the forum or SourceForge file 
EPCS16_W2022A.pof. It looks like the version is 8C7 because W2022A with 
letter "A". I wrote this file to EPCS16. Then I wrote to protected area 
of flash information from some W2022A.flash file (because during repair 
I erased flash totally). So, now I have label  8C7.0.G on the screen and 
undefined version inside EPCS16. Maybe that version 8C7.0.J, because I 
also observed that mighty spikes during warming up.

So, I have a couple of questions again.
What HW version is better to write to EPCS16? As I understand 8C7.0.G. 
In this case spikes will not appear any more during warming up?
What information is better to write to protected area of flash? Is this 
information just for watching on the screen only or FW is using it?

Best regards
Slava

von Blue F. (blueflash)


Lesenswert?

Slava Y. schrieb:
> Concerning RAM problem. There were two cold soldered pins (pin 43 A16
> and pin 44 A17) on the inner chip (see photo). They are corner pins.

That's good to know for quick testing. The problem with cold soldered 
pins of the RAM is well known here. Often the effect are stripes on the 
screen - that is because the display output is mapped to a RAM area.

> Even wrote software for Windows to analyze RAM through GERMS-monitor. If
> it is needed for somebody I can share it in someway. However now I
> understand that much simplier way just solder all the pins than
> analyze RAM pattern to define exact pins :).

Indeed it is simplier to solder all pins - but that seems to be a cool 
tool for analysing the correct function of the RAM. If you send it to me 
with a short description how it works I will upload it in our W2000A 
section on Source Forge. I'm sure it will be of good use for someone who 
has problems with his device because you can analyze without 
disassembling it.

> Concerning HW version. Unfortunatelly, I don't know exactly what HW
> version I have.

The version which is displayed on the screen is the real HW version. 
That's because the hardware ID is part of the FPGA design. The firmware 
is reading it directly from the FPGA.

> What HW version is better to write to EPCS16?

Any 8C7.x.x will be ok - not so good is the 1C9.x.x which seems to be an 
older version. We determined problems with the signal acquisition 
(shifted and interchanged bits, spikes etc.) Also see (in german)

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"

> What information is better to write to protected area of flash? Is this
> information just for watching on the screen only or FW is using it?

I don't exactly understand what you want to write to the flash. The 
protected area contains parameters and values for some registers etc. 
That is important for correct working of the device (yes firmware is 
using it at startup) - so it should not be overwritten. Otherwise, if 
you have a backup from this area you can restore it without problems.

Kind regards
Hayo

von Slava Y. (gnsrl)


Lesenswert?

Hello Hayo,

when I wrote about protected area of flash I meant what is better: to 
write there information from another oscilloscope with HW version 8C7.xx 
or leave original information? I followed steps PycLan from russian IXBT 
forum. There he copied protected sector from W2012A to W2012 after 
modification. In principle, you clarified me what kind of information 
where is situated. I'll experiment with this later.

I have one more question. It's about COM port in the oscilloscope. I was 
fixing the oscilloscopes for two weeks. All the time I switched on/off 
them, connected and disconnected cables from COM-ports, transferred 
through COM-ports a lot of data. Everything was excellent, any errors!
After fixing, modifications and experiments I assambled the oscilloscope 
(normally screwed it) and connect null-modem cable. And it didn't work. 
I connected the second assembled oscilloscope and it didn't work too. 
After disassembling the oscilloscopes and measuring I figured out that 
TX-out RS-232 line is broken. In two oscilloscopes simulteneously! And 
the same defect! -6 V is reached at this line, but + 6 V is not reached. 
Maximum 3.5 V with signal distortion.
I already ordered SP3220 and I will fix it. It is not a problem. But I 
want to figure out what happened. Was that ESD or potential difference 
between PC and oscilloscope? Or what? I suspect maybe I connected cable 
to oscilloscope when both PC and oscilloscopes were working. Is it 
important to connect cable only when devices are switched off? What do 
you say from your experience?

Best regards.
Slava.

: Bearbeitet durch User
von Blue F. (blueflash)


Lesenswert?

Hello Slava,

> is better: to write there information from another oscilloscope with HW > > 
version 8C7.xx or leave original information?

Due to the new "hardware configuration" in the FPGA it will be better to 
copy the protected flash from another 8C7 oscilloscope if available. If 
you don't have any -> no problem, I can upload.

> But I want to figure out what happened. Was that ESD or potential
> difference between PC and oscilloscope? Or what?

Hmmm... there is no known case here with such a problem (if I'm wrong - 
please report). I connected and disconnected my devices for years in 
every working condition - without any problems. So I guess there must be 
a problem with your PC-Port or you made a mistake while modifying your 
external trigger.

Kind regards
Hayo

von Slava Y. (gnsrl)


Lesenswert?

Hayo, thanks a lot for information! Hope, I will fix the port.

Best regards.
Slava.

von Slava Y. (gnsrl)


Angehängte Dateien:

Lesenswert?

Hi Hayo,
Hi All,

     There is a short report about replacing COM port chip SP3220. I 
wrote before that recently I found my COM ports broken in two 
oscilloscopes simultaneously. After replacing the chips COM ports are 
working properly. So, chips were broken. That is definitely. Why? I 
still don't know. Maybe there was some potential difference between 
oscilloscope and PC. Maybe they were powered from different sockets (one 
with grounding and another without it). Hope, that this will not happen 
again.
     For information 1. There is a possibility replace the chip not only 
with original wide SOIC package but to use narrow SOIC one. See attached 
photo.
     For information 2. One chip I replaced with original one. And one 
chip I replaced with FT232 USB UART chip. That was an idea to have 
built-in USB-COM adapter. I used some old board with FT232 and USB 
connector. This built-in USB-COM works properly but three times slower! 
I don't know why. Maybe it needs some additional configuration. So, my 
advise to whom wants to do the same. Just use standard USB-COM adapter. 
It will be much easier :) I tested my separate USB-COM adapter. It works 
correct, without any delays.

Best regards.
Slava.

von Blue F. (blueflash)


Lesenswert?

Little hint for the display: In the case your screen displays funny 
things which shouldn't be displayed normally there may be a contact 
problem with the display plug from the display to the PCB (can be seen 
with opened DSO).
In my case there was a green haze on the display. Some times only below 
- some times on the whole screen. So I unplugged it one, two times and 
waggled a bit - solved! So the RAM is not always the problem...



Kleiner Tip in Sachen Display: Wenn das Display komische Sachen anzeigt, 
kann der Stecker vom Display zur Platine (bei geöffnetem DSO direkt 
zugänglich) Kontaktschwierigkeiten haben. Bei mir äußerte sich das durch 
einen grünen Schleier auf dem Display. Mal nur im unteren Bereich, mal 
auf dem ganzen Display. Stecker ein, zwei mal rausgezogen und ein 
bißchen gewackelt und schon war das erledigt. Muss also nicht immer das 
RAM sein...

Hayo

von Slava Y. (gnsrl)


Lesenswert?

+100% Ich hatte das gleiche Problem und die gleiche Lösung. :)

von Jürgen R. (rupy)


Angehängte Dateien:

Lesenswert?

Hallo,
cool, dass ihr schon über 10 Jahre aktiv seit.
Ich habe schon in der Software Ecke kurz beschrieben welche Symptome 
mein Welec W2014A Oszi so zeigt. Nun noch eine frage in die Hardware 
Ecke.
Ich habe die Spannungen auf den Bild im 
sourceforge.net/projects/welecw2000a/files/Hardware/Original/Voltage_Sup 
ply_001.png  einmal mit meinen verglichen und bei mir habe ich völlig 
andere Spannungen gemessen. Meine zwischen 1,2....5V
Sind die Spannungen gegen Masse gemessen?
Wird die Masse wirklich nur über das Chassis verbunden?

Gruß
Jürgen

von Jürgen R. (rupy)


Lesenswert?

Hallo,
ziehe meine Frage zurück.
Wer lesen kann ist klar im Vorteil.
Die Spannungen wurden gegen schwarz Lüfter gemessen, dann stimmen sie 
mit
meinen Spannungen überein und GND wird auch über die Steckverbindung 
geleitet.

Gruß
Jürgen

von Yutie (Gast)


Lesenswert?

Hallo!

Ich habe seit vielen Jahren auch ein W2022A, welches bis heute klaglos 
seinen Dienst verrichtet hat. Vor ein paar Jahren musste ich mal das 
Schaltnetzteil überarbeiten, weil die Elkos breit waren. Ich machte da 
gleich den LB-Mod.
Seit heute geht es leider nicht mehr. Nach dem Einschalten ist nur noch 
ein schwarzer Bildschirm zu sehen und "Run" leuchtet. Auch das Drücken 
der äußeren Tasten um in den GERMS zu kommen, klappt nicht.
Woran könnte es liegen?

Gruß,
Yutie

von Blue F. (blueflash)


Lesenswert?

Hi Yutie!

Das ist natürlich nicht so einfach zu beantworten, da es mehrere 
Möglichkeiten gibt. Grundsätzlich sehr wahrscheinlich: Kontaktprobleme.

Wenn Du Glück hast, sind es nur Steckkontakte, die etwas rumzicken. So 
war bei mir z.B. der Stecker für das Display etwas bockig. Da habe ich 
dann mal dran gewackelt und es war wieder gut. Man kommt da gut dran 
wenn man hinten den Deckel abnimmt. Sonst einfach die Kiste komplett 
einmal auseinanderbauen und wieder zusammensetzen. Danach sollten die 
Kontakte erstmal ok sein.

Weitere Möglichkeit: kalte Lötstellen, die nach längerer Zeit etwas 
oxidiert sind. Schwieriger zu finden. Üblicher Verdächtiger - das RAM.

Evtl. mal die Spannungen am Netzteil durchmessen, ob alle korrekt sind. 
Du hattest da ja schon mal Probleme...

Du must Dich also systematisch durch die einzelnen Punkte durch 
arbeiten.

Gruß Hayo

von Yutie (Gast)


Lesenswert?

Hallo!

Vielen Dank für die Antwort.
Ich habe mitterweile rausbekommen, daß beim Drücken der beiden linken 
Tasten das Oszi in den GERMS geht. Beim Verlassen des Modus sind dann 
mehrere LEDs (zufällig) aktiv, aber der Bildschirm bleibt schwarz. Ich 
werde mal den RAM nachlöten. Auf den ersten Blick ließ sich aber nichts 
erkennen.
Ich denke mittlerweile auch, daß es mit dem RAM zu tun hat.

Gruß, Yutie

von Blue F. (blueflash)


Lesenswert?

Wenn Du den Germs starten kannst, läuft auch der Prozessor. Dann würde 
ich empfehlen, erstmal auf weitere Lebenszeichen zu testen.

Dazu kannst Du das Oszi via seriellem RS232 Kabel an den Rechner 
anschließen und per Terminal (Teraterm oder so) die Ausgaben prüfen. Da 
sollte dann beim Start gleich eine Meldung des Oszis erscheinen. Danach 
kannst Du dann per Tastatur einzelne Prüfroutinen aufrufen.

Außerdem haben wir mittlerweile zwei Optionen um das RAM zu testen. 
Beide findest Du auf SourceForge im Downloadbereich.

Hast Du mal am Displaystecker gewackelt?

Gruß und viel Erfolg
Hayo

von Yutie (Gast)


Lesenswert?

Hallo nochmals,

Ich habe jetzt das Oszi mal per Serieller Schnittstelle an den Rechner 
angeschlossen.
Es gibt "+C CPU048" aus und mehr nicht.
Ein versuchter Firmware-Flash quittiert der Updater mit "Timeout at 
line24"

Offenbar ist da wohl die CPU hinüber. Da, wo die CPU sitzt, wird es auch 
recht warm.
Kann ich sonst noch irgendetwas versuchen?

Gruß,
Yutie

von Yutie (Gast)


Lesenswert?

Und ja, am Displaystecker habe ich gewackelt.
Frage: Auf der Bottom-Seite, also die mit den Relais, ist ein 
Schaltkreis an zwei Pins kurzgeschlossen (Zinnbrücke). Muss das so sein?
Den RAM habe ich auch nachgelötet. Fehlanzeige.

von Blue F. (blueflash)


Lesenswert?

Im Downloadbereich von SF gibt es Fotos der einzelnen Platinen. Da 
kannst Du prüfen ob bei Dir was anders ist als normal.

Gruß Hayo

von Yutie (Gast)


Lesenswert?

Hallo nochmals.

Ich habe mir nun nen chinesisches Schätzeisen (250 MHz, 4-Kanal) als 
Ersatz fürs W2022A besorgt.
Daraufhin habe ich mir mal so ein paar Signale angesehen und 
durchgemessen.
Die Spannungen stimmen soweit, mit Ausnahme der 7,73V ganz rechts gegen 
Lüfterkabel. Da sinds bei mir nur 7,2V.
Mit dem neuen Oszi habe ich mal den 24-MHz-Quarz getestet. Er schwingt 
recht sauber auf seinen 24 MHz. Am RAM kann ich an A0 bis 15 einen 
Rechteck sehen und der "zuckt" manchmal auch.
An den Clock-Pins der ADCs messe ich nichts. Müsste da nicht auch ein 
Taktsignal sein?
Die von mir erwähnte Zinnbrücke ist offenbar normal. Die ist auf den 
Bildern bei SF.net auch zu sehen.

Was bewirken eigentlich die beiden Taster auf dem Mainboard?

von Blue F. (blueflash)


Lesenswert?

An die Taster kann ich mich jetzt nicht erinnern um ehrlich zu sein. 
Aber noch eine Frage...
Hast Du mal über ein Terminal geguckt welche Meldungen beim Start 
ausgegeben werden?

Wenn Du den Germs starten kannst, kannst Du auch mal versuchen die 
Firmware zu flashen. Das sagt ja auch schon mal was aus. wenn es 
funktioniert.

Gruß Hayo

von Yutie (Gast)


Lesenswert?

Hallo.

Also im Terminal steht "+C CPU048" und mehr passiert leider nicht. Die 
Baudrate sind 112,5 kBaud, nehme ich an.

Einen Flash quittiert der Flasher mit "Timeout at Line 24".

Ich mache mir keine Hoffnungen mehr. Hier hats irgendwas wichtiges 
zerschossen.

von Blue F. (blueflash)


Lesenswert?

Hi Yutie,

die genauen Infos zum Terminal findest Du in der mitgelieferten Doku 
"How to use a terminal"

Auf die Kürze hier die wichtigsten Daten:

Baud Rate:    115200
Data:     8 bit
Parity:   None
Stop:    1 bit
Flow control:  None

Wenn keine brauchbare Ausgabe erfolgt, kann das am FPGA oder am Speicher 
liegen. Da sich die Firmware nicht flashen lässt vermute ich das Problem 
beim FPGA (bzw. beim EEPROM für das FPGA). Mit dem Altera Blaster an der 
JTAG-Pfostenleiste kannst Du den NIOS-Core und die Peripherie neu drauf 
laden - oder auch nicht, wenn das EEPROM irgendwo ein kaltes Beinchen 
hat. Evtl. reicht es die EEPROM-Beinchen nach zu löten. Vielleicht geht 
es dann wieder. Wegschmeißen kannst Du es immer noch...

Gruß Hayo

von Jürgen R. (rupy)


Lesenswert?

Hallo Yutie,
wenn du es wegwerfen willst melde dich vorher bei mir.
Hoffnungslose Fälle sind meine Spezialität :-).
Hallo Hayo es wird hier nicht langweilig.

Gruß
Jürgen

von Yutie (Gast)


Lesenswert?

Hallo nochmals.

Danke für das Angebot. Vielleicht komme ich darauf zurück.
Ich habe jetzt mal den LB-Mod rückgängig gemacht, bzw. die 
entsprechenden Teile ausgelötet. Gebracht hats nichts. War halt nur so 
nen Gedanke von mir.
Das EEPROM...
Ich habe bereits den Flash und die beiden RAM nachgelötet. Das EEPROM 
muss ich erstmal suchen. Spontan wüsste ich nicht, wo das ist.

Gruß,
Yutie

von Yutie (Gast)


Lesenswert?

Hallo und ein (verspätetes) gesundes, neues Jahr!

Ich weiß mit dem Oszi nicht mehr weiter und würde gern das Angebot von 
Jürgen R. annehmen. Vielleicht kann er es retten.

Gruß,
Yutie

von Jürgen R. (rupy)


Lesenswert?

Hallo Yutie,
schade, dass du nicht weiter kommst.
Schicke mir eine PN.

Gruß
Jürgen

von Jürgen R. (rupy)


Lesenswert?

Als Gast kannst du ja keine PN schicken.
meine Mail Adresse juergen-rusies ät vodafone punkt de

Gruß
Jürgen

von yutie (Gast)


Lesenswert?

Hallo rupy!
Email geht raus. Ich hoffe sehr, daß du den Fehler finden kannst.

Gruß,
Yutie

von Jürgen R. (rupy)


Lesenswert?

Hallo hab Yutie's Oszi bekommen,
wie schon erwähnt keine Anzeige.
Habe Rams und Eproms nachgelötet ohne Verbesserung.
Der Ramtest zeigt sofort Fehler, alle LED's leuchten nach upload.
Habe gelesen, dass der Ramtest über die serielle Schnittstelle 
Statusmeldungen ausgibt eventuell erfahre ich da näheres.
GERMS scheint zu klappen und das Flashen über Jtac auch sonst käme ja 
beim upload vom Ramtest ein Fehler.

Gruß
Jürgen

von Jürgen R. (rupy)


Angehängte Dateien:

Lesenswert?

Hallo,
ich habe die Spannungen geprüft alle OK das Bild im SF ist verwirrend 
habe mal ein neues gemacht mit den Spannungen gegen GND und den dazu 
gehörigen Spannungsbereiche der Bauteile.
Flashen konnte aber nur mit der W2022A.jic Datei. Keine Änderung.
Was ist der Unterschied zwischen W2022A.jic und EPCS16_W2022A.pof.
Wozu ist die 24LC64.iic und wie kann ich diese flashen.
GERMS Loader hat auch geklappt hat zwar einmal mit Übertragungsfehler 
gestoppt, aber lief nach erneuter GERMS Aktivierung weiter.
Der Ramtest bringt sofort Fehler und im seriellen Monitor Unmengen an
fehlerhaften Bitwerten. Aktivieren der LCD Anzeige zeigt schwarz-weiß 
verschneiten Bildschirm ist aber statisch.
Das obere Ram habe ich aber schon nachgelötet und durchgemessen.
Seltsam ist auch, dass nach einem Neustart keine Aktivität am Ram zu 
messen ist als ob kein Programm laufen würde.

Gruß
Jürgen

von Jürgen R. (rupy)


Angehängte Dateien:

Lesenswert?

Hallo
bin ich gut oder bin ich gut :-)
Ram und Flash noch einmal überprüft ein paar Lötbrücken entfernt und 
nochmal nach gelötet.Ramtest lief ohne Fehler durch und diesmal mit 
dynamischen Schneegestöber. Neu geflasht und Software aufgespielt.
Siehe da. Jetzt muss ich nur noch den demontierten LB-Mod wieder 
herstellen,
dann sollte es wieder funktionieren.

Gruß
Jürgen

von Yutie (Gast)


Lesenswert?

Vielen, vielen Dank :-)

von Yutie (Gast)


Lesenswert?

Da ich als Gast nicht editieren kann:

Ich möchte auch ganz herzlich blueflash für seine Arbeit an der Firmware 
danken, die mittlerweile echt ausgereift und stabil ist.
blueflash's Arbeit an der Firmware ist echt Gold wert und kein Vergleich 
zum Original.

von Jürgen R. (rupy)


Lesenswert?

Lieder nur Punkt A der Tagesordnung :-(
Kanal 1 nur Linie am Minimum. Yutie sprach von einer Unterbrechung, 
gelöste Leiterbahn beim Rückbau.
Beim Kanal 2 alles andere nur keine anständige Anzeige, ähnlich wie bei 
meinen.
Ich tippe auf kalte Lötstellen am ADC.

Gruß
Jürgen

von Blue F. (blueflash)


Lesenswert?

Hallo Ihr Beiden,

auch wenn ich mich gerade mit ganz anderen Themen rumschlage, verfolge 
ich das hier natürlich aufmerksam. Das Thema kalte Lötstellen scheint ja 
auf jeden Fall das Problem Nr. 1 zu sein bei unseren Geräten. Zum Glück 
haben meine beiden da noch keine Anzeichen gehabt (klopf auf Holz...).

@Yutie
Danke für das Lob - ich muss allerdings darauf hinweisen dass auch noch 
etliche andere Mitstreiter sich sehr verdient gemacht haben bei der 
Entwicklung einer benutzbaren Firmware. Nicht zuletzt die ganze 
Testergemeinde, die unermüdlich jede Neuerung unter die Lupe genommen 
hat.

Gruß Hayo

von Gustl B. (-gb-)


Lesenswert?

Hallo zusammen,

ich habe kein solches Oszi, aber ich bastel selber mit schnellen ADCs 
und FPGAs. Gibt es hier irgendwo die vollständige Schaltung für das 
Analog Frontend? Und macht das Sinn diese nachzubauen wenn ich selbst 
ein 200 MHz Oszi bauen möchte oder gibt es deutlich bessere Frontend 
Schaltungen?

Vielen Dank!

von Blue F. (blueflash)


Lesenswert?

Hallo Gustl,

die originale Schaltung ist zum Teil ziemlicher Mist. Aus diesem Grund 
gibt es mehrere Ansätze (mit Dokumentation) um hier Abhilfe zu schaffen. 
Das geht von Umdimensionierung passiver Bauteile über Austausch des 
Eingangs-OPA bis zu einer kompletten kleinen Platine mit aktiver 
Eingangsschaltung.

Mit diesen Modifikationen ist das Ganze eigentlich recht brauchbar. Auf 
jeden Fall kann man durch die dokumentierten Modifikationen was zu dem 
Thema lernen und sich evtl. auch abgucken.

Die Dokus und Schaltpläne dazu findest Du auf Sourceforge:

https://sourceforge.net/projects/welecw2000a/files/Hardware/

Gruß Hayo

von Gustl B. (-gb-)


Lesenswert?

Vielen Dank, dann gucke ich mir das mal mit Vorsicht an.

von Jürgen R. (rupy)


Lesenswert?

Hallo,
Yutie's Oszi scheint im Analogsektor wirklich einen oder mehrere Defekte 
zu haben.Die Spannungen an den OPA's sind alle OK.
Beim Kanal 1 habe ich am Ausgang vom OPA1177 (U2) immer DC und kein 
Signal.
Beim Kanal 2 habe ich am Ausgang vom letzten AD8131 (U12) an Pin 4 
Signal und an Pin 5 DC. Keine Lötbrücken oder Unterbrechungen zu messen.
Wild Bauteile Tauschen möchte ich nicht, also gebe ich leider an der 
Stelle auf.

Gruß
Jürgen

von Jürgen R. (rupy)


Angehängte Dateien:

Lesenswert?

Hallo,
hab es doch noch reparieren können. :-)
Wieder waren die ADC's die Übeltäter und diesmal auch das RAM.

Gruß
Jürgen

von Yutie (Gast)


Lesenswert?

Vielen, vielen Dank

Auf die ADCs und das RAM wäre ich nie gekommen.

Danke =)

von Blue F. (blueflash)


Lesenswert?

Na das nenne ich mal wieder gute Arbeit!

Aber eigentlich ist die Ursache nicht überraschend - das RAM ist schief 
aufgelötet und hat an einigen Füßen nur minimale Auflagefläche, die ADC 
werden sehr warm, was durch thermische Ausdehnung zu einer mechanischen 
Belastung der Löt-Pads führt. Deshalb hatten ja auch einige (ich auch) 
die ADC mit Kühlkörpern versehen. Das reduziert den Effekt schon um 
Einiges.
Nachteil - wenn man die Kühlkörper aufklebt, kommt man an die Pins nicht 
mehr ran. Aber irgendwas ist ja immer...

Gruß Hayo

: Bearbeitet durch User
von Yutie (Gast)


Lesenswert?

Hallo nochmals!

Das Oszi ist heil wieder zuhause angekommen. Ich habe noch die 
Schirmbleche wieder montiert (daß ich die beim letzten Öffnen 
weggelassen habe, hatte ich wohl vergessen) und das Oszi wieder 
eingeschalten. Es läuft wieder wunderbar.

Die Firmware zeigt mittlerweile auch kaum noch Macken, zumindest für 
meinen Gebrauch nicht. Man kann es auch quasi mit einer hohen Frequenz 
"überladen", also den Bildschirm vollzeichnen lassen, ohne daß es 
ruckelt oder stockt. Ich meine, man nennt das "Overdraw". Das ist für 
viele chinesische Qualitätsprodukte nämlich ein Problem.

Ich bin vom Gerät immer wieder begeistert.

Als ich damals ein Oszi suchte, habe ich mich ganz bewusst für das 
Wittig entschieden. Nicht, weil es recht günstig war (um die 300€), 
sondern weil es eine offene Firmware besitzt, die aktiv entwickelt wird.

Was ich gern noch in der Firmware hätte, wäre eine Art Logikanalysator, 
z.B. für RS232, I²C oder USB, der die Pakete quasi "entschlüsseln" kann, 
also z.B. die Bedeutung eines Pakets als Hex-Zahl auswertet. Das würde 
das Debuggen in digitalen Schaltungen etwas erleichtern. Ich weiß, daß 
es das bereits in vereinfachter Weise gibt.

Vielen Dank nochmals und viele Grüße,
Yutie

von Jürgen R. (rupy)


Lesenswert?

Hallo Hayo,
bei meinen Oszi hat sich das von Ben L. (elecblu)06.01.2013 22:04 schon 
einmal aufgetauchte Problem gemeldet an Kanal 4.
Kann sein, dass es schon Anfangs da war. Kanal 4 brauche ich nicht. Bei 
mir nach ca. 5 Minuten wenn es warm ist ab ca 1µs/Div die Spikes gehen 
alle nach unten. Auch steht das Signal nicht ruhig. Mit gesetzten 
Filtern kann man es minimieren. Kältespray bei den ADC's hat nichts 
bewirkt. Kühlkörper habe ich ja schon.
Ben L. schrieb:
> hab seit kurzem Probleme mit Spikes. Und zwar treten diese bei Kanal 2
> erheblich auf, auch sogar ohne Signal. Kanal 1 ist i.O.
> Wenn das Gerät dann eine Zeit lang betrieben wird verschwinden sie
> vollständig, bei kühlem Gerät (12-18°C Werkstatt) wieder Spikes.
> Defintiv thermisch, Lötstelle? Wären da die SRAMs denkbar?

Wurde das Problem gelöst in dem Zeitraum habe ich keine Lösung gefunden.

Gruß
Jürgen

von Jürgen R. (rupy)


Lesenswert?

Hallo im FW Teil wurde ja das Thema über lange Strecken diskutiert.
einer der letzten Beiträge zu dem Thema war dieser:

Dietmar schrieb:
> Leider zeigen sich zuweilen immer noch die lästigen Spikes. Eine
> Einstellung im ADC Setup auf HighFreq 1 bringt schon einiges.  Im Forum
> habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf
> Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo
> das benötigte File für diese Version. Könnte mir jemand einen Link
> benennen?

Die Version 8C7 habe ich schon also werde ich das einmal testen:

Einstellung im ADC Setup auf HighFreq 1

Gruß
Jürgen

von Blue F. (blueflash)


Lesenswert?

Hi Jürgen,

ja leider lässt sich da nicht so viel machen. Es gibt auch noch andere 
Probleme bei Kanal 3 und 4. Wir haben damals so gut es ging versucht das 
zu kompensieren. Das Problem liegt dabei im FPGA und dem Timing zwischen 
den einzelnen Funktionsblöcken. Jörg hat ja sehr schön gezeigt, dass ein 
anderes FPGA-Design hier ganz andere Ergebnisse zeigt und so ganz 
nebenbei auch noch deutlich höhere Taktraten zulässt. Leider fehlte die 
Zeit um das komplett in ein neues Design umzusetzen.

Bei vielen Messaufgaben sind Kanal 1 und 2 zu bevorzugen. Je nach 
Messung muss bei Kanal 3 + 4 mit den Einstellungen gespielt werden.

Und grundsätzlich ist hier das 8C7-FPGA das weniger kritische Design.

Gruß Hayo

von Jürgen R. (rupy)


Lesenswert?

Danke Hayo,
ist jammern auf hohem Niveau :-)
Ist mir ja erst nach fast einen Jahr aufgefallen.
Mit Filtereinstellung sieht es wieder ganz gut aus.
HighFreq 1 hat leider nichts gebracht.

Gruß
Jürgen

von Yutie (Gast)


Lesenswert?

Hallo nochmals!

Mittlerweile habe ich dem Oszi mal einen größeren und leiseren Lüfter 
eingebaut. Dafür musste ich das Gehäuse ein wenig bearbeiten.

In den letzten Tagen beim Aufbau eines LC-Schwingkreises mit rund 20 MHz 
ist mir aufgefallen, daß das Oszi ab einer bestimmten Frequenz das 
Signal mit einer Art "Überlagerung" anzeigt. Deutlich wird das ab etwa 5 
MHz. Davon sind beide Kanäle betroffen.
Entdeckt hatte ich das beim Ausmessen eines 10 MHz Quarzofens. Sie 
werden aber offenbar nicht mit steigender Frequenz mehr, sondern bleiben 
einfach da.
Mit einem der Noise-Filter lässt sich das Problem verringern, aber nicht 
ausschalten. Wärmeeinwirkung kann ich ausschließen. Der 80mm-Lüfter 
erzeugt einen ordentlichen Luftstrom im Gehäuse.
Die beiden Schirmbleche sind natürlich wieder eingebaut.
Bis auf diese kleine Störung funktioniert das Oszi wieder klaglos.

Gruß,
Yutie

von Blue F. (blueflash)


Lesenswert?

Hallo Yutie,

hast Du vielleicht einige Screenshots davon? Und die genauen 
Messparameter (Messbereich Zeit/Spannung, Prüfspitze oder mit 50 Ohm 
terminierte Leitung etc.). Dann würde ich mal versuchen das 
nachzustellen und zu analysieren.

Gruß Hayo

von trollolo (Gast)


Lesenswert?

Leute... lasst das Projekt endlich sterben... Die Technik ist 
hoffnungslos überholt...

von trollolo (Gast)


Lesenswert?

erster Beitrag vor knapp 10 Jahren....

von Blue F. (blueflash)


Lesenswert?

Was heißt sterben lassen? Geräte wegschmeißen, Chinatechnik kaufen und 
keine Fragen mehr stellen bzw. beantworten???

Klar gibt es im Profibereich für einige Kilo-€ tolle Technik zu kaufen - 
hätte ich auch gerne...

Diese - in der Tat nicht gerade perfekten - WELEC W2000A leisten aber in 
diversen Hobbybereichen durchaus gute Dienste. Mein technisch eigentlich 
besseres China-Oszi benutze ich nur hin und wieder als Referenz zur 
Überprüfung von Messungen die ich mit dem in der Bedienung deutlich 
angenehmeren WELEC gemacht habe.

Solange das so ist und noch etliche Hobbyelektoniker diese Geräte in 
ihrer Elektroecke stehen haben, finde ich es durchaus in Ordnung auch 
weiterhin Unterstützung anzubieten und Fragen zu beantworten.

Übrigens leben Totgesagte eh länger :-)

Hayo

: Bearbeitet durch User
von Michael D. (mike0815)


Lesenswert?

"trollo" und als Gast angemeldet, sagt ja schon einiges aus!
Mal eben vor lauter Langeweile "konstruktiven" Dünnsch...  raushauen

von Blue F. (blueflash)


Lesenswert?

...genau - und der eine oder andere Besitzer eines teureren Oszis wäre 
vermutlich froh, wenn er so lange Support für sein Gerät hätte...

Für mein nicht gerade günstiges OWON SDS8102 gibt es schon seit 8 Jahren 
keinen Support/Update Service mehr, weil die Seriennummer zu niedrig 
ist. Es werden nur noch neuere Varianten supportet - klasse!

Hayo

: Bearbeitet durch User
von Jürgen R. (rupy)


Lesenswert?

Da bin ich deiner Meinung.
Ich brauch einmal wieder deine Einschätzung.
Hab mein Welec hier im Forum verkauft.
Bei mir war alles ok.
Beim Käufer angekommen zeigte es ein weißes Display.
Die Anzeige der LEDs scheint ok.
Sieht meiner Meinung nach einen abgegangenen Display Stecker aus.

Gruß
Jürgen

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Wenn es ungefähr so aussieht - ja! Dabei reicht es schon, wenn der 
Stecker nur an einer Ecke nicht ganz fest drin steckt.

Hayo

von Jürgen R. (rupy)


Lesenswert?

Hallo Hayo,
ja so sah es auf dem Bild, dass ich bekommen habe auch aus.
Jetzt warte ich auf Antwort ob er Erfolg hat.

VG
Jürgen

von Sigi (Gast)


Angehängte Dateien:

Lesenswert?

Blue F. schrieb:
> Diese - in der Tat nicht gerade perfekten - WELEC W2000A
> leisten aber in diversen Hobbybereichen durchaus gute Dienste.

Durchaus gute Dienste? Wohl mehr als das, denn man hat
ja ein fast komplett durchdokumentiertes Messinstrument!
Damit lassen sich die WELECs (für mich das 2-Kanal) mehr
als ausreichend gut an eigene Messexperimente anpassen.
Man braucht lediglich ein wenig FPGA-Kenntnisse und evtl.
noch eure ADC/OpAmp-Anpassungen. So habe ich sicherlich
schon für zig Projekte Mess-Designs entwickelt, die selbst
mit Kilo-Euro-Oszis nicht möglich wären.

Kleines Beispiel aus der Retro-Ecke: Für eine IC-Analyse
(SID, MOS6581) wurden alle möglichen Waveforms zu allen
denkbaren Registersettings eingescannt. Dazu hat ein
zweiter FPGA den Chip als auch das Oszi angesteuert
und alles automatisch getriggert als auch die Waveforms
an den PC zur Abspeicherung und weiteren Analyse geschickt.
Wie soll sowas mit wesentlich teureren Equipment gemacht
werden, und dazu noch vollautomatisch UND für 200 Ocken?

Weitere Beispiele sind eigene Oszi-Designs, wie z.B.
sog. "Digitales Phosphor", siehe Bilder. Läuft bis jetzt
zwar nur rudimentär, sieht aber in realtime fantastisch
aus.

Kaum ein anderes Oszi lässt sich so gut an eigene
Messexperimente anpassen, dazu fehlt mind. die Dokumentation,
wenn nicht auch noch der Preis zu hoch ist.

von Yutie (Gast)


Angehängte Dateien:

Lesenswert?

Hallo nochmals.

Im Anhang mal ein echter Screenshot des Fehlers. :-)
Die Frequenz beträgt 10 MHz aus einem Quarzofen. Bei einem 
LC-Sinusoszillator tritt das Problem auch auf. Es macht sich als "Kamm" 
bemerkbar. Bei kleineren Frequenzen ist der Fehler nicht sichtbar oder 
nicht vorhanden.
Ein Abschlusswiderstand bewirkt keine Besserung. Auch ein anderer 
Tastkopf bringt nichts. Die Störung kommt also nicht durch eine externe 
Störstrahlung, sondern ist intern.
Beide Kanäle sind betroffen. Die Abschirmbleche sind natürlich wieder 
angelötet. Mit dem Noise-Filter lässt sich das gut rausrechnen.

Gruß und frohe Pfingsten,
Yutie

von Jürgen R. (rupy)


Lesenswert?

Hallo Yutie,
das interessiert mich auch. Hab ja dein Oszi in den Fingern gehabt.
Bei meinen Testmöglichkeiten ist bei 5Mhz Ende Fahnenstange.
Wenn es bei beiden Kanälen auftritt schließe ich eine kalte Lötstelle an 
den ADCs aus. Oder es ist ein synchroner Fehler an den ADCs beider 
Kanäle.
Tritt es erst bei 20ns auf oder schon bei 50ns oder höher.
Habe beide Kanäle das gleiche Bild?
Gruß
Jürgen

von Blue F. (blueflash)


Lesenswert?

Sigi schrieb:

> Weitere Beispiele sind eigene Oszi-Designs, wie z.B.
> sog. "Digitales Phosphor",

Ja wie cool ist das denn? Kannst Du da noch etwas mehr Infos zu 
rausrücken? Deine Messaufbauten klingen ja doch schon recht 
anspruchsvoll und gehen wohl etwas über die üblichen Hobby-Messungen 
hinaus. Schön zu sehen, dass diese Geräte auch für anspruchvollere 
Messungen eingesetzt werden.

Wenn ich das richtig verstehe, verfügst Du über Kenntnisse in Sachen 
FPGA? Wäre da eine Überarbeitung des NIOS Designs unserer Oszis nicht 
etwas für Dich?

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Yutie

Ja das Problem ist bekannt. Hier handelt es sich um eine Vertauschung 
der Bits. Heißt, die ADC werden nicht in der richtigen Reihenfolge 
ausgelesen bzw. die Bits nach dem Auslesen vertauscht. Daher ist das 
auch nur an den Flanken so stark sichtbar und an den konstanten Stellen 
nicht. Das tritt natürlich auch bei 50ns auf, da alles darüber ja nur 
interpoliert ist und ebenfalls die 50ns Abtastung verwendet.

Wenn ich das richtig in Erinnerung habe, hängt das zusammen mit der 
FPGA-Version und den gewählten Hardwareeinstellungen. Bei meiner 8C7 
Version kann man das - glaube ich - durch Umschalten zwischen "Factory", 
High Freq 1 und High Freq 2 beeinflussen. Leider kann ich das momentan 
nicht prüfen, da ich gerade an Bord bin und kein Gerät hier habe. Wenn 
ich morgen wieder zu hause bin probiere ich das mal aus - kannst Du aber 
natürlich auch selbst bei Deinem Gerät machen.

Gruß Hayo

von Sigi (Gast)


Angehängte Dateien:

Lesenswert?

Blue F. schrieb:
> Ja wie cool ist das denn? Kannst Du da noch etwas mehr Infos zu
> rausrücken?

(ersmal sorry, dass ich mit eigenen Projekten hier
reinrausche, aber wenn so mancher Troll nur Blödsinn
schreibt.. Ob das Welec jetzt neu oder alt ist,
spielt doch überhaupt keine Rolle, Messungen mit
einem neueren und teureren DSO würde auch keine
"besseren" Daten liefern.)

Mein Design bassiert auf einem einfachen Nachahmen
von Phosphor durch ein Array.

Der einfachste Ansatz ist, die Daten in Form von Punkten
in das Array zu schreiben und evtl. ältere Punkte langsam
ausdimmen zu lassen.

Mein Ansatz geht viel weiter, statt Punkten werden ganze
Linien (nicht ganz so einfach) gezeichnet und parallel
dazu das gesammte Array abgedimmt (bel. steuerbar). Dann
noch entsprechende Filter für versch. Zeitskalen, um nach
Möglichkeit Artefakte zu vermeiden.

Kling erstmal recht einfach, wenn man aber mal die Anzahl
Rechenoperationen hochrechnet, dann kommt man schnell in
den Bereich von Teraops, d.h. für eine CPU, insbes.
NiosII-Derivate, nicht darstellbar. Kleines Beispiel:
alleine die R/W-Ops für die ADC-Array-Stufe bewegen sich
im Bereich 100-150 Gigabyte/sec. Je nach Zählweise bewegt
sich mein Design von 0.5 bis 1.0 Teraops.

Damit erhält man dann so etwa 1 Million Waveforms/sec (bei
etwa 200 Punkten je Waveform, neuere DSOs haben vlt. 10x
so viele Messpunkte!) und sogut wie keine "Auszeit" zur
Anzeige der Bilder, die per simpler GPU parallel berechnet
wird. Dann noch Color-LUT, Panel-Steuerung und IO wie z.B.
UART, und man hat ein erstes einfaches Design.

Nachteil meiner Vorgehensweise ist aber, dass alle Daten
im Phosphor-Array abgespeichert werden und bei jeder Änderung
der Zeitskala (und evtl. Werteskala) gelöscht und neu angesammelt
werden müssen. Alte Messungen gehen also mit Änderungen
der Panel-Einstellung verloren. Bei alten Oszis ist das aber
auch so.

Das ganze habe ich auch als UV- und FT-Plot (inkl. Waterfall-Modus),
mehr als ein Modus gleichzeitig in einem Design ist aber leider als
Platzgründen nicht möglich.

"Cool" sind aber nicht die statischen Bilder, sondern der Verlauf
in Echtzeit auf dem Welec. Z.B. eine Videokamera angeschlossen,
lässt sich das Videobild auf den Bildschirm erahnen, es wird in
Echtzeit 1:1 angezeigt. Und auch die Augendiagramme sehen echt
geil aus, zumind. beim ersten mal.

Zu den 3 Bildern: das erste ist aus einer echten Messung
(Digitalschaltung mit zufälligen 0/1-Wechseln), das Array
wurde dann per UART an den PC geschickt und dort als Graphik
abgespeichter. Die beiden Anderen stammen aus einer SW-Sim.,
die zum einen seltene Ereignisse simuliert, zum anderen die
Zeitskala verstellt (niederfreq. Sinus plus hochfreq. Sinus,
daher der "breite" Verlauf). Dazu hat mir zu der Zeit leider
ein passender Waveform-Generator gefehlt (die beiden letzten
Bilder sind also sozusagen gefakt, aber mit einem passenden
Generator genauso darstellbar).
geschummelt.

Zum NiosII-Design: mehr oder weniger alle Komponenten (UART,
Panel, VGA etc.) sind per AVALON an die CPU angebunden, die
CPU ist nur noch dirigirend tätig, die manuelle Auswertung
z.B. des Panels per SW entfällt. Als Beispiel habe ich mal
ein Panel-Design angehängt. In "compilation" ist das SOF-File
als auch die Pin-Beschreibung (bitte lesen!!), if "NiosIISystem"
die Software. Einfach "startshell" aufrufen (Achtung: läuft nur
unter 11.0, im Skript bitte das Verzeichnis in Zeile 16 anpassen),
dann per "./loadhw.sh" das SOF-File und per "./loadsw.sh" die
Software runterladen. Per "./buildsw.sh" lässt sich die Software
neu compilieren (nicht die Hardware!), an der Software kann man
sich ja mal austoben, viel Spass dabei.


Im Moment fehlt mir aber leider die Zeit, um weiter am
Design zu arbeiten, mein Haus muss renoviert werden. Ich
komme aber in den nächsten Jahren wieder dazu.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hallo Yutie,

wie schon vermutet ist es die Einstellung im ADC-Setup: Du hast wohl
bei Dir die Einstellung High Freq2 gewählt. Die ist aber nur für einige 
Sonderfälle zu empfehlen, wenn man bei sehr hohen Frequenzen mit den 
anderen Einstellungen keinen Trigger hinkriegt. Für sonstige Messungen 
lieber Factory oder High Freq1 nutzen (siehe Screenshots). Bei Dir ist 
der Effekt noch ausgeprägter, weil Deine Frequenz höher und die Flanken 
steiler sind. Bei mir sind es nur 5MHz, hatte jetzt keine Lust den 
Rechteckgenerator aus dem Regal zu ziehen (zu staubig).

Probier's mal aus...

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Sigi schrieb:
> (ersmal sorry, dass ich mit eigenen Projekten hier
> reinrausche,

Kein Grund sich zu entschuldigen - ist doch super interessant! Und nach 
all der Zeit von so coolen Projekten zu hören ist vermutlich nicht nur 
für mich inspirierend.


> Im Moment fehlt mir aber leider die Zeit, um weiter am
> Design zu arbeiten, mein Haus muss renoviert werden. Ich
> komme aber in den nächsten Jahren wieder dazu.

Ja das kommt mir bekannt vor - habe auch noch 80m Fußleisten rumliegen, 
die gerne zugesägt und angeschraubt werden wollen. Und dann das Boot...

So, genug auf hohem Niveau gejammert. Wünsche noch einen schönen 
Pfingstmontag :-)

Hayo

von Yutie (Gast)


Angehängte Dateien:

Lesenswert?

Moin zusammen!

Ich habe mal mit dem ADC-Setup gespielt. Es ist egal was ich einstelle, 
das "Messergebnis" ist das gleiche.
Um einen Sinus mal anzuzeigen habe ich kurzerhand den Lokaloszillator 
meines Eigenbau-Mittelwellen-Supers missbraucht. Auch da, bei rund 1,5 
MHz, tritt der Fehler auf, wenn auch nur klein.
Ein Abgleichen des Tastkopfs bringt im Übrigen nichts.
Wenn ich den Quarzofen über den zum Oszi gehörigen Tastkopf mit "X10" 
messe, dann sieht das Signal noch viel gruseliger aus. Aber gut, das 
liegt vielleicht eher an der höheren Frequenz. Die Tastköpfe können es 
nicht sein. Mit denen konnte ich einwandfrei ein 100 MHz Sinus-Signal 
messen. Die sind auch für 200 MHz spezifiziert.

Ob ich mal die Software neu aufspiele? Vielleicht hat sich etwas 
"verrannt"?

Gruß,
Yutie

von Yutie (Gast)


Lesenswert?

Da ich mein Posting nicht editieren kann:

Die Hardware-Version ist ebenfalls 8C7.0E und die Firmware ist 
1.2.BF.8.6, also die aktuelle.
Interessant ist auch, daß die "Störsignale" unterschiedlich sind.

von Jörg H. (idc-dragon)


Lesenswert?

Sigi schrieb:
> Mein Design bassiert auf einem einfachen Nachahmen
> von Phosphor durch ein Array.

Hallo Sigi,

uih, darüber hatte ich seinerzeit auch viel nachgedacht, aber ich kam 
mit Speicher und Bandbreite nicht aus. Mit wenigen Punkten vielleicht, 
aber die Bildschirmgröße? Es hätte geholfen, wenn das LCD vertikal 
scannen könnte statt horizontal.
Wie hast du das gemacht?

Kennst du meine HighColor-Erweiterung?

Ah, habe meine Überlegungen und die Erweiterung wieder gefunden:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
(weiter runter scrollen für Fotos)

Respektvolle Grüße
Jörg

von Sigi (Gast)


Lesenswert?

Jörg H. schrieb:
> Kennst du meine HighColor-Erweiterung?

Ja, und ich war auch sehr begeistert beim Lesen.
Die Abänderung der/meiner Ansteuerung ist eiglich
kein Problem, geht innerhalb von 1-2 Stunden inkl.
Testen, sollte nich mehr als 50-100 LEs vebrauchen.
(ich hatte auch mal eine kleine Erweiterung gebastelt:
Aus meiner Displaymodulsammlung hatte ich ein 1024er
Modul angeschlossen, vom Stecker her ging das ohne
Probleme)
Da ich gerade "DER Ansteuerung" geschrieben habe:
ich habe noch Bilder von eurem RGB-Modul in Erinnerung,
habt ihr das Orginaldesign (VHDL-Files etc.) abgeändert
oder ein eigenes Design verwendet?

Jörg H. schrieb:
> Wie hast du das gemacht?

Naja, zunächst musst du ja 2 Dinge machen:
1. dir über die HW-Architektur genau klar sein, insbes.
   über die Speicher (SRAM, und sehr wichtig: interner
   Speicher!!). Wichtig dabei ist die Busbreite und die
   Schreibrate. Das definiert wichtige obere Grenzen.
   Auch die CPU (hier NiosII) definiert (sehr niedrige!)
   untere Grenzen.
2. mehrere Ansätze durchdenken, Phosphor zu implementieren.
   Für mich blieb nur einer übrig. Daraus und der Sample-
   Frequenz ergeben sich dann weitere untere Grenzen.

Aus den Grenzen aus 1. und 2. scheidet dann ganz klar
SRAM aus (was wegen der Grösse schade ist), es bleibt
dann nur noch der interne Speicher. Der wird dann so
organisiert, dass eine (vertikale) Spalte je Scan
geschrieben werden kann. Mit 80 Blockrams kommt man so
auf eine Auflösung von 160x256 bei 9Bit. Beim Auslesen
für die LCD-Anzeige wird dann das Bild mittels Filter
auf 640x480 hochgerechnet, was total ausreichend ist.

Naja, so ganz einfach ist es dann auch nicht, so wie
gerade beschrieben gibt's beim Rauszoomen viele Artefakte.
Und die sind nur mit aufwendigen Filtern entfernbar. Ich
hatte aber Glück und fand einfache Möglichkeiten. (wenn
du dir aber mal auf Youtube Videos zu 5kEuro++-DSOs anschaust,
dann siehst du beim rauszoomen auch hier und da Artefakte,
selbst bei einem 100kEuro-DSO habe ich das schon gesehen)

(klein wenig SciFi: mein Algo/Design kombiniert mit
einem Stratix10MX würde so einen 2K-Monitor bespassen,
die ADC-Unit könnte dabei mit 1TeraHz arbeiten..)

Über die Grenzen bzgl. CPU brauch man ja wohl nicht zu
sprechen, "Digitales Phosphor" braucht bei mir ab 0.25TeraOps,
aktuell sind es ca. 0.5TeraOps. Selbst ein Win-basiertes
DSO mit aktueller Intel-CPU schafft das nicht. Bleibt also
nur spezielle Hardware, hier das FPGA.

Dann, das hatte ich ja glaube schon beschrieben, habe ich
mehrere Avalon-Componenten zu Ansteuerung der GPU (Punkte,
Linien, Blöcke, Buchstaben! und Auto-Clipping beliebiger
Rechtecke), des Panels (Knöpfe, RotEncoder, LEDs), was der
CPU SEHR viel Arbeit erspart. Meine CPU ist nur der kleinste
NiosII, der mit 50MHz betrieben wird, d.h. 10 MIPS.

Aber selbst ohne das "Digitale Phosphor" lässt sich damit
ein richtig gutes DSO zusammenstellen, inkl. Anasysemodulen
wie FFT, UART/SPI/etc.-Encoder uvm.

von Sigi (Gast)


Lesenswert?

.. und was ich unabhängig von meinen Spielereien noch
schreiben wollte:

Ich lese hier seit glaube ich Anbeginn mit, eines der
Hauptprobleme mit dem HW-Design ist die Clock-Beschaltung.

Das FPGA verfügt nur über 4 PLLs, angesteuert werden aber
8 ADCs (4 je Kanal). Die PLLs sind eiglich in der Lage,
3 Clocks zu generieren, so dass die Phase je ADC einzeln
angesteuert werden könnte.

Aber: erstens sind die ADCs "schlecht" konfiguriert, z.B.
könnten die ADCs mit halber Taktrate angesteuert werden
(der entsprechende Pin heisst glaube ich CLKDIV??) und
zweitens könnten noch unbenutze FPGA-Pins für zusätzliche
Clockleitungen sorgen. So hätte man damit 8 Phasenparameter.
Schade!!!

Bei der gegebenen Beschaltung werden jeweils 2 ADCs beider
Kanäle mit einer Phase bespasst, selbst bei bestmöglichen
Längenmatchings gibt's Versatz. Für "unser" DSO sieht man
dass am Besten in Bildern wie zuletzt von Yutie. Beide
Kanäle zeigen unterschiedliche Signalveräufe bzw. Fehler.
(Längenmatching der Datenleitungen sind dagegen iO)

Abhilfe hier: beim Zeichnen der Punkte/Linien müssen die
Phasen berücksichtigt werden. Das hatte ich mal gemacht,
sieht im Ergebnis dann gut genug aus.


Ein weiteres Problem ist der Trigger: testet man z.B. nur
einen Sample-Wert gegen ein Triggerintervall, dann kann es
bei ungünstiger Konstelation zum Springen der Kurve kommen.
Auch dafür hatte ich mal einen Ansatz ausprobliert: ich
verwende mehrere benachbarte Punkte und filtere diese zu
einem finalen Wert. Damit liess sich das Springen fast
komplett entfernen. Ich weiss aber nicht, wie das Triggern
bei euch implementiert ist (HW oder SW?).

Ich versuche mal, am nächsten Wochenende ein kleines Demodesign
aufzusetzen, dass diese Probleme deutlich macht.

von Blue F. (blueflash)


Lesenswert?

Hallo Yutie,

das Problem kann individuell von Gerät zu Gerät unterschiedlich sein. 
Auch bei meinen beiden Geräten sieht das nicht gleich aus. Die Ursache 
hat Sigi oben ja schon angedeutet:


Sigi schrieb:
> Ich lese hier seit glaube ich Anbeginn mit, eines der
> Hauptprobleme mit dem HW-Design ist die Clock-Beschaltung.

Um das Problem so einigermaßen in den Griff zu kriegen, hat WELEC hier 
das ADC-Change Register eingeführt, über das wir uns lange Zeit den Kopf 
zerbrochen haben. Es steuert vermutlich den Interleave zwischen den 
einzelnen ADC. In der Factory Einstellung wird ein Wert aus dem Flash 
verwendet den WELEC hier hinterlegt. Evtl. ist dieser Wert bei Dir 
schlecht gewählt. Kannst Du Dein Gerät über das RS232 Kabel an den PC 
anschließen und mal prüfen was da für ein Wert bei Dir erscheint?

Im Terminal dazu einfach ein Semikolon eingeben (;). Daraufhin gibt das 
Gerät eine Liste von Variablen aus. Hier suchst Du jetzt nach
_regADC[F1].adc_change - bei mir ist hier 2020800 eingestellt, beim 
anderen Gerät 2020f00.

Zusätzlich wäre noch der Registerinhalt von _regADC[F1].channel_Adr 
interessant. Bei mir erscheint hier 5f0a.

Wenn Du Fragen hast zum Einsatz des Terminals - einfach raus damit. Es 
gibt auch eine Anleitung im doc Verzeichnis.

Gruß Hayo

: Bearbeitet durch User
von Yutie (Gast)


Lesenswert?

Hallo!

rupy hatte die ADCs gewechselt. Vielleicht muss man die dann in der 
Software eben richtig kalibrieren, wenn sie neu sind. Hat man das bei 
Wittig damals auch gemacht?
Zum Glück habe ich mir letztes Jahr ne Schnittstellenkarte mit RS232 
gekauft und kann das Oszi an ein Terminal anschließen.
Die hinterlegten Werte werde ich mal kontrollieren und hier posten.
Wenn man die Signaldarstellung übrigens auf "Point Sprites" umstellt, 
sieht man quasi eine Art "Echo" der Kurve, also eine sozusagen "dünnere 
Abbildung" des Signals nach links oder rechts verschoben.

Danke erstmal,

Gruß,
Yutie

von Jürgen R. (rupy)


Lesenswert?

Hallo Yutie,
die ADCs habe ich nicht gewechselt. Ich habe einige kalte Lötstellen 
nach gelötet und mit Kühlkörpern versehen. Den LB-Mod habe ich gemacht.

VG
Jürgen

von Blue F. (blueflash)


Lesenswert?

Hätte mich jetzt auch etwas gewundert.

Aaaber - mir ist gerade die Idee gekommen woran es noch liegen könnte 
(war zu naheliegend um gleich drauf zu kommen :-) ).

Wenn Du das Gerät mit der High Freq2 Einstellung kalibriert hast, dann 
liegen evtl. verschobene Werte im Kalibrierungsspeicher. Stell doch mal 
das ADC-Setup auf Factory, lass das Gerät einen Moment laufen, damit es 
warm wird und mach dann eine Kalibrierung.

-> alle Eingänge offen oder kurzgeschlossen
-> Calibration: Standard
-> Default Setup
-> Calibrate Offsets

Letzteres kann bei mehrmaligem Ausprobieren ganz leichte Unterschiede 
zeigen. Sieht man daran, wie genau die Nulllage mit den Pfeilen am Rand 
übereinstimmt, und wieviel Grundrauschen auf dem Signal ist.

Probier doch mal aus ob das hilft

Gruß Hayo

von Yutie (Gast)


Lesenswert?

Hallo!

Okay, dann hatte ich das falsch verstanden. Es sind nur die Kühlkörper 
draufgekommen.

Ich habe das Oszi gerade am Rechner angeschlossen und lese die Variablen 
(Taste "," laut Hilfe) aus:
* _regADC[F1].adc_change  :  2020f00
* _regADC[F1].channel_Adr :  5f1f

Eine Kalibrierung bringt nichts. Kann man die oben genannten Werte 
händisch ändern? Ich kann sie ja notieren und mit den Werten ein 
bisschen spielen.

von Yutie (Gast)


Lesenswert?

Ist schon ein merkwürdiger Fehler.

Sagt mal, kann man das Oszi rein per Terminal steuern? Das ist 
vielleicht besser als dieses USB-Tool-Dingsbums^^
Da könnte man eine neue Software dafür schreiben. Gibts eine 
Befehlsliste für das USB-Tool?

Gruß,
Yutie

von Blue F. (blueflash)


Lesenswert?

Hi Yutie,

nein, eine manuelle Eingabe gibt es nicht. Ich kann Dir aber Folgendes 
anbieten. Ich kann Dir eine spezielle Firmwareversion basteln bei der 
die Werte nicht aus dem Flash gezogen werden, sondern fest vorgegeben 
werden (z.B. die Werte die bei meinem Gerät hinterlegt sind). Damit 
kannst Du dann prüfen, ob das bei Dir eine Verbesserung bringt. Wenn ja, 
müssen wir die Werte in Deinem Flash korrigieren. Dazu würde ich Dir 
dann einen kompletten Abzug meines Flash zur Verfügung stellen.

Soll ich das mal in den nächsten Tagen machen?

Und ja  - etliche Funktionen lassen sich per Terminal steuern. Die 
einfache Variante ist das Interface, welches Du sehen kannst wenn Du h 
oder H eingibst. Eine zweite Variante hat Falk mal implementiert und 
wird derzeit vom Screenshot Programm genutzt. Beide kann man natürlich 
auch für eigene Programme nutzen. Als Vorlage kann man sich z.B. das 
Coding vom Screenshot Programm ansehen.


Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

So mein Lieber!

Da ich trotz Coronaerkrankung und angespannter Lage beim Kunden, in der 
heimischen Einzelhaft Lust hatte ein wenig an der Firmware zu basteln, 
habe mal eine neue Compilation von der 8.6 gemacht und bei SF 
hochgeladen:

https://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2.BF.8.x/

Im ADC Setup sind jetzt zwei neue Einträge Test 1 und Test 2, die Du 
ausprobieren kannst. Es handelt sich bei den Werten um die Standard 
Flash Werte meiner beiden DSOs. Sie bewirken bei meinen Geräten genau 
gegensätzliches Verhalten. Wenn ich eines der Geräte mit den Werten des 
anderen lade, gibt es die schon bekannten Zacken auf der Signalflanke. 
Ist also schon recht individuell. Bei Bedarf kann ich auch noch weitere 
Werte hinzufügen.

Viel Spaß beim Probieren

Hayo

von Yutie (Gast)


Lesenswert?

Hallo und guten Abend!

Danke für das Modifizieren der Firmware, das werde ich ausprobieren.

Ich habe auch ein bisschen mit dem Oszi gespielt. Eine Sinusschwingung 
von 125 MHz ist auf Kanal 1 recht schwer darzustellen, auf Kanal 2 mit 
einem Filter hingegen schon.
Kanal 1 klappt bis ca. 40 MHz einigermaßen ordentlich. Mir fallen auf 
beiden Kanälen Spikes auf, die nach mehrfachen umschalten der Zeitbasis 
meist verschwinden. Tatsächlich kann man im ADC-Setup deren Häufigkeit 
beeinflussen. In der Stellung "Factory" sind sie am geringsten.
Bis ca. 100 MHz ist es also auf Kanal 2 brauchbar.

Na ja, ich versuche die Firmware mal und lasse euch wissen, ob und was 
sich tut.

blueflash wünsche ich eine gute Besserung.

Danke und Viele Grüße,
Yutie

von Yutie (Gast)


Lesenswert?

So, die Arbeitswoche ist vorbei und ich hatte Zeit, die Werte zu testen.

Als erstes hatte ich das Problem, daß das Oszi immer die 
Software-Version 7.15 ausgab, bis ich merkte, daß ich die falsche 
Firmware flashte.

Nach einem neuerlichen Flash probierte ich die beiden Testpunkte aus.
Test1 bewirkte nichts.
Test2 hingegen lässt die "Zacken" auf Kanal1 geringer werden. Es sind 
zwar noch immer kleine Stufen sichtbar, aber man erkennt die Sinuskurve 
deutlicher. (30 MHz, 50 mV/Div, 10ns/Div).
Kanal 2 ist noch immer gestört, egal welches Setup ich wähle.
Test2 ist also der richtigen Einstellung recht nah.

Danke und Gruß,
Yutie

von Yutie (Gast)


Lesenswert?

Ich nochmal.

Mir ist gerade etwas aufgefallen:
Nach einiger Zeit zeigte das Oszi wieder diese Zacken an. Jetzt habe ich 
es aus-.und wieder eingeschalten und da sind die Zacken wieder fast weg 
(mit Test2).
Beim Wiedereinschalten klickten auch die Relais.
Ich habe das gleiche nochmal gemacht und da klickten die Relais nicht.
Vielleicht sind die fehlerhaft geworden oder eine Spannung stimmt mal 
wieder nicht. Das könnte ich überprüfen. Vielleicht ist auch ein 
Rauschen drauf.

Gruß,
Yutie

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.