Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)

[Sandro (Gast)]

Hi Hayo,
I tested the level and rotary, it's good but  unfortunately  the memory 
recall waveform is buggy,still different to the memory save 
waveform,both in channel 1 and 2,auto and combi.Could be a trigger 
problem,I agree with you.
Anyway the persistence function works well ,together with the main 
functions.

Regards
Sandro

[Blue F. (blueflash)]

Hi Sandro,

thanks for reporting, I will test the memory saving once more.

Regards Hayo

[Blue F. (blueflash)]

Die Reaktion auf meine letzte Anfrage war ja recht verhalten. Ich habe 
die Neuerungen jetzt einfach mal eingebaut, da sie mir ganz gut 
gefielen. Vielleicht kommen ja jetzt einige Reaktionen dazu. In der 
Zwischenzeit war ich recht aktiv und habe an diversen Baustellen 
gearbeitet (siehe readme).


@Sandro

Save/Recall problem should be solved now. It was not the trigger, but 
the activated filter which changed the pointer to the signal memory. In 
consequence the wrong memory area has been saved to flash. Please test 
out and be so kind to report any problem.


@Andii

Wärst Du noch mal so nett die Sourcen in SVN einzuchecken?

Gruß Hayo

[Andiiiy (Gast)]

Hayo W. schrieb:
> Wärst Du noch mal so nett die Sourcen in SVN einzuchecken?

Gern ... soeben erledigt!

Es ist schon beindruckend wie sich die Software entwickelt hat. Ich 
hoffe ich kann Dich weiter für das neue FPGA Design begeistern? Jeder 
der es nur Testweise mal auf dem Gerät hatte, wird es bestätigen können.

Im Hintergrund haben wir mit Jörg etwas über das Thema "Gradient - 
displaying  the  Data" gesprochen, d.h. was sich an einen farbigen 
persistence Mode anlehnt. Mit dem aktuellen Design ist das aber nicht 
mehr möglich, da eine Plane nur eine Farbe haben kann.

Grüße Andiiiy

[eProfi (Gast)]

Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü 
einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der 
Absolutwert konstant bleibt. Das kann der LeCroy auch, ich finde das 
sehr praktisch.

[Blue F. (blueflash)]

Andiiiy schrieb:
> Ich hoffe ich kann Dich weiter für das neue FPGA Design begeistern?

Aber ja! Damit haben wir so viele neue Möglichkeiten...  Ich warte nur 
(wie eigentlich alle) darauf, dass Jörg sein Design für alle vier Kanäle 
stabil hinbekommt. Das ist natürlich leichter gesagt als getan. Ich bin 
da jedoch voller Zuversicht und glaube auch nicht, dass das Projekt 
wegen kleiner kreativer Pausen tot ist.

Die Updates an der BF-Firmware werde ich aber erst einstellen, wenn wir 
einen halbwegs vollwertigen Ersatz auf der neuen Plattform anbieten 
können.


eProfi schrieb:
> Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü
> einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der
> Absolutwert konstant bleibt

Hatte ich auch vorgehabt. Leider habe ich im Menübaum keinen 
(sinnvollen) freien Platz mehr gefunden. Das Triggermenü (bzw. Submenü) 
ist schon voll. Vorschläge nehme ich gern entgegen.

[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

[Sandro (Gast)]

Hallo Hayo,

now the memory save/recall   and trigger  works and the new functions 
also.Please check the cal standard menu isn't available. it's a little 
jewel!

@Victor
Some features (USTB,digital edge trigger,10 FFT filters and many 
more)and continuos technical support   all together  are only available 
on our Welec project, despite a limited hardware.May be the colour 
persistence is useful too.

Regards,
Sandro

[Blue F. (blueflash)]

eProfi schrieb:
> Bitte bitte Hayo, mach so viel es geht in einem Setup/Config-Menü
> einstellbar, hier: ob beim Triggerlevel die Zahl der Kästchen oder der
> Absolutwert konstant bleibt

Ok, ich habe den Rücksprung aus dem Triggersubmenü geopfert und da ein 
Popupmenü eingesetzt um das Triggerlevelverhalten einzustellen. Den 
Rücksprung kann stattdessen mit dem Mode/Coupling Button machen.

Sandro schrieb:
> Please check the cal standard menu isn't available. it's a little
> jewel!

Thanks for the hint! Bug is fixed now. Next version is coming soon.

[Blue F. (blueflash)]

Die neue Version ist da!

Neben einigen Verbesserungen und Bugfixes habe ich den 
Testsignalgenerator noch mal überarbeitet. Die Testsignale skalieren 
jetzt mit den Spannungsbereichen und sind DC/AC/Inverted sensitiv.

Da öfters mal gefragt wurde, wozu das Testsignal gut ist, habe ich mal 
eine kurze Beschreibung in der Datei Special Functions hinterlegt.

Hayo

[김사백 (Gast)]

Thank you Hayo.
Not less reading special functions document have arisen in to my head 
some doubts.
How many is the memory depth for each channel?
I knew Welec is 16kBytes memory depth for each channel independently 
from the time base but in your documents it's stated even 32kBytes 
somewhere.
And then another more trivial question which I don't know.
During acquisitions how much is it the maximun time which is possible to 
take recording of the waveforms on the screen?
I guess it depend on the time base and numbers of sample.
So when it using 1000s/div in USTB how much is the maximum time it is 
possible to browse the memorized waveforms?
Is it possible to calculate it?
Nice job.

400

[Blue F. (blueflash)]

김사백 schrieb:
> How many is the memory depth for each channel?
> I knew Welec is 16kBytes memory depth for each channel independently
> from the time base but in your documents it's stated even 32kBytes
> somewhere.

Memory depth is changing due to the sample rate. In fast sampling modes 
all 4 ADC are working interleaved. The result register is 32 bit long 
and every ADC has one byte in this register for its values. The readout 
length is alway 4096 samples long. So we get 4 * 4096 bytes. Well that 
are our 16Kbyte. In slower sampling modes (25MS and slower) only one of 
the four ADCs is working. So we get only one byte in the 32 bit register 
every readout cycle. That results in 4096 * 1 byte = 4Kbyte. In ultra 
slow timebases (USTB) the acquisition works completely different. The 
number of ADCs which are working is no longer important. The limiting 
factor is the internal RAM size. Some modes need more RAM space as 
others. So you can choose for some modes 32Kbyte buffer size.

김사백 schrieb:
> So when it using 1000s/div in USTB how much is the maximum time it is
> possible to browse the memorized waveforms?
> Is it possible to calculate it?

Indeed it is! One Div are 50 samples. that are 12*1000s = 12000s on the 
screen (3.3 hours). 1000s/Div are 20s/sample. 16K * 20 = 327680s (ca. 91 
hours) that you can browse in the 16Kbyte buffer (more than 3 days!!!).

Hayo

[김사백 (Gast)]

Hayo jjang!
327680s, daebak!
Terrific lasting time acquiring waveforms!
I didn't knew it.
I don't understand some things though.
Ok in USTB there are 50Sa/s (why 50?) setting time base for 1000s/div, 
so 12000s (3h 20m) for the whole screen because graticule is 12 
divisions.
But why is 20s/Sa in 1000s/div?
Welec is a real 1Gsa/s, starting by this I don't understand the other 
numbers you wrote where they come from.
Sorry I'm babo.

So long,
400

[Blue F. (blueflash)]

김사백 schrieb:
> Ok in USTB there are 50Sa/s (why 50?)

Not 50Sa/s - 50Sa/Div. That is always in every TB the screen resolution.
So you get 50 samples in one Div. One sample every 20s. That are 20s * 
50Sa = 1000s/Div. 12 Div on the screen are 12 * 1000s = 12000s

Hayo

[Blue F. (blueflash)]

Ok, weiter gehts. Ich hatte mich ja schon vor einiger Zeit mit der 
Sin(x)/x (auch bekannt als Sinc) Interpolation beschäftigt. Ich hatte da 
viel Zeit und Gehirnschmalz reingesteckt um das zu implementieren. 
Leider musste ich feststellen, dass unser veralteter NIOS Prozessor mit 
seiner langsamen Taktrate mit der Berechnung total überfordert war. Ich 
hatte die weitere Implementierung daher eingestellt.

Aber - nach der letzten kreativen Pause hatte ich wieder neue Ideen und 
habe mich noch mal drangesetzt. Zum Testen des FIR Algorithmus eignet 
sich das generierte Testsignal auf Kanal 1 besser als jedes echte 
Signal. Das ideale Rechteck hat eine Anstiegszeit gegen 0ns, was bei 
unserer Auflösung (Abtastung) einer Risetime < 1ns entspricht. Das 
Signal ist absolut rauschfrei. Folgerichtig habe ich also alles mit dem 
Testsignal überprüft.

Man kann auf den Bildern schön die Schräge und die Ecken der linearen 
Interpolation sehen. So sieht natürlich kein echtes Signal aus. jetzt 
kommt unsere Sinc Interpolation ins Spiel...

[Blue F. (blueflash)]

Ich habe den FIR Algorithmus soweit reduziert und mit einigen Tricks 
angepasst, dass die Sinc Interpolation mit einer noch akzeptablen 
Framerate läuft. Wenn alle 4 Kanäle gleichzeitig an sind, bricht die 
Framerate natürlich total ein, aber das DSO bleibt wenigstens nicht ganz 
stehen.

Man kann hier schön sehen, dass die Sinc Interpolation aus dem idealen 
Rechteck ein reales Rechteck simuliert wie es ein Pulsgenerator erzeugen 
würde.

Bei größeren ADC-Werten (150 - 255, unterer Screenbereich) kommt ein 
leichtes Rauschen hinzu, welches durch Rundungsfehler der auf 8bit 
reduzierten 16bit Berechnung entsteht.

Zur Zeit mache ich noch etwas Feinschliff, aber mit der nächsten Version 
steht die Sinc Interpolation zur Verfügung.

Hayo

[Kruno (Gast)]

Hmm
Aber das sinc interpolierte Signal zeigt Überschwinger die es in der 
Abtastung nicht gibt. Oder verstehe ich da was falsch?
Das könnte mich leicht auf die falsche Fährte führen wenn ich es an 
einer gut angepasster Leitung sehe.
Da kann man gar nicht mehr unterscheiden was echt ist und was das Oszi 
macht.
Bitte um Aufklärung.
Gruß,
Kruno

[김사백 (Gast)]

Thank you Hayo, I get it now...
...I hope.
I guess it's related with the screen resolution of the graticule on the 
screen that should be 600pixels horizontally (TFT of the Welec is 
640x480pixels as resolution).
Each TB is 50Sa/div and so 600 samples for the whole screen being 12 
divisions (50Sa/div * 12div = 600Sa) then it is 1 sample for each pixel 
of the screen (600 pixels).
Now for USTB and 1000s/div it is 12000s on the whole screen, so doing 
the division (12000s) / (600Sa) it is 20s which is 1 sample every 20s 
(20s/Sa) or 1 pixel every 20s which is the same thing.
Am I wrong?
Sorry I'm babo.

So long,
400

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
~
~Zur Zeit mache ich noch etwas Feinschliff, aber mit der nächsten 
Version
steht die Sinc Interpolation zur Verfügung.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
~
Just saw.
Daebak!
Are those from the original hardware rather than LB/OPA mods?

[Blue F. (blueflash)]

Kruno schrieb:
> Da kann man gar nicht mehr unterscheiden was echt ist und was das Oszi
> macht.

Jain! Du hast nicht ganz unrecht. Grundsätzlich ist es so dass in den 
interpolierten Zwischenräumen nicht das angezeigt wird was das Oszi 
misst, sondern das was man (man ist in diesem Fall die Interpolations- 
routine) an Signalverlauf vermutet. Bei der linearen Interpolation geht 
man davon aus, dass zwischen Punkt A und Punkt B der Signalverlauf in 
der Zwischenzeit linear weitergeht. Man verbindet die beiden Punkte also 
auf dem kürzesten Weg. In der Realität ist aber, wie wir wissen, nix 
linear. Steile Anstiegszeiten von Signalen sind immer verbunden mit 
Einschwingvorgängen. Beim Rechteck kann man das schön in einer 
mathematischen Reihenentwicklung aus der Überlagerung der einzelnen 
Frequenzkomponenten zeigen.

Bei der Sinc-Interpolation macht man jetzt nichts anderes als lauter 
Sinc-Signale zu überlagern und erhält dadurch eine Simulation die ganz 
dicht an der Realität ist.

http://de.wikipedia.org/wiki/Sinc-Funktion

Um zu sehen was echt ist und was nicht empfiehlt es sich zwischen 
linearer und Sinc Interpolation hin und her zu schalten. dann sieht man 
sehr deutlich was da Fake ist und was nicht.

Hayo

[Blue F. (blueflash)]

김사백 schrieb:
> Am I wrong?

You are right.

김사백 schrieb:
> Are those from the original hardware rather than LB/OPA mods?

Interpolation is completely independent from Hardware Mods.

Hayo

[Blue F. (blueflash)]

> Um zu sehen was echt ist und was nicht empfiehlt es sich zwischen
> linearer und Sinc Interpolation hin und her zu schalten.

Besonders gut sieht man das im Delayed Mode.

Hayo

[Kruno (Gast)]

Danke für die Aufklärung.
Danke auch für die gute Arbeit an der FW.

Kruno

[Blue F. (blueflash)]

So, gerade rechtzeitig vor dem Abendbrot noch fertig geworden. Viel Spaß 
beim Ausprobieren.

Jetzt werde ich mal die beste aller Ehefrauen bekochen :-)

Hayo

[Blue F. (blueflash)]

Hi Andiiiy,

danke für's Einchecken.

Hayo

[CB (Gast)]

Ciao Hayo.
Grazie for new software!

@Hayo
Indeed it is! One Div are 50 samples. that are 12*1000s = 12000s on the
screen (3.3 hours). 1000s/Div are 20s/sample. 16K * 20 = 327680s (ca. 91
hours) that you can browse in the 16Kbyte buffer (more than 3 days!!!).


Is possible take picture on PC of that big time?
If the answer is yes, how?
I am only capable to pour a single picture of the screen and I never see 
anybody do the entire area of memory.
Sorry for my english, I am from Italy.

[Blue F. (blueflash)]

CB schrieb:
> Is possible take picture on PC of that big time?

Ciao,

the screenshot program delivered with the firmware can receive raw data 
from the DSO which can be edited with excel. Unfortunately the USTB-Mode 
is not supported at this time. May be it is possible to download parts 
of the USTB-Signal but that is not guaranteed.

The good news are - I'm working on that. I hope to get it ready in the 
next time.

Buona notte

Hayo

[김사백 (Gast)]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Interpolation is completely independent from Hardware Mods.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hayo: that's good!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~The good news are - I'm working on that. I hope to get it ready in the 
next time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hayo: even that is good.
I had never thought.

So long,
400

[CB (Gast)]

Grazie Hayo!
My Welec have again original hardware.
I want do modify but again I have not the component.
For start I want use 24,9Ω and 150Ω (better 174Ω or 180Ω) that perhaps I 
have in old printed circuit.
For now I have open the oscilloscope and try adjust input but nothing 
happen.
I must upgrade the hardware before adjust or it is functional only with 
LB and OPA modification?
I like very much black/red theme you use, also I want use this.  ;-)
Buona Domenica.
Carlo

[Blue F. (blueflash)]

CB schrieb:
> I must upgrade the hardware before adjust or it is functional only with
> LB and OPA modification?

Ciao Carlo,

adjusting the input stage is always a good idea due to the fact that the 
factory adjustment is mostly poore. That is independent from any 
modification. It is just the same as adjusting a probe before you can 
use it for serious measuring.

By the way, I checked the coding for transfering raw data to the PC. 
Actually there are transferred the first 4096 samples of every channel 
in USTB mode. The rest is cut off. I'm working on that...

Hayo

[CB (Gast)]

Ciao Hayo.
Well, but trimmer don't function in my oscilloscope.
I see with a lens and trimmer are broken.
Big new for PC transfer, tank you for the help!
Buona sera.
Carlo

[Blue F. (blueflash)]

CB schrieb:
> Well, but trimmer don't function in my oscilloscope.

Maybe the soldering is bad. If so, you have to desolder the metal covers 
and resolder the pads. On my DSO some of the pads are also bad soldered.

[CB (Gast)]

Ciao Hayo.
No, unlucky soldering is well are trimmer that are broken chipped.
I must substitute.
Grazie!
Carlo

[Krunoslav O. (kruno3)]

Hallo Hayo
Bei der letzter FW habe ich einen komischen Offset am Display bemerkt. 
Auf der Mittellinie ist alles OK, aber je mehr man die Nulllinie nach 
oben oder unten verschiebt, wird ein Offset dazu addiert, unten positiv, 
oben negativ (siehe Bild).
Der Betrag ist unabhängig vom Bereich und kommt bei beiden Kanälen 
(W2022A) gleichermaßen vor.
Vorher habe ich die Offsets kalibriert (vielleicht hat es was damit zu 
tun).
Gruß,
Kruno

[Blue F. (blueflash)]

Hallo Kruno,

bin wieder gerade erst vom Griechen zurück (Montags ist immer Grieche). 
Das Bild ist wohl irgendwie verloren gegangen. Aber ich weiß schon was 
Du meinst. Da stimmen die Faktoren für die Verstärkung (Gain) nicht so 
richtig.

Die Einstellung dafür findest Du im Hardwaremenü. Die Grundeinstellung 
macht man mit Pre Gain. Wenn Deine Kiste noch original ist "Factory" 
nehmen. Sonst je nach Modifikation einstellen. Die Feineinstellung macht 
man mit Gain. Bei 1,000 passiert nix (1 x irgendwas ist immer noch 
irgendwas). Je nach Bedarf den Wert nach oben oder unten verstellen - 
dann sollte es passen.

[Blue F. (blueflash)]

CB schrieb:
> I must substitute.

So I would take the muRata, seems to match the demand.

Hayo

[Krunoslav O. (kruno3)]

Ja, das war's.
Dort war LB-Mod eingestellt (nicht von mir).
Danke Hayo

[Blue F. (blueflash)]

Hi Folks,

hier die neue Version. Diesmal habe ich vor allem an den Tools 
gearbeitet. Die Screenshot-Version ist jetzt bei 1.0 und bietet USTB 
Support. Die Version ist nicht abwärtskompatibel und braucht mindestens 
die aktuelle FW 7.5, da der Trace-Header erweitert wurde. Weiterhin habe 
ich die Parametertexte angepasst (es waren noch uralte Menütexte drin) 
und die Trennzeichen für ASCII und CSV korrigiert. Die Anzahl der 
Übertragenen Samples ist abhängig von der eingestellten Timebase bzw. 
der eingestellten Buffergröße und kann bis zu 32K pro Kanal betragen.

Bei 20s pro Sample sind das 640000s = 177h = 7,4 Tage = 1 Woche!

Da in der Vergangenheit immer mal wieder bei Einsteigern Schwierigkeiten 
bei der Installation von Perl und WIN32 Serial Port auftraten habe ich 
einen einfachen Firmware Updater als Konsolenprogram geschrieben, der 
statt des Perlscripts verwendet werden kann. Er ist genauso schnell 
(180s = 3min), kann aber weder gepackte UCL-Dateien laden noch Backups 
erstellen. Es können aber Backupdateien vom WELEC-Updater oder vom 
Perlscript geladen werden.

Das Tool soll in erster Linie eine Vereinfachung für Einsteiger und 
Gelegenheits-Flasher sein. Poweruser und Programmierer wechseln wie 
gehabt in das UCL Verzeichnis und benutzen das Perlscript mit 18s 
Uploadzeit.

Gruß Hayo

[Thomas (kosmos)]

by the Way. Habe heute auch Perl installiert erst die 64bit Version 
damit funktioniert aber Serialport nicht, also deinstalliert und die 
32bit Version installiert. Für Serialport (aktuell V0.22) ist es wichtig 
im Gerätemanager erst auf 9600 bps umzustellen um das Makefile... 
auszuführen. Bei der Firmware dann später aber wieder auf 115200 bps 
einstellen.

Was mir bei der 7.4 aufgefallen ist. Gridcolor Gray und With sind 
identisch beides grau

[Blue F. (blueflash)]

Hatte vergessen eine kurze Anleitung beizufügen. Als alter Hase denkt 
man nicht immer daran, dass ein Neuling oft nicht so genau weiß wie man 
das macht. Ist dann bei der nächsten Version mit im doc Verzeichnis.


@Thomas

Die beiden Gridfarben sind nicht ganz identisch. In der 66% Einstellung 
unterscheidet sich die Farbe etwas.

Hayo

p.s. wer den easyloader als Windows 64 bit Version braucht möge sich 
melden, dann stelle ich das zur Verfügung

[김사백 (Gast)]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Hatte vergessen eine kurze Anleitung beizufügen. Als alter Hase
~denkt man nicht immer daran, dass ein Neuling oft nicht so genau
~weiß wie man das macht. Ist dann bei der nächsten Version mit im
~doc Verzeichnis.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thank you Hayo, I have some trouble though.
This time for the upgrade I have used your easyloader.
I have setted the batch file for my COM number and tried it.
I got this:

D:\>"D:\\easyloader.exe" -c 3 -f TomCat.flash

************************************************************************ 
*
* 
*
*                        Easy Loader v1.0 
*
* 
*
* RS232 serial port firmware update tool for WELEC DSO W20xxA. 
*
* Update the flash memory with a new firmware using TomCat.flash. 
*
* The firmware can also be loaded temporarily into RAM for tests using 
*
* the TomCat.ram file. Please keep in mind, that the new firmware may 
*
* overwrite settings of the previous firmware. Therefore it may be 
*
* a good idea to make a complete backup of the flash memory before 
*
* changing anything. Don't switch off the DSO while flashing!!! 
*
* 
*
* This program is distributed with absolutely no warranty. Problems or 
*
* damages that may arise out of the use of this program are completely 
*
* on your own risk! 
*
* 
*
* 
*
*                                       2014 by BlueFlash 
*
* 
*
************************************************************************ 
*


open file TomCat.flash
file size is 1668964 bytes
communicatition test    - ok
starting transmission...

setting address offset register
erasing flash sector 00040000

command not recognized - retry

command not recognized - retry
Error: transmission error - aborting firmware update
, exiting.

(OS was Windows7 Starter)
Since then my Welec show black screen and doesn't work anymore.
Switch off/on or reset do anything.
Connecting the DSO through a serial cable to a computer running TERATERM 
I'm able to only get this:

++C CPU048

"h" doesn't work but it change HEX numbers on the serial terminal 
output.
I guess flash in my DSO was erased so now it doesn't work.
All this don't worry me because I know my Welec only need to be 
reflashed using the good old Perl Script.
Later I'll do that and I'll post the result.
Repeat not worry at all, actually not any trouble.
Please chill out, nothing happened.

So long,
400

[Blue F. (blueflash)]

Hi,

try to load the firmware once more. If this don't work -> use perl 
script.

Do you have installed Perl and WIN32 Serial Port?
If so, you can use the perl script which can be found in the UCL 
directory. Change the flasloader.bat according to your com port settings 
and start it. Upload should be done after 18s.

Hayo

[김사백 (Gast)]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ try to load the firmware once more. If this don't work -> use perl
~ script.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hayo: I know, I know.
I have tried several times with easyloader but no joy.
I had to use the Perl Script.
I had to use the Perl Script.
That solved the issue and now the DSO is functioning like before.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Do you have installed Perl and WIN32 Serial Port?
~ If so, you can use the perl script which can be found in the UCL
~ directory. Change the flasloader.bat according to your com port
~ settings and start it. Upload should be done after 18s.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hayo: I have it, don't worry.
Nothing happened, my Welec is live better than before with your new 
firmware.
Thank you.

So long,
400

[Blue F. (blueflash)]

That's good to hear. Unfortunately I only have an old WinXP / Linux PC 
for developing. So I don't know how the program works under Vista or Win 
7. I will try to solve that problem. Is it possible, that your system is 
a 64 bit system? That might be a reason.

So long

Hayo

[김사백 (Gast)]

Hayo: no it's Windows 7 Starter Edition 32bit.
Microprocessor inside the netbook is a N450 64bit but the operating 
system is only 32bit.
Anyway nothing happened except I now enjoy the new firmware.
Thanks.

So long,
400

[Blue F. (blueflash)]

Now I set up a second PC for testing and on this PC the easyloader has 
the same problem as on yours, while on my main system it is running 
without problems. Strange! I will try to solve the problem.

Hayo

[Charly B. (charly)]

Hi 김사백

try this, i use it also, maybe its works on your system

vlG
Charly

[Blue F. (blueflash)]

Hi Charly,

hat der easyloader bei Dir auch Probleme gemacht? Bis jetzt habe ich 
dazu keine weiteren Rückmeldungen.

Hayo

[Charly B. (charly)]

moinmoin Hayo,

hab i noch nicht versucht, bin z.Z. im Stress, hab seit ~2 Monaten nix
mehr gemacht, werde ihn aber event. am WE mal ausprobieren. I flashe
schon seit Jahren mit dem obigen Prg., z.Z. unter win7/64U

vlG
Charly

[Blue F. (blueflash)]

OK,was ist das für ein Programm?  Gibt es den Code dafür? Bin gerade mit 
dem Tablet in der Bahn und hab nur eingeschränkte Möglichkeiten (bin 
beruflich in Frankfurt).

Hayo

[Charly B. (charly)]

keine Ahnung, hab es irgendwann im netz gefunden weil bei mir
dieser 'pearl loader' damals nicht wollte und der original
loader mehr als 15 Minuten brauchte (wenn i mich richtig erriner)
Bei dem Prg steht auch nicht dabei von wem es ist ;(
aber es funktioniert, ich dachte auch es sei hier auch bekannt,
es gibt auch keine Rueckmeldungen ob es funktioiert o. nicht........

vlG
Charly

[김사백 (Gast)]

Charly: thanks.
Isn't it the original upgrade software from Welec?
I know it's slow compared to Perl Script so normally I use the latter.
I didn't know it worked using new Windows versions (Win7/8/8.1) and 
32/64bit too.
For what I know WelecUpdate is especially good in order to get a safety 
backup of the original firmware.
It's slow but safe and never fails while Perl Script isn't so suitable 
for that kind of operations.
~
Hayo: one question about Test-Signal.
I see amplitude of the test signals depends on the gain set in the 
hardware menu.
So would not be possible to use it to calibrate the level of the input 
channels?
Thanks.
 ~

So long,
400

[Charly B. (charly)]

Hi 김사백

its not the Original Wellec, i found the Prg long long time
ago on the Net, its work on my system w. W7/64U and need
~ 180s for flashing

vlG
Charly

[김사백 (Gast)]

Charly: thanks.
Aish!~
Indeed it isn't at all, sorry!
You are right though, it works on my netbook.
IMHO it's very useful, I didn't know that program.
At first glance it seems to be something from Wittig/Welec.
Though there is any copyright.

So long,
400

[Blue F. (blueflash)]

Charly B. schrieb:
> Bei dem Prg steht auch nicht dabei von wem es ist ;(
> aber es funktioniert, ich dachte auch es sei hier auch bekannt,
> es gibt auch keine Rueckmeldungen ob es funktioiert o. nicht........

So bin wieder zurück und habe mir das Programm mal angesehen. Es läuft 
bei mir auf allen PCs problemlos. Ich kannte das bisher überhaupt nicht. 
Bevor ich jetzt noch Zeit investiere um herauszufinden, warum beim 
easyloader das bescheuerte Windows API den Com-Port nicht richtig 
ansteuert werde ich einfach mal dieses kleine aber feine Programm meinen 
Paketen hinzufügen. Ich hoffe das ist im Sinne des unbekannten 
Programmierers.

Die Linux-Version des Easyloaders wird auch weiterhin dabei sein, da 
diese auf allen bisher getesteten PCs problemlos lief.

Danke für den Tip

Hayo

[김사백 (Gast)]

~W2012A/OPA653
~BF.7.5
Hayo: overlay function doesn't works as supposed to do.
Channel 2 became 10:1 probe and persistence switch on even if it isn't 
selected.
Thank you.

So long,
400

[김사백 (Gast)]

~W2012A/OPA653
~BF.7.5
Hayo: OSS switched on, then IP label is always Off even though actually 
Linear or sin(x)/x are selected.
Something like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Turn off then on or reset doesn't fix, IP label is always Off.

~

Some times parameters in the hardware menu are changed.
Setting for OPA653 but it find 24/180ohm without do anything.

~

Some times sine wave for the Test Signal is a sawtooth.

~

Often position of the trigger in the time (browser) doesn't match with 
the slope.
Something like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks.

So long,
400

[Sandro (Gast)]

Hi Hayo,
 I tested the last firmware with two IC OPA653 installed works well up 
to 230 MHz.
Used reference HP3325A / TDS540A and with gain 1.00 accuracy is so good.
Just a a minor bug the test signal is triangular.

Thank you and Regards,
Sandro

[김사백 (Gast)]

~W2012A/OPA653
~BF.7.5
Hayo: the amount of the delay between the channels depend on the V/div 
setting.
Range 1 and range 2 have a their unique value while range 5 has its 
other one which is different.
So the delay set in hardware menu doesn't match in all the situations.

~

Sandro: I also reported the bug in the Test Signal.
In my case it isn't always a triangle.
Indeed it's a sine wave until the moment in which touching something it 
becomes triangular.
~
Sandro: nice pictures.
I have also a W2012A modified with OPA653 and it works great.
In my case I have to set gain under 1 to obtain correct levels.
I used leveled voltage reference so I'm pretty sure all is 100% 
matching.
I compared my Welec against Tektronix 500MHz DPO using a square wave 
generator and finding it can reach about 200MHz, no more.
With the gain I have setted adjusting it using the leveled voltage 
reference the Vpeak-peak and the shape of the reference square wave is 
the same I see on the DPO using sin(x)/x interpolation otherwise using 
the linear one Vpeak-peak is lower even if the shape of the waveform 
isn't very different (only less overshoot).
HP3325A is a 21MHz function generator, how could you get 230MHz?
Thanks.

So long,
400

[Sandro (Gast)]

Hi 400,
I use also a 8GHz Wiltron generator , 0.1 dB accuracy in the full range 
,compared with a Anritsu microwave signal gen.same accuracy,then a 
calibrated power meter up to 30GHz and 4 GHz spectrum analyzer to be 
sure about the level and harmonics.You can read it in this forum.
3325A is suitable to adjust the square wave response  and also have 
enough accuracy.
So,for daily use I trust our W2022 and appreciate the software.

Sandro

[김사백 (Gast)]

Sandro: thanks, you are lucky to have all those instruments.
I didn't know it, sorry.
Do you mind some questions?
I'd like to have your opinion on some things here and in the "Hardware 
(Teil 2)" (Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"), because 
I see you have the necessary tools to dig the matter.

~ Are setting for delay in the hardware menu good for all 1/2/5 range?
(In my case the amount of the delay between the channels depend on the 
V/div setting)

~ By applying a leveled square wave signal matched for 50Ω is the 
Vpeak-peak amplitude correct compared to the generator while using 
linear or the sin(x)/x interpolation?
(In my case the correct value is while using sin(x)/x after adjustment 
performed with a DC leveled voltage reference while Welec was set for 
linear interpolation)

~ Is the overlay function functioning?
(In my case it doesn't works)

~ What rule have you used for set the gain in hardware menu?
(In my case I used a DC leveled voltage reference while Welec was set 
for linear interpolation but I had to set gain under 1 to obtain correct 
values)

~

Sandro: when you wrote 230MHz were you mean like bandwidth?
(In my case last year at school I have measured 165MHz after the OPA653 
modification, starting by a W2012A with 33/150Ω)

Other questions follow here:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks.

So long,
400

[Sandro (Gast)]

Yes, max frequency is typical  as the enclosed screenshot,but 200 MHz is 
enough.
Input 1 V pp square to the dso and adjust gain and input capacitors.
Overlay is working but : Let's wait Hayo reply.

Sandro

[김사백 (Gast)]

Sandro: thanks for the help.
Nice your picture.
You mean the trigger ability while I mean the bandwidth.
Starting from 1Vpeak-peak the bandwidth is supposed to be within the 
limit of -30% and 148mVpeak-peak is much less than -30%, it is -85%.
Anyway the shape of that 250MHz sine wave looks quite good using 
sin(x)/x, it surprise me.
~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Input 1 V pp square to the dso and adjust gain and input capacitors.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sandro: ok for the 1Vpeak-peak (Hayo wrote between 1kHz and 1MHz) square 
wave.
My doubt is if I must adjust for the overshoot peak at the same level of 
the flat top/bottom of the square wave or in order to get the flat 
top/bottom side as long as possible and overshoot peak over the level of 
that.
That's why I asked you a picture with the details of the overshoot taken 
with filter off and reduced time base.
Moreover when I adjusted mine Welec there wasn't sin(x)/x support and I 
have used Linear interpolation.
Today sin(x)/x is supported so what should I use for the best result?
Thanks.

So long,
400

[Blue F. (blueflash)]

김사백 schrieb:
> My doubt is if I must adjust for the overshoot peak at the same level of
> the flat top/bottom of the square wave or in order to get the flat
> top/bottom side as long as possible and overshoot peak over the level of
> that.

Overshoot - the name is the meaning! So the overshooting has to be a 
little bit higher than the flat top of the rect signal (see pictures).


The persistence setting in Save/Recall/Overlay is not longer saved with 
the signal (coming with BF.7.6). I changed it today.

Hayo

p.s. added bigger picture

[Blue F. (blueflash)]

Die neue Version mit einigen Bugfixes und kleinen Änderungen bzw. 
Optimierungen. Das kleine Uploadprogramm das Charly hier geposted hat 
ist jetzt auch mit an Bord.

Gruß Hayo

[김사백 (Gast)]

Hayo: jjang!
Pictures daebak!
Thanks, that's what I was looking for!
Now I know what I must do.
Of course thanks also for new release and bug fix.

So long,
400

[Sandro (Gast)]

@ 400
Square wave is for adjustment only.Then start auto offset calibration 
and check the frequency response.
I mean -3dB bandwidth is 230 MHz: use a sine generator and terminate the 
dso with a 50 ohm load for testing.Input level between 0 (220 mVrms) and 
-10 dBm.
Enjoy it

Sandro

[김사백 (Gast)]

Sandro: honestly I don't understand what you mean.
Sorry, aish!~~~
OK, square wave is for adjustment only.
I know because Hayo explained it very well.
I don't understand the meaning of the phrase

~ start auto offset calibration and check the frequency response

and especially of this

~ I mean -3dB bandwidth is 230 MHz: use a sine generator and terminate
~ the dso with a 50 ohm load for testing.Input level between 0 (220 
mVrms)
~ and -10 dBm.

Aish!~

Anyway, last Monday  I too have measured a 250MHz sine wave in very 
pretty good shape like the your.
Starting by a 50Ω matched 1Vpeak-peak 250 MHz sine wave I have got 
250mVpeak-peak ond the screen.
Really good but 250mVpeak-peak starting from 1Vpeak-peak is -75%, not 
-30%.
I rather have got -30% (-3dB) at 165MHz: 700mVpeak-peak.

A weird thing I noticed is the behaviour of my Welec with sine waves 
over 200MHz.
250MHz sine wave have good shape but going down in frequency for 
instance 230MHz isn't so good.
It seem to be overimposed to a low frequency sine wave and it has not a 
stable amplitude.
Under 200MHz all is good like amplitude even if seems to me trigger 
position very often doesn't match with the trigger level.
Thanks.

So long,
400

[Blue F. (blueflash)]

김사백 schrieb:
> I rather have got -30% (-3dB) at 165MHz: 700mVpeak-peak.

That could be the wrong adjustment of the input stage. If the input 
stage is adjusted in that way you wrote above (overshooting is flat), 
higher frequencies will be attenuated. To get a correct result of your 
bandwidth measuring you first have to adjust the input stage.

Hayo

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

Hallo Hayo,

schön das du wieder dabei bist, ich denke auch über einen Wiedereintritt 
nach.
Ich habe zugegeben nicht in den Code geguckt und die Firmware auch nicht 
ausprobiert, frage trotzdem:
Kannst du dich zu deiner sinc-Interpolation noch etwas auslassen, wie 
man die praktisch realisiert? Ich hatte verstanden, sinc ist ein idealer 
Tiefpaß und daher leider unenlich lang, nicht praktikabel.
Zweite Frage, wie hast du die variable Persistenz gelöst? Dazu müßte man 
ja eigentlich alle Wellen speichern und immer alle neu zeichnen, nachdem 
man hinten eine weggenommen hat. Ich vermute du löscht periodisch 
komplett, oder gibt es was raffinierteres?

Grüße,
Jörg

[김사백 (Gast)]

Hayo: this time before starting with measures I tuned inputs in the 
right way as you explained.
Actually bandwidth doesn't matter to me because mine it's the 100MHz 
version so 150MHz it's fine for me.
What I'm talking about is for things I learned at school in the recent 
past which now are stated in different way from what I know.
That's spirit.
Moreover I see my measurements very alike with those to others, Sandro 
for instance.
I got same results so I'm pretty sure all it's good.
Surely I'm missing something but I get -30% at roughly about 165MHz.
Going over there the amplitude decreases more and more, no way.
May be a problem only if others can document a different behavior.
Next Monday I'll take some picture and I'll post them here, I hope.
Only thing that really worry me is the weird behaviour I get between 
200MHz and 250MHz because it's crazy that 250MHz are better and more 
easily shown on the screen than 230MHz or less.
May be a resonance.
Wonder if it's only with my Welec.
Thanks.

So long,
400

[Blue F. (blueflash)]

김사백 schrieb:
> actually bandwidth doesn't matter to me because mine it's the 100MHz
> version so 150MHz it's fine for me.

You are right! And we should keep in mind, that a 200 MHz DSO is made 
for measuring real signals with main frequency of max. 40 - 50 MHz to 
get convincing results. In real live we rarely measure pure sinus 
signals, so this is more theoretical. Especially in digital circuits we 
find signals that are a kind of rectangle which contain multuple other 
(higher) frequency components than the main frequency.

Hayo

[Blue F. (blueflash)]

Jörg H. schrieb:
> schön das du wieder dabei bist, ich denke auch über einen Wiedereintritt
> nach.
Das sind bei mir nur kreative Pausen. Speziell im Sommer bin ich meist 
so im Freizeitstress, dass ich kaum weiß was ich bei gutem Wetter zuerst 
machen soll. Da fallen dann alle Bastel und Programmiersachen hinten 
raus. Im Winter wendet sich dann das Blatt...  :-)

Ich hoffe ja inständig auf Deine FPGA Implementierung.

> Kannst du dich zu deiner sinc-Interpolation noch etwas auslassen, wie
> man die praktisch realisiert? Ich hatte verstanden, sinc ist ein idealer
> Tiefpaß und daher leider unenlich lang, nicht praktikabel.

Ja, das ist ein leidiges Thema. Wenn man es mathematisch korrekt machen 
will, dann muss man eigentlich filtern bis das Universum aufhört zu 
existieren. Praktisch macht man es wie bei der FFT, man benutzt 
Fensterfunktionen die den Filter endlich begrenzen. Man findet hier die 
üblichen Versdächtigen, nämlich alle möglichen Arten von Cosinusartigen 
Fenstern (Hamming, Hanning, Blackman etc.).

Des weiteren sind die Anforderungen an die Rechenleistung nicht 
unerheblich. Signalprozessoren haben hier den Vorteil, dass sie die 
typische Berechnung mit nur einem MAC Befehl (multiply and accumulate) 
abfackeln können. Bei unserer Gurke muss man da tief in die Trickkiste 
greifen, damit das Ding nicht ganz stehen bleibt. Da wäre zum einen die 
Verwendung von Lookup-Tabellen. Die Werte werden beim Start des DSO 
schon berechnet und in einer Tabelle abgelegt.

Zum Anderen gibt es für die Berechnung in digitalen Systemen 
hochoptimierte Algorithmen. Da wäre in unserem Fall die Implementierung 
als Polyphase Filter. Das bedeutet im Prinzip, statt eines langen 
Filters mehrere kurze Filter die eine gegeneinander verschobene 
Mittenfrequenzen haben. Die Implementierung ist so gemacht, dass immer 
nacheinander jeweils ein Filterwert auf den Ausgang geschaltet wird. Im 
Programm macht man das mit Arrays und ineinander verschachtelten 
Schleifen.


> Zweite Frage, wie hast du die variable Persistenz gelöst? Dazu müßte man
> ja eigentlich alle Wellen speichern und immer alle neu zeichnen, nachdem
> man hinten eine weggenommen hat. Ich vermute du löscht periodisch
> komplett, oder gibt es was raffinierteres?

Das ist eigentlich relativ einfach gelöst. Die Persistenz wird dadurch 
erreicht, dass die Signalebene nicht gelöscht wird bevor neu 
reingezeichnet wird. Das entspricht dann der Einstellung "Unendlich". 
Bei den ander Einstellungen (5s, 10s, 25s, 50s) gehe ich mittels 
Schleife durch den Speicher und schreibe in bestimmten Abständen 
Nullen(schwarz) in den Grafikspeicher. Wenn man das zyklisch wiederholt 
und dabei die Abstände verändert ist irgendwann der ganze Speicher 
gelöscht.

Hayo

[Blue F. (blueflash)]

Ach ja, aktuell bin ich dabei ein altes Problem wieder herauszuzerren 
und endlich mal eine Lösung dafür zu bauen. Viele haben es vermutlich 
schon wieder vergessen, aber vor längerer Zeit wurde schon durch 
Exportieren der ADC-Werte festgestellt, dass unter bestimmten Umständen 
die ADC-Werte nicht in der richtigen Reihenfolge ausgelesen werden und 
daher auf Signalflanken üble Zacken zu beobachten sind (ich glaube Falk 
hatte das festgestellt). Meine jetzigen Messungen haben ergeben, dass 
bei der Hardwareversion 8C7.xx die Zeitbasen 2µs und 5µs (500MSa/250MSa) 
betroffen sind - siehe Bilder.

War gar nicht so einfach herauszubekommen was da schiefläuft. Die Werte 
werden ja immer als 32 Bit Wert aus dem FPGA-Register gelesen und dann 
in 4 Bytes zerlegt. Ich habe dann versucht die Bytes in der Reihenfolge 
zu ändern aber das machte die Sache nur schlimmer. Bis ich dann drauf 
gekommen bin, dass es immer zwei 32 Bit Werte sind die zusammenhängen 
(also 8 Byte).

Die Bytes sind immer paarweise falsch angeordnet. Statt 01|23|45|67 
kommen die Bytes in der Reihenfolge 45|01|67|23. Ich habe daraufhin 
einen Assemblertreiber geschrieben der die Reihenfolge korrigiert. 
Allerdings funktionierte das erst, nachdem ich den Triggeroffset vor dem 
Buffer Readout auf eine gerade Addresse gesetzt hatte. Ergebnis seihe 
drittes Bild. Die endgültige Implementierung ist noch in Arbeit.

Hayo

[김사백 (Gast)]

Hayo: exactly, I agree.
Plus I'm sure nothing is wrong in my Welec.
My doubts are only for some things that teachers have told me in 
different way and now I don't understand who is wrong and who is right.
All this even keeping in mind that one teacher of mine explained at me 
the wrong way to make compensation of the inputs immediately after OPA 
mod.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Die Bytes sind immer paarweise falsch angeordnet.
~ Statt 01|23|45|67 kommen die Bytes in der Reihenfolge 45|01|67|23.
~ Ich habe daraufhin einen Assemblertreiber geschrieben der die
~ Reihenfolge korrigiert.
~  Allerdings funktionierte das erst, nachdem ich den Triggeroffset vor
~ dem Buffer Readout auf eine gerade Addresse gesetzt hatte.
~ Ergebnis seihe drittes Bild. Die endgültige Implementierung ist noch
~ in Arbeit.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That's daebak!
Hayo: I could be wrong but I guess you have just found the culprit for 
the weird behaviour that I wrote!
You are jjang!
Thanks.

So long,
400

[Blue F. (blueflash)]

김사백 schrieb:
> Hayo: exactly, I agree.
> Plus I'm sure nothing is wrong in my Welec.
> My doubts are only for some things that teachers have told me in
> different way and now I don't understand who is wrong and who is right.
> All this even keeping in mind that one teacher of mine explained at me
> the wrong way to make compensation of the inputs immediately after OPA
> mod.

No teacher can know every thing! And teachers are also learning every 
day. So we have to be critical and have to verify things we have learned 
in school :-)

Hayo

[Blue F. (blueflash)]

Kurzer Zwischenstand meiner Nachforschungen:

Anders als bisher angenommen (und auch in der Firmware implementiert), 
gibt es nicht nur eine Betriebsart mit 16K Speichertiefe (Highspeed) und 
eine Betriebsart mit 4K Speichertiefe (Lowspeed), sondern noch ein 
Zwischending. In den Timebases 5µs und 2µs (250MS und 500MS) sind 
nämlich immer zwei Byte (nahezu) identisch wenn man das FPGA im 16K 
Modus ausliest. D.h diese TB laufen real mit 8K Speichertiefe.

Da muss ich wohl noch etwas mehr umbauen als den Treiber...

Hayo

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

Hallo Hayo,

Von einem 8k Modus weiß ich nichts, aber was mir gerade wieder einfällt, 
ich habe schon mal versucht dich drauf zu stubsen:

Du könntest auch mal in meinem Sourcecode von Osoz forschen, der kann 
auch die bei dir "fehlenden" Sample Rates zwischen 25 und 250 MSa/s.
Guck' mal in den Treiber für die alte Hardware, in 
platform/nios/src/capture.c, Funktion CaptureSetTimebase().

Jörg

[Blue F. (blueflash)]

Jörg H. schrieb:
> Von einem 8k Modus weiß ich nichts

Ist ja auch kein offizieller 8K Modus sondern eigentlich in beiden 
Fällen ein 16K Modus. Da aber immer zwei Werte als Pärchen identisch 
sind (da werden offensichtlich immer zwei ADC zur gleichen Zeit 
ausgelesen) sind es effektiv nur 8K echte Werte. Es fällt nur im 
Normalbetrieb nicht auf, da in der entsprechenden Screendarstellung 
immer nur jeder 20ste bzw. 25ste Wert ausgegeben wird. Auffallen tut es 
nur wenn man die Daten als ASCII Datei downloadet oder im Delayed Modus. 
Mir ist es aufgefallen als ich mir die FFT noch mal genauer angesehen 
habe, da hier alle Werte verwendet werden.

Jörg H. schrieb:
> Du könntest auch mal in meinem Sourcecode von Osoz forschen, der kann
> auch die bei dir "fehlenden" Sample Rates zwischen 25 und 250 MSa/s.

Ja ich erinnere mich, eigentlich brauche ich nur die Registerwerte, dann 
könnte ich das mal einbauen. Da sehe ich noch mal nach.

Hayo

[Blue F. (blueflash)]

Ok, hab den Treiber extrahiert und in die BF-Firmware eingebaut. Nach 
einigen Tests hat sich Folgendes ergeben:

- Wir reden hier von unterschiedlichen Dingen. Die Sampleraten von 125MS 
und 62,5MS die der Treiber einstellt sind keine echten Sammpleraten 
sondern nur dezimierte Sampleraten. Die kann ich auch jederzeit 
erzeugen. Es geht hier um die echten Taktraten mit denen die ADC 
getaktet werden bzw. die dazugehörigen Registerwerte.

- Der Treiber ist sehr schön aufgebaut vom Funktionsprinzip her, wurde 
aber wohl nicht so richtig getestet. Der Subsampling-Wert 32 
(Registerwert 0xFFFFFFFC) soll einer Abrtastrate von 31.5 MSa 
entsprechen.

Tatsächlich ist die Abtastrate aber identisch mit Subsampling-Wert 40 
(Registerwert 0xFFFFFFFB) = 25MSa. Das Gleiche gilt für Subsampling-Wert 
48 (Registerwert 0xFFFFFFFA) der ebenfalls 25MSa entspricht.

- Und wie von mir jetzt entdeckt -> 250MSa und 500MSa sind eigentlich 8K 
Betriebsmodi. Der 500MSa Modus lässt sich durch Tauschen der 
Bytereihenfolge wieder geradebiegen, der 250MSa Modus leider nicht, da 
sich die Bytereihenfolge hier willkürlich von Mal zu Mal ändert. Diese 
Zeitbasis ist also eigentlich überhaupt nicht verwendbar, da hier die 
zeitliche und die quantitative Zuordnung nicht reproduzierbar ist. Das 
trotzdem so etwas wie eine Signalform entsteht ist der Tatsache 
geschuldet, dass im normalen Betrieb nur jeder 25ste Wert verwendet 
wird. Wenn man aber im Delayed-Modus aufzoomt, dann sieht man was ich 
meine.

Ich hatte schon vor längerer Zeit alle möglichen Registerwerte 
ausprobiert und dabei die funktionierenden Registerwerte extrahiert. Es 
hätte mich jetzt sehr gewundert wenn ihr da auf einmal neue Betriebsmodi 
entdeckt hättet.

Gruß Hayo

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

Hallo Hayo,

es ist lange her daß ich den Code geschrieben habe, die Details habe ich 
nicht mehr parat.
Wo du davon schreibst erinnere mich mich aber an die wirre 
Sample-Reihenfolge. Daran war ich glaube ich auch verzweifelt. Ich hatte 
mal eine Kalibrierroutine geschrieben oder angefangen, die die 
Sortierung austestete, aber dann gemerkt das jedes Mal neu gewürfelt 
wird.
Das mit der Dezimierung stimmt glaube ich, im Übergangsbereich ist es 
reine Ansichtssache, ob man den Speicher 1-, 2- oder 4-zügig betrachtet.

Jörg

[Blue F. (blueflash)]

Ich hatte ja auf eine echte Abtastrate unterhalb von 250MSa gehofft um 
diese TB dadurch zu ersetzen. Naja, spes saepe fallit wie der Lateiner 
sagt.

Dafür habe ich jetzt einen handoptimierten interpolierenden 
Assemblertreiber für die 500MSa TB gebaut. Was heißt das?

Also erst einmal wird die Bytereihenfolge in Ordnung gebracht, was etwas 
tricky ist wenn man gleichzeitig schnell sein will (und er ist schnell - 
schneller als der normale Treiber). Zusätzlich habe ich den Lesezugriff 
auf jedes zweite Byte rausgenommen, da ja hier immer der gleiche Wert 
wie vorher gelesen wurde. Ist also redundant. Stattdessen habe ich den 
Mittelwert zwischen dem vorhergehenden und dem folgenden Wert gebildet. 
Dadurch bekommen wir jetzt statt 16KB lang Treppchen aus 8KB Werten 
tatsächlich 16KB sinnvolle Werte die zwar nicht alle echt aber zumindest 
schlüssig sind.

In der 250MSa TB kann dieser Treiber zwar das eigentliche Problem nicht 
lösen, sorgt aber für eine gewisse Schadensbegrenzung. Das man nach all 
den Jahren immer noch auf solche Überraschungen stößt...

Ich schreibe zur Zeit noch die invertierende Version des Treibers, dann 
gibt es die neue FW Version und Ihr könnt Euch selbst ein Bild machen.

Schönes WE

Hayo

[Jürgen (Gast)]

Moin Hayo,

Hayo W. schrieb:
> - Wir reden hier von unterschiedlichen Dingen. Die Sampleraten von 125MS
> und 62,5MS die der Treiber einstellt sind keine echten Sammpleraten
> sondern nur dezimierte Sampleraten. Die kann ich auch jederzeit
> erzeugen. Es geht hier um die echten Taktraten mit denen die ADC
> getaktet werden bzw. die dazugehörigen Registerwerte.

Dann erzeuge *125MS und 62,5MS* bitte, das wäre echt Klasse!

Gruß
Jürgen

[Blue F. (blueflash)]

Jürgen schrieb:
> Dann erzeuge *125MS und 62,5MS* bitte, das wäre echt Klasse!

Wozu? Das ergäbe eine Zeitbasis von 400ns bzw. von 800ns bei einer 
Dezimierung von 8 bzw. 16 ausgehend von 1GSa. Das wäre eher unüblich.

Wir benutzen die Dezimierungsfaktoren 4, 10, 20  für die Zeitbasen 
200ns, 500ns, 1µs was einer Samplingrate von 250MSa, 100MSa und 50MSa 
entspricht ausgehend von 1GSa true sampling rate.

Nett wäre es halt gewesen, wenn es noch bei 100MSa oder 125MSa eine true 
sampling rate gegeben hätte. Dann hätte man da die Dezimierungsfaktoren 
noch anders verteilen können.

Gruß Hayo

[Jürgen (Gast)]

Da an der true sampling rate nichts geändert werden kann, geht es doch 
nur darum bei der Darstellung die Lücke zwischen 250 MS/s und 25 MS/s 
mit zwei weiteren Darstellungen zu füllen.
Deshalb wäre die zusatzliche Darstellung mit 100 MS/s und 50MS/s genau 
so willkommen.

Gruß Jürgen

[Blue F. (blueflash)]

Ja richtig, zusätzlich würde ich gerne die total vergurkten 250MSa 
ersetzen, was aber leider nicht geht, da die 25MSa von unten nicht weit 
genug nach oben reichen und die 500MSa von oben nicht weit genug 
dezimiert werden können da sie sonst nur noch mit 400 Punkten Breite 
(statt 600) auf dem Bildschirm dargestellt kann.

Tja da kann nur noch Jörgs FPGA-Design helfen :-)

Hayo

[Blue F. (blueflash)]

Ok, hier das Ergebnis meiner Bemühungen. Folgende Einschränkungen:

- für 250MSa funktioniert das Neusortieren nicht richtig, aber durch die 
Interpolation wird die Verzerrung etwas vermindert.

- für 500MSa funktioniert der neue Assemblertreiber nur für Kanal 1 + 2. 
Auf Kanal 3 + 4 (FPGA 2) ist die Bytereihenfolge so verwurstet, dass ich 
keine Lösung gefunden habe, die vom Aufwand her zu rechtfertigen wäre.


Um sich das Ganze anzusehen schaltet man am Besten in die Zeitbasis 2µS 
(500MSa) mit einem Sinus oder Rampensignal mit ausreichender Steigung. 
Dann in den Delayed Mode wechseln und ganz aufzoomen. Mit dem 
C-Codierten  "Standard" Treiber sieht man wie das Signal verzerrt wird. 
Schaltet man im Hardwaremenü auf den Assembler-Treiber um sieht man den 
Unterschied.

Gruß Hayo

[김사백 (Gast)]

~ W2012A/OPA653
~ BF.7.6
~ 50Ω feed-through termination
Hayo: this is what I got.
It isn't the new release though.
Anyway that's the sequence that I have captured:
~ 10MHz ~
~ 50MHz ~
~ 100MHz ~
~ 150MHz ~
~ 160MHz ~
~ 185MHz ~
~ 200MHz ~
The last two pictures are the square wave I used in order to check good 
tune.
Thanks.

So long,
400

[Blue F. (blueflash)]

Looks good! Seems to work all fine!

Hayo

[CD K. (cd_k)]

~ W2012A/OPA653 and W2022A/24Ω-150Ω
~ BF.7.7
~ 50Ω feed-through termination
Hayo: DAC calibration doesn't work on factory device with the standard 
24Ω-150Ω modification.
A classmate of mine has a W2022A.
Long time ago he has modified his Welec with 24Ω and 150Ω resistors.
Now installing on it the latest version of the firmware then DAC 
calibration doesn't work.
The same revision on my W2012A/OPA653 exhibits a weird behaviour while 
performing the DAC calibration.
Indeed DAC calibration works but not better as before because it isn't 
so precise and the calibration depends on the position where the tracks 
are on the screen.
The offset changes depending on the position of the tracks on the 
screen.
So in order to get a good calibration we need to put the tracks where 
the offset is null and then perform DAC calibration.
Doing so after the calibration become super perfect all over the whole 
screen, everywhere.
Hence actually on W2012A/OPA653 it works but you need to act in a way 
different from the usual
For both W2012A/OPA653 and W2022A/24Ω-150Ω performing default setup then 
time for the trigger position is in a weird position which doesn't match 
grid nor anything.
Not real problem but it's weird.

~

Hayo: maybe a failure in my W2012A/OPA653, but I have noticed something 
of wrong.
Until roughly 350Hz the square waves are distorted, then up of there all 
is good.
Seems like the OPA653 modification isn't so good in low frequencies.
Generator was good, no fault.
We have compared its output using other oscilloscopes and the 
W2022A/24Ω-150Ω.
In very low frequencies range (hundred of mHz) even W2022A/24Ω-150Ω show 
some distortion.
Though we can't know if it is by wrong tuning because we have retuned 
the compensators losing the factory calibration performed by Welec.
I'm pretty sure that behaviour on W2022A/24Ω-150Ω is normal because we 
accurately tune-up our devices, unless actually Welec performed tune-up 
in a different way.
Everyone who have Welec in factory condition or modified are requested 
to verify and write their impressions.
Thanks.

~

Hayo: sometimes appears a ghost rotatory switch.

Thanks.

So long,
400

~~~ It's still me 김사백 but away.
~~~ Sorry

[nichtGast (Gast)]

Easyloader funktioniert bei mir nicht, mit strace sehe ich, dass er eine 
Datei ohne Namen öffnen will:

./easyloader -c /dev/ttyUSB0 TomCat.flash
> open("/dev/ttyUSB0", O_RDWR)            = 3
> open file
> open("", O_RDONLY)                      = -1 ENOENT (No such file or directory)
> flash file: Unable to open
> +++ exited with 1 +++

[Blue F. (blueflash)]

> open("/dev/ttyUSB0", O_RDWR)

Du bist an der falschen Schnittstelle zugange! Es ist TTYS0 bis 10.
Also seriell, nicht USB.

Hayo

[nichtGast (Gast)]

Hayo W. schrieb:
>> open("/dev/ttyUSB0", O_RDWR)
>
> Du bist an der falschen Schnittstelle zugange! Es ist TTYS0 bis 10.
> Also seriell, nicht USB.

ttyUSB0 ist seriell über USB.

Sorry, ich hatte das so verstanden, dass easyloader eine Alternative zu 
germsloader.pl sei.

[Blue F. (blueflash)]

nichtGast schrieb:
> Sorry, ich hatte das so verstanden, dass easyloader eine Alternative zu
> germsloader.pl sei.

Ja war auch so gedacht. Soll nur ohne Perl laufen. Geht aber auch über 
RS232, also mit dem String

`dirname $0`/easyloader -c /dev/ttyS0 -f TomCat.flash $*

sprichst Du Com Port 1 an.

Hayo

[nichtGast (Gast)]

Bei mir werden die ausgewählten Quick-Measure-Sachen nicht gespeichert. 
Im Grunde kein Problem, nur sehe ich bei jedem Druck Quick-Measure 
erstmal zwei "alte" Messdinger, die ich meist nicht brauche.

[Blue F. (blueflash)]

Ja stimmt, ich schau mal ob ich da was machen kann. In letzter Zeit war 
ich in anderer Mission unterwegs :-) aber ich könnte mich mal wieder 
dransetzen und eine neue Version auflegen.

Gruß Hayo

[Blue F. (blueflash)]

Gesagt - getan.

Die neue Version hat einige unsichtbare Änderungen unter der Haube und 
jetzt das persistente QM-Menü. Beim Neustart sollte alle so sein wie 
beim Abschalten. Nur wenn vor dem Abschalten alle QM-Slots gelöscht 
wurden (Clear Measure) werden danach Default-Werte gezogen.

Gruß Hayo

[Sandro (Gast)]

Ciao Hayo,

with last FW 7.8 there's something wrong with the memory save/recall:
I tried to save CH1 waveform one channell, but recall result is 
different and shows 2 channels.Installed back 7.6 and works properly.
Persistence now is fine.

Regards
Sandro

[Blue F. (blueflash)]

Ciao Sandro,

thanks for reporting. I changed the internal channel numbering. So there 
might be a bug. I will check it.

Hayo

[Ricardo (Gast)]

Hallo Hayo,

mir ist ein kleiner Schönheitsfehler aufgefallen (1.2.BF.7.8):
Benutze ich den Assembler ADC-Driver, so startet bei Average (flat oder 
deep) die Average-Berechnung nicht neu, wenn ich Zeitbasis oder 
Y-Verstärkung umschalte. Sieht dann einen Moment etwas komisch aus.  Das 
tritt beim Standard-Treiber nicht auf.

Ricardo

[Blue F. (blueflash)]

Hmmm, das muss ich mir mal ansehen. Danke für den Tip. Leider bin ich 
die nächsten zwei Wochen viel unterwegs und komme da nicht zu. Ist aber 
notiert.

Hayo

[Benedikt K. (benek)]

Da ich nun auch stolzer Besitzer eines Wellec W2024As (aktuell BF 7.7 
installiert, 7.8 kommt sobald ich einen gescheiten USB-RS232 Adapter 
gefunden habe) bin, wollte ich mich hier auch mal melden :).

Und wo ich schonmal dabei bin, hätte ich auch direkt mal zwei Fragen:
1) Ist das hochfrequente vom Oszi ausgehende Piepsen/Pfeifen normal oder 
bin ich der einzige dem das auffällt?
2) Bei mir ist es so, dass das Oszi nach direktem Anschalten fehlerhaft 
misst. So werden aus 5V plötzlich 0V oder auch mal -2,5 V. Ein 
Dreiecksignal, das eigentlich von 0V bis 5V geht wurde von -2,5 bis 2,5V 
angezeigt. Nach einigen Malen Offsetkalibrierung läuft das Gerät nach 
ca. 5 Minuten wieder normal. Ist das ein Softwareproblem? Jemand einen 
Lösungsvorschlag?

Danke für schon einmal im voraus,
Benedikt

[Blue F. (blueflash)]

Hi Benedikt,

Glückwunsch zu Deinem W2024A. Zum Pfeifen - das ist eigentlich nicht 
normal und stammt höchstwahrscheinlich aus dem Netzteil. Schaltnetzteile 
arbeiten mit Hochfrequenztransformatoren. Manchmal schwingt da was mit 
und verursacht dann dieses unangenehme Geräusch. Muss aber nichts 
Schlimmes sein.

Das Oszi hat eine kurze Warmlaufphase, in der auch die Nullpunkte etwas 
driften. So große Abweichungen wie bei Dir sind allerdings ungewöhnlich. 
Die Software ist da nicht die Ursache. Normalerweise sollte nach einer 
Offsetkalibrierung in warmem Zustand die nächsten Male keine 
Kalibrierung mehr nötig sein. Wenn doch, ist da irgndetwas nicht in 
Ordnung. Hast Du das Gerät neu erworben oder war es ein Gebrauchtkauf? 
In letzterem Falle ist die Frage ob der Vorbesitzer daran herumgebastelt 
hat.

Ich weiß nicht wie tief Du schon eingestiegen bist - es gibt da zwischen 
den Geräteversionen 100MHz/200MHz und auch zwischen den Hardware- 
(sprich FPGA) Versionen bestimmte Unterschiede. Manche 200MHz Geräte 
sind auch keine, sondern wurden mit den billigeren Bauteilen bestückt, 
die in den 100MHz Geräten drin sind.

Gruß Hayo

[Benedikt K. (benek)]

Danke für die schnelle Antwort!

Hayo W. schrieb:
> Manchmal schwingt da was mit
> und verursacht dann dieses unangenehme Geräusch

Interessant ist aber vielleicht, dass das Geräusch nur bei bestimmten 
Signalen oder Time-Base Einstellungen auftritt. Hat das vielleicht auch 
mit irgendwelchen Modifikationen zu tun?

Hayo W. schrieb:
> Hast Du das Gerät neu erworben oder war es ein Gebrauchtkauf

Das Gerät ist gebraucht. So wie es von innen aussieht ist auch einiges 
modifiziert, was genau kann ich aber nicht sagen. Jedenfalls ist bei 
Pre-Gain der LB-Mod eingestellt. Anbei ein Foto vom innenleben, ich 
denke du kennst dich da drin besser aus als ich ;)

[Blue F. (blueflash)]

Ok,

das wird etwas offtopic hier - lass uns mal umziehen in den 
Hardwarethread, den findest Du hier:

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

Weitere Dateien und Infos findest Du hier:

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

Hayo

[Blue F. (blueflash)]

Hello Mark,

I'm still working on our problem - and I found a solution. Resistor R13 
(390KOhm, in original 908KOhm) is dimensioned a little bit too big. 
Using 300KOhm I got much better results. The remaining discharge error 
on the signal is minimal, but I will try to find the optimal value.

On the screenshots channel 1 is equiped with 300KOhm and channel 2 with 
390KOhm. The correction factors in the firmware need to be updated also.
A new fw version and an update of the OP653 Mod manual will be available 
after that.

Hayo

[Blue F. (blueflash)]

Got the wrong thread - sorry. Should be in the hardwarethread...

[mark (Gast)]

Hello Hayo, that's fine!
I agree that the result could be further improved being sure it doesn't 
come to unintentionally create other problems before releasing the final 
version.
Maybe it isn't relevant but looking at the schematic R19 (9080ohm) is 
1/100 of the size of the original R13 (908kohm).
Is it a chance?
I know nothing about the mathematical which is behind that circuit but 
perhaps there is a link.
Anyway was your screenshot obtained with the original value for C11 
(22nF)?
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.
I understand the zerolevel side but what would happen by putting a more 
common 270kohm resistor instead of a 300kohm?
Thanks.

mark

[Blue F. (blueflash)]

Coming in late today from sports, so answer is coming in the hardware 
thread  tomorrow.

Good night

Hayo

[luigi (Gast)]

Hi Hayo,
I own a 2024 and I cycle recur in my many hobbies, now is time for 
electronic.
I still haven't do upgrades, altoght I have all components (opa 653 
also), I wanna be sure before.

Playng and checking I found a bug in BF.7.8.
IN TB 20uS frequency measure reports value is greather than real and 
also display is affected.

Congratulation for good job.
luigi

P.S.
I don't succeed to find complete schematic, could you give me a link?
Thanks

[Blue F. (blueflash)]

Ciao Luigi,

> Playng and checking I found a bug in BF.7.8.
> IN TB 20uS frequency measure reports value is greather than real and
> also display is affected.

please would you be so kind to make some screenshots and describe signal 
form, levels frequency etc. That makes it more easy for me to find the 
failure.

> I still haven't do upgrades, altoght I have all components (opa 653
> also), I wanna be sure before.

yes I can understand that. The OPA653 Mod is working stable in higher 
frequency ranges but Mark found a little problem at lower frequencies 
caused by the DC input circuit after my modifications. But this will be 
fixed in the next days.

> I don't succeed to find complete schematic, could you give me a link?

complete schematic is not available. There are only some schematics of 
single parts like input circuits, external trigger circuit and some 
digital parts.


Hayo

[luigi (Gast)]

Ciao Hayo

'please would you be so kind to make some screenshots and describe 
signal
form, levels frequency etc. That makes it more easy for me to find the
failure.

Sorry I can't do that, home logistic problems but if necessary I shall 
try after,  I tried 20uS/div 10KHz to 100 KHz Sine, Square, Pulse, with 
Rigol 1022A and against also a Tek 2445B for validate.
I hope information is adeguate for replicate measures.
have a nice day,
luigi

[luigi (Gast)]

Hi, Hayo
it's visible at a glance in the display viewing 3-4 waveforms.

luigi

[Blue F. (blueflash)]

Ok, thanks

I will try it. At the moment I'm a little bit busy with the correction 
for the OPA653 Mod.

Hayo

[luigi (Gast)]

Ciao Hayo,
here screenshots.

luigi

[mark (Gast)]

Hello Luigi.
From my own experience nothing is bad in what you have noticed.
I have also noticed the same thing with other oscilloscopes than Welec, 
I think there is any issue at all.
You must take note of the effect of overshoots that you can easily 
spotting expecially on the square waves and which is more or less 
visible depending on how the time base is set.

mark

[luigi (Gast)]

'Hi Mark,
'sorry I don't agree, it was so for old scopes not for digital TB.

Ciao Hayo,
I checked from 200S to 5nS and only 20uS is affected in high 
frequencies,
while 1S and 2S are slightly affected.

luigi

[Blue F. (blueflash)]

luigi schrieb:

> Playng and checking I found a bug in BF.7.8.
> IN TB 20uS frequency measure reports value is greather than real and
> also display is affected.

Ok, I checked it - and it is no bug. The accuracy of the measurement is 
depending on the number of samples in one signal period. Best accuracy 
you will get when only one period is displayed on the screen. The more 
periods are displayed the worse is the accuracy. So you have to choose a 
higher timebase for a better result.

Hayo

[Blue F. (blueflash)]

Ok, die neue Version ist fertig. Wichtigste Änderung sind die neuen 
DAC-Offsetfaktoren, die zum neuen R13 = 305K passen. Der alte Wert 
(390K) wird nicht mehr unterstützt. Wer erst mal nicht dazu kommt sein 
OPA653 Mod anzupassen sollte FW 7.6 verwenden. Diese Version ist noch 
ohne Save/Recall Bug. Die Mod-Doku wird noch aktualisiert.



Ok, new version is released. Main change are the new DAC-offset factors 
for matching the new R13 = 305K. The old value (390K) will not be 
supported any longer. For those Who want to use the old value longer fw 
version 7.6 is recommended because there is no Save/Recall bug.
OPA653 Mod docu will be updated soon.

Hayo

[mark (Gast)]

Hello Luigi.
No problem, that's my experience.
Anyway carefully observing 20kHz square waves into your screenshots it's 
quite clear that to make a difference in amplitude is mainly the initial 
overshoot.
I think Hayo is righy and his explanation fits perfectly.
If I can afford I would suggest at you to take a look to the document 
"Peak Detect_en.pdf" inside the "doc" folder of 1.2.BF.7.9.zip archive.
On the other hands there must be a reason because Hayo wrote the 
function in that way, I think.

mark

[mark (Gast)]

Hello Hayo, thank you for having fix the problem that was serious for me 
cause I use the oscilloscope in my daily job.
The issue was severe expecially for me.
Now I have to find the right resistor but that isn't a problem.
Thanks.

mark

[luigi (Gast)]

Hi Mark,

I agree about amplitude effects of overshhots, but what I mean is all TB 
settings, for the same signal, are very good but 20uS, and aince Hayo 
says no bug I think the question is hardware.
(also amplitude of same pulse signal decrease a lot decreasing TB 
settings, but this is another story).
I haven't still open my 2024 and don't know hardware condition, but now 
is time to do upgrades as soon as I have 2 free days.

There is around a TB sketch ?

Hayo is tyreless with the new mod and related firmware.
Thanks Hayo.

luigi

[Blue F. (blueflash)]

Ciao Luigi,

if you are opening your DSO the first time - there is a detailed 
description how to remove the knobs on the frontside in the document

W20xxA - External Trigger Mod.pdf

Hayo

[luigi (Gast)]

Ciao Hayo,

downloaded with other docs.
I hope next week to do all upgrades.

I teporarily tried trigger leds on Ch3 and Ch4 (of course disabled), is 
possible to limit flickering as Tek?

luigi

[Blue F. (blueflash)]

what do you mean with limiting?

[luigi (Gast)]

When triggered led is on it should last on till next transisition off/on 
if it happens in the next period of TB, (while trigger wait should last 
off).
I hope to have well explained what I mean.

[Martin H. (marndra)]

Hallo Alle,

habe ein W2022 un die 6.5 Firmware.
Habe noch keine Hardware Optimierungen gemacht.

Mein derzeitiges Ziel:

Ich muss meine Junsi 4010 Lader kalibrieren. Ein 2x10 Zellen Lader mit 
2000W Ladeleistung, welches ich per Werte bis auf 5mV kalibireren kann 
in der SW.

Eignet sich mein W2022 dazu?

Wie gehe ich vor?
Genau:
Lipospannung 4,2V DC schwanken je nach Pack zwi. 3,8 und 4,2V.
Ich habe mal mit 1:10 Probe und 20ms Abtastung mittels Cursur gemessen, 
ist aber ungenauer als mein Voltcraft VC250 DMM.

Wie kann ich kalibrieren, bzw. gibt es eine Art Sefkalibration in der 
SW?

[Blue F. (blueflash)]

Hallo Martin,

zunächst zwei Dinge,
- Du solltest auf die aktuelle FW 7.9 updaten
- ein DSO/Oszi ist immer ungenauer als ein DMM da die ADC weniger
   Auflösung haben

Was genau willst Du denn messen? Welche Frequenz und welche Signalform 
erwartest Du denn?

[Martin H. (marndra)]

Da ich wie gesagt "nur" auf hohe Messgenauigkeit aus bin, kann ich 
Abtastung und Waveform quasi vernachlässigen.

Es geht eigentlich nur darum eine Niedervolt Gleichspannung zu messen, 
wie ich es praktisch mit einem DMM machen würde.

Üblich haben DMM eine Messtoleranz von 0,5% (wie mein VC250).
Bei 4,2V DC ergäbe das +/-0,0882V. plus ein paar Digits (Leider bei mir 
nur 2 Stellen hinterm Komma)

D.h. bei 4,200V kann das sein 4,2084 --> Mein DMM zeigt dann 4,21

Mein W2022 hat 4,35 gemessen, wieso das?
Wie messe ich das mit möglichst hoher Auflösung, was muss ich da 
einstellen??

[Blue F. (blueflash)]

Hallo Martin,

für genaue Gleichspannungsmessung ist ein DSO völlig ungeeignet. Dieses 
ist optimiert auf schnelle Signalabtastung und nicht auf Genauigkeit was 
die Pegel angeht. Es geht da eher um die Signalform und alle möglichen 
Parameter im Zeit und Frequenzbereich. Natürlich hängt das auch noch vom 
gewählten Messbereich ab. Nimm für Deine Anwendung lieber ein 
Multimeter, damit bist Du deutlich besser bedient.

Als Beispiel: Im Messbereich 1V hast Du ca 30 Werte pro Div (ca 240 
Werte Fullscreen / 8 Div). Das sind 0,033V Genauigkeit. Dann rechne noch 
Bauteiltoleranzen und einen gewissen Abstimmfehler hinzu, dann bist Du 
bei höchstens 0,05V bis 0,1V Genauigkeit wenn es gut läuft.

Das kann jedes DMM vom Discounter besser - aber dafür kann  es keine 
Signalformen anzeigen.

[Blue F. (blueflash)]

Ach ja, den zusätzlichen Messfehler Deines 1:10 Tastkopfes habe ich 
dabei noch nicht einmal berücksichtigt...

[Martin H. (marndra)]

Ok Super Hayo, genau diese Info hab ich benötigt, DANKE !!

Muss ich mir doch ein Solartron 7150plus besorgen und etwas "modden" :-)

[Blue F. (blueflash)]

Ich habe zwar auch ein sehr genaues Tischmultimeter, aber eigentlich ist 
mein Handmultimeter von Voltkraft (Metex) mit vier Anzeigestellen schon 
genauer als ich es bisher gebraucht habe. Sowas sollte bei Dir 
eigentlich auch locker hinhauen. Die haben dann intern minimum 14 Bit 
Auflösung, was schon alles erschlägt was nicht hochpräzisen 
wissenschaftlichen Laboransprüchen genügen muss.

Mehr als 30 - 40 Euro muss man dafür wirklich nicht ausgeben.

[Martin H. (marndra)]

Sorry Hayo,

da muss ich jetzt mal Dir widersprechen.

Für 40-50 Euro bekommt man keine sehr genauen DMMs das mehr als 0,5% 
gesamt Tol. hat.
Selbst die besten Handgeräte sind da meist nicht besser als 0,1 bis 
0,05%.

Das fast über 40 Jahre alte und ev. neu kalibrierte Solartron 7150plus 
hat üblicherweise unkalibriert 0,05%. Kalibriert kann es bestimmt 0,002% 
!
Bei 6 1/2 Display.

Wer kennt ein DMM für unter 100Euro das extrem genau ist wie das 
Solartron.

....upss, tut mir Leid, ist sehr Offtopic ;-|

[Martin H. (marndra)]

Ach soo nochmal zum Thema,

das Welec DSO kann leider tatsächlich keine Toleranzenn von denen ich 
sie brauche Messen. Selbst wenn ich auf 0,5V Auflösung oder noch mehr 
gehe und dann mit viiieeel Offset arbeite. (Abtastung ist meist 50ms)

Meine Lipos dürfen beim Laden und Balancen nicht mehr als 2mv Delta 
haben.
Um das hinzubekommen, MUSS der Lader sehr genau kalibriert sein.

Also z.B. 6 Zellen in Reihe geschaltet:
1. 4,189 V
2. 4,191 V
3. 4,201 V
4. 4,188 V
5. 4,199 V
6. 4,202 V

Delta wäre hier 13mV, was für Lipos auf Dauer grenzwertig wäre, da ich 
beim Entladen bis 250A raushole (in Peaks).

[Blue F. (blueflash)]

Martin Haßlöcher schrieb:
> Für 40-50 Euro bekommt man keine sehr genauen DMMs das mehr als 0,5%
> gesamt Tol. hat.

Ja korrekt. Das sind bei Deinen Spannungen ca. 25mV. Genauer brauchte 
ich das bisher jedenfalls noch nie. Bei Dir scheint es ja extrem zu 
sein. Das sind dann tatsächlich schon Laboranforderungen - sowas wird 
nicht billig. Und nicht vergessen, wenn man mit diesen Ansprüchen messen 
will nützt einem ein gutes Gerät wenig, wenn es nicht regelmäßig 
kalibriert wird.

[Thomas (kosmos)]

du könntest aber auch ein paar Spannungsreferenzen hernehmen um 
festzustellen wie genau dein DMM über einen kleinen Bereich ist. In 
einer Tabelle kannst du dir das dann interpolieren lassen.

Angenommen DMM Messbereich auf 20V und du möchtest etwas um die 4V 
messen. Dann nimmst du einen Spannungsreferens von 3V und 5V und 
schreibst dir die Werte auf setzt sie in deine Tabelle ein misst dann 
z.B. 4,18V und siehst in der Tabelle nach wo du dann liegst.

[Blue F. (blueflash)]

Hast Du eine so genaue Spannungsreferenz? Ich nicht. Sonst könnte ich 
mein Tischmulti auch selbst kalibrieren.

[Martin H. (marndra)]

Ja, das ist klar, sobald ich eine Spannungsreferenz oder Messreferenz 
habe, kann ich das alles "relativ" hinbekommen.
Sogar durch interpolation seeeehr genau.
Leider kosten solche "Referenzen" auch nicht wenige Euro.
Ich habe einen Lipo Checker genommen, der brutal genau war, aber leider 
nur 3 Digits hat   )-:  Da musste ich selbst schätzen, er rundet dann 
mal bei 0,004 und dann wieder auf 0,005 auf. Das ist genau die Messtol. 
die ich überwinden muss.

[Martin H. (marndra)]

Ach übrigens, wenn ich bald ein DMM mit 0,002% habe (kalibriert für ein 
Hunni),
wie kann ich dann mein Welec 2022 kalibrieren, (nachdem ich auf 7.9 
"geupdated" und den 390KOhm eingelötet habe) ?

Geht das per SW Setup?

[Blue F. (blueflash)]

Ja, zur genaueren Kalibrierung gibt es im Hardwaremenü eine "Gain" 
Einstellung. Die steht normalerweise auf 1,000 da kannst Du dran drehen 
bis es passt. Das gilt dann aber für alle 3 Bereiche (5er, 2er, 1er). 
Also am besten den "Lieblingsbereich" kalibrieren, und dann prüfen ob 
die anderen noch akzeptabel sind. Evtl. für spezielle Messaufgaben den 
benötigten Bereich nachkalibrieren. Damit kann man dann für 
Oszi-Verhältnisse schon recht genau messen.

Der empfehlenswerteste Bereich ist der 5er Bereich, da hier am wenigsten 
Rauschen auf dem Signal ist welches ja auch zur Ungenauigkeit beiträgt.

Übrigens wird in der Bucht gerade ein Schlumberger für 175,- Ocken 
angeboten

[Blue F. (blueflash)]

Ach ja, noch ein Tip wenn es auf genaue Pegelmessungen ankommt. Wenn man 
mit Quick Measure (also automatisch) misst, dann wird der Rauschpegel 
mitgemessen. Das sorgt natürlich für eine zusätzliche Ungeauigkeit in 
höhe des Rauschpegels.

Wenn man es genau braucht ist die manuelle Cursormessung besser, da man 
hier den Cursor ungeachtet des Rauschens direkt auf das Signal legen 
kann.

[Martin H. (marndra)]

Hi Hayo,

ja genau auf das Schlumberger in der eBucht ziele ich.
Ist auch eins dabei das derzeit günstiger steht vom Preis. Alle aus UK.
Plus eben Zoll, Kalibrierung etc. komme ich trotzdem auf über 200 Euro.
Dafür bekomme ich schon ein Voltcraft VC950 nach ISO zertifiziert und 
mit 0,05% auch schon recht gut.

Achso, danke für den Kalibrier Tipp.
Hatte ja schon geschrieben, dass ich mittels Cursor Messung gemessen 
habe, bzw. mit RMS Einstellung. Aber wie gesagt, bei 0,5V Teiler hatte 
ich anstatt 4,200V schon 4,35V gemessen, da hab ich das ganze 
abgebrochen und bin auf den LipoChecker gegangen.

Schlussendlich werde ich mir eine CellPro 8 kaufen, der misst extrem 
genau und ist schon kalibriert (auf 0,005V bei den Lipo typischen 4,2V) 
Für unter 20 Euro zu bekommen. Damit wäre schon so ganz grob mein Ziel 
erreicht.

[mark (Gast)]

Hello  Martin,you have to pay attention at the fact that generally DVM 
have 10-11Mohm like input impedance while oscilloscope is 1Mohm.
Welec also is 1Mohm input impedance and this makes a difference.
DVM is better than oscilloscope basically due its great input impedence.
Going over surely you can tune your W2022 availing of a leveled voltage 
generator by adjusting the gain in the hardware menu.
I did do it so and it works.
Anyway the instrument still is a 1Mohm input impedance.

mark

[Charly B. (charly)]

Martin Haßlöcher schrieb:
> Ach übrigens, wenn ich bald ein DMM mit 0,002% habe (kalibriert für ein
> Hunni),

welches DMM ist das denn und wer kalibriert das denn auf die 
genaugikeit?

mein UT804 zeigt bei 0.4V   0.3997V das sind ~0,075% abweichung
bei 4V siehts genauso aus


vlG
Charly

[Martin H. (marndra)]

Hi Charly,

das hatten wir doch mehrfach erwähnt, es ist das Schlumberger Solartron 
7150plus.
Ein Gerä aus den 80er, rein entwickelt für's Millitär. Es sind in den 
2000ern einige Geräte in den Handel gekommen, die immer wieder in Ebay 
auftauchen.
Kalibrieren kann man das Gerät in der SW direkt.

Und ja man kann das Gerät fast wieder auf Werksgenauigkeit kalibrieren, 
mit entsprechendem Werkzeug.

Jeder gute Kalibrier Service macht das für 80-150 Euro, je nachdem.
Das sind dann Normen die über Iso oder DAkkS gehen.
Nur die PPms/C° sind eben nicht ganz so gut, da die Kondis etc. halt 
meist über 40 Jahre alt sind. Referenz ist eine hochselektierte / Diode 
mit ca. 6,2V, was ja egal ist, da das im ACD gewandelt wird und 
kalibriert. PPm/C° ist ca. 5 der Diode!

[mark (Gast)]

luigi schrieb:
> When triggered led is on it should last on till next transisition
> off/on
> if it happens in the next period of TB, (while trigger wait should last
> off).
> I hope to have well explained what I mean.

Hello Luigi.
Sorry I didn't understand what do you mean but have a look at this 
document here:
http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/W20xxA%20-%20LED%20Mod.pdf/download
Maybe actually Welec works in opposite way to other oscilloscopes.

mark

[luigi (Gast)]

Hi Mark,

I have read this doc but what I mean is when the signal is triggered and 
led is on it stay on for a short time so before time expires (time out) 
and a new signal is detected it it's still on and continous on/off is 
avoided.

luigi

[Blue F. (blueflash)]

I think I understood. So in case of stable trigger, the red LED (trigger 
indicator) is always on, correct? What about the green led (trigger 
armed)?

Hayo

[luigi (Gast)]

Correct.

The same, till Red Led is on the Green couldn't go on, (I think a aimple 
xor instruction)
I prefer yellow for armed trigger and green for triggered.

luigi

P.S.

I think next info could be useful forn many people.

In the various flashing I had Model, HW and serial resetted, I could 
restore them reflashing original firmware with your WalecUpdate not with 
WalecUpdater.

[Blue F. (blueflash)]

Ok, I will try add a Tek-option for the LED

Hayo

[luigi (Gast)]

Ehi Hayo,
whath do you think about Display Persistence values lower than 5 sec.?

luigi

[Blue F. (blueflash)]

Ok, I added 1s and 2.5s - Is that ok?

Hayo

[luigi (Gast)]

Wonderful,
this does a better display of some modulated waveform.

You surely noticed aliasing and colliding display problems (sampling 
rate and memory depth) in sweeped wf.
Do you think can just do something ?
Yes I know it's hard but sw often can do miracles.

Off topic:
Playing with R19 (reducing) and C11 (increasing) a bit can we improve HF 
BW linearity ?

luigi

P.S.
When you thing I go too far tell me and I shall stop.

[Blue F. (blueflash)]

luigi schrieb:
> When you thing I go too far tell me and I shall stop.

No problem - thinking and discussing about improvements are always 
welcome. I try my best to make it possible. Unfortunately there are some 
limits due to bad hardware/FPGA design which can't be solved without 
changing the FPGA-core. Jörg made some good attempts which showed us 
what could be possible with a NIOS 2 core. At the moment the development 
sticks a little bit but we hope that Jörg will go one.

Hayo

[Blue F. (blueflash)]

luigi schrieb:
> Off topic:
> Playing with R19 (reducing) and C11 (increasing) a bit can we improve HF
> BW linearity ?

No, that is the wrong step. The OP1177 and the back coupling with 
C11/R19 is only responsible for the DC part of the signal. To change HF 
linearity we have to play with the back coupling of the OPA656 (R22/C12) 
as I have done in the LB-Mod. Changing the values can raise or bring 
down the higher frequency range of the characteristic. In original 
design the upper range of the amplitude characteristic (80 - 180MHz)is 
much to high - this results in a greater 3dB bandwidth but with 
completey distorted signals. So it is better to have less bandwidth but 
more linearity. And that is what I made in the LB-mod.

Hayo

[luigi (Gast)]

Understood, thanks.

luigi

[Blue F. (blueflash)]

Ok Folks,

the new firmware version for all WELEC "A" models with or without 
modifications.


Die neue Firmwareversion für alle WELEC "A" Modelle mit oder ohne 
Modifikationen.

Gruß Hayo

edit: please use the second compilation. I added the new LED option for 
Peak Detect also

[Paolo (Gast)]

Thanks a lot again, Hayo.

[Martin H. (marndra)]

Hi,

Danke Hayo. DSO wird mit jedem kleinen Fix besser, perfekt so!

Übrigens hab ich mir so ein China DMM geholt. Damit wird dann auch mal 
das Welec kalibriert.
Das DMM hat bei DC 0,003% Genauigkeit :-)

[mark (Gast)]

Hello Hayo.
OK, thanks for the upgrade.
So 1.2.BF.7.10C2 is better cause it has the new LED option for Peak 
Detect that 1.2.BF.7.10 hasn't yet, correct?

Martin Haßlöcher schrieb:
> Übrigens hab ich mir so ein China DMM geholt. Damit wird dann auch mal
> das Welec kalibriert.
> Das DMM hat bei DC 0,003% Genauigkeit :-)

Hello Martin.
Am I pushy asking exactly which DMM model it is?
Thanks

mark

[Blue F. (blueflash)]

@mark

That's correct, I was a little bit in hurry because of preparing 
holidays beginning next week and so I forgot it in the first 
compilation.


@Martin
Welches Modell und bitte einen kurzen Erfahrungsbericht ob das Gerät 
empfehlenswert ist.

[luigi (Gast)]

Thanks,

luigi

[Martin H. (marndra)]

Hi All,

It's from Digitek the model  DT 80000.
Precision in DC is genius.
I calibrated my Charger with 3mv tolarance, the values are fully 
reproducible.
Next step is the firmware update to the welec and then the calibration.
The AC tolerance is not the best at all, but DC is more my usage.

Quality is not the best, but also not bad. Background light is blue, 
nice :-)
The best is the Frequenz Generator, precise and great to check the welec 
!

Further will follow.

[Jürgen (Gast)]

Hi All,

unlängst brauchte ich mal wieder den Pulsewidth Trigger. Der 
funktonierte leider nicht in der aktuellen BF7.10C2.
Ursache war eine im Edge Trigger eingestellte Holdoff Zeit.
Irgendwann hatte ich mal herausgefunden, daß für den Pulsewidth Trigger 
Holdoff = 0 sein muss.
Also habe ich das mal am Ende der Funktion Hardware::CaptureTrigSetPulse 
als CaptureTrigSetHoldoff(0) nachgetragen:
Pulsewidth Trigger funktioniert wieder!
Zum Ausprobieren im Anhang die zwei geänderten Files.

Vielleicht kann das Hayo nun mal endgültig für das alte FPGA-Design 
übernehmen?!

Gruß
Jürgen

[Blue F. (blueflash)]

Hi Jürgen,

ja klar, ich baue das ein. Manche Sachen brauchen halt länger bis sie 
den Weg in die Firmware finden ;-)

Hatte ich wohl irgendwann mal aus den Augen verloren. Da bei mir Holdoff 
immer auf Null steht ist mir das nie aufgefallen (Anderen wohl auch 
nicht...).

Gruß Hayo

[mark (Gast)]

Hello Jürgen.

Jürgen schrieb:
TomCat_flash.ucl     TomCat_ram.uc

Are those intended like a recognized legit fix?
Thanks

mark

[Jürgen (Gast)]

mark schrieb:
> Hello Jürgen.
>
> Jürgen schrieb:
> TomCat_flash.ucl     TomCat_ram.uc
>
> Are those intended like a recognized legit fix?
> Thanks
>
> mark

Hello Mark,

this is a fix for me and this fix is running for me.  If you are not 
happy with it, please use the the standard version from Hayo. You can 
flash it forward or flash back the standard version. No problem.

Regards,
Jürgen

[Jürgen (Gast)]

PS:

Hi Mark,

Hayo will use this fix in his next version:

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

Jürgen

[Blue F. (blueflash)]

Hi there folks,

a was a little bit busy the last time. So I had no chance to build a new 
version. But don't worry, I will bring it out soon. If anyone needs to 
use the pulsewidth trigger I would recommend to use Jürgens fix. 
Otherwise there is no need to do anything. I will be back...

Hayo

[Blue F. (blueflash)]

Ach ja - @Jürgen - ich weiß auch warum Deine Änderung wieder fehlt. Die 
ist bei der Umstellung auf das OSOZ API verlorengegangen. Da musste ich 
so viele kleine Einstellungen übernehmen bzw. anpassen, dass dieser 
Punkt wohl einfach untergegangen ist.

Hayo

[mark (Gast)]

Hello Jürgen.
Maybe I explained bad, sorry.
I'm happy with your fix and I'm grateful to you for it.
The only thing I wanted to know is if that is 1.2.BF.7.10C2 fixed by you 
or instead a different one.
Please take in mind I'm not saying different firmware like for instance 
one completely wrote by you or anybody else isn't good as the Hayo 
release.
What I want to say is that because I use my Welec for job I need stable 
and tested firmware in order to avoid errors.
My fear is that your firmware have differents hidden features which can 
create problems in my application field.
Hoping to be clear now.
I repeat it, for me your firmware is good for what is related the 
Pulsewidth Trigger.
Rarely I use Holdoff and Pulsewidth Trigger and therefore very likely I 
would not have noticed the problem, so thank you for having fix it!

mark

[Jürgen (Gast)]

mark schrieb:
> Hello Jürgen.
> Maybe I explained bad, sorry.
> I'm happy with your fix and I'm grateful to you for it.
> The only thing I wanted to know is if that is 1.2.BF.7.10C2 fixed by you
> or instead a different one.

Hello Mark,
no, it's only one additional line of source code in Hayo's 1.2.BF7.10C2 
firmware.

Jürgen

[Blue F. (blueflash)]

So, hatte jetzt mal so zwischen Firma, Raspberry Pi Projekt und diversen 
anderen häuslichen Verpfichtungen mal Zeit die Korrektur von Jürgen 
einzubauen. Damit sollte das ein für alle Mal erledigt sein :-)

Hi folks, this is the correction for the pulse width trigger. Also 
available on SFN

[Stefano (Gast)]

OK, well done.
But what about adding a kind of alert while persistence is on?
I understand that's a silly question but after I lately upgraded I have 
had trouble just because 1s/2.5s persistence was activated and it took a 
little time and some reset before I understood that the problem was 
there.
Likely I have activated and forgot it, surely it's my bad, but perhaps 
I'm not alone.

[Blue F. (blueflash)]

Hi Stefano,

sorry for the late answer, I was a little bit busy last time. Yes maybe 
I can add a message in the (optional) On Screen Message System. The 
status bar is a little bit crowded with other things. Any own ideas how 
to solve this?

Hayo

[Stefano (Gast)]

Hi Hayo, no problem.
If status bar is too crowded On Screen Message System would be the 
better choice but I can tell how.
That I don't know, I guess exists many way.
I'm sure you are in the zone most than me and I trust you.
Maybe putting some indication in the channel labels just like for AC/DC 
indication would does the job.
It does not need something complex then any way will be fine.
Another thing related to the issue I met.
Is it possible that using Tek option for trigger LEDs introduce delays 
on trigger's acquisitions?

[Michael D. (mike0815)]

Nach langer Pause und nach dem Low Budged Umbau, der mein Welec ausser 
Bertieb setzte, durch eigens verschuldete Lötkünste... jetzt mit 
gefixten W2022 (es rennt wieder), habe ich mal die aktuelle FW7.11 
geflasht.

Im "Edge"-Menu auf "Trace Middle" habe ich einen Spike auf beiden 
Kanälen, bis ins unendliche, bei 50 u. 100ns.
Das Verhalten geht zurück bis zur FW6.4 ! An der Low Budged Option kann 
es nicht liegen, da die FW6.4 diese noch nicht hat. Ich bin mal zurück, 
bis zur FW6.0, da tritt der Fehler nicht auf.

Anbei 3 Screenshots

Gruß Michael

[Blue F. (blueflash)]

Hi Michael,

bin gerade zurück vom Portugiesen (nicht Griechen!). Ich werde mir das 
mal morgen ansehen wenn die berufliche Lage das zulässt. Hört sich ja 
merkwürdig an.

Mal schaun...

Hayo

[Blue F. (blueflash)]

Hi Michael,

die Lösung liegt so nahe! Schau mal in Dein Hardwaremenü, ich wette Dein 
ADC-Setup steht auf High Frequency 2. Diese Einstellung ist nur für 
besondere Messungen gedacht, wenn es mit dem Factory oder HF 1 Setup 
nicht so gut klappt. Also eher experimentell. Für alles Andere lieber 
das Factory-Setup benutzen.


Also alles wird bzw. ist gut!

Gruß Hayo

p.s. aber schön rauschfrei das Signal, oder?

[Michael D. (mike0815)]

Nein, stand auf "Factory"! Und wie gesagt, tritt nur bei "Trace Middle" 
auf.
Aber gut, das du es erwähnst.
Ich habe mal von "Factory" auf HF 1 geschaltet, plötzlich waren die 
Spikes weg!? Weiter auf HF 2, sind sie wieder da.
Also muss ich auf HF 1 stehen lassen, da ist dann alles hübsch! Wie 
kommt das denn? Bzw. was ist bei HF 1 anders?  Hat es jetzt auch was mit 
meinem LB Umbau zutun?

Und ja, das Rauschen ist so minimalistisch, das sogar die 1V, 2V Div's 
brauchbar geworden sind. Normaler Weise fehlt ja noch der Tausch von 
Bauteilen u. Abgleich unter den Schirmblechen. Trotzdem stimmt der 
Gainfaktor, also die Spannungsangabe bei DC-Messungen ist realistisch.

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:
> Also muss ich auf HF 1 stehen lassen, da ist dann alles hübsch! Wie
> kommt das denn?

Also bei dieser Einstellung wird ein bestimmter Wert in eines dieser 
ominösen nicht dokumentierten Register des FPGA geschrieben. In der 
Einstellung "Factory" wird der von WELEC vorgegebene (bzw. mit dem Gerät 
ausgelieferte) und im Protected Flash abgelegte Wert verwendet. In den 
anderen Einstellungen werden experimentell ermittelte Werte (die sind 
hart codiert in der Firmware hinterlegt) hinengeschrieben. Wie wir ja 
festgestellt haben, wirkt sich das je nach Hardware- (bzw. FPGA) Version 
unterschiedlich aus und es sind auch unterschiedliche Factory-Werte 
hinterlegt.

Welche Werte da aktuell verwendet werden, kannst Du über ein Terminal 
mit der Kommataste herausfinden. Das Register heißt adc_change12_reg und 
wir haben im Hardwarethread/Firmewarethread damals recht ausgiebig damit 
herumexperimentiert.

Gruß Hayo

[Jürgen (Gast)]

Hallo Hayo,

leider mal wieder eine sehr schlechte Nachricht :-(
Die Version BF7.10C2 triggert nicht in der einfachsten Triggerart EDGE 
im NORMAL Mode!
Bei 500kSa/s läuft das noch, bei 250kSa/s und darunter erfolgt keine 
Triggerung mehr.
Test war die Darstellung einer seriellen Ausgabe ca. im Sekundenabstand 
auf 3,3V Niveau.
Der Fehler muss in der BF7.10 hereingekommen sein, da in der BF7.9 noch 
sauber bis hinunter zur USTB getriggert wird.
Ja, ich weiß, das Warten beim Testen ist hier schon langweilig! :-)

Bitte, wenn Du mal Zeit hast....

Viele Grüße
Jürgen

[Blue F. (blueflash)]

Uuups! Das muss ich mir mal ansehen. Ist das sonst noch keinem 
aufgefallen?

Ich schau mal...

Gruß Hayo

p.s. ok, ich kann das bestätigen. Die Triggerung reißt unterhalb von 
250KS ab. Da muss ich wohl mal abgleichen was ich da geändert habe und 
auf Fehlersuche gehen. Danke für den Hinweis.

[Stefano (Gast)]

Jürgen schrieb:
> Hallo Hayo,
>
> leider mal wieder eine sehr schlechte Nachricht :-(
> Die Version BF7.10C2 triggert nicht in der einfachsten Triggerart EDGE
> im NORMAL Mode!
> Bei 500kSa/s läuft das noch, bei 250kSa/s und darunter erfolgt keine
> Triggerung mehr.
> Test war die Darstellung einer seriellen Ausgabe ca. im Sekundenabstand
> auf 3,3V Niveau.
> Der Fehler muss in der BF7.10 hereingekommen sein, da in der BF7.9 noch
> sauber bis hinunter zur USTB getriggert wird.
> Ja, ich weiß, das Warten beim Testen ist hier schon langweilig! :-)

Actually that's the problem I was talking about.
In reality it's trigger lack, don't a persistence problem.

[Blue F. (blueflash)]

Hi, I'm sorry but I'm a little bit busy last time - new project at work. 
But I'll keep it in mind. The correction will come...

Hayo

[Stefano (Gast)]

No problem for that.
It's me who want underline how my previous statement was wrong.

[Jürgen (Gast)]

Werte Welec-Oszi Freunde,

ich hatte etwas Zeit und habe versucht die mich am meisten störenden 
Fehlfunktionen in der Firmware

zu finden und zu beheben.
Folgende Dinge sind mir bei der Review der aktuellen Firmware BF7.11 und 
in der Funktion unseres

Scopes aufgefallen:

1. wie schon gemeldet, kein Edge-Triggern unterhalb 500kSa/s im Normal 
Mode

2. FFT aktualisiert nicht im Normal - Mode

3. PW-Triggerung funktioniert immer noch nicht zuverlässig, da teilweise 
falsche Anzeige der

eingestellten Werte

4. PreTrigger entspricht nicht der üblichen Funktion

5. ein Workaround für den Normal - Mode ist normalerweise ein K.O. 
Kriterium :-(

6. tolles Geflimmer einiger Trigger-LED's trägt nicht unbedingt zur 
Übersichtlichkeit in der Firmware

bei :-)

Mittlerweile ist der Test nach Änderungen in der Firmware die 
zeitraubendste Tätigkeit.

Jetzt etwas "Fachchinesich":

Überarbeitet habe ich zunächst die Ablaufsteuerung des Oszis etwas. Aus 
der Erinnerung funktionierten

doch einige Funktionen in vorhergehenden Versionen zuverlässig. Deshalb 
als These eine

althergebrachte Ablaufsteuerung: Sampling KOMPLETT einstellen - Starten 
- Ergebnis abwarten -

Sampling Stoppen - Ergebnisse anzeigen - und von vorn :-)
Allerdings muss ich einschränkend sagen, das es mir in den letzen drei 
Tagen wegen der inzwischen

doch recht hohen Komplexität der Firmware nicht gelungen ist, alle 
Zweige zu testen und zu

durchschauen. Ich habe mich nur auf die Grundfunktion beschränkt.

zu 1. mit der Umstellung der Ablaufsteuerung funktioniert das jetzt

zu 2. dieser Fehler resultiert irgendwie aus der (notwendigen?) 
Verstellung des Nullpunktes für

XY-Betrieb. Dies ist für FFT nicht notwendig(?). Dort habe ich die 
Nullpunktverstellung FFT erstmal

stillgelegt. Ist noch nicht perfekt. Das könnte sich unser Experte 
nochmal ansehen :-)

zu 3. Die PW-Triggerung hat tatsächlich nur 16 bit breite Register mit 
einer Auflösung von 8 ns :-(
Dadurch ist der im Handbuch vorgegebene Einstellbereich der Parameter 
bis 100 ms vollkommen

illusorisch. Habe versucht die als "ungenutzt" bezeichneten Bits im 
trigger_width zu nutzen - leider

kein Erfolg :-(
Daraufhin habe ich die zwei Tastenfunktionen F4 und F5 und die Funktion 
des Drehknopfes komplett

überarbeitet und die Begrenzung der Einstellbarkeit der Zeiten auf 524 
us eingearbeitet. Damit stimmt

wenigsten die Anzeige mit der Einstellung im Hardwareregister überein 
(vorher Zahlenbereichsüberlauf

und auch bei * ms teilweise Funktion, falls der Rest im Register gerade 
gepasst hat).
Da die "SM" Smaller Funktion nicht so sicher funktionierte und als 
Workaround mit "Range" ersetzt

wurde, habe ich hier für den kleineren Teil einfach 1/32-tel des grossen 
Parameters gesetzt. Dies

erscheint mir klein genug, da man ja auch den grossen Parameter recht 
klein einstellen kann.

Jedenfalls funktioniert das besser als 16ns ... für den kleinen 
Parameter.

zu 4. der Pretrigger nutzt nur maximal die Breite des Bildschirmes in 
der aktuellen Samplerate aus.

Da geht normalerweise besser, falls man ein komplizierteres Signal hat, 
bei dem das Triggerereignis

erst nach weiteren Samples erfolgt. Maximal sollte hier die Länge des 
Samplepuffers einstellbar sein.

-> Habe hier Keine Änderung in der Firmware gemacht.

zu 5. Workaround in Handle_ADC komplett entfernt

zu 6. unverändert :-)

Anbei die geänderte Firmware als *.flash und *.ucl zum ausprobieren und 
testen.
Bitte wirklich testen und Rückmeldung geben, auch wenn ich selber weiss: 
Ein Oszi braucht man

unbedingt. Aber wenn es denn da ist, braucht man es doch relativ selten 
:-)

Einzelheiten werde ich besser gern mit Hayo per PN diskutieren, falls 
und wenn er wieder Zeit und

Lust dazu hat. Schliesslich entsteht das alles in unserer Freizeit!

Also viel Spass beim Testen.

Viele Grüße
Jürgen

[Jürgen K. (oj_k)]

Hallo zusammen,

mir ist gestern noch eine Kleinigkeit aufgefallen: Die Anzeige der 
Triggerschwelle bei externer Triggerung skalierte nicht mit dem 
eingestellten Probefaktor. Das ist jetzt korrigiert.
Die Dateien ersetzen direkt die gestern von mir hochgeladenen Dateien.

Gruß
Jürgen

[Ricardo (Gast)]

Hallo,

mir ist gerade aufgefallen, dass die Trigger Betriebsart "Free Run" mit 
der neuen my7.11-Firmware nicht mehr funktioniert, die Kurve steht. Habe 
es gleich mit der älteren 1.2.BF.7.11 (von Hayo) gegengeprüft, da läuft 
es noch.

Gruß Ricardo

[Jürgen K. (oj_k)]

Hallo Ricardo,

ja das ist wohl so. Habe da nicht so darauf geachtet.
Ich kann mir auch beim besten Willen nicht vorstellen, wozu diese 
Betriebsart im Gegensatz zur Betriebsart Auto gut sein soll!?
Da könnte man nochmal das Menü aufräumen und diesen Betriebsmodus 
entsorgen. Soweit bin ich aber noch nicht vorgedrungen :-(

Gruß
Jürgen

[Blue F. (blueflash)]

Ok, hier wie versprochen die neue Version mit den Korrekturen der von 
Jürgen gemeldeten Bugs.

-----------------------------------------------------------------

Ok folks, here the new version with latest bugfixes -> thanks to Jürgen 
for reporting


Hayo

[Jürgen K. (oj_k)]

Hi Hayo,

Hayo W. schrieb:
> Ok, hier wie versprochen die neue Version mit den Korrekturen der von
> Jürgen gemeldeten Bugs.

da bin ich ja gespannt, wie Du das gemacht hast ohne meine Source 
gesehen zu haben :-)

Ich werde noch einmal vergleichen...

Gruß
Jürgen

[nichtGast (Gast)]

Hallo Jürgen,

cool das du auch etwas beisteuerst!
Magst du deine Quelle bzw. Patches veröffentlichen?

Viele Grüße

[Blue F. (blueflash)]

Jürgen K. schrieb:
> da bin ich ja gespannt, wie Du das gemacht hast ohne meine Source
> gesehen zu haben :-)

Naja, die Source ist ja mittlerweile mein zweites Zuhause. Da kennt man 
ja schon fast die Zeilennummer aus dem Kopf wenn man mal was reparieren 
muss ;-)

Da ich etwas kanpp an Zeit war konnte ich nur die beiden wesentlichsten 
Punkte auf die Schnelle korrigieren.

Zu Punkt 4. z.B. habe ich nicht ganz verstanden wie Du das gemeint hast. 
Denn eigentlich nutzt der Pretrigger schon den gesamten Bufferbereich.

Gruß Hayo

[egberto (Gast)]

Vielen Dank für die neue Version!

Ich habe auch noch nicht wirklich getestet - aaaber das Testsignal auf 
Kanal 3 (blau) hat jetzt eine wesentlich geringere Frquenz als die 
anderen....soll das so? Auch werden die im Autoscale nicht mehr so schön 
scaliert.

Könnt ihr das reproduzieren?

Grüße,

Egberto

[Blue F. (blueflash)]

Also am Testsignal und auch an der Skalierung habe ich nichts geändert. 
Eigentlich sollte das alles so sein wie vorher. Dass das blaue 
Testsignal eine geringere Frequenz hat war doch auch schon vorher - oder 
irre ich mich da?

Die Skalierung des Testsignals mit Autoscale ist übrigens nicht ganz 
repräsentativ, da es sich nicht exakt wie ein natürliches Signal 
verhält. Hier also nicht zu viel hineininterpretieren. Autoscale am 
Besten immer mit einem echten Signal testen.

[Jürgen K. (oj_k)]

Hallo nichtGast,

nichtGast schrieb:
> Hallo Jürgen,
>
> cool das du auch etwas beisteuerst!
> Magst du deine Quelle bzw. Patches veröffentlichen?
>
> Viele Grüße

natürlich mache ich das wie bisher auch schon

VG

[Jürgen K. (oj_k)]

Hallo Hayo,

leider ist in der neuen Woche wieder viel zu wenig Zeit für's Hobby und 
zum ernsthaften Testen ist offenbar auch nur wenig Zeit oder Lust in der 
Community vorhanden :-(

Anbei die kompletten Quellen meiner Fixes der Version BF7.11. Ich würde 
Dich bitten alle Dateien mit Datum 5.9.2015 komplett zu übernehmen, 
damit nicht wieder etwas verloren geht und nicht mehr 
funktioniert.(Teilweise hab ich auch nur für mein Verständnis Kommentare 
eingefügt. Deshalb die größere Anzahl Dateien.) Erläuterung folgend:

Ich habe ebenfalls die BF7.12 nochmal den gleichen Tests unterzogen, die 
ich für die Fixes my7.11+ durchgeführt hatte.

Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung, 
weder im Edge-Trigger noch im PW-Trigger. Die Scalierung des externen 
Triggerlevels ist ebenfalls unvollständig. Die Einschränkung in der 
Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls 
noch und läßt hier eine Fehlerquelle in der Bedienung zu.
Mit der geänderten Signalerfassung in der 7.11+ erfolgt stabil eine 
Triggerung unter allen Umständen.
Es wäre eben schön gewesen, wenn dies von Anderen ebenfalls getestet und 
bestätigt würde!

Hayo W. schrieb:
> Zu Punkt 4. z.B. habe ich nicht ganz verstanden wie Du das gemeint hast.
> Denn eigentlich nutzt der Pretrigger schon den gesamten Bufferbereich.

Das muss ich mir nochmal ansehen, was ich mir dazu überlegt hatte. Ist 
aber im Moment keine Zeit dazu.
Wie schon geschrieben, habe ich mich extra hier angemeldet. Einzelheiten 
der Software habe ich aber nicht vor hier zu diskutieren. Das können wir 
jetzt auch anders tun :-)

Viele Grüße
Jürgen

[Blue F. (blueflash)]

Jürgen K. schrieb:
> Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung,
> weder im Edge-Trigger noch im PW-Trigger.

Hast Du hier ein Beispielsignal an dem ich mir das mal ansehen kann? 
Signalform, Frequenz, Amplitude. Dann kann ich das direkt vergleichen 
mit Deiner Version.

> Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig.
Was fehlt noch? Habe ich was übersehen?

> Die Einschränkung in der
> Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls
> noch und läßt hier eine Fehlerquelle in der Bedienung zu.

Da bin ich auf die Schnelle nicht mehr zu gekommen, muss ich dann noch 
nachrüsten.

Guats Nächtle

Hayo

[Jürgen K. (oj_k)]

Hi Hayo,

Hayo W. schrieb:
> Jürgen K. schrieb:
>> Leider gibt es in der BF7.12 nach wie vor keine stabile Triggerung,
>> weder im Edge-Trigger noch im PW-Trigger.
>
> Hast Du hier ein Beispielsignal an dem ich mir das mal ansehen kann?
> Signalform, Frequenz, Amplitude. Dann kann ich das direkt vergleichen
> mit Deiner Version.
>

Ja, habe ich:
Edge-Trigger: einfach ein Signal (hier 3,3V) von irgendeiner 
Comm-Software via seriellen Port, welches im Abstand von >=  1sec (!) 
z.B. Anfragen an ein Gerät sendet.

PW-Trigger:
Siehe Ausdruck. Das ist natürlich nur nachzuvollziehen, wenn ein 
entsprechender Funktionsgenerator vorhanden ist. Das Signal besteht aus 
4000 Werten, die mit ca. 900Hz wiederholt werden. Sync-Signal wird 
selbstredend hier nicht benutzt.
Dabei setzt die Triggerung eben auch beim Durchkurbeln und Zurückstellen 
der Ausgabefrequenz sicher aus und wieder ein.

>> Die Scalierung des externen Triggerlevels ist ebenfalls unvollständig.
> Was fehlt noch? Habe ich was übersehen?
>

Der wird verstellt mittels Triggerlevel, Mainwheel und mittels 
F5-Button.

>> Die Einschränkung in der
>> Zeiteinstellung für die PW - Triggerzeiten (nur 16 bit) fehlt ebenfalls
>> noch und läßt hier eine Fehlerquelle in der Bedienung zu.
>
> Da bin ich auf die Schnelle nicht mehr zu gekommen, muss ich dann noch
> nachrüsten.

Ist eben alles in meiner 7.11+ eingebaut.

Gruß
Jürgen