mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)


Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sandro,

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

Regards Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andiiiy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: eProfi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: WWWelec (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Jörg,

Good idea but IMHO it's a mere exercise in style if what we'll get on 
the screen is the same of today.
Make no sense the effort to upgrade from a DSO to a DPO if then the 
waveforms on the screen will be crude (drawn rappresentation) and not 
stable (poor hardware trigger) like it is right now
My two cents.

Victor

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

: Bearbeitet durch User
Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kruno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Kruno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Danke für die Aufklärung.
Danke auch für die gute Arbeit an der FW.

Kruno

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

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

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

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Andiiiy,

danke für's Einchecken.

Hayo

Autor: CB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ 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

Autor: CB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: CB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: CB (Gast)
Datum:

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

Autor: Krunoslav O. (kruno3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CB schrieb:
> I must substitute.

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

Hayo

Autor: Krunoslav O. (kruno3)
Datum:

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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ 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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charly B. (charly)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi 김사백

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

vlG
Charly

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Charly,

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

Hayo

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~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

Autor: Sandro (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
~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

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sandro (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
김사백 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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 김사백 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
~ 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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Looks good! Seems to work all fine!

Hayo

Autor: CD K. (cd_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
~ 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

Autor: nichtGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 +++

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> open("/dev/ttyUSB0", O_RDWR)

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

Hayo

Autor: nichtGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nichtGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ciao Sandro,

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

Hayo

Autor: Ricardo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benek)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Got the wrong thread - sorry. Should be in the hardwarethread...

: Bearbeitet durch User
Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

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

Good night

Hayo

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

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

luigi

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, thanks

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

Hayo

Autor: luigi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ciao Hayo,
here screenshots.

luigi

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
what do you mean with limiting?

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

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

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Super Hayo, genau diese Info hab ich benötigt, DANKE !!

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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-|

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

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

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
Maybe actually Welec works in opposite way to other oscilloscopes.

mark

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, I will try add a Tek-option for the LED

Hayo

Autor: luigi (Gast)
Datum:

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

luigi

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, I added 1s and 2.5s - Is that ok?

Hayo

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Understood, thanks.

luigi

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks a lot again, Hayo.

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: luigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks,

luigi

Autor: Martin Haßlöcher (marndra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Jürgen.

Jürgen schrieb:
TomCat_flash.ucl     TomCat_ram.uc

Are those intended like a recognized legit fix?
Thanks

mark

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:

Hi Mark,

Hayo will use this fix in his next version:

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

Jürgen

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Stefano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefano (Gast)
Datum:

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

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen K. (oj_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ricardo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: nichtGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

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

Viele Grüße

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen K. (oj_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen K. (oj_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke,

ich schau mir das mal an.


Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aktueller Zwischenstand,

- Du hast Recht Jürgen, die Einstellroutinen für den Pulsweitentrigger 
sind zum Teil noch auf dem alten Stand von Wittigs ursprünglicher FW. 
Ich habe das jetzt mal gründlich überarbeitet.

Jürgen K. schrieb:
>>> 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.

Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der 
Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen 
Einstellung/Kombination hat es denn bei Dir nicht funktioniert?


Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so 
reproduzieren können, habe aber mit etlichen verschiedenen "normalen" 
Signalen getestet und konnte keine Probleme beim Triggerr feststellen. 
Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der 
vermurksten Hardwareimplementierung doch recht gut funktioniert.


Gruß Hayo

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Hayo W. schrieb:
>> Der wird verstellt mittels Triggerlevel, Mainwheel und mittels
>> F5-Button.
>
> Ich konnte hier keine Unregelmäßigkeiten erkennen. Bei mir skalierte der
> Triggerlevel sauber mit den Probe-Faktoren. Bei welcher genauen
> Einstellung/Kombination hat es denn bei Dir nicht funktioniert?
>

Ich habe das eben nochmal versucht durchzuspielen. Es scheint doch so zu 
funktionieren. Kann sein, ich hatte nur die Quellen verglichen. Aber 
bekanntlich führen viele Wege nach Rom :-)

> Beim Trigger habe ich Deine Signale auf die Schnelle nicht genau so
> reproduzieren können, habe aber mit etlichen verschiedenen "normalen"
> Signalen getestet und konnte keine Probleme beim Triggerr feststellen.
> Beim PW-Trigger war ich sogar überrascht, dass dieser trotz der
> vermurksten Hardwareimplementierung doch recht gut funktioniert.

Na ich bin gespannt und wir werden sehen...

Grüße

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Und hier ist die neue Version. Auch verfügbar auf SFN - wie immer. Die 
Drucktastensteuerung der Pulseweitenwerte hat jetzt neue Steps und eine 
Begrenzung auf 524µs, ebenso die Mainwheelsteuerung. Ich habe noch mal 
alles geprüft und es lief bei mir alles schön stabil. Der Teufel steckt 
aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler 
jederzeit willkommen.


Gruß Hayo

: Bearbeitet durch User
Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

Hayo W. schrieb:
> Der Teufel steckt
> aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler
> jederzeit willkommen.

also los geht's:
Ich komme zuerst mal auf den Pretrigger zurück. Mit dem oben genannten 
Edge Trigger Signal mit ca. 1s Abstand sieht man in der
1.2BF.7.13:
Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt. 
Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal 
angezeigt. Dabei sieht es so aus, als ob zweimal ein Signal angezeigt 
wird. Zum Schluss aber der falsche Ausschnitt. Wenn man auf Single 
umschaltet, stimmt dann die Anzeige wieder nach dem Triggern.
Als Referenz nehme ich jetzt mal die V1.4 :-)
Dort funktioniert die Anzeige mit dem richtigen Triggerzeitpunkt (z.B. 
triggern auf fallende Flanke) in allen Timebase.
Dazwischen habe ich weitere Versionen daraufhin getestet:
BF6.3 und BF6.4C6 OK - ab BF6.5 falsche Darstellung

Gruß
Jürgen

Autor: Stefan Andres (estoban1000)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

auf meinem W2024A war noch eine sehr alte Software.
Jetzt habe ich die 7.13 eingespielt und habe folgendes Problem:

In Y Richtung wird die Spannung falsch angezeigt. Statt 5V wird nur 4V 
angezeigt (Sprich: 0,8*Wert). Ich habe bereits gesucht wo ich die 
Kalibrierung verändern könnte aber habe nichts richtiges gefunden.

Ich hoffe jemand kann mir hier weiter helfen.

Danke.

Gruß
Stefan

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stefan,

erstmal die Frage ob Dein Gerät irgendwie modifiziert ist oder die 
originale Factory-Bestückung hat?

Die entsprechende Einstellung nimmst Du im Hardwaremenü vor:

Utility -> More -> Hardware

- ADC Setup erstmal auf Factory
- Pre Gain je nach Modifikation oder wenn nicht modifiziert dann Factory
- Gain kann zur Feinabstimmung benutzt werden (default 1.000)
- ADC-Driver würde ich Assembler nehmen, Standard geht aber auch

Dann wieder zurück und Default Setup machen. Danach kalibrieren wenn das 
Gerät etwas warm geworden ist. Dann sollten die Amplituden eigentlich 
stimmen.

Gruß Hayo

Autor: Stefan Andres (estoban1000)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo,

Danke für die schnelle Antwort. Mein Gerät ist Factory.

Habe versucht ADC Setup auf Factory zu stellen und jetzt ist das Oszi 
eingeschlafen. Bildschirm leicht grün und keine Taste geht mehr. Aus- 
und einschalten bringt nichts ebenso reset (F2 + F1) es landet immer 
wieder an dieser Stelle.

Gruß Stefan

PS:
Habe die alte FW eingespielt und anschließend wieder auf 7.13. -> Oszi 
läuft.
Habe nur preGain auf Factory gesetzt und die Volt Kalibrierung stimmt.
Danke.

-> Das mit dem ADC Setup müsste ein Bug in der FW sein.

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stefan,

nein ein FW-Bug in dem Sinne ist es nicht. Aber wenn Du von einer sehr 
frühen Version upgradest kann es vorkommen, dass noch alte Werte im 
Flash an Stellen stehen, die jetzt eine andere Funktion haben. Daher wie 
in der Anleitung beschrieben immer ein Default Setup machen  nach dem 
Flashen wenn man größere Versionssprünge macht.

Wenn das erst mal in Betrieb ist sollte man keine Probleme mehr haben. 
Wenn Du da jetzt was verstellst müsste das ohne Probleme auch wieder 
zurückzustellen sein.

Wenn nicht, dann bitte noch mal Bescheid sagen.

Gruß Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen K. schrieb:
> Bei Timebase <= 250kSa/s wird der Triggerpunkt richtig angezeigt.
> Teilweise ab 500kSa/s oder ab 2,5MSa/s wird ein falsches Signal
> angezeigt.

Hi Jürgen, ich habe versucht das nachzustellen. Versuchsaufbau mit drei 
Oszis
 - Owon SDS8102
 - WELEC W2022A mit OPA653 Mod und FW 7.13
 - WELEC W2014A mit LowBudget Mod und FW 6.3

Am Signalgenerator habe ich Pulse eingestellt und den Start manuell 
getriggert um eine gewisse Ähnlichkeit zu Deinen Signalen zu erreichen. 
Spannungsbereich am Oszi war auf 2V/Div 90% ausgesteuert (also ca. 12V).

Ich konnte keine Unterschiede zwischen den Oszis feststellen. Es wurde 
bei allen korrekt getriggert. Dein Signal scheint ja sehr speziell zu 
sein wenn es da Probleme gibt.

Gruß Hayo

Autor: Jürgen K. (oj_k)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Hayo W. schrieb:
> Dein Signal scheint ja sehr speziell zu
> sein wenn es da Probleme gibt.

da ist aber überhaupt nichts spezielles an dem Signal. Ist einfach ein 
Stück serielle Comm (9600,8,N,1 oder so) im ca. 1 s Abstand gesendet und 
aufgezeichnet.
Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus.
Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst 
angezeigt wird und danach im RUN gleich überschrieben wird.

Ich habe mal drei Screenshots angehängt. Vielleicht wird es damit besser 
sichtbar. Gesamt.bmp zeigt das gesamte Signal :-)
Die zwei anderen eben Richtig und Falsch.
Die Bilder hab ich wegen der Größe besser gezipt.

Die Screenshots sind vom W2024A, 8C7.0H, BF7.13 und was auf den Bildern 
für Einstellungen zu sehen sind.
Falls Du unter Windows unterwegs bist, kann ich Dir gern das kleine 
Progrämmchen zusenden, was die Signale ausgibt.

Gruß
Jürgen

Autor: Wolfgang A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen K. schrieb:
> Die Bilder hab ich wegen der Größe besser gezipt.

Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-)
http://cetus.sakura.ne.jp/softlab/b2p-home/

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang A. schrieb:
> Probier doch mal, die in PNG zu wandeln. Das wirkt Wunder ;-)

Danke für den Hinweis!

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oho, da hab ich mich wohl geirrt :-(
Ich habe wahrscheinlich die Antwort schon in der Frage mitgeschrieben:

>> Ich vermute Dein Signal ist zu kurz und löst kein erneutes Triggern aus.
>> Wie schon geschrieben, sieht es so aus, als ob das richtige Bild zuerst
>> angezeigt wird und danach im RUN gleich überschrieben wird.

Das wäre ja auch das beabsichtigte Verhalten: Im RUN so viel wie möglich 
Frames anzeigen, damit man kein Signal verpasst. Eben blos schlecht,
wenn weitere Triggerereignisse im zu untersuchenden Signal folgen.
Damit können durchaus je nach Länge des Signales verschiedene 
Darstellungen angezeigt werden.
Je schneller die Anzeige ist und um so kürzer der Puffer im Verhältnis 
der Signallänge ist, umso mehr verschiedene
Darstellungen des Signales können angezeigt werden.
Nur war das eben nicht das von mir erwartete Signal "Triggern auf die 
ERSTE negative Flanke und Anzeige des ersten Teiles des Signals". Beim 
Single wird deshalb auch das erwartete Signal angezeigt,
da nach dem Füllen des Samplespeichers nicht auf ein neues 
Triggerereignis getriggert wird.

>> Die zwei anderen eben Richtig und Falsch.

Das sollte also besser "Erwartet" und "Nicht erwartet" heissen.
Bei langsamen Sampleraten dauert es eben länger bis der Samplebuffer 
gefüllt ist und eventuell passt das gesamte Signal in den 
Samplespeicher.
Dadurch ergibt sich nicht die Möglichkeit einer erneuten Triggerung 
(hier bei 1s Impulsabstand und ca. 22,2ms Impulsfolgedauer).

Also muss man hier besser SINGLE einstellen, um genau das Erwartete zu 
sehen.

Sorry, man lernt eben nie aus :-)

Beste Grüße und ein schönes WE
Jürgen

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

ja das ist allgemein ein Systembedingtes Problem bei Oszilloskopen. Auch 
bei den alten analogen Geräten. Man hat immer eine gewisse Zeit in der 
das Gerät "blind" ist. Wenn es ungünstig läuft kommt das nächste 
Triggerereignis (Signalanfang) ausgerechnet in dieser Zeit.

Da die Konstrukteure von Oszis dieses Problem auch schon recht früh 
erkannt haben gibt es die Holdoff-Time. Die kann man so einstellen, dass 
die "blinde Zeit" etwas länger wird, nämlich idealerweise so lang, dass 
der Trigger erst wieder nach dem letzten Signalteil scharf wird. So kann 
er dann wieder auf den nächsten echten Signalanfang triggern.

Ob das bei unserem DSO so gut funktioniert wäre zu testen. Vielleicht 
kannst Du uns dazu Infos liefern? Dein Signal wäre ja der ideale 
Testprobant.

Gruß Hayo

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

genau in diese Richtung hatte ich gedacht. Ich werde die Holdoff 
Funktion etwas genauer mit dem Signal untersuchen.

Gruß
Jürgen

Autor: Jürgen K. (oj_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

die Holdoff Geschichte funktioniert bei unserem DSO so wie es sein soll!
Du kannst nur in der Hardware Beschreibung mal korrigieren, daß das 
Holdoff  Register doch nur 24 bit breit ist. Da ist es noch 32 bit 
breit.
Damit ergibt sich bei 8ns Increment eine maximale Holdoff Zeit von 
134,217 ms.
Diese Begrenzung ist ja auch im User Interface so eingebaut (134,000 
ms). Da gibts noch eine kleine Reserve :-)
Der Pretrigger und die Anzeige ist ebenfalls ok.
Schön wäre, wenn auch die Triggerpositionsauswahl "Fixed" oder 
"Constant" gespeichert würde und nach dem Einschalten entsprechend 
gesetzt wird.

Gruß Jürgen

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah ja, danke. Ich schau mir das mal an und korrigiere das.

Gruß Hayo

Autor: Sandro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Merry Christmas and happy 2016 to all  Hayo and the dso team

Let's hope that the  new year will bring all the best and a new 
firmware!

Sandro

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
And from me also a happy new year 2016 to all.

The support for the hardware-mods and the BF-Firmware is still alive! If 
there are any questions or problems or maybe new ideas - post it here...

Kind regards

Hayo

Autor: Alfons (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo liebe Freunde des Welec!

Ich bin Besitzer eines W2024 und bis jetzt sehr zufrieden und finde euer 
Engagement bezüglich FW Erweiterungen bemerkenswert!
Ich dachte nun, dass ich nach langem mal meine FW aktualisiere und bin 
von 1.2.BF.2.7 direkt auf die neueste 1.2.BF.7.13 umgestiegen.
Folgendes Problem ist aufgetreten, die Nullpunkte stimmen nicht mehr, 
bzw. nur mehr auf der Null-Linie. Also verschiebe ich einen Kanal, dann 
verschiebt sich der Nullpunkt (wie wenn eine Skalierung nicht stimmen 
würde) - Kalibrieren hilft nichts. Habe dann verschiedene FW Versionen 
ausprobiert und bin da zu stehen gekommen, dass es bei meinem Gerät bis 
1.2.BF.6.5 funktioniert, ab der Version 1.2.BF.6.6 aber nicht mehr.
Ist das ev. wegen meiner HW-Version (8C7.0F), oder mach ich was falsch.

Danke im Voraus für alle Antworten.

LG
Alfons

Autor: Alfons Bach (abach)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Alfons!
Vergesst bitte den obigen Beitrag, Hayo hats bereits oben beantwortet. 
Bin durch die vielen Beiträge erst jetzt drauf gestoßen. Pre Gain -> 
Factory war bei mir das Schlüsselwort.

Danke

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alfons,

ja das ist dem Einen oder Anderen auch schon passiert. Im erstem Moment 
nach dem Update denkt man nicht an die Hardwareeinstellungen...   :-)

Aber Du hast es ja selbst gefunden. Noch viel Spass

Hayo

Autor: Sladjan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

i have one question about sampling memory. Is there any way for using 
other memory on board like SDRAM to extend sampling memory buffer for 
slow speed (like 1MSps) or direct usb continuos reading to PC.

Thanks a lot for best work firmware :)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sladjan,

unfortunately the fast memory is limited to 4K for each ADC. This memory 
is directly coupled to the ADC (inside the FPGA). In Fast sampling Mode 
all four ADC are used in interleave mode - so there are 16K memory 
available.

In slow sampling mode only one ADC is used, so there are only 4K memory 
available. Only in very slow sampling mode (USTB - ultra slow time 
bases) the samples are stored in the main memory and so there is a 
little bit  more space.

Without new FPGA-design there is no possibility to change this :-(

Haye a nice week

Hayo

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So I vote for a new FPGA design!

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> Der Teufel steckt
> aber bekanntlich im Detail und deshalb sind Hinweise auf Fehler
> jederzeit willkommen.

Moinmoin Hayo & CO.

hab seit laengerem nun wieder in Hardware zu tun und hab die
7.13 aufgespielt weil die 7.1 massive Probleme im Single mode
hat, leider sind die geblieben nur geht der Quick Mess jetzt
auch nicht mehr (Freq. messung) die Cursors haengen links am
'Anschlag'; (oder hab i die bedienung vergessen), vllcht kann
das auch noch jemand hier mit der 7.13 testen, danke

Hayo koenntest du bitte zumindest nach dem Single mode schauen,
ist f. mich sehr wichtig


vlG
Charly

*EDIT*:

hab eben die FW nochmal geflascht, def.setup und jetzt geht die Freq. 
messung im Quickmess, was da vorher war, KA......

der Single mode ist aber immer noch nicht OK, was genau kann i noch
nicht genau beschreiben, ein Problem ist zb. falls trigger auf auto
steht u. man aktiviert den Single dann Triggert er wenn man die TB
aendert....

nochmals vlG
Charly

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Charly,

also aktueller Stand bei Dir ist, dass der Single Mode irgendwie 
Probleme bereitet - korrekt? Du weißt aber noch, dass es ein Submenü 
gibt in dem Du einige Einstellungen zum Trigger vornehmen kannst? Hast 
Du die Einstellungen mal gecheckt?

Gruß Hayo

Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nice to heard you again, Hayo!! :-) Have you some good surprise for us, 
about new version of firmware? Thanks again for your great work... 
Regards, Paolo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Paolo,

at the moment there is no active development of the firmware from my 
side. This is because the actual version is running fairly stable and as 
second reason I'm deeply committed in some Raspberry Pi projects - for 
example RPi as ADS-B flight radar or RPi as media player build in a JVC 
boom blaster and so on.

But nevertheless I'm giving support for bugs or problems in the firmware 
or hardware. So if you have trouble with one of these - don't hesitate 
to report your problems here. I will try to help you with a new FW 
version or some new hardware hints.

Kind regards to you and all WELEC owners

Hayo

Autor: Paolo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thanks to you for your great works....

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello guys,
for me it's time for a dumb question:
how is it possible to forecast the sample rate at a given time base?
For Welec's DSO the related formula should be

sample rate = memory depth/(time per division*12)

that doesn't match though.
On my W2012A I read

sample rate    |    time base
    50Sa/s     |    1s/div
    1kSa/s     |    200ms/div
  100kSa/s     |    2ms/div
  250kSa/s     |    1ms/div
  500kSa/s     |    500us/div
    1MSa/s     |    200us/div
   25MSa/s     |    10us/div
  500MSa/s     |    2us/div
    1GSa/s     |    20ns/div
    1GSa/s     |    5ns/div
and so on which doesen't fit.
What's the trick?
Thanks,

Pico

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pico,

the trick is to use oversampling. That means, that we read more samples 
than we need - except 50ns (which is 1:1) and 20ns/10ns/5ns/2ns (which 
is undersampling with interpolation).

For example when we have 4 x oversampling - we are only using every 
fourth sample in the memory to display it on the screen. That gives us 
the possibility to "zoom in" in Stop-Mode or in Delay-Mode.

Also this is the only possibility to get all needed timebases in spite 
of the very poor implemented ADC controlling unit in the FPGA.

Hope that helps

Hayo

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Hayo,
honestly I don't understand.
I meant the sample rate shown on the top of the screen.
I thought it was related to something calculated by the firmware.
For instance there is:

sample rate    |    time base
    50Sa/s     |    1s/div
    1kSa/s     |    200ms/div
  100kSa/s     |    2ms/div
  250kSa/s     |    1ms/div
  500kSa/s     |    500us/div
    1MSa/s     |    200us/div
   25MSa/s     |    10us/div
  500MSa/s     |    2us/div
    1GSa/s     |    20ns/div
    1GSa/s     |    5ns/div

Why by setting the time base for 200ms/div is shown 1kSa/s like sample 
rate on the top of the screen?
Why 250kSa/s with 1ms/div?
Why is 1GSa/s by setting for 5ns/div and still with 20ns/div?
I guess that the firmware derives the sample rate from a formula, but I 
don't know what formula.
Thanks,

Pico

Autor: Tom E. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
The Sample rate gives the number of samples per second, while the time 
base gives the horizontal scaling of the waveform on the screen. These 
are different things. If you activate the "Delayed" presentation of the 
signal, you even can have two different time bases for a signale aquired 
with an identical sample rate.

Tom

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Tom,
I agree.
But i think in the firmware have to be a formula that ties sample rate 
with the setting of the time base, that is what I'm talking about.
I set the time base for 200us/div and so on the top of the screen it's 
shown 1MSa/s, I set for 20ns/div and it's 1GSa/s, still the same value 
for 5ns/div, while by setting time base for 1s/div it's instead 50Sa/s 
and so on.
How the firmware choose the sample rate shown on the top of the screen?
For me by a formula that I don't know.
Thanks,

Pico

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello guys,
just another question.
I know it's already been discussed but I'm not sure of the right answer 
because it has been provided differently from time to time.
About the FPGA revision in some occasions have been told that 8C7 is 
better than 1C9, in other ones that 1C9 is better than 8C7.
Which of the two is more resistant to spurious spikes?
Thanks,

Pico

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pico,

there is no formula inside of the firmware. This is controlled by table 
entries. Here a piece of the code:

- the register values

const unsigned long tb_value[36] =
{
  /*-------16Kb--------*/
  0xFFFFFFFF,    //   0 -> 2 ns
  0xFFFFFFFF,    //   1 -> 5 ns
  0xFFFFFFFF,    //   2 -> 10 ns
  0xFFFFFFFF,    //   3 -> 20 ns
  0xFFFFFFFF,    //   4 -> 50 ns
  0xFFFFFFFF,    //   5 -> 100 ns
  0xFFFFFFFF,    //   6 -> 200 ns
  0xFFFFFFFF,    //   7 -> 500 ns
  0xFFFFFFFF,    //   8 -> 1 µs
  0xFFFFFFFE,    //   9 -> 2 µs (500MSa/S)
  0xFFFFFFFD,    //  10 -> 5 µs (250MSa/S)
  /*-------4Kb--------*/
  0xFFFFFFFB,    //  11 -> 10 µs (25MSa/S)
  0xFFFFFFF3,    //  12 -> 20 µs
  0xFFFFFFE7,    //  13 -> 50 µs
  0xFFFFFFCE,    //  14 -> 100 µs
  0xFFFFFF83,    //  15 -> 200 µs
  0xFFFFFF06,    //  16 -> 500 µs
  0xFFFFFE0C,    //  17 -> 1 ms
  0xFFFFFB1E,    //  18 -> 2 ms
  0xFFFFF63C,    //  19 -> 5 ms
  0xFFFFEC78,    //  20 -> 10 ms
  0xFFFFCF2C,    //  21 -> 20 ms
  0xFFFF9E58,    //  22 -> 50 ms
  0xFFFF3CB0,    //  23 -> 100 ms
  0xFFFE17B8,    //  24 -> 200 ms
  0xFFFC2F70,    //  25 -> 500 ms
  /*------- USTB -----*/
  0xFFFFFFFF,    //  26 -> 1 s [USTB]
  0xFFFFFFFF,    //  27 -> 2 s [USTB]
  0xFFFFFFFF,    //  28 -> 5 s [USTB]
  0xFFFFFFFF,    //  29 -> 10 s [USTB]
  0xFFFFFFFF,    //  30 -> 20 s [USTB]
  0xFFFFFFFF,    //  31 -> 50 s [USTB]
  0xFFFFFFFF,    //  32 -> 100 s [USTB]
  0xFFFFFFFF,    //  33 -> 200 s [USTB]
  0xFFFFFFFF,    //  34 -> 500 s [USTB]
  0xFFFFFFFF    //  35 -> 1000 s [USTB]
};

- and the text output

unsigned char SampleRateData[36][11] =
{{"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, 
{"1 GSa/s "}, {"1 GSa/s "}, {"1 GSa/s "}, //interpolated / normal

{"1 GSa/s "}, {"500 MSa/s "}, {"250 MSa/s "}, {"25 MSa/s "}, {"10 MSa/s 
"}, {"5 MSa/s "}, {"2.5 MSa/s "}, {"1 MSa/s "},  //normal

{"500 kSa/s "}, {"250 kSa/s "}, {"100 kSa/s "}, {"50 kSa/s "}, {"25 
kSa/s "}, {"10 kSa/s "}, {"5 kSa/s "}, {"2.5 kSa/s "}, //normal

{"1 kSa/s "}, {"500 Sa/s "}, {"50 Sa/s "}, {"25 Sa/s "}, {"10 Sa/s "}, 
{"5 Sa/s "}, {"2.5 Sa/s "}, {"1 Sa/s "}, {"1 Sa/2s "},//USTB

{"1 Sa/4s "}, {"1 Sa/10s "}, {"1 Sa/20s "}};

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
And to your question about the FPGA version - 8C7 is the better choice. 
If someone have problems with his 1C9, there is the possibilty to change 
the version to 8C7. All you need is an Altera byte blaster clone (for < 
10€) and the Altera programming software.

Hayo

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Hayo,
thanks, finally I get it!
So ultimately it's a parameter taken from a table that decides the label 
on the top of the screen for the sample rate versus the time base.
For me it's a useful thing to know.
Thanks also for your reply about the better anti-spikes FPGA design.
Honestly by reading the forum sometimes it's said that 1C9 is better 
than 8C7 and other times the reverse.
Your post clarifies the issue once and for all, even if actually it 
isn't exactly what I was hoping for because my oscilloscope has the 8C7 
and it isn't so resistant to the spikes.

Pico

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yes the 8C7 also can have some problems with spikes. This seems to be a 
thermal problem. The 2 channel version has less problems than the 4 
channel version. Optimizing the thermal design (like in my mod guides) 
can help to minimize these problems.

The original build in fan has nearly no cooling effect. So it is 
recommended to change it against a better one. Doku and all other stuff 
can be found here:

https://sourceforge.net/projects/welecw2000a/files/

Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,

bezüglich Sampleraten ist die alte Hardware meine ich noch nicht 
ausgereizt. In meinen Experimenten mit OSOZ auf dem alten FPGA habe ich 
keinen solchen Sprung von 250 MSa/s auf 25 MSa/s beobachtet. Die Werte 
dazwischen sind zugegeben aber recht krumm.
Siehe CaptureSetTimebase() in osoz/platform/nios/capture.c
Die Hardware hat erstmal einen "exponentiellen" Einstellbereich, wo sich 
bei jedem Registerschritt die Abtastrate halbiert. Ergibt 1GSa, 500MSa, 
250MSa, 125MSa, 62.5MSa/s. Alle 4 ADCs und die volle Speichertiefe gibt 
es nur bei den beiden schnellsten Raten.
Dann kommt ein schier endloser "linearer" Einstellbereich wo sich der 
Teiler mit jedem Registerschritt um 8 erhöht. Das ergibt Abtastraten von 
31,25MSa, 25MSa, 20,83MSa, 17,86MSa, 15,625MSa, 13,89MSa, 12,5MSa, ...

Mit dem neuen FPGA wird das besser. Vor allem steht immer die volle 
Speichertiefe zur Verfügung, bei Nichtbenutzung des anderen Kanals 
kriegt man dessen Speicher sogar noch hinzu. Für die Abtastraten siehe 
die Schwesterdatei osoz/platform/nios2/capture.c, gleichnamige Funktion, 
sowie die Tabelle gDecimations[].

Grüße
Jörg

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Hayo,
my DSO already has the thermal improvements described in the forum but 
spikes are a pain in the back because you never can know if they are 
real or artifacts.

Pico

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Jörg,
this means that somewhere there is an alternative design?
Where?
Thanks,

Pico

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I shoudn't advertise it, since it's kind of abandoned. I haven't worked 
on it since almost 3 years (just checked), no free time in sight.
This is the thread about it:
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
Originally started as just a new software, then on mid 2012 it turned 
into a new FPGA design, too. Some coverage in the hardware thread, too:
Beitrag "Wittig(welec) DSO W20xxA Hardware (Teil 2)"

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jörg, ja das Thema mit der Samplerate hatten wir schon mal vor 
einiger Zeit. Ich hatte daraufhin das OSOZ-Coding geprüft und 
festgestellt, dass die 125 und 62,5 nur softwaremässig implementiert 
waren. Für diese Samplingraten gibt es aber (meines Wissens) keine 
Registerwerte die die ADC auf diese Rate einstellen. Falls ich mich da 
täuschen sollte bitte ich unbedingt um Hinweise. Dann würde ich da 
nochmal was nachrüsten.

Aber - wo Du das alternative Design ansprichst - wie ist den der Stand 
der Dinge? Bist Du da noch dran? Oder ist das in Dauerparkposition? Ohh, 
sehe gerade dass sich das mit Deiner Antwort überschneidet. Du warst ja 
schon mal an einem sehr vielversprechenden Punkt...

Schon dieser Stand wäre mit etwas zusätzlicher Peripherie um Lichtjahre 
weiter als das derzeitige Factory-Design.

Hayo

: Bearbeitet durch User
Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pico,

did you adjust the settings in the hardware setup? There are factory and 
highspeed settings that may cause different behavior. Do you own a 4 
channel version?

Hayo

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hayo,
I did but still the problem is there.
As suggested in the forum I have to put time for trigger out of the 
viewable area of the screen even if me I don't like it much.
It's known that most likely spikes are near trigger event.

Pico

Autor: Pico (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Jörg,
thanks.

Pico

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pico,

can you upload a screenshot with an example? That may help to identify 
the problem. Preferred a typical situation of measuring with this 
spikes.

Hayo

Autor: mark (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hello folks.
It is a long time that I didn't set foot here.
Lately I'm debugging a device for a friend of mine so I want to show how 
a Welec DSO can be used as MSO oscilloscope.
So here you go a couple of pictures showing my W2012A_OPA653_MOD when 
compared with a logic analyzer while it's acquired the ATR response of a 
4442 chip card using digital and analog trigger on Welec.
As it's possible to see it works great.
I did notice a little problem though.
In my W2012A is installed the latest firmware 1.2.BF.7.13C2 and when 
using zoom by DELAYED button with some time base's values I get garbage 
on the screen.
It seems that something is wrong with the memory used for the captured 
waveforms.
Hardware is good, any fault, being that the problem only emerges using 
DELAYED feature.
Could it be a firmware issue?
Thanks!

mark

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Mark,

yes indeed I think you are right and this is a firmware issue. The 
digital mode function seems to be tested not so good as the other parts. 
I think it is used not so often - especially the delayed function. Due 
to that this failure has not been detected yet. If I find some time for 
that I will try to fix it.

Thanks for reporting

Hayo

Autor: mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello Hayo, thanks!
In my opinion digital mode function works great, the only problem is in 
DELAYED function, in fact the garbage appears with both digital and 
analog representation.
I don't want to abuse your time but I have some questions that I'd like 
to have an answer from you as soon as the time will allow it to you.

1) Are EXT Trigger working while using DIGITAL mode function?
I'm not able to use it even by setting the trigger to NORMAL.

2) Are SINGLE mode trigger working while using DIGITAL mode function?
I'm not able to use it even by setting the trigger to NORMAL.
I guess due the well known issue of noise that plagues the Welec DSO's I 
have many random trigger acquisitions even when real one isn't present.

3)Would be possible add a new DIGITAL function that allows for the same 
rappresentation on the screen as the usual ones togheter with the chance 
to adjust the thresholds of the triggering action?
I understand that make no sense because DIGITAL trigger have their own 
levels.
I mean rappresntation of the waveforms on the screen though, something 
like FILTERS in AQUIRE menu, don't a real DIGITAL trigger as those 
already allowed in the firmware.

Course I'm not in a hurry either for this questions than for the fix of 
the issue I have written, answers well when you have the time and mood, 
I repeat there is no rush.
Thanks.

mark

Autor: Sandro (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi to all ,
I confirm that the last firmware is good for spike triggering with CAN 
automotive signal, as enclosed image, but that improvements for digital 
may help.
Let's wait for  Hayo and the team amazing news.

Best 2017 to all of you.

Sandro

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay
ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. Wegen der
bekannten Probleme stand es bei mir jahrelang nahezu ungenutzt herum.
Nun bin ich endlich dazu gekommen, die neueste BlueFlash Firmware
1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den
LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank
an alle Beteiligten für die große Mühe!
Leider zeigen sich zuweilen immer noch die lästigen Spikes. Eine 
Einstellung im ADC Setup auf HighFreq 1 bringt schon einiges.  Im Forum
habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf
Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo
das benötigte File für diese Version. Könnte mir jemand einen Link
benennen?

Vielen Dank!
Dietmar

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dietmar,

das File kann sicher einer unserer FPGA Spezialisten hier zur Verfügung 
stellen. Notfalls müsste ich mal meine Archive durchstöbern oder von 
meinen Geräten eine Kopie runterziehen.

Evtl. die Anfrage nochmal im Hardware- Thread wiederholen.

Wenn keiner der Anderen helfen kann, sag noch mal Bescheid, dann muss 
ich mich mit dem Altera-Programm noch mal beschäftigen - ist schon etwas 
her, dass ich das benutzt habe.

Gruß Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Version, kann ich einem "Gast" aber nicht schicken. Bitte 
anmelden/einloggen.

Ist ein ByteBlaster vorhanden? Man kann auch den USB-Chip mit einer 
entsprechende Firmware ausstatten.

Jörg

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

auf die Schnelle habe ich folgendes File für den EP2C35 gefunden. Das 
könnte es sein, soweit ich mich erinnere. Im Hardwarethread hatte glaube 
ich auch mal jemand etwas hochgeladen.

edit: Oh hallo Jörg, Du warst schneller als ich...

: Bearbeitet durch User
Autor: Dietmar Sch. (dietmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg, vielen Dank für dein Angebot. Ich habe mich gerade am Forum 
angemeldet und es wäre nett, wenn du mir das File zur Verfügung stellen 
könntest. Ein Altera USB-Blaster incl. Quartus-Software ist vorhanden.

Grüße Dietmar

Autor: Dietmar Sch. (dietmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo, auch dir vielen Dank! Ich werde von meinen Versuchen 
berichten.

Grüße
Dietmar

Autor: Chris El (chris_el)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hayo,
darf ich mich anschließen, mit den Files. Ich besitze aus einem Nachlass 
auch jetzt auch noch ein W20xx ohne A. Nach den ersten Test war die 
Freude dann schnell am Ende. Ich fand dann den Thread hier, leider sind 
viele Links doch schon offline. Hast du noch die Files local bei dir ? 
Ich muss ja erstmal ein A aus dem DSO machen. Würde mich sehr über Hilfe 
freuen.

VG
Chris

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chris,

bin gerade aus dem Urlaub zurück und muss mich hier erstmal etwas 
sortieren. Aber ich schau mal was ich für Dich tun kann. Wegen der Files 
am Besten noch mal bei Jörg anfragen, seine Files sind auf jeden Fall 
die richtigen und er kann Dir auch in Sachen FPGA-Programmierung am 
Besten weiterhelfen wenn Du da Fragen haben solltest.




@Jörg

vielleicht kannst Du die Files ja im SF-Repository unter

https://sourceforge.net/projects/welecw2000a/files/

ablegen? Dann hätten wir die an einer zentralen Stelle verfügbar.



Gruß Hayo

: Bearbeitet durch User
Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, ja ich bin ein blutiger Anfänger. Habe nur soviel 
verstanden das man den Treiber bei Windows irgendwie trauschen muss. 
Dann tut der Wittig so als wäre er ein Programmer und dann dann sollte 
man das FPGA Programmieren können. Alles andere geht ja dann über den 
GERM und dem Welecupdater. Habe ich das soweit richtig verstanden?

Chris

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ist soweit korrekt. Für die FPGA-Programmierung hab ich mir für unter 
10,- einen Blasternachbau in der E-Bucht gekauft da der Treiber bei 
meinem Windows einfach nicht funktionieren wollte. Damit geht es auf 
jeden Fall - auch unter Linux.

Dann brauchst Du eine Altera Installation um das FPGA (bzw. den 
Speicher) zu programmieren. Kann man kostenfrei runterladen. Die 
Anleitung zum Upgrade auf den A Typ muss ich noch mal raussuchen. Bist 
Du wirklich sicher, dass Dein Teil kein A ist? Auf dem Gehäuse steht das 
nämlich nirgends drauf - da steht immer nur W20xx ohne A.

Gruß Hayo

Autor: Chris El (chris_el)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, den Blasternachbau habe ich mir jetzt für 3€ gekauft. Weil 
ich die treiber auch auf teufel komm raus weder unter Windows XP noch 
unter Windows 7 schaffe zu wechseln.
Ja es ist eines ohne A, W2012 Software 1.00.08 / Hardware 3C7.0H
Wird wohl eines der ersten sein.

Chris