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

Hi Sandro,

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

Regards Hayo

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

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.

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

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

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

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

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

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

> 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

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

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

Hayo

Hi Andiiiy,

danke für's Einchecken.

Hayo

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

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

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

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.

CB schrieb:
> I must substitute.

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

Hayo

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

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

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

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

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

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

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

Hi 김사백

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

vlG
Charly

Hi Charly,

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

Hayo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Looks good! Seems to work all fine!

Hayo

~ 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

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

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

Hayo

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

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

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

Ciao Sandro,

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

Hayo

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

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

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

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

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

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

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

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

Good night

Hayo

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

Ok, thanks

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

Hayo

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

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

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

what do you mean with limiting?

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?

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?

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

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.

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

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

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

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.

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

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

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.

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.

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

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.

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?

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

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.

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.

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

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!

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

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

Hayo

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

Hayo

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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?

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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