Wittig(welec) DSO W20xxA Hardware (Teil 2)

[Slava Y. (gnsrl)]

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

[Blue F. (blueflash)]

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

[Slava Y. (gnsrl)]

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

[Blue F. (blueflash)]

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

[Slava Y. (gnsrl)]

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.

[Blue F. (blueflash)]

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

[Slava Y. (gnsrl)]

Hayo, thanks a lot for information! Hope, I will fix the port.

Best regards.
Slava.

[Slava Y. (gnsrl)]

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.

[Blue F. (blueflash)]

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

[Slava Y. (gnsrl)]

+100% Ich hatte das gleiche Problem und die gleiche Lösung. :)

[Jürgen R. (rupy)]

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

[Jürgen R. (rupy)]

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

[Yutie (Gast)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Yutie (Gast)]

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.

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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?

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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.

[Blue F. (blueflash)]

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

[Jürgen R. (rupy)]

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

[Yutie (Gast)]

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

[Yutie (Gast)]

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

[Jürgen R. (rupy)]

Hallo Yutie,
schade, dass du nicht weiter kommst.
Schicke mir eine PN.

Gruß
Jürgen

[Jürgen R. (rupy)]

Als Gast kannst du ja keine PN schicken.
meine Mail Adresse juergen-rusies ät vodafone punkt de

Gruß
Jürgen

[yutie (Gast)]

Hallo rupy!
Email geht raus. Ich hoffe sehr, daß du den Fehler finden kannst.

Gruß,
Yutie

[Jürgen R. (rupy)]

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

[Jürgen R. (rupy)]

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

[Jürgen R. (rupy)]

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

[Yutie (Gast)]

Vielen, vielen Dank :-)

[Yutie (Gast)]

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.

[Jürgen R. (rupy)]

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

[Blue F. (blueflash)]

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

[Gustl B. (-gb-)]

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!

[Blue F. (blueflash)]

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

[Gustl B. (-gb-)]

Vielen Dank, dann gucke ich mir das mal mit Vorsicht an.

[Jürgen R. (rupy)]

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

[Jürgen R. (rupy)]

Hallo,
hab es doch noch reparieren können. :-)
Wieder waren die ADC's die Übeltäter und diesmal auch das RAM.

Gruß
Jürgen

[Yutie (Gast)]

Vielen, vielen Dank

Auf die ADCs und das RAM wäre ich nie gekommen.

Danke =)

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Jürgen R. (rupy)]

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

[Jürgen R. (rupy)]

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

[Blue F. (blueflash)]

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

[Jürgen R. (rupy)]

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

[Yutie (Gast)]

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

[Blue F. (blueflash)]

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

[trollolo (Gast)]

Leute... lasst das Projekt endlich sterben... Die Technik ist 
hoffnungslos überholt...

[trollolo (Gast)]

erster Beitrag vor knapp 10 Jahren....

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

"trollo" und als Gast angemeldet, sagt ja schon einiges aus!
Mal eben vor lauter Langeweile "konstruktiven" Dünnsch...  raushauen

[Blue F. (blueflash)]

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

[Jürgen R. (rupy)]

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

[Blue F. (blueflash)]

Wenn es ungefähr so aussieht - ja! Dabei reicht es schon, wenn der 
Stecker nur an einer Ecke nicht ganz fest drin steckt.

Hayo

[Jürgen R. (rupy)]

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

[Sigi (Gast)]

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.

[Yutie (Gast)]

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

[Jürgen R. (rupy)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Sigi (Gast)]

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.

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Yutie (Gast)]

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.

[Jörg H. (idc-dragon)]

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

[Sigi (Gast)]

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.

[Sigi (Gast)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Jürgen R. (rupy)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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.

[Yutie (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Yutie (Gast)]

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

[Yutie (Gast)]

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

[Yutie (Gast)]

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