Wittig(welec) DSO W20xxA Hardware (Teil 2)

[Max M. (vcc)]

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

[Blue F. (blueflash)]

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

[Max M. (vcc)]

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

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

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

[Max M. (vcc)]

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?

[IZ2EIB (Gast)]

Hi Max,

please 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)"

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

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

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

Regards,

Fabio

[IZ2EIB (Gast)]

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)"

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

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

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

Regards,

Fabio

[IZ2EIB (Gast)]

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)"

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

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

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

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

Regards,

Fabio

[IZ2EIB (Gast)]

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

[Max M. (vcc)]

Thx!
Now i got collected all possible docs about the mods ;)

[Max M. (vcc)]

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

[Max M. (vcc)]

Wo kann ich denn an der unteren Grenzfreuenz überhaupt drehen?
Fehlt bei diesem Umbau nicht eine Gegenkopplung beim OPA653?

[Blue F. (blueflash)]

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

[Max M. (vcc)]

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.

[Blue F. (blueflash)]

> 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

[Alessandro C. (musashi)]

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

[IZ2EIB (Gast)]

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

[Alessandro C. (musashi)]

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?

[IZ2EIB (Gast)]

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

[Alessandro C. (musashi)]

I did, but unfortunately the HD is gone..
Should I use the WelecUpdater to install this?
Is the welec site completely offline?

thanks

[IZ2EIB (Gast)]

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

[Blue F. (blueflash)]

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

[IZ2EIB (Gast)]

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

[Blue F. (blueflash)]

> 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

[Alessandro C. (musashi)]

>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

[IZ2EIB (Gast)]

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

[Blue F. (blueflash)]

@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

[vcc (Gast)]

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

[Blue F. (blueflash)]

Freut mich zu hören, dass jetzt alles läuft. Dann mal viel Spaß mit dem 
Gerät und immer eine gute Erdung!

Hayo

[Blue F. (blueflash)]

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

[Alessandro C. (musashi)]

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

[Blue F. (blueflash)]

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

[Alessandro C. (musashi)]

When opening .bat I get:
Error: Unsupported mode parameter, please specify <r>ead or <w>rite!

Should I insert w than enter?

[Blue F. (blueflash)]

Sorry,

I took an old version of the perl script. Please use the script 
attached.

Hayo

[Alessandro C. (musashi)]

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

[Blue F. (blueflash)]

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

[Alessandro C. (musashi)]

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

[Alessandro C. (musashi)]

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!

[Alessandro C. (musashi)]

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!

[Blue F. (blueflash)]

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.

[Alessandro C. (musashi)]

Not so good...
I have restarted the DSO now end it acts again as before!!!
what the hell!!

[Alessandro C. (musashi)]

I have opened the DSO and started it up keeping the fan cable far from 
the boards (as Fabio suggested).
Nothing changes

[IZ2EIB (Gast)]

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.

[Alessandro C. (musashi)]

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?

[IZ2EIB (Gast)]

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

[Alessandro C. (musashi)]

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!

[Blue F. (blueflash)]

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!

[Alessandro C. (musashi)]

But when the problem is present, it's there from the start up of the 
device.
When it's still cool...

[Blue F. (blueflash)]

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.

[IZ2EIB (Gast)]

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

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

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.

[WWWelec (Gast)]

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

[Blue F. (blueflash)]

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

[김사백 (Gast)]

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

[Alessandro C. (musashi)]

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

[Blue F. (blueflash)]

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

[Alessandro C. (musashi)]

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?

[WWWelec (Gast)]

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

[CB (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[CB (Gast)]

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

[Blue F. (blueflash)]

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

[CB (Gast)]

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

[Blue F. (blueflash)]

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

[CB (Gast)]

Ciao Hayo.
Lucky only in trigger there is OPA656 with green point.
I must substitute?
Is difficult do it for me.
Thank you.
Carlo

[김사백 (Gast)]

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

[Blue F. (blueflash)]

김사백 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

[Guido B. (guido-b)]

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

[김사백 (Gast)]

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

[Guido B. (guido-b)]

김사백 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.

[김사백 (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

> 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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[Andiiiy (Gast)]

Hallo Micha,

auf dem Bild vom Hayo ist das zu erkennen ...

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

Grüße Andiiiy

[Andiiiy (Gast)]

noch besser ...

Beitrag "Re: Wittig(welec) DSO W20xxA Einsteiger"

[Michael D. (mike0815)]

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

[Michael D. (mike0815)]

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!

[WWWelec (Gast)]

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

[Blue F. (blueflash)]

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

[Michael D. (mike0815)]

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.

[Blue F. (blueflash)]

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

[mark (Gast)]

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

[Blue F. (blueflash)]

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

[mark (Gast)]

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

[mark (Gast)]

Sorry, I forgot some screenshots.
Here they come.
Thanks.

mark

[Thomas (kosmos)]

JPG vor PNG?

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

...and for sure it has be written sure not shure...  ;-)

[Blue F. (blueflash)]

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

[mark (Gast)]

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

[Blue F. (blueflash)]

I used this schematic as basic information.

Hayo

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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.

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[mark (Gast)]

> 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

[Blue F. (blueflash)]

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

[mark (Gast)]

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

[Blue F. (blueflash)]

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

[luigi (Gast)]

Hello,
till now I found 0603 305K .5% avalaible at mouser, do you know other 
vendors?

luigi

[luigi (Gast)]

Hello,
till now I found 0603 305K .5% avalaible at Mouser, do you know other 
vendors?

luigi

[Blue F. (blueflash)]

No, I only found 300K at ebay

[Blue F. (blueflash)]

Here the new version of the OPA653 Mod manual. Also available on SFN.

[Blue F. (blueflash)]

Und auch noch die deutsche Version.

Hayo

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[mark (Gast)]

OK, resistor R13 (390kohm) changed with 305kohm 0.1% EIA E192.
It works and this is good for me, thank you Hayo.

mark

[Bruno A. (bruno_a586)]

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 ?

[Blue F. (blueflash)]

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

[Bruno A. (bruno_a586)]

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 ?

[Blue F. (blueflash)]

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

[Bruno A. (bruno_a586)]

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

[Blue F. (blueflash)]

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.

[Bruno A. (bruno_a586)]

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

[Bruno A. (bruno_a586)]

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

[Benedikt K. (benek)]

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

[Blue F. (blueflash)]

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

[Benedikt K. (benek)]

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

[Blue F. (blueflash)]

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

[Sigi (Gast)]

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.

[Sigi (Gast)]

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)

[Benedikt K. (benek)]

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

[Benedikt K. (benek)]

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

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

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

[-gb- (Gast)]

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!

[Blue F. (blueflash)]

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

[-gb- (Gast)]

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.

[Blue F. (blueflash)]

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

[-gb- (Gast)]

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?

[Blue F. (blueflash)]

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.

[-gb- (Gast)]

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.

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

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

[-gb- (Gast)]

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.

[Sönke P. (snke_p)]

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

[Blue F. (blueflash)]

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

[Sönke P. (snke_p)]

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

[Blue F. (blueflash)]

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 :-)

[Oliver (Gast)]

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?

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

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Oliver D. (ollinoscope)]

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

[Olaf (Gast)]

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.

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

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

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

[Blue F. (blueflash)]

Hallo Guido,

schildere doch mal Dein Problem, vielleicht können wir etwas empfehlen 
oder anders weiterhelfen.

Gruß Hayo

[Guido S. (backslash)]

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.

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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.

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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.

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Guido S. (backslash)]

Oder liegt es an der DAC Korrektur ?
Wird die DAC Korrektur auf 0 gesetzt vor der
Offset Kalibrierung ?

Gruß,
Guido

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[Guido S. (backslash)]

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

[Blue F. (blueflash)]

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

[BRUNO ALLAIN (Gast)]

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

[Blue F. (blueflash)]

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

[Olaf (Gast)]

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?

[Blue F. (blueflash)]

Hallo Olaf,

ja auf jeden Fall berichten. Wenn Du Fragen hast oder auf Probleme stößt 
unterstütze ich auch gerne.

Gruß Hayo

[Olaf (Gast)]

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.

[Olaf (Gast)]

Mein Meguro MSG2560B ist der Käfer, der SG1000 der Mercedes, Rigol 815 
ist auch nicht schlecht.

[Michael R. (mreck)]

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

[Michael R. (mreck)]

Okay, hab es gefunden, hab den Gain entsprechend angepasst, jetzt stimmt 
es :-)

[Michael D. (mike0815)]

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

[Michael D. (mike0815)]

Da war ich ja gar nicht so verkehrt. Welchen Wert hatte den dein Gain, 
bzw. hat er jetzt?

[Blue F. (blueflash)]

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

[Michael R. (mreck)]

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

[Michael R. (mreck)]

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?

[Blue F. (blueflash)]

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

[Josef F. (jofri)]

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

[Blue F. (blueflash)]

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

[K-H J. (k-h)]

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

[Blue F. (blueflash)]

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