Hallo Hayo,
mit der aktuelen BF 3.0 C2 bin ich bei der inversen Erfassung mit Kanal
1 auf ein sehr merkwürdiges Feature gestoßen. Zum Vergleich liegt das
selbe Signal am normal dargestellten Ch2.
Am linken Rand taucht ein falscher Wert ("Flanke") auf (Bild:
Messung...) und wenn man auf STOP geht und das Anzeigefenster nach
rechts verschiebt, kommen merkwürdig nach unten versetzte Daten ins Bild
(Bild: Pan_...).
Eingangssignal ist Probe Comp (passiert aber genauso mit anderen
Signalen). Wenn man dagegen Ch2 invertiert, ist alles gut. :-)
Gruß
Rainer
p.s. Die Screenshots wurden mit w2000a-screenshot 0.97 erstellt und
nicht nachbearbeitet - sicher ist sicher. ;-)
@Hayo,
denke bitte daran mir die mail wegen dem USB-Host zu schicken. ;-)
Ich wollte gerade die neuesten Änderungen in meine Firmware übernehmen.
B/W funktioniert aber nicht richtig. Da schon in der UC_SCREENSHOT_BW()
die Schwarz/Weiß Werte zusammengebaut werden vermute ich den Fehler
dort.
Die Gegenprobe mit dem screenshot zum PC scheitert leider daran:
1
- Receiving a monochrome screenshotError: screenshot data version newer on DSO than known here in receive_screen(), exiting.
hmpf,
> Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig> eingestellt und auch kalibriert?
kennst mich doch, mach das jedes mal, auch resette ich das Teil mehrmals
bevor ich pöpel!
Wie sieht's denn bei den Anderen so aus?
Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active
Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die
Einstellungen für die 24 u. oder 33 Ohmler?
Zum Germsloader über die RS232 Schnittstelle: Ich selbst habe Win XP auf
dem Lappi sowie auf dem Hauptrechner Athlon Phanom 9500, SP2(Laptop) SP3
(Athlon) funzt mit der eingebauten RS232 sowie mit dem Adapter(FTDI)!
Wichtig sind die Comport-Einstellungen!!! Diese müssen oder sollten
immer überprüft werden, d.h. 115kb , Datenbits=8, Parität=non(keine),
Händshake(Flussteurung)= none(keine), Stopbit=1
Hat mal ein Gerät darauf zugegriffen, kann es vorkommen, daß der Port
nicht, oder noch nicht freigegeben ist, dann zickt das Ganze und man muß
den Rechner komplett neu hochfahren!!!
Das sind jetzt meine Erfahrungen, die ich hier weiter gebe kann.
...habe bis jetzt jedes Miststück zum laufen gebracht, unter Anderem
auch das LEON3 Design! Wie ist denn da eigentlich der Fortschritt? Das
was ich bisher aufgespielt hatte, war schon sehr beachtlich, schade,
wenn das einschlafen würde...
Gruß Michael
Hi Hayo, Niklas O. and all!
I take just peeping through, I am in a hurry, so apologize me.
First:
@Hayo and all who involved in the Welec project:
I installed the new 1.2.BF.3.0_C2 release and I'm trying it.
I have few time and I was able to give only a superficial glance, but
this new release seem to me very, very impressive!!!
Modifications and improvements are so many and such that I make it hard
to use the oscilloscope.
It is as if I were using a new DSO and I have to read the instruction
manual for understand how to use it.
Options and settings are significantly increased compared to a few
previous versions, have been added feature that I couldnt even imagine
could be implemented in the Welec DSO!!!
The DSO seem me to be more fast and especially for me now it is less
noisy, a lot less noisy!!!
Then the calibration is now super precise than ever on mine W2022A and
W2012A.
For me also the trigger behavior is better now.
I repeat, very, very impressive!!!
Over the weekend I'll try to find time to do some testing instrument.
That said, Hayo and all who involved I thank You very, very much for
this new jewel, I have no words, RESPECT, RESPECT, RESPECT!!!
Niklas O. schrieb:
>Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich>kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt.>Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz">Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung>x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal>mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO>verglichen.>>Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD>(inkl. Versand) Tastkopf. Die Traces sind etwas verschoben,>da ich den Versatz nocht nicht wieder ueber die Delays im>Utility-Menue kompensiert habe. Man sieht's aber auch>"mit blossen Augen" ohne Cursor recht gut ;)
About this I tried with the W2012A probe in CH1 and W2022A probe in CH2
of my W2012A (screenshoot 1) and then I exchanged them in the channels
(screenshoot 2), both are set x1 so like also the DSO's channels:
W2012A's probe win on the W2022A.
The square wave is the inner DSO probe calibrator and both probes are
correctly matched.
I have to investigate further, I have to try with the W2022A.
Now I run away.
Hayo again many thanks to You and all, really thanks very much to all
You!!!
Vielen Dank!!!
Luc
Hallo Kurt,
hab es schnell noch mal gerichtet. Die UI Planes 3 + 4 dürfen nicht mit
übertragen werden, da sie die anderen Planes überdecken.
Weiterhin habe ich das Übertragungsprotokoll für B/W an die neueste
Version angepasst - sollte also keinen Abbruch mehr geben.
Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei
das korrigierte Coding und die Kompilation 3.
Gruß Hayo
Hayo W. schrieb:> Oha, das ist ja merkwürdig.> Da muß muß ich wohl mal ran.
Vielleicht war das Problem doch vor dem Oszi und du mußt da nicht noch
mal ran. Mein letztes "Default Setup" war vor dem Einspielen der 3.0 C2.
Nachdem ich das jetzt nachgeholt habe, benimmt sich auch der invertierte
Kanal 1 anscheinend richtig.
Dafür bin ich drauf gestoßen, dass bei im Single Shot mit Einstellung
"Invert" erfaßten Signalen das Invertieren anscheinend auf allen Kanälen
ignoriert wird. Beim STOP, wo der gleiche Effekt auftrat, hattest du das
ja schon repariert.
Gruß Rainer
Hayo W. schrieb:> Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei> das korrigierte Coding und die Kompilation 3.
Super. Danke!
Gute Nacht.
Moin Hayo,
Hayo W. schrieb:> Oha, das ist ja merkwürdig.> Da muß muß ich wohl mal ran.
Gestern Abend war es wohl doch schon etwas spät.
Langer Rede kurzer Sinn: Der Fehler mit den falsch dargestellten
invertierten Daten beim Pan ist doch echt und betrifft alle 4 Kanäle in
gleicher Weise, was schon mal beruhigend ist.
Reproduzieren läßt sich das (jetzt mit BF 3.0 C3) wie folgt:
ProbeComp an Ch1..4 - Default Setup - Autoscale -
AutoPreTrigger "Trace Middle" - Invert Ch1..3 (Bild Mess...) - STOP -
Pan nach links oder rechts (Bild Pan...)
bringt dann falsche Daten zur Anzeige.
Das Ding mit der normalen Darstellung eines invertierten Kanals beim
Single Shot sieht man ebenfalls mit obigen Einstellungen. (Bild
Single...)
Für die ScreenShots habe ich Ch4 als Referenz nicht invertiert, der
Effekt tritt dort aber genauso auf.
Gruß
Rainer
Hallo Rainer,
das Problem sitzt nicht vor dem Gerät. Es ist tatsächlich ein Fehler,
den ich auch schon gefunden habe. Auch die Lösung habe ich mir schon
überlegt. Leider ist es ein grundsätzliches Problem und die Lösung
erfordert einen etwas größeren Umbau. Bin ich aber dran...
Gruß Hayo
@Michael
> man muß den Rechner komplett neu hochfahren!!!
Das kann es sein!
Ich hatte nur die Schnittstelle im Gerätemanger ausgetragen und dann
neue Hardware suchen lassen. Auf die Parameter habe ich geachtet.
Ich reiche mal den Fix für den Invertion Bug nach.
Es gibt da zwei Lösungsansätze. Zum Einen die einfache Lösung die
Performance kostet aber gut und problemlos funktioniert, zum Anderen die
aufwändige und auch fehlerträchtigere Variante die aber deutlich
performanter ist.
Ich habe erstmal die langsamere Lösung eingebaut um auf die Schnelle
eine fehlerfreie Lösung biten zu können. An der Optimierung arbeite ich
dann in der nächsten Zeit.
Gruß Hayo
Hayo W. schrieb:> Ich reiche mal den Fix für den Invertion Bug nach.
Das ging ja fix mit dem Fix.
Wenn du an der optimierten Lösung arbeitest, hast du dann ein Auge auf
das letzte Byte am Ende vom Speicher, dass im Moment bei invertierten
Kanälen im Display als unschöner Spike erscheint, wenn man das Fenster
ganz nach rechts schiebt. (Ch1 im Anhang)
In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte
w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die
Zusammenarbteit mit dem Argument:
" - Receiving trace...
* Receiving parameters...Error: trace parameter format newer on DSO
than known here in receive_trace(), exiting."
verweigert.
Und noch etwas (wahrscheinlich aber bekannt): Die großen Spikes auf
Ch3/4 scheinen immer synchron zu kommen.
Schönes Wochenende
Gruß
Rainer
Hallo Rainer,
> In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte> w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die> Zusammenarbteit mit dem Argument:>> " - Receiving trace...> * Receiving parameters...Error: trace parameter format newer on DSO> than known here in receive_trace(), exiting.">> verweigert.
die Header-Groesse die das DSO dem Programm uebermittelt ist
um ein Byte zu klein. Als Version liest es jetzt den
Index des Pretriggers. Wie das jetzt zustande kam weiss ich nicht.
Ob mein letzter Patch gg. Firmware von mittlerweile anno dazumal,
versionsgeschichtlich gesesehen, schon den Fehler hatte oder
zwischendurch noch was geaendert wurde weiss ich nicht, ist
aber auch egal.
Workaround, ohne Firmware neu zu kompilieren, waere nen
para_len++; in receive_trace() vom Screenshotprogramm vor
dem malloc().
Niklas
Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der
jetzt korrekt unterstützt, auch auf Kanal 3+4?
Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren
Rand. Kanal 1+2 sind OK.
Kurt Bohnen schrieb:> Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der> jetzt korrekt unterstützt, auch auf Kanal 3+4?
Wird komplett unterstützt, automatisch!
> Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren> Rand. Kanal 1+2 sind OK.
Dann ist beim Einlöten was schiefgelaufen.
Hayo
Hayo W. schrieb:> Dann ist beim Einlöten was schiefgelaufen.
Stimmt. Ein Pad hatte kein Zinn angenommen. Ich hätte nicht nur per
Lupe, sondern auch per Mikroskop kontrollieren sollen.
Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet
wie du. ;-)
Niklas O. schrieb:> Workaround, ohne Firmware neu zu kompilieren, waere nen> para_len++; in receive_trace() vom Screenshotprogramm vor> dem malloc().
Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich
ist Hayo mit dem nächsten Update aber wieder schneller. ;-)
Rainer
Kurt Bohnen schrieb:> Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet> wie du. ;-)
Na prima, was machst Du jetzt damit? Klebst Du Ihn in einen Bilderrahmen
und hängst eine Lupe daneben damit man ihn sich ansehen kann? ;-)
Übrigens gehe ich immer nach dem Motto vor: Für eine gute Sache muß man
auch mal Opfer bringen!
Den zweiten hab ich übrigens heil raus gekriegt, aber was ich damit
machen soll weiß ich auch nicht...
Gruß Hayo
Rainer W. schrieb:> Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich> ist Hayo mit dem nächsten Update aber wieder schneller. ;-)
Ich arbeite dran :-)
Hayo
Gute Sonntag Hayo and guys all!
@Hayo and all who involved in the Welec project:
I installed the new 1.2.BF.3.0_C4 release and I played with it.
For the way I use the DSO I have not found defects, the new
1.2.BF.3.0_C4's release works like a charm.
It is fast, stable and for me it is also a lot less noisy and much more
precise.
Even AUTO SCALE works well, but I must point out something perhaps
already You know.
As usual, I specify that this report is not intended as a critique of
the good work You Hayo and all who involved in the project have done,
but only like a remark.
In most cases the AUTO SCALE works very well, quickly and accurately,
but the signals in a particular range of frequencies are displayed
incorrectly.
I tried with my RF sine wave generator and for example with 80MHz, 25MHz
and 12.5 MHz frequency's signals I got the screenshots You can see.
This actually is not much of a problem, You can fix it by manually
adjusting.
I must stress that AUTO SCALE's function in previous releases never
worked so well, so even like it is now it still a huge leap forward from
the original Welec/Wittig's implementation!
So Hayo and all who involved I thank You a lot for this new bug fix
release that make me happy in the DSO usage, again I have no words,
RESPECT, RESPECT, RESPECT!!!
Good also for Grid Intensity / Grid Color and Quick Print menu.
Very well and much impressive the Auto Pretrigger / Pre Trigger Setup
and Manual Trigger / Single Trigger Setup menu where settings's number
and improvements are so many and such that them are not commonly
available even in high-end DSO!
In the end just one last thing, I did not understand how use the "Send
Measure" button, how it work?
Vielen Dank!!!
Gruß Luc
Wie versprochen,
Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder.
@Luc
Thanks for Your detailed report. I will check it!
>In the end just one last thing, I did not understand how use the "Send>Measure" button, how it work?
When using the Cursor or Quick Measure function there are displayed
additional values on the screen. These values are sent to a file if You
push the Send Measure button. This is working only with activated
cursors!
Gruß Hayo
Hi Hayo,
die inversen Signale sehen ja jetzt aus wie eine eins. Da habe ich mit
meiner Bemerkung doch deinen Ehrgeiz geweckt. Die Bemerkung war aber
nicht als Aufforderung gemeint, jetzt sofort den Compiler anzuschmeißen.
Ich hoffe, du hast das nicht falsch verstanden.
Vielen Danke
Gruß
Rainer
Nein nein, Du muß jetzt kein schlechtes Gewissen haben. Aber so ein
Fehler in der Firmware ist wie ein unausgedrückter Pickel.
Irdendwie muß man da ran und das beseitigen ;-)
Davür gebe ich mir jetzt auch die Badewanne - verdienterweise.
Gruß Hayo
seht ihr irgendwie eine Möglichkeit den Spannungsabfall an einem Shunt
über 2 Kanäle zu messen (also Kanal 1 vor dem Shunt und Kanal 2 nach dem
Shunt) und am Oszi dann eine Stromkurve anzuzeigen?
Guten Abend Hayo and guys all!
Hayo W. schrieb:
>Wie versprochen,>>Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder.
Hayo, super danke für blitzschnelle Updates!!!
Klasse!!!
Hayo You really are tireless and very kind, so thanks You very, very
much Hayo for the great job and free time You provided generously to
us!!!
I immediately installed the newest 1.2.BF.3.0_C5 version.
For me the problem with the INVerted channels is solved, thank You,
really thank You very much Hayo!!!
RESPECT!!!
However, at the risk of appearing rude, I would like to point out one
thing.
I do not know if it also happened with previous versions, I do not even
know if it happens only with my DSO.
But I have noticed that when I activate the INV's function then the
tracks suffer from a certain offset, especially in my case the CH2.
Please look at the screenshot.
The two images refer to the CH1 and the CH2 shorted to GND.
The NORMAL image shows the tracks that are superimposed on the zero
line.
The INV image shows the tracks set to INVerted mode that are not on the
zero line, especially the CH2's track even if also CH1's track is a
little bit raised by the zero line.
The oscilloscope was switched on for about 2 hours and it had reached
thermal equilibrium when I made the two screenshots
As usual this my report is not intended as a critique but only like a
remark.
@Hayo, @Niklas O.
Hayo, really thank You very much for your kind explanation about the
"Send Measure" function.
Now I understand and I must to say it is a very usefull function.
Of course I also thank Niklas O. for it because if I am not wrong, He
has suggested it.
So, Niklas O. RESPECT!
Vielen Dank!!!
Gruß Luc
bin jetzt heute erst dazu gekommen habe jetzt die 3.0_C5 drauf, die
Fortschrittsanzeige ist echt klasse. Bin auch der Meinung das die
Anzeige noch einen Tick schneller geworden ist.
Mir ist noch ein Fehler aufgefallen, kurze Beschreibung: Ich habe im
Singlemodus auf die ansteigende Flanke getriggert, Pretrigger ist egal
hatte verschiedenen Werte zw. 200 nSek und 4µSek(Standart) ausprobiert.
Alle paar Messungen hat man diese negativen Spikes auf Kanal 1. Auf dem
nicht mal ein Tastkopf angeklemmt war.
Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich
habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel
Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit
wäre doch absolut ausreichend.
Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich
fände es gut wenn man die Übertragenen Dateien in einen festgelegten
Ordner speichern könnte. Im Moment ist es ja so ich lade mir eine neue
Firmware runter entpacke sie und es wird ein neues Verzeichnis erstellt,
wenn ich jetzt die dazugehörige Screenshot.exe aus diesem Verzeichnis
starte landet das Bild in diesem Verzeichnis. Beim nächsten
Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht
könnte man das Programm so gestalten das es eine Systemvariable
durchsucht und sich dort ein festgelegtes Verzeichnis ausliest.
Mit Systemvariable meine ich z.B. die Festlegung wie
temp=C:\TEMP
tmp=C:\TEMP
SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot
so wäre es egal aus welchem Verzeichnis ich die Screenshot.exe aufrufe
oder welche Version sie hat, die Shots landen immer im vorgegebenen
Verzeichnis.
Thomas O. schrieb:> Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht> könnte man das Programm so gestalten das es eine Systemvariable> durchsucht und sich dort ein festgelegtes Verzeichnis ausliest.
Hi Thomas,
mit der -f option geht das Abspeichern von Screenshot in einem festen
Verzeichnis auch ohne Systemvariable.
Beispiel für den Aufruf, um unter Windows die Dateien in C:\bilder
abzuspeichern, wäre z.B.
w2000a-screenshot.exe -a -f c:\bilder\
Gruß
Rainer
Hello,
Luc schrieb:> About this I tried with the W2012A probe in CH1 and W2022A probe in CH2> of my W2012A (screenshoot 1) and then I exchanged them in the channels> (screenshoot 2), both are set x1 so like also the DSO's channels:> W2012A's probe win on the W2022A.> The square wave is the inner DSO probe calibrator and both probes are> correctly matched.
This is especially strange because according to the
specs that came with the Welec probes, the 100 MHz and 200 MHz
versions should both have the same rise time/bandwidth on
1:1. The 200 MHz probe seems to perform poorly. I don't
have the means to fuly measure the 1:10 bandwith, but I strongly
suspect it isn't quite 200 MHz as advertised.
I don't have the Welec probes spec sheet at hand at this moment,
I will have to scan and upload it at a later time.
Niklas
Hallo,
Thomas O. schrieb:> Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich> habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel> Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit> wäre doch absolut ausreichend.
Ja, 4 Bit mit Palette waere ausreichend. Der Grund, warum das
Screenshot-Programm aus den proprietaer RLE komprimierten Daten,
die das DSO sendet, ueberhaupt BMP macht, statt das fuer diese Anwendung
praedestinierte PNG-Format, ist allein, dass dies der einfachste Weg
ist.
BMP, PPM und so weiter sind sehr einfach ohne Hinzunahme von externen
Libraries usw. zu schreiben.
Ich hab' mir nicht angesehen, in welcher Groessenordnung es
Aufwand waere 4-bittige BMPs zu schreiben, dennoch halte ich das
fuer einen Schritt zu kurz. Die Dateien waeren immer noch 150kB
gross, satte 145kB groesser als noetig. Wenn, dann sollten wir
eine Loesung ueber externe passend lizensierte Libraries suchen und
konsequent PNG schreiben.
> Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich> fände es gut wenn man die Übertragenen Dateien in einen festgelegten> Ordner speichern könnte. [..]
Wie Rainer auch schon schreibt gibt es genau dafuer den Schalter -f.
> Mit Systemvariable meine ich z.B. die Festlegung wie> temp=C:\TEMP> tmp=C:\TEMP> SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot
Systemvariablen, wie geht man da unter Windows eigentlich mit um?
Soweit ich weiss muss man da unter Windows auf "My Computer" rechts
klicken, dann "Properties", dann im neuen Fenster auf den Reiter
"Advanced" wechseln, dort dann "Environment Variables" anklicken
und im neuen Fenster kann man dann endlich den Kram setzen.
Was ich sagen will: Zu kompliziert. Angesichts dessen, dass
ich, wie schonmal angedeutet, in Zukunft plane, auch eine
Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit
den Standort dieser irgendwie global festzulegen. Unter
unixoiden Betriebssystemen ist btw. systemweit /etc und per-User
in Dotfile unter ~/ bzw. in ~/.config/ Standard.
Vorschlaege?
Niklas
Luc schrieb:> I do not know if it also happened with previous versions, I do not even> know if it happens only with my DSO.> But I have noticed that when I activate the INV's function then the> tracks suffer from a certain offset, especially in my case the CH2.
Hi Luc,
the offset of inverted signals is not specific to your DSO. To me it
looks like a gain error. The offset depends on the position of the
trace. Traces at the top don't show any offset, those at the bottom do.
I am confident Hayo will catch it.
Gruß
Rainer
Niklas O. schrieb:> Was ich sagen will: Zu kompliziert. Angesichts dessen, dass> ich, wie schonmal angedeutet, in Zukunft plane, auch eine> Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit> den Standort dieser irgendwie global festzulegen. Unter> unixoiden Betriebssystemen ist btw. systemweit /etc und per-User> in Dotfile unter ~/ bzw. in ~/.config/ Standard.
Hi Niklas,
unter Windows gibt es z.B. die vordefinierte Environmentvariable
"APPDATA" die auf das Verzeichnis "Anwendungsdaten" des Benutzers zeigt.
Mit C kommt man an den Pfad vermutlich über Aufruf von getenv("APPDATA")
dran. Die Alternative wäre ein Eintrag in der Registrierdatenbank.
Gruß
Rainer
Hi Niklas O., Rainer W. and guys all!
Niklas O. schrieb:
>This is especially strange because according to the>specs that came with the Welec probes, the 100 MHz and 200 MHz>versions should both have the same rise time/bandwidth on>1:1. The 200 MHz probe seems to perform poorly. I don't>have the means to fuly measure the 1:10 bandwith, but I strongly>suspect it isn't quite 200 MHz as advertised.
In the parallel to the 1Mohm oscilloscope input impedance there are for
example, 30pF (the value is written on the oscilloscope) and even in
parallel you still have the capacitive value of the cable (such as
another hundred of pF).
Do not put any attenuation, this total capacitive value will in parallel
with the voltage to be measured.
To reduce the capacitive load (cable + oscope), the first thing you can
think is to put an R in series, for example a 9Mohm, so the measured
circuit sees a more high impedance and the signal is divided by 10.
But this only works in DC.
In AC, the two R and two capacitors form a low pass filter that cuts to
about 1.4 Mhz.
To extend the system bandwidth (ie to put on the oscilloscope a tension
that is 1/10 of what is measured with the probe even at high frequency)
it must be put in parallel to the 9Mohm R a capacitor of 130 pF divided
by the ratio of resistors (9 in this case).
In this way a capacitor of about 15pF removes the low-pass effect and
the probe can work until at frequencies far greater (about hundreds of
megahertz).
The 9Mohm R and the compensation capacitor are in the probe.
To fix the exact capacitive ratio's values (which must be equal to that
of the resistors), need somewhere to put a small variable capacitor with
which to calibrate the tolerances that may to exist.
If instead of divide by 10 should be divided by 100, the values become
99Mohm and 1.5 pF: this explains why often the probes that go (were) to
more high frequency had an attenuation of 100:1 and so why the x1 probes
have a frequency response limited compared to the x10 probes.
Said that, perhaps the behavior of the W2022A probes is caused from an
incorrect setting of the second trimmer.
In fact, according to the instructions of my analog oscilloscope probes
(they are x10 probes with a 300Mhz bandwidth), they must be tuned by a
1Khz and 1Mhz square wave with not more than 4ns's rise time.
In my case the problem may depend on this but I must investigate
further.
I will try to use the W2022A probes that are credited as 200Mhz
bandwidth on my 150Mhz analog oscilloscope who is provided with 300Mhz
probes and which has a suitable calibrator for calibration.
However, the probes provided by Welec / Wittig with the W2012A are the
same as those provided by LeCroy with its WaveAce series DSO.
I'm sure because I use them where I work.
Niklas O. schrieb:
>I don't have the Welec probes spec sheet at hand at this moment,>I will have to scan and upload it at a later time.
Me too I have not the data sheet handy.
I think it would be useful and interesting.
Thanks in advance Niklas O.
Rainer W. schrieb:
>the offset of inverted signals is not specific to your DSO. To me it>looks like a gain error. The offset depends on the position of the>trace. Traces at the top don't show any offset, those at the bottom do.>I am confident Hayo will catch it.
Thank You very much for the useful information and explanation Rainer
W.!
I hope someone can fix the problem.
Vielen Dank!!!
Gruß Luc
Hello Luc,
the entire "operator's manual" for the probes is attached. According
to it, the rise time on x1 should be 23.3ns for both types of probes.
> Said that, perhaps the behavior of the W2022A probes is caused from an> incorrect setting of the second trimmer.
Since there's no description how to use those I never touched them.
(I've got two seperate ones in the box near the BNC.)
The attached manual contradicts itself, it mentions that the
input capacitance can be compensated "Within the box cover located
near the BNC (W202 Probe)", but on the next page under
"Compensation and Adjusting the Probe" it explicitly tells to
compensate with the trimmer on the body of the probe. It fails
to mention that the probe needs to be put into 1:10 divider.
Niklas
Hi Luc,
the INV-offset is the result of the combination of the DAC-scale factor
and screen drawing scale factor. It has to be adjusted more precisely.
But this is not so easy because of thermal drift and differences between
the DSOs.
If You want to measure precisely You have to center the trace in the
screen middle. In this positon there are no offsets because it is the
virtual zero.
Regards Hayo
@Niklas
Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot:
Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die
aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht
implementiert.
Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern
in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine
recht schnelle Sache.
Man müßte nur das Flag mit if (USTB_Mode != USTB_OFF) abfragen und dann
anstatt des normalen Signalspeichers den USTB-Speicher übertragen.
Die übertragene Länge wird jetzt ja schon zwischen 4K und 16K
unterschieden. Käme noch 600 hinzu.
Was sagst Du?
Gruß Hayo
Hallo Hayo,
Hayo W. schrieb:> Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot:>> Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die> aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht> implementiert.>> Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern> in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine> recht schnelle Sache.> [..]> Was sagst Du?
Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die
Aufnahme ueber noch laengere Zeitraeume interessant, also sowas
was ein Trace Recorder macht. Es gibt da z.B. Leute die ueber
Tage hinweg Daten von einer Heizungsregelung loggen. Bei einem
4-Kanal Geraet kann das durchaus schon interessant sein.
Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme
an die 600 Werte sind im Moment zugleich das Maximum was gespeichert
werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue
Werte ueberschrieben?
Hier koennte man zum einen die Werte direkt "Realtime" mit dem
Screenshot-Programm aufzeichnen lassen, zum anderen muesste doch
auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen
im Flash abzulegen und am Ende abzurufen?
Mein Plan sieht nun wie folgt aus:
- zunaechst Flash-Upload-Programm fuer Windows erstellen mit
minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich
nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen
erweitert werden
- im Screenshot-Programm:
- kontinuierliches Loggen von den Measurement-Daten
- USTB-Speicher download
- Evaluation bzgl. direktes Speichern als PNG
- Dokumentation Uebertragungs-Protokolle
(in absteigender Prioritaet)
Niklas
Niklas O. schrieb:> zunaechst Flash-Upload-Programm fuer Windows erstellen mit> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen> erweitert werden
Warum war der Welec Updater so langsam, kann man den nicht
beschleunigen?
Niklas O. schrieb:> - Evaluation bzgl. direktes Speichern als PNG
Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei
BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
ja wenn die Konfigurationsdatei global festgelegt wird wäre das super.
Sonst muss man immer die config.ini vom alten ins neue
Screenshot-Verzeichniss verschieben oder die Screenshot.bat jedesmal um
das eigene Verzeichniss ergänzen. Es wäre wünschenswert diese Globale
festlegung ändern zu können da nicht jeder mit den Standart APPDATA
Verzeichnissen arbeiten. Meine Eigenen Dateien sitzen z.B. auf einem
2ten Laufwerk.
Niklas O. schrieb:> - Evaluation bzgl. direktes Speichern als PNG
Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng
Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich,
um direkt die PNGs abzuspeichern.
http://netpbm.sourceforge.net/
Gruß
Rainer
Kurt Bohnen schrieb:> Niklas O. schrieb:>> zunaechst Flash-Upload-Programm fuer Windows erstellen mit>> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich>> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen>> erweitert werden> Warum war der Welec Updater so langsam, kann man den nicht> beschleunigen?
Wir sprechen doch von dem Ding der Wittigs, oder?
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload
Da steht auch was von 25 Minuten. Ich hab' das Wittig-Ding
zuletzt Anfang 2009 oder so gearbeitet, also kurz nachdem
ich mein Scope bekam.
Haben wir davon ueberhaupt den Sourcecode?
> Niklas O. schrieb:>> - Evaluation bzgl. direktes Speichern als PNG> Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei> BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
Ja, das habe ich mir auch noch nicht angesehen. Ich weiss nicht,
wie effizient die wirklich ist. Ein kurzer Versuch in Gimp mit
Reduzierung auf 16 Farben Palette und RLE zugeschaltet bringt mir
ein File mit 36kB Groesse. Ob das noch mit zu rechtfertigem
Aufwand zu Fuss gemacht werden kann, oder man da besser eine
externe Library nimmt, muss ich schauen.
Notieren wir also mal "Evaluation BMP mit optimierter Palette u. RLE"
in meine ToDo-Liste.
Niklas
Thomas O. schrieb:> ja wenn die Konfigurationsdatei global festgelegt wird wäre das super.> Sonst muss man immer die config.ini vom alten ins neue> Screenshot-Verzeichniss verschieben
Hi Thomas
man kann doch einfach eine Batch-Datei irgendwo ablegen, in der eine
einzige Zeile mit dem aktuellen Screenshot Programmverzeichnis und dem
Bilderverzeichnis drinstehen, ohne irgendetwas zu verschieben und zu
kopieren, z.B.
"C:\Programme\Screenshot-0.97\w2000a-screenshot.exe" -a -f C:\Bilder\
IMO ist man damit flexibler, da man sich für jeden Zweck eine passende
Start-Datei zurechtlegen kann.
Rainer W. schrieb:> Niklas O. schrieb:>> - Evaluation bzgl. direktes Speichern als PNG> Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng> Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich,> um direkt die PNGs abzuspeichern.> http://netpbm.sourceforge.net/
Ja, kenne ich (hab' ich glaub' ich auch in der README.txt
empfohlen zur Konvertierung ;)), jedoch bislang nur mit den
Kommandozeilen-Tools gearbeitet.
Niklas
im Moment sieht es bei mir z.B. so aus
E:\Treiber\Welec\1.2.BF.3.0_C5\Screenshot_0.97
davor war es
E:\Treiber\Welec\1.2.BF.3.0_C2\Screenshot_0.97
und da man ja immer die neueste/dazugehörige Screenshot.exe nutzen will
startet man die Scrennshot.exe aus dem neuerem Verzeichniss.
Oder evtl. wirds ja mal E:\Treiber\Welec\1.2.BF.3.0_C6\Screenshot_0.98
und dann darf man jedesmal die .bat Datei anpassen.
Deswegen würde ich mir wünschen das jede zukünftige Screenshot.exe sich
am gleichem Punkt im System die gewünschten Einstellungen holt.
Hat nichts mit faul zu tun sondern eher mit Comfort das man nicht immer
alles anpassen muss.
Was sagen denn die anderen dazu, vielleicht gibt es ja bessere
Vorschläge das ganze zu lösen.
Mein Ansatz war, die aufrufende(n) Batch-Datei(en) an einem festen Ort
stehen zu haben, so dass man bei irgendwelchen Updates mit dem
Verzeichnis der neuen Version gar nicht weiter in Berührung kommt,
sondern nur einmal den Programmpfad in der Batch-Datei anpassen muß.
Wenn das Bilderverzeichnis an einer festen Stelle im System liegt,
verbaut man sich den Weg zu projektbezogenen Speicherorten und ist dann
bei jedem Screenshot am rumschieben. Es ist halt die Frage, ob man öfter
Screenshots macht oder öfter Updates vom Programm einspielt.
Gruß
Rainer
Hallo zusammen,
wie wäre es denn, das Screenshot-Programm zuerst nach einer ini-Datei
z.B. in "Eigene Dateien" (bzw. $HOME) suchen zu lassen und die Parameter
dahin zu verlegen. Wenn es da keine passende ini-Datei gibt, sucht man
noch im lokalen Verzeichnis (des Programms) und Vorrang haben immer die
mitgegebenen Parameter. Damit kann man z.B. die exe auch per Doppelklick
aufrufen und die Einstellungen bleiben unabhängig von der Version
gleich.
Viele Grüße,
Rainer
Hallo,
(sitz' im Zug und habe keine Zugangsdaten, daher Post als Gast)
Kurt Bohnen schrieb:> Niklas O. schrieb:>> Wir sprechen doch von dem Ding der Wittigs, oder?>>>> http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload>> Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232.> Sourcecode haben wir auch:> http://sourceforge.net/apps/trac/welecw2000a/brows...
Okay. Da gibt's dann das Problem dass ich weder Pascal
beherrsche noch die Entwicklungsumgebung dafuer habe.
Wie sieht es jetzt aus? Reicht uns das Programm, moechte
vllt. jemand anderes sich dem annehmen der entsprechende
Moeglichkeiten besitzt, oder soll dennoch ein weiteres
Upload-Programm her?
Niklas
Niklas O. schrieb:> Hallo Hayo,> Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die> Aufnahme ueber noch laengere Zeitraeume interessant, also sowas> was ein Trace Recorder macht.
Ja das ist machbar.
> Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme> an die 600 Werte sind im Moment zugleich das Maximum was gespeichert> werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue> Werte ueberschrieben?
Nein, es ist nicht das Maximum und auch nicht hart verdrahtet. Die
USTB-Funktion ist ja eine reine Softwarefunktion die ich nachgerüstet
habe.
Zur Zeit steht ein 1200 Byte Buffer pro Kanal zur Verfügung von dem aber
nur 600 Byte genutzt werden. Ich könnte aber auch deutlich mehr zur
Verfügung stellen. Ich hatte auch schon überlegt ob es Sinn macht dass
man durch den Speicher scrollen kann (so wie in den normalen TB)
> Hier koennte man zum einen die Werte direkt "Realtime" mit dem> Screenshot-Programm aufzeichnen lassen,
Ja, ist auch eine Möglichkeit, jeden Abtastwert einzeln zu übertragen um
eine Langzeitmessung zu realisieren.
> zum anderen muesste doch> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen> im Flash abzulegen und am Ende abzurufen?
Ebenfalls eine Möglichkeit...
Platz ist im Flash noch genügend vorhanden!
Gruß Hayo
Hi Niklas O., Rainer W., Hayo and guys all!
Niklas O. schrieb:
>the entire "operator's manual" for the probes is attached.
Thank You Niklas O., at this time my DSO packaging is not handy.
The document is very interesting.
Niklas O. schrieb:
>According to it, the rise time on x1 should be 23.3ns for>both types of probes.
I had forgotten these values.
23.3nS means something like a 15MHz bandwidth, seem to me quite
optimistic.
Even more curious the x10 values where the bandwidth is precisely 100MHz
and 200MHz just like the W2012A and W2022A to which the probes are
provided with.
For the W201 I'm sure it is very similar or the same Chinese
manufactured probe supplied by LeCroy DSO with its WaveAve 224 model
DSO.
The model provided by LeCroy is called PP016 and it is claimed as a
300MHz probe.
The only visual difference between the W201 and PP016 is a sticker label
on the latter where it says the 300MHz bandwidth.
The PP016 is not a good probe, it is quite fragile, often it breaks even
though it is always handled with care: where I work has happened twice
within the first month of use.
I have to make checks.
Niklas O. schrieb:
>Since there's no description how to use those I never touched them.>(I've got two seperate ones in the box near the BNC.)
About the second capacitor on the W2022A probe, I know for a fine
adjustment I must set two capacitor for RF compensation with my analog
oscilloscope's probes.
These two capacitors are on BNC plug, a third capacitor is located on
the probe body and it is for the LF compensation.
The probes adjustment need a 1KHz and 1MHz square wave with a rise time
no more than 4nS and it is done in this way:
1) Connect probe to a 1 kHz square wave signal and adjust LF
compensation trimmer for optimum square wave response.
2) Connect probe to a 1 MHz square wave signal and adjust HF
compensation trimmer(s) for optimum square wave response.
I guess also with W202 Welec's probes is the same.
I have to check.
Unfortunately my oscilloscope analog probes are fixed at x10 and can not
be switched to x1.
However I have other probes switchable x1 and x10.
I was also thinking of building a pulse generator with rise and fall
times of about 300ps.
With an such instrument would be simple to evaluate the probes
bandwidth.
It could also be used to assess the bandwidth of W201xA and W202xA DSO
without worrying too much about the linearity lack of the front-end,
thing that makes hard performing a such measure in the Welec DSO.
But perhaps this is not a suitable place for this because there is a
"hardware section", so apologize me.
Niklas O. schrieb:
>The attached manual contradicts itself, it mentions that the>input capacitance can be compensated "Within the box cover located>near the BNC (W202 Probe)", but on the next page under>"Compensation and Adjusting the Probe" it explicitly tells to>compensate with the trimmer on the body of the probe.
The welec's manuals are always a little foggy. ;-)
Niklas O. schrieb:
>It fails to mention that the probe needs to be put into 1:10 divider.
This is really a serious lack!
But who is not a newbie should know it.
@Hayo.
Very well Hayo, thank You very much for the kindly explanation.
Now with the Rainer W.'s help and your help I understand how it works
and I know there is a way to avoid it.
I understand is not so easy to fix the problem due the thermal drift and
differences between the DSOs, but now I know a simple way to avoid it.
I can say the problem is gone for me, so thanks very much to Rainer W.
and You Hayo: RESPECT!!!
Vielen Dank!!!
Gruß Luc
@Niklas
Bau mal noch nichts um im Screenshot. Ich habe mir was überlegt wie ich
den USTB-Betrieb etwas "aufbohren" kann und den 16K Signalspeicher
nutzen kann. Und der wird ja schon übertragen.
Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu
scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie
schnell ich das eingebaut kriege.
Gruß Hayo
Kurzer Tipp an alle die Windows 7 64 Bit einsetzen:
Dieser USB- Seriell Adapter funktioniert einwandfrei und auch die
Screenshot- Funktion läuft damit super:
http://www.amazon.de/gp/product/B003AVQ00A/ Digitus DA-70156
Da ich mir selber einen abgesucht habe bis ich einen Adapter gefunden
wurde der unter W7 gut läuft denke ich dass das dem einen oder anderen
nützlich sein könnte.
Hallo zusammen,
Hayo W. schrieb:>> zum anderen muesste doch>> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen>> im Flash abzulegen und am Ende abzurufen?>> Ebenfalls eine Möglichkeit...>> Platz ist im Flash noch genügend vorhanden!>> Gruß Hayo
Haupsache es bleibt noch genügend Platz im Flash für Save und Restore
der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal
wieder an einem PC vorbei komme :-)
Gruß Jürgen
Hi,
> Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active> Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die> Einstellungen für die 24 u. oder 33 Ohmler?
mein Anfrage ist wohl etwas unter gegangen?!?
---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.---
Gruß Michael
Jürgen schrieb:> Haupsache es bleibt noch genügend Platz im Flash für Save und Restore> der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal> wieder an einem PC vorbei komme :-)
Keine Sorge,
die haben Ihre eigenen reservierten Segmente. Es sind aber noch einige
64K Segmente frei.
Gruß Hayo
Michael D. schrieb:>> ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.---
Ist einfach nur eine Bezeichnung, mir fiel nichts Besseres ein. Es sind
einfach nur vier verschiedene Kalibriersets die man auswählen kann. Die
ersten Beiden habe ich einfach mal Standard und Active Probe genannt.
Es ist einfach nur so, dass die Kalibierung unter dem gerade
eingestellten Set abgespeichert wird. Man kann auch eine kalt/warm
Kalibrierung abspeichern oder eine mit einem vorher auf den Eingang
gelegten DC-Offset, was auch immer. Mann kann dann ohne neue
Kalibrierung zwischen den Werten hin und herschalten. Du kannst auch als
Standardkalibrierung Set 3 verwenden, das ist echt egal.
Ich habe bei mir auf allen 4 Sets die normale Kalibrierung drauf, damit
ich da nicht versehentlich falsche Werte eingestellt habe.
Gruß Hayo
Hi Niklas O. and guys all!
@Niklas O.
About the W2022A's probe, I will be brief because this is not the right
place.
I did the tests and in the x1 position the rise time is about 30nS
(10MHz bandwidth) while the rise time is about 15nS (about 20MHz
bandwidth) with the W2012A's probe.
In the x10 position the W2012A's probes are like my 250MHz Hameg's
probes, so about 200MHz bandwidth.
Instead in the x10 position the W2022A probes are best of my 250MHz
probes by Hameg, they have better rise and fall time response, so they
are a 200MHz probes for sure.
The W2022A probes are optimized to high frequencies work and W2012A
probes for low frequencies.
The W201 probes by Welec/Wittig and PP016 probes by LeCroy are the same,
same rise and fall time.
LeCroy claim they like a 300MHz bandwidth probes, their performances are
same of my 250MHz bandwidth probes by Hameg, so no bad.
But W202's probes for the W2022A are better than both PP016 and W201,
great!
Vielen Dank!!!
Gruß Luc
Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-(
Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch
für Linux anbieten.
Viele Grüße
Mit TomCat.ram getestet.
* Opening COM1 (115200,8,N,1)... success
* Asking the user to put the DSO into GERMS loader, if not already
done...
* Uploading firmware to DSO
- @line 134 |writing to DSO| |reading response|
Bis dahin funktionierte es bei mir, dann hängt er sich auf.
Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
Hallo nochmal,
Hayo W. schrieb:> @Niklas> [16K Samples fuer UTSB]> Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu> scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie> schnell ich das eingebaut kriege.
Das klingt doch gut!
@Luc:
Thank you kindly for your explanations and tests! It is good
to know that the W202 probes actually are usable for high
frequency.
stone schrieb:> [..]> - @line 134 |writing to DSO| |reading response|>> Bis dahin funktionierte es bei mir, dann hängt er sich auf.> Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
Du warst der mit den Uebertragungsproblemen, oder?
Ich hab' da noch kein Timeout eingebaut und keine erneuten
Uebertragungsversuche wie (ich glaube) der GERMSloader.pl macht,
auch fange ich Schreibfehler nicht ab. Bei Dir wartet das Programm
nach Uebertragung von Zeile 134 auf das '+' von GERMS. Wenn da
100% CPU Usage sein sollten liegt das daran das ich da noch die
ComTools.cpp nutze (wie das Screenshot-Programm unter Windows auch)
was nur Polling kann (in ner Schleife dauernd fragen "ist jetzt was
da?").
Ich wuerd' daher noch gerne Berichte von anderen hoeren.
(Selber testen kann ich nicht weil ich keinen Windows-Rechner
mit serieller Schnittstelle habe und jegliche USB-seriell-Wandler
die ich habe nicht unter Windows tun (oder ich stelle mich zu bloed an).
Fritz Richter schrieb:> Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-(> Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch> für Linux anbieten.
Haettest Dich vorher melden sollen dass Du auch was vorhast,
dann haette ich mir das Suchen in MSDN heute Nachmittag sparen
koennen :)
Bei einer kurzen Suche zu Deinem Namen hab' ich diesen
interessanten Beitrag von 2009 gefunden:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Hast Du das danach noch weiter verfolgt?
Bei Deinem Programm koenntest Du noch einbauen dass es
in der Dropdown-Liste nur Ports anzeigt die auch existieren,
zudem kann der Fall dass ein Port existiert aber schon
durch ein anderes Programm geoeffnet ist abgefangen werden
und evtl. entsprechend angezeigt.
Womit hast Du das entwickelt, btw.? Wundert mich gerade
warum es so gross ist.
Wenn Du Lust/Zeit/Interesse hast koenntest Du eine GUI
fuer das Screenshot-Programm machen. Die Core-Funktionalitaet
wollten wir eh ausgliedern. GUI bzw. Konsolen-Variante wuerden
dann auf entsprechende C-Funktionen zugreifen die dann
Trace, Screenshot, usw. liefern.
Niklas
Niklas O. schrieb:> Schaut mal ob das funktioniert.
Hallo Niklas,
die Übertragung einer .ram unter WinXP SP3 über einen Prolific
USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert.
Gruß
Rainer
Niklas O. schrieb:> Bei einer kurzen Suche zu Deinem Namen hab' ich diesen> interessanten Beitrag von 2009 gefunden:> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"> Hast Du das danach noch weiter verfolgt?>> Bei Deinem Programm koenntest Du noch einbauen dass es> in der Dropdown-Liste nur Ports anzeigt die auch existieren,> zudem kann der Fall dass ein Port existiert aber schon> durch ein anderes Programm geoeffnet ist abgefangen werden> und evtl. entsprechend angezeigt.>> Womit hast Du das entwickelt, btw.? Wundert mich gerade> warum es so gross ist.
Du meinst das USB?
Ich war damals ziemlich entsetzt über die erreichbare Geschwindigkeit,
es war deutlich langsamer als seriell, deshalb hatte ich es erstmal
frustriert sein gelassen.
Deinen Vorschlag mit den existierenden Comports habe ich noch eingebaut.
Programmiert habe ich das mit Delphi, weil ich gerade nix anderes zur
Hand hatte, deshalb wahrscheinlich die Größe.
Hi Niklas,
> Hallo Niklas,> die Übertragung einer .ram unter WinXP SP3 über einen Prolific> USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert.> Gruß> Rainer
...dito,
habe das Teil von HAMA mit dem FTDI drinnen, funzt wunderbar und es gibt
kein gezicke!
Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in
Sekunden, wie es beim Germsloader der Fall ist?!?
Gruß Michael
Hallo!
Mich würde mal interessieren, was es beim NIOS Design für
Debugmöglichkeiten gibt.
Ich bin in der Firma zufällig beim RTEMS Betriebssystem auf einen gdb
Stub gestossen und überlege, dass ich den gdb stub und RTEMS für das
LEON3-Zeug benutzen werde. Falls es was besseres oder einfacheres beim
NOIS Design gibt, wäre ich dem gegeüber auch sehr offen.
Übrigens scheint das Changelog im Trac nicht mehr ganz am neuesten Stand
zu sein.
MfG
Alexander
Hallo Nochmal!
Ich habe jetzt mein zweites Preview Version 1.1 auf im Sourceforge zum
Download bereit gestellt.
Das Ausprobieren ist gefahrlos, da ich den FLASH-Speicher nicht benutze
oder verändern kann. Nach dem man das Gerät komplett Ausgeschalten hat,
ist alles wieder wie es vorher war.
Ausprobieren auf eigene Gefahr (, die es praktisch nicht gibt)!
Das FPGA-Design ist jetzt schon in einem sehr brauchbaren Zustand.
Die Firmware ist hingegen noch in einen sehr frühen Stadium und für den
normalen Einsatz nur bedingt geeignett.
http://sourceforge.net/projects/welecw2000a/files/LEON3%20FPGA%20Design/Previews/
Dennoch bietet sie eine GUI, manuelles Einstellen der Zeitbasen, der
analogen Spannungsbereiche, und es kann der DAC-Offset analog
eingestellt werden.
Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro
Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design.
Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle.
Die Sprünge der Offsets bei den 5er,2er und 1er sind durch das analoge
Frontend bedingt und fehlen hier noch im Gegensatz zu der Firmware für
den Nios Softcore.
Im AUTO Trigger Mode ist die Bildwiderholrate langsam, falls nichts zum
Triggern gefunden wurde.
Die Spannungsverstärkung ist auch noch nicht kalibriert.
MfG
Alexander
Gute Sonntag an alle und Niklas O.
Niklas O. schrieb:
>anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows.>Schaut mal ob das funktioniert.
Niklas, thank You very much for the masterpiece and free time You kindly
provides to us: RESPECT!!!
I have tried your software and it works like a charms both through
direct serial connection than via MANHATTAN's usb to serial converter.
My equipment are:
computer Pentium IV@3GHz with operating system Windows XP Home Edition
SP3 and hardware version 8C7.0.C of W2022A's model DSO.
Through a usb to serial converter it is little slower than direct serial
connection, but this even with Perl Script, so it is normal.
I do not want to appear rude and I do not want to criticize your
excellent work, but I would say that the software is very detailed in
describing the operations to be done but it not warn you when it ended
(the Perl Script at the end thank for the fishes so the user understands
the operations are successfully completed).
Repeat, this my reporting is not intended as a criticism but it is
simply for knowledge, so apologize me.
Niklas O. RESPECT!
Vielen Dank!!!
Gruß Luc
Wow, is ja Wahnsinn, was sich inzwischen überall getan hat.
Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und
Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das
Leon-Design selber hat ja ein unglaubliches Potenzial!!!
Als reiner Nutzniesser noch einmal einen besten Dank an alle. Ist schon
echt klasse, dass das Welec jetzt inzwischen voll brauchbar ist und mit
dem Leon Design sogar noch Best-Of-Class werden könnte (mal vom analogen
Teil abgesehen).
Michael
Hallo,
Michael D. schrieb:> Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in> Sekunden, wie es beim Germsloader der Fall ist?!?
Jupp. Baue ich noch ein.
Luc schrieb:> [..] but I would say that the software is very detailed in> describing the operations to be done but it not warn you when it ended> (the Perl Script at the end thank for the fishes so the user understands> the operations are successfully completed).
Yes. It will open a MessageBox saying that the operation is finished
but I forgot to write that info on the console, too.
Michael schrieb:> Wow, is ja Wahnsinn, was sich inzwischen überall getan hat.>> Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und> Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das> Leon-Design selber hat ja ein unglaubliches Potenzial!!!
Ich stimme zu, allerdings glaub' ich nicht, dass wir da an ein
"Portieren"
der Firmware denken koennen. Ganz abgesehen vom unterschiedlichen
FPGA-Design ist da immer noch jede Menge Furcht erregende Altlast drin.
Ich finde aber, dass es nun an der Zeit ist mitzuwirken und die GUI
aufzubauen. Da ich ein 4-Kaeneler habe muss ich zum Ausprobieren
des Leon-Designs nochmal auf und Front ab und Loetbruecke rein. Ich
hoffe ich komme mal die naechste Zeit endlich dazu.
alex008 schrieb:> Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro> Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design.
Mhm, nur 8kSa?
> Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle.
Im FPGA-Design generell oder nur in der Firmware?
Niklas
Hallo Niklas!
Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie
ist auf 2 Kanäle mit 16 Bit Daten eingestellt.
Falls man auf 8 Bit, 1 Kanal umstellt hat man 32kSamples. Mehr geht
nicht, da der Cyclone II "nur" ca. 56 kByte zu Verfügung hat, und der
LEON3 mit seinen Registerwindows und seinem Cache auch eine ganze Menge
an RAM-Blöcken braucht.
Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so
viele FPGAs (2 statt 1) nutzt.
Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei
unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt.
Des weiteren ist der Messdatenpuffer auf den Roll-Mode ausgelegt, jedoch
wird das von der Firmware noch nicht unterstützt. Ein entsprechender
DMA, mit dem 20MSamples/sec beim Roll-Mode theoretisch möglich sind, ist
im FPGA-Design angedacht, aber noch nicht drinnen.
MfG
Alexander
alex008 schrieb:> Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie> ist auf 2 Kanäle mit 16 Bit Daten eingestellt.
Wie machst Du das mit den 16 Bit?
> Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so> viele FPGAs (2 statt 1) nutzt.
Habe ich das richtig mitgekriegt, dass Kanal 3 + 4 zur Zeit FPGA-seitig
noch nicht unterstützt werden?
> Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei> unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt.
Vor allem gibt es aus unbekannten Gründen einen ziemlichen Sprung
zwischen 25MSa und 250MSa was ziemlich unpraktisch ist. da die
dazwischenliegenden Samplingraten auf Kosten der effektiven
Speichertiefe geht.
@Niklas
Die effektive Speichertiefe ist beim NIOS-Design nur bei <=50ns/div
16KB. Bei den anderen Zeitbasen sorgt der Zoomfaktor dafür, dass nur ein
Teil der 16KB bzw. 4KB im normalen Betrieb genutzt werden.
Dafür stehen die ungenutzten Werte im Stopmodus und im Delayedmodus für
weitere (schnellere) Zeitbasen zur Verfügung.
Gruß Hayo
Alex, klasse! Das sieht ja schon richtig gut aus.
Wir müssen dem Alex mal einen 4Kanäler sponsorn...
Vorher wird das mit mir und der Leon-Firmware nix. Ich würde echt gern
selber dran mitarbeiten, aber mir fehlt die Zeit.
Nur am Rande, bestimmt hatte schon mal jemand die Idee, ich frage
trotzdem: Wäre es eigentlich möglich, aus dem Welec ein DPO (statt
momentan DSO) zu bauen? Also eines was kontinuierlich abtastet und in
der Kurvendarstellung statt Einzelwerten entsprechend breitere
Verteilung anzeigt? Ich habe zugegeben noch nicht mit sowas gearbeitet,
fände ein "analogeres" Feeling gut. Derzeit nehme ich fast immer mein
Hameg statt dem Welec, da weiß ich was ich sehe, falle nicht auf
Unterabtast-Artefakte rein.
Jörg
ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte
mal fragen ob sich das vielleicht auch integrieren lässt.
1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1,
2, 3 oder 4 auftritt.
2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals
steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
Hi Niklas O., alex008, Hayo and guys all!
Niklas O. schrieb:
>Yes. It will open a MessageBox saying that the operation is finished>but I forgot to write that info on the console, too.
Niklas O., thanks so much for your kind explanation!
@alex008
Alex008, really very impressive your work who it also make user friendly
the approach to the LEON 3 Design: RESPECT!!!
I will try to explore the question, thank You very much Alex008 and all
who are involved with the LEON 3 NIOS design: again RESPECT!!!
@all who can answer
I update my W2022A to the latest 1.2.BF.3.0_C5 firmware revision and
with it I experimented the spikes problem, this is known as spikes that
affect both channels simultaneously.
Now with the same software release on mine friend's W2012A it seems less
noisy, as I already written, and no spikes problem.
Instead my W2022A seems to me less noisy also, but there is the spikes
problem I never seen before on my W2022A.
Normally I could set "Factory" or "Hi Frequency" in the hardware menu
without problem, now only "TEST 5" give some improvement but do not
entirely eliminate the problem.
So I ask myself:
My W2022A is hardware version 8C7.0C while my friend's W2012A is
hardware version 8C7.0B, but what the difference is?
Could this be the cause of the problem?
And what means 8C7.0C, 8C7.0B, 8C7.0L, 8C7.0G and so?
Are they perhaps the NIOS revision?
I know Hayo have W2022A hardware version 8C7.0G or 8C7.0L
(http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument), so
He test firmware with it and due the differences between the DSOs I
understand is not so easy for He to release a firmware that will work on
all W202XA and W201XA Welec's revisions, although he usually succeeds in
this.
@Hayo
Hardware's menu settings are used to eliminate ringing problems plaguing
some Welec's DSO, precisely the spikes's problems.
Broadly, what are the affected parameters?
I mean the inside firmware parameters to be adjusted to eliminate the
spikes
Vielen Dank!!!
Gruß Luc
Hallo Hayo,
eine Frage zur FFT:
Im Zeitbereich schaltet ja zwischen "Ablenkgeschwindigkeit" 5 us/div und
10 us/div die Abtastrate zwischen 250 MSa/s und 25 MSa/s um. In der FFT
springt dann die Frequenzskala direkt von 15.62 MHz/div auf 1,56
Mhz/div. Aus der Abtastung ergibt sich natürlich dieser Sprung, aber für
die Ablesung wäre es manchmal gut, ggf. per Zoom Zwischenwerte
einstellen zu können. Habe ich da etwas übersehen oder geht das (noch?)
nicht?
Gruß
Rainer
@Luc
The hardware version consists of three single values:
tc_hw_version, tc_production_lot1, tc_production_lot2
Only 8C7 (tc_hw_version)is the real hardware version! This value is read
from the FPGA. The values after the dot are stored in the protected
flash (tc_production_lot1, tc_production_lot2). This are values which
where set by WELEC while programming the flash.
Maybe the values after dot are not correct in my W2022A because I
restored my flash after an upload crash from another DSO (I think is was
from Falk).
Do You have a screenshot of Your spike problem?
Regards
Hayo
Hi Hayo, Niklas O. and guys all!
Hayo W. schrieb:
>Only 8C7 (tc_hw_version)is the real hardware version!
Hayo as always You are very kind!
I thank You very much for the explanation and for your patience!
Hayo, You are great!
So ultimately be always the same review worked at different times
without substantially differences.
For me this is very interesting, thank You Hayo!
Hayo W. schrieb:
>Maybe the values after dot are not correct in my W2022A because I>restored my flash after an upload crash from another DSO
Well Hayo, but the batch is not relevant if there are not other
differences.
If I understand correctly means that comparing different hardware
revisions the only difference is related with the production batches
fields.
Is this correct?
This means uploading an hardware revision rather than another in the DSO
make no difference.
Certainly when the LEON 3 design will be implemented in full there will
be a standard environment that perhaps will help the compatibility
between the different DSO, this I think.
Hayo W. schrieb:
>Do You have a screenshot of Your spike problem?
Hayo, spikes are very fast and random, very difficult to capture.
I unable to get it directly, so in order to capture they I had to enable
the persistence of the display.
The result is visible in the two attached screenshots named Spike1.jpg
and Spike2.jpg.
However, I noticed my W2022A has a bit crazy behavior.
AUTOSCALE do not work correctly, the AUTOSCALE_probe.jpg pic show the
result of the function with the signal for the probes compensation: very
crazy!
Other pics show the behavior without signal on CH1 and CH2: also very
strange.
@Niklas O., @Hayo
I tried to reload the same firmware via Perl Script but I have not
solved the problems.
I had updated the W2022A using the fwupload.exe software released by
Niklas O.
Now,
Niklas O. schrieb:
>Yes. It will open a MessageBox saying that the operation is finished>but I forgot to write that info on the console, too.
But when I upgrade I have no get the message, so I wrote:
Luc schrieb:
> [..] but I would say that the software is very detailed in> describing the operations to be done but it not warn you when it ended> (the Perl Script at the end thank for the fishes so the user understands> the operations are successfully completed).
So, might be this related?
I would like to make it clear that I do not write these things to blame
Niklas O. or others for what happens to me but only for knowledge
because this maybe can help to prevent a recurrence of the problem also
to other.
I am sure that Niklas O. has done a great job and I thank him again for
the amazing fwupload.exe software and for free time He kindly provides
to us, Niklas O. RESPECT!!!
I hope not to seem rude and above all not be misinterpreted.
I even do not expect a solution, I will only document the fact.
Repeat this is for knowledge, I do not write these things to blame
Niklas O. or others but only because this maybe can help to prevent a
recurrence of the problem also to other.
I hope all You understand what I mean, what I want to say.
However, I'm sure I can certainly solve by loading a previous revision
of the Hayo's firmware, so really no problem for me, I do not think my
W2022A was permanently ruined ! :-)
Vielen Dank!!!
Gruß Luc
Hi, bin grad (Ihr ahnt es schon) vom Griechen zurück, diesmal allerdings
zwecks 10. Hochzeitstag. Trotzdem ist noch kurz Zeit für eine Antwort
(ist halt die beste aller Ehefrauen!).
@Rainer
Es gibt leider (aus unerfindlichen Gründen) einen Sprung zwischen 250MSa
und 25MSa. Das Ganze wird im laufenden Betrieb durch den Zoomfaktor
zwischen 10 und 25 kaschiert. Das ist natürlich suboptimal. Ich habe
auch schon mit diversen Registerwerten experimentiert, aber ohne Erfolg.
Anscheinend haben die Jungs (Wittigs) es voll vergeigt! Die einzige
Abhilfe die mir da so in den Sinn kommt ist das LEON3 Design. Mit dem
NIOS Design läßt sich da wohl wenig ändern.
Gute Nacht
Hayo
Hallo!
Ich habe eine mögliche Erklärung zu den unterschiedlichen Speichertiefen
bei den verschiedenen Samplingraten im NIOS Design.
Es scheint mir so, dass beim NOIS Design jeder ADC einen Puffer von 4 kB
oder 4 kSamples hat.
Bei 500 MS/s werden nur 2 ADCs benutzt, weshalb auch nur 2*4 kB Speicher
zur Verfügung stehen.
Bei 250 MS/s wird nur ein 4kB Speicher benutzt.
Um nun die 1,2,4,10, ... Teilung zu schaffen, ohne dass der vertikale
Gridabstand verändert wird, muss wenn nur ein 4kB Speicher verwendet
wird, die erste Teilung einen Faktor 10 aufweisen.
250MS/s / 2,5 Samples = 100MS/s geht nicht mit Samples verwerfen, die
das NIOS Design sicher nicht hat.
Möglicherweise gibt es auch die 50MS/s Teilung nicht, da der 4kB
Speicher mit hoher Warscheinlichkeit mit 16 Bit @ 125 MHz beschrieben
wird, und das dem FPGA-Entwickler zu schwierig oder zu aufwendig war.
Im Unterschied hat das LEON3 design einen 32 kB Puffer, welcher nach der
Dezimierung mit oder ohne HW-Filter ist, und kein einziges Sample Jitter
auf irgendein Triggerevent hat.
@LUC
To be shure you do not have a hardware fault (soldering) try the LEON3
design. It does have an glitch trigger which can trigger downto one
sample long gliches with every samplingrate (also @ 1 GS/s)!
The HW-Filters must be turned off for this!
@Thomas
Einen OR-Trigger habe ich im Moment noch nicht drinnen, die
Triggereinheit ist aber so modular aufgebaut, dass eine Nachrüstung
relativ einfach wäre.
Die Bandbreitenbegrenzung im DLM2000 unter 100MHz wird laut Aussage
eines Yokogawa Vertreters auch mit ähnlichen digitalen Filtern gemacht,
wie die HW-Filters bei mir!
MfG
Alexander
@Hayo: Also hat die Triggerung nicht mit dem Nios Design zu tun, gibs da
einen Baustein in Hardware der sich darum kümmert, oder wie meinst du
das mit modularer Triggereinheit.
@Axel
Wenn ich mit Datenrate und Tracelänge nachrechnet, scheint es so, dass
bis einschließlich 10 us/div (25 MSa/s) eine Speichertiefe von knapp 4
kSa pro Kanal verwendet wird, ab 5 us/div (250 MSa/s) komme ich dann auf
16 kSa pro Kanal, d.h. das ist noch eine andere Sache als das Reduzieren
des ADC Interleaves von 4..2..1 ADC. Hayo kann das bestimmt bestätigen.
@Hayo
Da man an den Samplingraten vermutlich erstmal nicht drehen kann, zielte
meine Bemerkung zum 1:10 Sprung in der Frequenzachse eigentlich mehr in
Richtung Zoom-Funktion für die FFT. Bei 1024 gerechneten Punkten wären
ein 2:1 Zoom sicher drin, ein 4:1 Zoom eventuell nicht schön, aber
darstellbar. Früher gab es ja schon mal die Frage nach einer Art
Frequenzlupe. Ohne neue Berechnung von Frequenzdaten, könnte man sowas
vielleich in der Anzeige auf Basis der bestehenden Daten umsetzen.
Gruß
Rainer
@Thomas
die Triggerung ist größtenteils hardwareseitig (ADC, FPGA)
implementiert. Das schränkt die Möglichkeiten firmwareseitig etwas
nachzurüsten ziemlich ein. Beim LEON3 hat Alex zum Beispiel die
Möglichkeit ein Oder-Glied in die Triggerlogik des FPGA einzufügen,
diese Möglichkeit habe ich beim NIOS nicht. Ich kann also nur mit dem
arbeiten was bei der Firmware ankommt und das ist nur die Triggerung
eines einzelnen Kanals zur Zeit.
@Rainer
Zur Zeit verwende ich für die FFT nur die realen Abtastraten, Daher auch
der Sprung zwischen 250 und 25MSa. Ich könnte natürlich stattdessen die
virtuellen Abtastraten des Zeitbereichs verwenden, dann hätte man eine
feinere Abstufung. Dazu müßte ich dann wie beim Zoom die nicht
benötigten Abtastwerte weglasssen. Das wäre machbar. Ich seh mal was da
geht. Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen
beschäftigt.
Gruß Hayo
Hallo zusammen,
wegen der Sammelbestellung:
Es sind immer noch zu wenig Interessenten. Beim USB-Host erst 5 Leute.
Dann wollen noch 4 Leute Teile für die Huckepackplatinen und auch noch
Platinen. Die Teile sind natürlich kein Problem, wohl aber die <10
Platinen die eine Bestellung unwirtschaflich machen.
Ich würde vorschlagen die Sammelbestellung (USB-Host+Huckepack2) solange
offen zu halten bis Hayo die Firmware angepasst hat. Dann werden sich
sicherlich noch mehr Interessenten melden.
Gibt es Meinungen/Einwände dazu?
Mfg,
Kurt
Gute Sonntag an alle und alex008, Kurt Bohnen, Thomas O. und Hayo.
alex008 schrieb:
>@LUC>To be shure you do not have a hardware fault (soldering) try the LEON3>design. It does have an glitch trigger which can trigger downto one>sample long gliches with every samplingrate (also @ 1 GS/s)!>The HW-Filters must be turned off for this!
Thanks for the suggestion alex008!
As I have already written, I am sure my W2022A is not dead and it is
just a loading error.
I already load an old Hayo's firmware release in to W2022A and spikes
problem is gone, so I am pretty sure the W2022A is ok and it has no
problem.
On the other hand I have similar experiences with firmware upgrades
asthe my work even covers these issues, so nothing new for me.
The problem is due to hardware incompatibility or loading error or both.
Returning to your kind suggestion, I have installed the LEON3 design in
my W2022A.
It is very easy, maybe because I use Quartus and similar software daily
when I work but it is very easy to do!
To be honest, I was able to easily install the NIOS LEON3 design and its
software, but I was not able to do any measure due the fact I am unable
to do even simple thing like move traces, so they are always in a bad
position on the screen, I am only able to move the trigger level,
nothing other.
I am able to set some parameters like probe attenuations, time base's
factor, vertical amplitude's factor, set the trigger source, set the
trigger slope and so, but nothing other.
Signal track are very clean and noiseless, but seems to me like they are
be fixed.
However, I repeat I was unable to make use of the DSO with the LEON 3
design installed on it, I am so sorry.
Is there no a user manual that explains how to use it?
What mean LEON or FPGA UART setting?
For me the LEON 3 DEMO design is really very user friendly to put in to
the DSO, although then I was not able to properly use the DSO I invite
everyone to try the LEON 3 design, if only because it is very easy and
safe to install it in the DSO: You load the LEON 3 in the DSO, You try
it and once You turned off and on the oscilloscope everything is back as
it was before without a trace!
Really very cool, so thank You very much to You alex008 and all who is
involved with the LEON 3 design's development: RESPECT!!!
However moving forward, to more accurately test the hardware of my
W2022A I decided to hurt me and I reinstalled the original 1.4 version
by Wittig/Welec! ;-)
A blast from the past, a return to youth! ;-))
After having played a little with the good old Wittig/Welec firmware, go
running to update the DSO to the latest 1.2.BF.3.0_C5 firmware release!
;-)))
Now spikes are come back like in a nightmare!
My goodness, this is really a wonderful and unforgettable Sunday! :-)
In the end seems the 1.2.BF.3.0_C5 firmware do not like at my W2022A so
I make a downgrade!
@Kurt Bohnen
What is the >Huckepack2?
@all
Thomas O. schrieb:
>ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte>mal fragen ob sich das vielleicht auch integrieren lässt.>>1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1,>2, 3 oder 4 auftritt.>2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals>steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
In the Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)
weitererGast schrieb:
>>> Ist eigentlich schon implementiert, dass man auch auf einen Kanal>>> triggern kann der ausgeblendet, aber dennoch angeschlossen ist? Das>>> missfiel mir am Anfang gewaltig. Manchmal muss man wegen der>>> Übersichtlichkeit schlichtweg auch mal den zu triggernden Kanal>>> ausblenden.
Antonio schrieb:
>> I don't understand, what you mean?>> Also Hayo's answer isn't clear for me, please help about this.
Hayo W. schrieb:
>What he meant is, that triggering should be possible on channels which>are inactive. But to realize that I have to change the source channel>selection logic because the actual logic switches off the source channel>if it becomes inactive and searches for the next available active>channel automatically.
Subject matter in some ways similar.
Vielen Dank!!!
Gruß Luc
mir ist gerade etwas in den Sinn gekommen und da wollte mal fragen ob
das praktizierbar ist.
Ein differentielles Signale anzuzeigen also Kanal 1 mit Kanal 2 zu
verrechnen und ab einer Differenz größer X das eigentliche Signal
darzustellen dazu wäre es vielleicht sinsvoll die gespeicherten Werte
rechts zu schieben um die Auflösung zu verringern und dann miteinander
verrechen.
Viellicht läßt sich sogar eine 3 Oszilinie zw. Kanal 1 und 2 Zeichnen.
http://www.kfztech.de/kfztechnik/elo/can/bmw1.JPG
Hi Leute,
ich weiß man hört im Augenblick nicht viel von mir. Aber ich ich bin
trotzdem dabei. Zur Zeit bin ich noch an den USTB-Funktionen dran.
Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte.
@Luc
I fixed the spike problem caused by the hardware setting "High Frequ". I
changed the register setting and it seems to work.
Hayo
Thomas O. schrieb:> ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal> schauen ob sich das so gut auf digitale Signale anwenden lässt.
Zum Glück sind die Digitalsignale eine Teilmenge der Analogsignal.
:-)
Hallo Hayo,
mal noch eine Frage etwas anderer Natur. Wäre es denkbar die Auflösung
des Scopes zu 9bit hin zu treiben?
Ich glaube die Diskussion hatten wir schon mal an irgendeiner Stelle.
Ich stelle mir das so vor:
- Sampledurchgang 1:
Es wird gesamplet wie bisher
- Sampledurchgang 2:
Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2
LSB erhöht ist.
- Zusammenführen der Daten aus Sampledurchgang 1 und 2
Mir ist klar das das auf dem Bildschirm keinen Unterschied machen wird,
jedoch beim Export der Daten auf einen PC wird das einen Unterschied
machen, weil dann die höhere Auflösung zur Verfügung steht.
Ließe sich das grundsätzlich realisieren?
branadic
branadic schrieb:> - Sampledurchgang 1:> Es wird gesamplet wie bisher>> - Sampledurchgang 2:> Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2> LSB erhöht ist.>> - Zusammenführen der Daten aus Sampledurchgang 1 und 2
Das Problem sind das Zusammenführen der Signale und die Wiederholrate.
Die Wiederholrate wird massiv einbrechen, da
1. doppelt so viele Sampledurchgänge pro Frame benötigt werden
2. vor jedem einzelnen Sampledurchgang der DAC justiert werden muß, was
noch viel mehr Zeit kostet, da vor dem nächsten Sampledurchgang solange
gewartet werden muß bis der DAC (und OP Amp) gesetzt und eingeschwungen
ist.
Das Zusammenführen ist insofern problematisch, dass es einen sehr
präzisen Trigger erfordert, da sonst das Signal in Horizontalrichtung
unscharf wird. Man erkauft sich dann vertikale Präzision mit
horizontaler Unschärfe.
Wie das aussieht kann man sich ansehen wenn man ein Signal mit steiler
Flanke auf dem Bildschirm hat und dann auf persistente Anzeige schaltet.
Gruß Hayo
Hallo Hayo,
ich hab mir schon fast gedacht, dass das auf Basis des Nios nicht
klappen wird.
Es wird wirklich Zeit, dass der Leon das Licht der Welt erblickt, denn
da steht auch der Trigger wie eine eins und ließe, aufgrund seiner
Geschwindigkeit, solche Spielereien ebenfalls zu.
branadic
Hi Hayo, Kurt Bohnen and guys all!
@Hayo
First, thanks You very, very much Hayo for the free time You provided
generously to us and for have fixed the spike's problem!!!
Hayo, I installed your latest great job, the new 1.2.BF.3.0_C6.
It is very impressive, as always You are right the spikes are gone!:
RESPECT!!!
I setted hardware configuration as "High Frequency" and "1,25 Gain" and
no more spikes!
You are great, so thank You very much again for the excellent job done:
RESPECT!!!!!!!
I know the work must not have been easy, so as usual I am speechless!!!
Kurt Bohnen schrieb:
>It's (the "Huckepack2") the second collective order of the>pickabackboard parts (and PCB).
Hello Kurt Bohnen, thank You for your kind explanation.
What You wrote it is very interesting for me and I guess for many other
also.
How can I place a purchase order?
How can I pay the materials?
How much is it shipping included?
Is there a possibility to purchase a Vinculum VNC2 USB-Host also?
And the power supply shield?
Please, let me know, I guess it is very interesting also for many other
people.
Thank in advance.
Mit Freundlichen Grüßen,
Luc
Hello LUC,
sorry for my late answer.
I am happy to read you did try the LEON3 design.
For your measuring problem:
The LEON3 design software is not ready to use for daily operation.
Their is no DC offset calibration available at the moment.
And because the original analog frontend was made with poor quality you
have to set the dc offset with the offset gain button and the offset
wheels before you can measure anything.
I have put a video about setting the dc offset on a previous entry from
10.04.2011 here.
The signal quality can be improved with the HW-Filters.
Alexander
hat außer mir noch jemand Probleme mit Timebase >1s/div mit der 3.0 C6
oder wurde da irgentwas geändert, ich habe einige Versionen
übersprungen. Bekomme keine Aktualisierung mehr mit den Sekunden-
Einstellungen.
Hi BLUE
I have a worrying problem on my W2012.
While today I tried to adjust the course to display a horizontal drive a
TVC suddenly the track of the instrument has become fixed and immobile,
but clean (not even a pixel out of place). Of course not display any
picture nor the TEST SIGNAL.
I say that at the time of the defect, the tip was removed from the
circuit.
I reinstalled an earlier version that was installed
but the defect remains. Channel 2 still works
Sorry for the language
wailer schrieb:> Hi Hayo> I have a worrying problem on my W2012.> While today I tried to adjust the course to display a horizontal drive a> TVC suddenly the track of the instrument has become fixed and immobile,> but clean (not even a pixel out of place). Of course not display any> picture nor the TEST SIGNAL.> I say that at the time of the defect, the tip was removed from the> circuit.> I reinstalled an earlier version that was installed> but the defect remains. Channel 2 still works> Sorry for the language
Hi Kurt Bohnen, alex008, wailer, and guys all!
Kurt Bohnen schrieb:
>Details zur Sammelbestellung gibt es jetzt hier:>http://sourceforge.net/apps/trac/welecw2000a/wiki/...
Very well Kurt Bohnen, great job!
Kurt Bohnen thank You very much for your kind support!
You are really a big one, RESPECT!!!
alex008 schrieb:
>sorry for my late answer.>I am happy to read you did try the LEON3 design.
Hi alex008, no apologies, I must thank You for the great work and free
time You provided generously to us: RESPECT!!!
alex008 schrieb:
>For your measuring problem:>The LEON3 design software is not ready to use for daily operation.>Their is no DC offset calibration available at the moment.>And because the original analog frontend was made with poor quality you>have to set the dc offset with the offset gain button and the offset>wheels before you can measure anything.>I have put a video about setting the dc offset on a previous entry from>10.04.2011 here.
Ok alex008, I understand, so thank You a lot for the kindly and useful
explanation.
alex008 schrieb:
>The signal quality can be improved with the HW-Filters.
I am currently away from my computer and I have no to hand Quartus, so I
can not try but in the weekend I will try for sure.
Thank You again alex008!
wailer schrieb:
> I have a worrying problem on my W2012.> While today I tried to adjust the course to display a horizontal drive a> TVC suddenly the track of the instrument has become fixed and immobile,> but clean (not even a pixel out of place). Of course not display any> picture nor the TEST SIGNAL.> I say that at the time of the defect, the tip was removed from the> circuit.> I reinstalled an earlier version that was installed> but the defect remains. Channel 2 still works> Sorry for the language
Hi wailer, seem to me to understand perhaps you damaged your DSO while
performing a measurement on a TV color set.
Is it correct?
I think already I read You somewhere and I guess You are Italian, so I
try to write Italian to facilitate the understanding.
Italian translation:
Ciao wailer, mi sembra di capire che tu hai danneggiato il tuo DSO
effettuando una misura su un televisore a colori.
E' corretto?
Mi pare di averti già letto da qualche parte e che tu sia italiano, per
cui provo a scrivere in italiano per facilitare la comprensione.
@ all
Due to high voltage on some point inside a color television set, is
unfortunately possible you damaged your DSO for true.
How much is great the signal amplitude on which You done the measure?
Was the probe setted x1 or was it setted x10?
Sorry, but due to the exceeded in the maximum input voltage for analog
inputs is possible the DSO is now broken.
Please weiler, tell us more about what you done.
Italian translation:
A causa dell'alta tensione presente in alcuni punti di un televisore a
colori è purtroppo possibile che tu abbia realmente danneggiato il DSO.
A quanto ammonta l'ampiezza del segnale sul quale hai effettuato la
misura?
Come era impostata la sonda, x1 o x10?
Spiacente ma a causa del superamento dei valori massimi consentiti per
gli ingressi analogici è possibile che il DSO sia adesso guasto.
wailer per favore facci sapere di più circa quello che hai fatto.
Mit Freundlichen Grüßen,
Kind regards,
Cordiali saluti,
Luc
Luc grazie
Preciso che il probe non era a contatto con i circuiti del TVC
Sul TVC il trasformatore di EAT era smontato (assente)Quindi non poteva
esserci Alta Tensione.
Il pilotaggio (driver) di riga ha come Vpp 12-15 volts
Il blocco del Input 1 è avvenuto cercando di regolare il Time Base
Posso ora dire che il problema era software ed è RISOLTO.
Con WELECUPDATER ho reinstallato il firm originale (avevo Backup)
e il DSO ha ripreso a funzionare. Successivamente ho aggiornato alla
3.0C6
del grande HAYO .Ora tutto sembra funzionare.
Prima del blocco avevo notato che il DSO a volte si bloccava ed era
necessario riavviarlo
English Version:
Thanks Luc
Specify that the probe was not in contact with the circuitry of the TVC
The TVC transformer EAT was removed (absent), then there could be high
voltage.
The pilot (driver) has the Vpp line 12-15 volts
The input block 1 occurred trying to set the Time Base
I can now say that the problem was software and ubuntu.
With WELECUPDATER I reinstalled the original signature (I Backup)
and the DSO has resumed operation. Then I upgraded to 3.0C6
Hayo's great. Now everything seems to work.
Before the block I noticed that the DSO sometimes crashed and had to
restart
Hi there,
I'm just back from holiday in Spain. In the "outback" (Alicante) where I
spent my time, I had no internet connection. This is the reason why my
answer is coming a little bit later.
@wailer
You solved Your problem by yourself - well done!
@elec + Rainer
Tut mir leid wenn im USTB-Bereich Probleme auftreten. Da sind dann wohl
doch schon einige Änderungen mit reingerutscht. Zur nächsten Version
wird ohnehin alles im USTB-Bereich umgekrempelt, dann hat sich das auch
erledigt. Sonst Notfalls downgraden auf auf eine ältere 3er Version. Die
C4 oder C5 müßte doch noch funktionieren oder?
@Kurt
Muß ich irgendwas machen wegen der Bestellung, oder warte ich bis ich
von Dir eine Nachricht bekomme?
Gruß Hayo
Hayo W. schrieb:> Tut mir leid wenn im USTB-Bereich Probleme auftreten.
Hallo Hayo,
kein Problem - mit der C5 läuft USTB wie gewohnt. Bezüglich Spikes -
die, die synchron auf Ch3 und 4 auftreten - konnte ich zwischen C5 und
C6 übrigens keinen rechten Unterschied feststellen.
Gruß
Rainer
Die Unterschiede sieht man auch nur bei Hardwareeinstellung "High
Frequ". Wenn man dann ein Rechtecksignal mit der steigenden Flanke
mittig positioniert (z.B. bei 100ns) und auf persistente Anzeige
schaltet dann sieht man die Spikes synchron auf Kanal 1 + 2.
Gruß Hayo
Hallo Hayo,
wie oben schon geschrieben sind weitere Fakten zur Bestellung auf
http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder
nachzulesen.
Die offene Deadline gibt es damit nicht wieder 10 Nachzügler kommen,
nachdem die Huckepackplatine von der Firmware unterstützt wird.
Mfg,
Kurt
Guten Abend an alle.
With a friend, I'm trying to assess the bandwidth of the W2022A and
W2012A.
It is not so easy, just completed the measures I will explain the matter
in detail in the Hardware forum.
At this moment I would to talk about some things maybe to be already
known.
I built a pulse generator which has Rise and Fall time so fast that I
can not measure them with precision.
The best oscilloscope I could use to calibrate the pulse generator has a
bandwidth of 500MHz, but it is inadequate to measure the Rise and Fall
times of pulses, which should be less than 300ps, so I preferred to
compare the performance of the W2022A and W2012A compared with those of
other oscilloscopes with known characteristics.
Seems to me the W2022A is better than the W2012A, better frequency and
amplitude response.
About this last I am not sure due the linearity lack of the Welec.
However I noticed some things.
A) With the Welec's oscilloscopes, in order to make better measure I
must put the trigger level just below the peak of the pulse otherwise
the waveform is continually moving.
But in this way the signal amplitude increases considerably compared to
when the trigger level is set lower.
In short, the size of the displayed signal depends on the position of
the trigger threshold, if the trigger threshold is low, the amplitude of
the signal is so and the waveform is moving, whereas if the amplitude is
high it becomes high itself and the waveform is more steady.
I had never noticed this thing before, but maybe it is always been so.
B) Seem to me when the Rise or Fall time are less than 1nS, in the Quick
Measure is show 0,00S not allowing to know which is the measured in
true.
Ok, it exist the cursors, but also this thing I had never noticed
before, but maybe it is always been so.
C) Both W2022A and W2012A have the 1.2.BF.3.0_C6 firmware.
About this, I have no more spikes problem, but during the measurements I
have noticed that "High Frequency" setting in Hardware menù is good for
show the inner probe compensation signal but it is inadequate for the
fast pulse, so I must to switch it to Test3 to perform the measure: by
setting Test3 I can visualize both slow and fast waveform optimally, for
me is the better choise with my W2022A and W2012A.
Now, I know the 1.2.BF.3.0_C6 firmware fix the spike's problem caused by
the hardware's setting "High Freq" by changing the register setting.
Have others noticed this?
Seems to me strange the better choice is now other than "High Freq"
setting, also "Factory" works well without spikes problem.
About this, I tried a downgrade on both W2022A and W2012A and i noticed
no spikes when I connect an external signal generator, while there are
spikes using the internal probe compensation signal.
So, I do not know if it was a case or not, but could spikes really be
caused by noise coming from the power supply?
Mit Freundlichen Grüßen,
Luc
Hi Luc,
thanks for Your detailed report about pulse response. It would be
interesting to find out how the C5-Version with the old High Frequ.
setting is working. Maybe I rename the Test 3 setting like "Pulse" or
something in this way as hint to use this for quick signals.
In the moment I'm a little bit short in time, so I have to stave You off
in relation to the next version.
But don't worry - it will go on.
Kind regards Hayo
@all
Hi Leute,
bin zur Zeit etwas im Stress und muß Euch leider erstmal etwas
vertrösten bis zur nächsten Version. Aber nicht verzagen, es geht auf
jeden Fall weiter.
Bis dahin genießt das schöne Wetter
Gruß Hayo
Hello Hayo,
I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy
occures with these settings:
ADC :High freq Pregain 1.25 Filter IIR1 .With C6 the accuracy is 1dB
less and settings are different.
Just one question ,I can't see anymore the higher resolution in the
frequency counter,is it possible to see
1 kHz at 100 Mhz carrier?
Regards,
Alex
Hi Alex and guys all!
Alex schrieb:
>I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy>occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1
It would be possible to see some screenshots, please?
I mean a screenshot for each acquisition mode: noise filter off, noise
filter smooth, noise filter strong, noise filter IIR 1 stage, noise
filter IIR 2 stage and noise filter IIR 3 stage.
Due the filter switch in STOP mode this is easy to do.
However, should not the best results be obtained without filters?
Alex schrieb:
>With C6 the accuracy is 1dB less and settings are different.
It would be possible to know how the DSO is set for better performances
in this case, please?
@Alex
Alex, is your W2022A a standard version or a modified version?
Thanks in advance.
Mit Freundlichen Grüßen,
Luc
Hello,
my W2022A is standard.About the screenshot Let's wait the next version
from Hayo.
Without any filter at 50MHz and upper the noise cause a level peak error
because,up to now,there isn't a sin interpolation available.
I only tried C6 ,anyway works well up to 50MHz and fix some issue, now
I'm using the previous on the lab.
Sandro(Alex)
Hi Alex(Sandro) and guys all!
Alex schrieb:
>my W2022A is standard.
Thank You for the answer!
Alex schrieb:
>About the screenshot Let's wait the next version from Hayo.
Thank You Alex, You are very kindly, then I will wait.
Alex schrieb:
>Without any filter at 50MHz and upper the noise cause a level peak error>because,up to now,there isn't a sin interpolation available.
I know, it was my intention to talk about this.
Alex, You tested your W2022A with a 100 MHz 100mV, I guess a leveled
signal generator, so have You noticed that signal amplitude depend on
the trigger treshold?
I mean, when the trigger treshold is not a bit below the waveform's peak
it is then continually moving and lower level than when the trigger
level is just below the waveform's peak and it is itself more steady and
its level has much more great amplitude.
In short, the size of the displayed signal depends on the position of
the trigger threshold, if the trigger threshold is low, the amplitude of
the signal is so and the waveform is moving, whereas if the amplitude is
high it becomes high itself and the waveform is more steady.
Maybe it is due sin(X/X) lack, maybe it is for ather reasons...
I tested both W2012A and W2022A up to 170MHz and they work well, if it
were not for a lack linearity problem and poor representation due up to
now there is not a sin(X/X) interpolation available.
From my test on high frequencies the W2022A is better than the W2012A.
Both W2012A and W2022A I tested are not modified unit, they are standard
manufactured by Welec.
Alex schrieb:
>I only tried C6 ,anyway works well up to 50MHz and fix some issue, now>I'm using the previous on the lab.
Can you kindly tell us how your W2022A is set for the better
performances with the C6 release?
I mean the Hardware menu's settings and the Filter setting in the Aquire
menu.
Thanks in advance.
Mit Freundlichen Grüßen,
Luc
Hallo Leute
Ich habe vor ein paar Tagen ein Welec W2024A geerbt.
Nach der ersten Euphorie kam nach einem Vergleich mit meinen anderen
Oszis schnell die Ernüchterung. (Ich Arbeite sonst mit einem Hameg
HM1005 und einem Tektronix TDS 340).
Gestern habe Ich mich dann getraut die Kiste zu Flashen dabei ist mir
aufgefallen das eure Flashsoftware ein Problem mit unterschiedlichen COM
Ports zu haben scheint. Zuerst auf COM 1 kam immer wieder die Meldung
wie oben beschrieben mal Abbruch in Zeile 30 mal in 234 u.s.w. ein
Neustart des PC konnte auch nicht helfen, nach ca. 20 missglückten
versuchen habe Ich dann mein Glück mit COM 2 Probiert und da
funktioniert es immer. (Die W2000 Update Software funktioniert bei mir
überhaupt nicht b.z.w. behaupte immer „File not Found“). Ich habe jetzt
die Letzten 3 Versionen eurer Firmware ausprobiert und muss sagen Ihr
habt ganze Arbeit geleistet Kompliment!!!! Mir ist aber auch aufgefallen
das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch
angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version
3.0_C6“
Mache Ich hier etwas falsch oder liegt das an den (Noch nicht
vorgenommenen Hardware Änderrungen)? Ich habe leider keine
Bedienungsanleitung und alles was Ich im Netz gefunden habe ist in
English und beinhaltet sicher auch nicht eure Änderrungen.
Gibt es vielleicht eine Bedienungsanleitung die einem Einsteiger die
Funktionen des Geräts erklärt? Ich habe gesehen das ihr eine Huckepack
Platine entworfen habt wenn das möglich ist würde Ich mich an der
Sammelbestellung noch ganz gerne beteiligen.
Ich hoffe meine Erfahrungen helfen euch weiter.
Gruss Rudi
Hallo Rudi,
> (Die W2000 Update Software funktioniert bei mir> überhaupt nicht b.z.w. behaupte immer „File not Found“).
die originale Upd-Software ist Schrott, dauert auch viel zu lange!
Am schnellsten ist der Germsloader, da muß aber das komplette Paket
heruntergeladen werden...
Hier der Link für die neuen Downloader, müssen nicht installiert werden
und funktionieren einwandfrei:
---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"> Mir ist aber auch aufgefallen> das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch> angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version> 3.0_C6“
Ich habe auch im Leerlauf so um die 400-600mV Pk-Pk(bei jeder Version),
egal welchen Filter ich einschalte...Hayo wird's schon richten :-)
> Ich habe gesehen das ihr eine Huckepack> Platine entworfen habt...
Schick mir mal eine PM, habe einen kompletten Satz inkl. Platinen
abzugeben.
Gruß Michael
Hallo
Ja genau diese Uploader habe Ich benutzt!!!
Bei offenen Eingängen ist das mehr oder weniger Normal da kommen
natürlich Einstreuungen rein oder Leck ströme an den Sperrschichten der
Eingangs OPs bei anliegendem Signal sind 60% Abweichung aber nicht
akzeptabel mal schauen wie es nach dem Hardwareupdate aussieht.
Rudi
Was für ein Signal hast du denn eingespeist? Das Welec ist zwar kein
Präzisionsgerät aber 60% Abweichung hat es definitv nicht solange man
sich nicht in höheren Frequenzbereichen bewegt.
Gruß
Michael
Hallo,
ich habe ein 4-Kanal-Welec (W2014A, sofern das überhaupt eine Rolle
spielt) abzugeben.
Das Gerät besitzt das Schirmblech aus galvanisch verzinntem Stahlblech,
die DACs sind bereits auf die 16 bit Version umgerüstet und Kanal 4 ist
für die Huckepackplatine vorbereitet, sprich die originale Eingangsstufe
ist entfernt.
Die anderen Kanäle besitzen die 24.9 Ohm (0.1%) Widerstände vor den
ADCs.
Zum Scope kommen drei fertig aufgebaute sowie vier nicht bestückte
Huckepackplatinen hinzu.
Zum Gerät gehören die vier Tastköpfe.
Als Bonus gibt es einen meiner selbstgebaut aktiven Tastköpfe V4b dazu.
Bei Interesse mailt einfach an: branadic [ed] users (punkt) sf {punkt}
net
branadic
Müssen wir uns Sorgen machen?
Das klingt ja fast nach Projektaufgabe! :-(
Alex braucht dringend einen 4Kanäler, finde ich. Wenn das Leon-Design
mit 4 Kanälen arbeiten würde wäre ich schon längst mit Feuer und Flamme
dran am Software-schreiben.
Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal
50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu?
Jörg
Jörg H. schrieb:> Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal> 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu?
Ich bin dabei, Betrag unbenannt. Warten wir auf Alex.
Ach ja, Hayo hatte sich ja irgendwie gegen jedes Sponsering
ausgesprochen - da würde ich aber noch viel mehr hin überweisen (wenn
Interesse ;-))
Viele Grüße,
Egberto
Jörg H. schrieb:> Müssen wir uns Sorgen machen?> Das klingt ja fast nach Projektaufgabe!
Genau das ist es. Ich möchte Projektleichen loswerden und für mich zählt
das Welec mittlerweile dazu. Ein kurzer Abriss:
Im Oktober/November 2009 haben Walter und ich die erste Version der
Huckepackplatine entworfen und gelayoutet, im Februar 2010 wurde die
erste Version dann vorgestellt und vermessen. Dieser Version sind drei
weitere Versionen gefolgt.
Im Dezember letzten Jahres wurde der Einbau der finalen Version
dokumentiert und die erzielten Möglichkeiten vorgestellt.
Bis heute hat die Huckepackplatine keine Softwareunterstützung erfahren
und ich sehe offen gestanden auch nicht, dass sich daran was ändern
wird.
Auch das Leon-Design wird noch eine ganze Weile brauchen. Alex ist
mittlerweile berufstätig und zeitlich eingeschränkt, nicht zuletzt dank
Freundin.
Im Laufe des Projektes sind unzählige Leute, die anfangs mit Eifer dabei
waren, heimlich still und leise untergetaucht und waren nicht mehr
gesehen.
Als Walter das Projekt verlassen hat gab es einen kurzen Aufschrei und
die Unterstützung der Huckepackplatine ist in der Prioritätenliste ganz
nach oben gerutscht. Davon ist nicht viel über geblieben.
Salz macht aus Wasser noch lange keine Suppe und die Änderungen an der
Firmware mögen Hayo wichtig erscheinen, aber mir genügen diese schon
lang nicht mehr, zu viel Schein, zu wenig echte Funktionalität, viel zu
viel für das Auge.
Für mich steht das Projekt seit der Fertigstellung der Huckepackplatine
still. Unzähliges Nachfragen, wann die Huckepackplatinenansteuerung in
Angriff genommen wird, hat nicht den Erfolg gebracht.
Daher meine Entscheidung, ich bitte diese zu verstehen.
branadic
Aber das ist doch kein Grund die Flinte ins Korn zu werfen.
Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja
unbezahlbarer Aufwand drin.
In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber.
Letztes Wochenende hätte ich meine Huckepackplatinen fast bestückt, wenn
mir ein Kollege nicht das Equipment abgezogen hätte. Steht auf jeden
Fall noch auf der Liste.
Supportest du den Einbau noch, auch wenn du selber keine Platinen hast?
Jörg
Jörg H. schrieb:> Aber das ist doch kein Grund die Flinte ins Korn zu werfen.> Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja> unbezahlbarer Aufwand drin.
Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg
eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene
regelmässig.
Meine Empfehlung: nicht groß drüber nachdenken.
/Hannes
¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht
ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."
Johannes S. (johannes_s94) schrieb:
> Das legt die Vermutung nah, dass der plakative Ausstieg> eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene> regelmässig.
Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein.
Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930"
Aber deswegen nicht entmutigen lassen und vor allem nicht um Gnade
winseln.
Grüße
Klaus Bauer
Jörg H. schrieb:> Aber das ist doch kein Grund die Flinte ins Korn zu werfen.> Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja> unbezahlbarer Aufwand drin.> In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber.
Hallo Jörg,
die Entscheidung muss man mir überlassen. Ich habe genug Baustellen zu
bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und
gern verzichten.
Jörg H. schrieb:> Supportest du den Einbau noch, auch wenn du selber keine Platinen hast?
Klar, das hat Walter angeboten und das gilt für mich gleichermaßen.
Johannes S. schrieb:> Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg> eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene> regelmässig.>> Meine Empfehlung: nicht groß drüber nachdenken.>> /Hannes>> ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht> ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."Klaus Bauer schrieb:> Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein.>> Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930"
Noch einmal, ich bin niemandem Rechenschaft schuldig und die
Entscheidung treffe ich ganz allein für mich, dazu brauche ich kein
Feedback von irgendwelchen Leute die meinen sich nur aktiv beteiligen zu
müssen, wenn man mit dem Knüppel auf jemanden hauen kann und sonst nicht
konstruktives beitragen. Die Gründe für meine Entscheidung sind auch
ganz allein meine Sache und hat euch nicht zu interessieren.
Ich euch, lasst jedwede Unterstellung oder Verleumdung meiner Person,
das gilt insbesondere für Johannes S. und Klaus!
Danke, branadic
branadic (Gast)schrieb:
> Ich habe genug Baustellen zu> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und> gern verzichten.
Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder
muß
man mit unfertigen Projekten weiterleben.
Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten)
Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen
welche danach nutzlos sind.
Darüber sollte mal nachgedacht werden.
Gruß
Klaus
Klaus Bauer schrieb:> branadic (Gast)schrieb:>>> Ich habe genug Baustellen zu>> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und>> gern verzichten.>> Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder> muß> man mit unfertigen Projekten weiterleben.> Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten)> Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen> welche danach nutzlos sind.> Darüber sollte mal nachgedacht werden.>> Gruß>> Klaus
Ich kenn dich nicht und habe mir dir nichts zu tun, ich bin dir zu
nichts verpflichtet und wenn du der Meinung bist technisch unbegabt zu
sein, so steht es dir frei das zu ändern! Aber versuche nicht mich für
deine Unfähigkeit in die Verantwortung zu ziehen!
Es wurde keine Hoffnung vorgegaulkelt, sondern eine Lösung erarbeitet.
Diese Lösung hat bisher keine Unterstützung gefunden und damit ist das
Thema Welec für mich beendet. Alle Imformationen zur Huckepackplatine
sind veröffentlicht worden und für jedermann frei zugänglich, was willst
du eigentlich noch? Hast du auch nur eine Minute mit in die Entwicklung
gesteckt? Du hast doch bisher alles mundgerecht bekommen, ohne selbst
etwas beigetragen zu haben!
Ich versteh gar nicht, warum hier von der "Knüppeltruppe" so ein Wind
gemacht wird. Andere Mitwirkende haben sich irgendwann einfach nicht
mehr gemeldet. Hat da jemand was gesagt?
Als Walter sich vom Projekt verabschiedet hat, hat da irgendwer das
Motzen angefangen? Warum wird jetzt wo ich klipp und klar sage das ich
keine Lust mehr auf dieses Langzeitprojekt habe, weil ich ein Messmittel
brauche und keine Entwicklungsplattform, so ein Wind gemacht?
Die Huckepackplatine ist fertig entwickelt und muss nur noch eingebaut
und durch die Software unterstützt werden.
Noch einmal ganz klar für dich Klaus, lass die Unterstellungen gegenüber
meiner Person. Du musst mit keinem meiner Projekte leben, ich bin nicht
zu deiner Unterhaltung da. Die Entwicklung der Huckepackplatine ist
abgeschlossen!!! Abgeschlossen!!!
Das Welec bleibt aber eine Baustelle, solange das neue FPGA-Design mit
der neuen Firmware nicht die neue Basis bilden und die Huckepackplatine
unterstützen. Ich möchte nicht mehr länger warten bis das so weit ist,
weil ich, ich sage das noch einmal, ein Messmittel und nicht länger eine
Entwicklungsplattform brauche. Ich hoffe das ist jetzt auch endlich bei
dir angekommen.
Statt in Foren zu pöbeln solltest du die Energie lieber dazu verwenden,
dich in die Themen einzuarbeiten, um selbst auch mal etwas, wie du es so
schön formuliert hast, produktives beizutragen!
Frage: Ist das jetzt endlich auch bei dir angekommen?
branadic
Ich habe großen Respekt vor branadic, hayo, alex und all den andern die
dieses Projekt so weit gebracht haben, danke. Ich kann auch nicht
verstehen, dass manche Leute jetzt hier rumpöbeln, gerade über Menschen
die sich hier besonders eingebracht haben.
Ich habe das Projekt gern verfolgt, dass es jetzt vorläufig nicht
weitergeht ist bedauerlich. Alle die wie ich bis jetzt sich nicht aktiv
an der Entwicklung beteiligt haben, aber Interesse am Fortgang haben,
können sich jetzt an die eigene Nase fassen.
@branadic: Willst du dein Welec Equipment nicht liebe einmotten, wäre
doch schade wenn hier doch noch was zustande kommt und du nicht davon
profitieren würdest.
Gruß
Stefan
Kleiner Vorschlag am Rande: ímmer wenn man veröffentlichte Oszillogramme
in Fachzeitschriften oder sonstwo sieht, sieht man auf den ersten Blick
dass es sich um ein Bild eines Tektronix Geräts handelt weil in der
linken oberen Ecke das "Tek" steht. Wie wäre es wenn sowas auch hier
gemacht würde? Ich fänds lustig. Besonders wenn sich manche Leute auf
einmal fragen: was ist das denn für ein Hersteller? Das sieht ja richtig
gut aus von Funktionsumfang und Design her...
Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
moin,
> Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
Gute Idee! Als Kürzel käme ja eigentlich nur " WT " in Frage...
Ansonsten fände ich die "Sinuskurve" ganz schick...
branadic (Gast) schrieb:
> Frage: Ist das jetzt endlich auch bei dir angekommen?
Antwort : JA, ich hoffe bei all den anderen nicht so technisch
hochbegabten auch.
Klaus
Hallo!
Ich finde es auch sehr schade, dass wir keine neuen Entwickler für das
Open Source Projekt mehr finden.
Unsere zwei größten Mankos sind, dass wir einerseits zu wenig im
Internet präsent sind, und dass den meisten Open Source Entwicklern die
Kompetenzen für so eine Embedded Systems Programmierung fehlt.
Leider schauen die meisten Personen nur auf den kurzzeitigen Erfolg, da
man mit dieser Strategie die größten positiven Rückmeldungen bekommt.
Mit Hayos Verbesserungen der Software mit dem originalen FPGA-Design ist
leider die Warscheinlichkeit von Nachschub an Entwicklern für das
LEON3-FPGA-Design stark geschrumpft.
Hayo hat es geschafft, dass die meisten Nutzer mit dem Oszilloskop
zufrieden sind.
Was aber klar ist, dass dieses Oszi so niemals überall so gut oder
besser wie die Markenoszilloskope sein wird.
Branadic hat mit Walter meiner Meinung nach eine sehr gute Arbeit beim
analogen Frontend gemacht.
Wenn ich bei der Entwicklung des LEON3-Zeug schon weiter wäre, hätte ich
das sicher schon integriert.
Schließlich sollte man möglichst versuchen, die eingebrachten
Fähigkeiten und Arbeitsleistungen anderer möglichst versuchen zu
Integrieren und zu Ergänzen, da man sonst irgendwann nur mehr alleine
weiter entwickelt.
MfG
Alexander
Hallo zusammen.
Ich hätte folgenden Vorschlag: schreiben wir doch (von mir aus ich)
einen Artikel für das embedded projects journal. Da erreicht man Leute,
die sich für Open Source begeistern und durchaus auch sehr fähige
Menschen, jedenfalls gibt es dort immer wieder ganz interessante
Projekte.
Man könnte auch versuchen, Alex' Weg fortzuführen und Professoren
kontaktieren, um Diplomanden für das Projekt zu gewinnen.
Ich z.B. habe nach wie vor guten Kontakt zu einem Professor, der selbst
in Sachen VHDL sehr versiert und auch aktiv ist - der könnte evtl.
Studenten dafür gewinnen. Denn meiner Erfahrung nach wollen viele was in
Richtung VHDL machen, finden aber kein passendes Thema in der Industrie.
Mir ging es übrigens auch so, genauso wie einem Masterstudenten den wir
zur Zeit in der Arbeit beschäftigen. Leider habe ich selsbt keine Zeit
um einen wirklich sinnvollen Beitrag zu leisten aber das könnte doch ein
Weg sein...
Eure Meinung?
Gruß
Michael
>Da erreicht man Leute,>die sich für Open Source begeistern und durchaus auch sehr fähige>Menschen
Zumindest an der Firmware hier ist es sehr schwer sich zu beteiligen.
Die letzte Aktualisierung des Codes in Sourceforge ist 6 Monate her
(stammt noch von mir) und den Quellcode hier rauszusuchen wird sich auch
keiner antun. Zumindest hatte ich darauf irgendwann keine Lust mehr und
habs einfach gelassen.
Von daher mach es für mich keinen Sinn, Leute extra für die Firmware
anzuwerben.
In diesem Sinne.
Hallo Michael!
Deine Idee mit dem embedded projects journal finde ich sehr gut.
Ich würde mich sehr über so einen Beitrag freuen.
Vor allem sollte betont werden, dass sich das Welec Oszilloskop quasi
als Open Source Prototyping Plattform sehr gut eignet (Verfügbarkeit,
Doppelnutzen,...).
Unser langfristiges Ziel ist ein vollkommen offenes Oszilloskop mit
hoher Qualität zu schaffen. Zur VHDL- und Firmware-Entwicklung schadet
die mäßige Signalqualität nicht.
Weiters sollte auf die Möglichkeit der Adaptierung auf hochauflösenenden
ADCs hingewiesen werden (Doku dazu gibts aus Mangel an Interesse im
Moment keine).
Übrigens ist der Zustand des VHDL-Design wirklich schon reif für ein
Release.
Das größte Manko liegt an der Firmware, die noch weit von einem Release
entfernt ist.
Die Dokumentation habe ich im Moment auch nur sehr minimalistisch
ausgeführt, da den zuküftigen Softwareentwicklern fertig programmierte
Hardwareschnittstellen mehr bringen und ich zugleich die von mir
geschriebene Hardware testen kann.
@Stefan: Die Originalsoftware verbessern bringt nur den Wittigs und den
Besitzern des Welec was, sonst niemanden.
MfG
Alexander
Hallo Alex.
Es ist ja toll, dass du das VHDL Design schon zur Einsatzbereitschaft
gebracht hast, dafür zolle ich dir meinen größten Respekt!
Dann werde ich mal zusehen, dass ich einen Artikel entwerfe. In Bezug
auf dein VHDL/Leon3 Design werde ich dann vermutlich aber auf dich
zukommen müssen, da ich darüber leider noch nicht sonderlich viel weiß.
Ich könnte mir vorstellen, dass einige Leute bei dem Projekt Open Source
Oszi hellhörig werden, hoffentlich täusche ich mich da nicht.
Wenn die Programmiermaschine Hayo wieder mehr Zeit hat, kann er sich ja
vielleicht auch mit dem Thema Leon3 beschäftigen, dann wären
Fortschritte garantiert, allerdings wäre es dann natürlich toll wenn es
mit svn klappen würde...
Ich finde es übrigens ziemlich schade, dass branadic aufgegeben hat.
Vielleicht wird es ja trotzdem noch was mit der Huckepack Unterstützung,
dann wäre die Arbeit von ihm und Walter nicht vergebens gewesen.
Gruß
Michael
Von mir auch nochmal ein großes Danke an die die hier mitbearbeitet
haben und werden.
Ihr habt aus dem Scope ein für mich verwendbares Werkzeug gemacht. Ich
beschäftige mich mit Elektronik nur als Hobby und nicht beruflich,
konnte so leider hier auch nichts beitragen - aber von eurem Einsatz
profitieren.
Für das Geld, das es mich die Anschaffung gekostet hat, habt ihr und das
umsonst, den Nutzen des Gerätes für mich mehr als verdoppelt. DANKE
Ich hoffe, dass es weitergeht und wünsche allen hier beteiligten
mindestens so viel Spaß am Hobby, wie es mir bereitet.
Hi @ all.sich
I'm just alive, so don't worry! Work will go on soon...
Hallo allerseits,
leider hatte ich in letzter Zeit etwas wenig von selbiger für unser
Projekt. Mit Bedauern lese ich, dass Branadic sich aus dem Projekt
zurückzieht. Ich weiß, dass sich das mit der Hardwareunterstützung etwas
hinzieht.
Ich möchte aber nochmals darauf hinweisen, dass zeitweilige
Entwicklungspausen kein Grund zur Besorgnis sind. Da ich berufstätig bin
ist die Zeit manchmal etwas knapp. Die beste aller Ehefrauen ist da
wirklich sehr tolerant, wenn man bedenkt wieviel Zeit ich schon in das
Projekt gesteckt habe.
Ich möchte ebenfalls darauf hinweisen, dass ich das Ganze aus reinem
Spass an der Sache mache. Ich könnte mir ohne Weiteres auch ein 3000,-
Euro Gerät kaufen wenn es mir darauf ankäme. Nur würde das keinen Spaß
machen!
Zu den beschriebenen Problemen:
- das mit den falschen Messwerten werde ich mal prüfen und ggf.
korrigieren
- ich stelle in den nächsten Tagen mal eine weitere Compilation bereit
bei der die USTB-Bereiche wieder gehen.
Noch einen sonnigen Tag
Hayo
So, die Platinen sind bestückt. Hat deutlich länger gedauert als ich
dachte, mit Bauteilgröße 0402 ist das doch sehr fummelig. Gut das Kurt
etwas Reserve in die Tütchen gepackt hat, ein paar von den Sandkörnern
sind mir aus der Pinzette gehüpft, natürlich auf nimmerwiedersehen.
Nun habe ich den Compiler vorgewärmt und Hayos Software in der Version
C6 zum Üben durchkompiliert. Spricht eigentlich was dagegen, die im
Sourceforge-Branch "bf" einzuchecken, zur ggf. gemeinsamen Arbeit? Dort
liegen anscheinend ältere Sourcen. Ich kenne die Arbeitsweise hier
zugegeben nicht.
Ich Noob suche mir gerade zusammen, wie denn die Ansteuerung der Platine
zu machen wäre, bin für Starthilfe dankbar.
Ist diese Schaltplanänderung von Kurt aktuell? Trägt das auch für
4Kanäler?
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Wenn ich das recht deute wird aus dem 16-Bit Schieberegister aus U23/U21
dann ein 24-Bit Schieberegister U23/U21/U24. Die Chip-Selects der
Eingangsstufen werden daraus gewonnen. Sind die anderen Ausgänge von U24
obsolet? Macht das FPGA auch 24-Bit breite Shifts? Um unsere
Chip-Selects wieder wegzunehmen muß U24 neu "befüllt" werden. Machen die
Takte dann nicht unsere Daten im LMH651 kaputt?
Mir ist auch noch nicht klar, wie SPI von der Software aus bedient wird.
Wie werden die von U25 erzeugten Chip-Selects programmiert, wie die
Anzahl der Shifts eingestellt? In der Software wird fleißig auf
serdata->np_piodata zugegriffen, der Transfer anscheinend mit
serstartsw->np_piodata ausgelöst.
Jörg
Ich antworte mir mal selbst, mit meinen Forschungsergebnissen von
gestern. Bin durch Hardware und Software gekrochen.
Die SPI-Hardware im Nios-Design macht mehr selbst als ich dachte. Der
Chip-Select Adressdecoder U5 wird vom obersten Hex-Digit des
Registerwerts serdata->np_piodata eingestellt, genau genommen Bits
22:20. Die Länge des Schiebetransfers ist entweder immer 24 Bit, oder
(was ich nicht hoffen will) von den Bits 22:20 abhängig. Die DACs
brauchen 24 Bit, die Schieberegisterketten 8 oder 16.
Um das genauer rauszufinden muß ich mir da Drähte anlöten, zum Logic
Analyzer, um das im Betrieb zu messen.
Den Anschluß der Huckepackplatinen stelle ich mir daher etwas anders
vor.
Ich hoffe das FPGA schiebt auch 24 Bit an Daten wenn Register Bits 22:20
gleich Null sind, also keiner von den bestehenden Chip Selects aktiv
ist. Dann können wir die Platinen direkt an SPI Clock und Data
anschließen, nicht hinter ein Schieberegister. Auf den Platinen müssen
die Pullups entfallen oder vergrößert werden, denn die SPI-Signale sind
wegen der Transistorschaltung Q9,Q10 speziell nach low recht schwach.
Den Schieberegistern habe ich ein Stück weit hinterhergemessen. In
Brunos Bestückungsplan "Analog-Input-Part_assignment_V3_4.pdf" ist eine
Diskrepanz zum Schaltplan, die mich in die Irre führte. Sein U21 ist in
Wirklichkeit U23. U21 ist auf der anderen Platinenseite, unter dem
Abschirmkäfig von Kanal 1.
Wo ich gerade bei den Bauteilbezeichnungen der Schieberegister bin: Das
im Plan unbeschriftete MC4094 (unterhalb vom 74HCT238, der U23 wäre) ist
U22. Weiter rechts und nicht mehr im Bild sind zwei weitere
Schieberegister, wie die heißen weiß ich noch nicht. Wieder auf der
anderen Seite, nahe der seriellen Buchse ist U26.
Ich bin glücklicher Besitzer eines Stereomikroskops, zum Löten der
Platinen sehr nützlich. Gestern habe ich Sittenstrolch damit den
Schieberegistern zwischen die Beine geguckt um zu sehen welche
Ausgangsleitungen tatsächlich noch unbeschaltet sind. Wir brauchen ja 4
Stück für die Chip Selects der Eingangsplatinen. Der Schaltplan ist da
noch recht unvollständig. Auf der den Chips der Oberseite gehen von
allen Ausgängen Leiterbahnen weg, die sind also anscheinend alle belegt.
Auf der Unterseite sind insgesamt 6 Ausgänge frei, aber ungünstig
verteilt, jeweils 3 bei U21 und U26, an verschiedenen Positionen. Dann
nehmen wir wohl besser Ausgänge die an die alten Eigangsstufen gehen und
deshalb obsolet werden.
Wie störempfindlich sind die neuen Eingangsstufen eigentlich? Sollte man
die besser mit in die Abschirmkäfige löten? Dann sähe es auf der Platine
vielleicht auch nicht so schlimm aus, das Gebastel wäre versteckt.
So long,
Jörg
Hallo Jörg,
ich sehe Du kniest Dich da voll rein. Wenn Du firmwareseitig
Unterstützung brauchst sag Bescheid.. Ich kann Dir dann die Stellen
sagen an denen Du im Coding eingreifen mußt.
Gruß Hayo
@Hayo:
Danke, ich melde mich. Du meinst warscheinlich die Funktion
Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach
Eingangsstufe.
Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man
als Kennung anders brücken könnte? Dann brauchen wir keinen
Konfigurationsdialog ob alte oder neue Eingangsstufe.
@All:
Ich messe gerade mit dem Logicanalyzer wie das FPGA denn den SPI
bedient. Leider tut es das bereits maßgeschneidert für die jeweilige
Empfangskette, nicht generisch. Die Anzahl der erzeugten Bitclocks ist
genau passend, 8 Bit für Chip Selects mit einem Schieberegister, 16 Bit
für Chip Selects mit zwei Schieberegistern, 24 Bit für die
DAC-Chipselects. Für letzere wird Enable während der Bits gehalten, für
die Schieberegister ist es ein Strobe hinter den Bits. Von daher klappt
es nicht, irgendwelche Register umzuketten oder sich dahinter zu hängen.
Für Adressbits = 0 wird gar kein Signal erzeugt.
Ich habe aber eine Art Lücke gefunden: Für die eigentlich nicht
vorhandenen Adressen 8 und 9 (der Demux kümmert sich nur um 0 bis 7)
werden auch Daten rausgetaktet, und zwar 16 Bit wie für 2
Schieberegister. Der Adressdekoder U25 kriegt eine 0, erzeugt dann also
keinen verwendeten Chip Select. Eigentlich genau das was ich suchte,
außer das wir 24 Bit brauchen. Man muß so eine Adresse also zweimal
beschreiben.
So long,
Jörg
Hallo Jörg!
Es freut mich zu lesen, dass du für die nette Huckepack-Platine eine
Software-Unterstützung dazufügst. Das ist für mich aus Respekt für die
geleistete Arbeit von unseren Analogtechnikern ein muss.
Das der NIOS die SPI Ansteuerung in Hardware gemacht hat, schreckt mich
ein wenig und erklärt auch ziemlich, weshalb das noch nicht vorher
(erfolgreich) in Angriff genommen wurde. - Selbst ich habe nur das eine
Oszi und keinen Logic-Analyser zur Hand.
Anfangs hatte ich die SPI Ansteuerung auch beim LEON3 Design in Hardware
vorgesehen.
Während ich die Software-Treiber dafür schrieb, fiel mir aber auf wie
blöd so eine zugescheiderte Ansteuerung in einem möglicht portablen
FPGA-Design ist, und habe das ganze auf GPOs zurückgebaut.
MfG
Alexander
Jörg H. schrieb:> @Hayo:> Danke, ich melde mich. Du meinst warscheinlich die Funktion> Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach> Eingangsstufe.
Jupp, eine (ganz kleine) Verzweigung ist schon drin für Gain 1,25.
Ansonsten habe ich alles kommentiert was sich mir so an Funktionen
erschlossen hat. Der WELEC-Programmierer war mit Kommentaren und Doku
ziemlich geizig...
> Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man> als Kennung anders brücken könnte? Dann brauchen wir keinen> Konfigurationsdialog ob alte oder neue Eingangsstufe.
Keine Ahnung, die Idee ist gut, aber ich finde das mit dem Konfigmenü
auch nicht so schlimm.
Gruß Hayo
Muss man überhaupt unterscheiden? Wer die Huckepackplatine
nicht hat, den stört doch das Bitgewackel nicht. Und wer
den ursprünglichen Eingang nicht nutzt, dem kann doch egal
sein, wie der eingestellt ist?
Guido schrieb:> Muss man überhaupt unterscheiden? Wer die Huckepackplatine> nicht hat, den stört doch das Bitgewackel nicht. Und wer> den ursprünglichen Eingang nicht nutzt, dem kann doch egal> sein, wie der eingestellt ist?
Ich widme eine Steuerleitung der alten Eingangsstufe um, zu einem Chip
Select für die neue. Von daher stört es, diese Leitung muß penibel
bedient werden. Und wenn man (wie ich) nicht alles auslötet, dann muß
der letzte Analogschalter der alten Stufe offenbleiben, sonst muß man
ihn entfernen.
Die neue Eingangsstufe hat zudem mehr Möglichkeiten, das könnte man in
Zukunft nutzen. Die Verstärkung ist fein einstellbar, die
Bandbreitenbegrenzung hat mehrere Stufen.
Der SPI-Bus kann nicht lesen, nur schreiben, die Einstellungen erfolgen
blind. Sonst ginge das damit ganz gut.
Man könnte das Oszi theoretisch über das gemessene Signal "erfühlen"
lassen, welche Eingangsstufe es hat.
Aber erstmal muß es überhaupt funktionieren. Ich komme frühestens am
Wochenende dazu.
@Hayo: Viele Variablen werden ins Flash geschrieben und davon wieder
gelesen, und da gibt es noch auskommentierte Lücken. Ich habe nun 4
Flags neu eingeführt, die pro Kanal anzeigen ob alte oder neue
Eingangsstufe. Kann ich mir eine solche Lücke aussuchen, oder muß das
aus irgendwelchen Kompatibilitätsgründen frei bleiben?
Jörg
Ich such Dir mal 4 raus. bzw. da es ja eine long Variable ist, könnte
man natürlich auch alle vier Flags in einen Speicherplatz mergen.
-> ich sag gleich bescheid
Hayo
Also da es sich ja um eine feste Hardwareinformation handelt gehört das
ja eigentlich ins Protected Flash. Du könntest die Flags ab
Speicherplatz 80 ablegen.
Wenn Du die Flags lieber ins normale Config Flash schreiben willst würde
ich empfehlen die Werte in der jeweiligen Kanalsektion unterzubringen.
Da bieten sich z.B. an: Speicherplatz 74/92/110/128 -> also nicht
zusammenmergen.
Gruß Hayo
Ein kleines Statusupdate zur Eingangsplatine:
Sie funktioniert, und ich habe sie softwaremäßig "unter Kontrolle". Zwar
noch nicht an allen Stellen der Software, bei Spezialitäten wie
Autorange arbeitet die nämlich an ihren eigenen Funktionen vorbei. Es
sind auch noch keine Kalibrierwerte drin und keine
Konfigurationsmöglichkeit. Ich habe die Einstellungen welcher Kanal
welche Eingangsstufe hat aber immerhin schon wie von Hayo vorgeschlagen
im Protected Flash abgelegt.
Der Anschluß an SPI kann leider doch nicht so wie von mir vorgeschlagen
erfolgen. Der Chip auf der Eingangsstufe mag es nicht, wenn ich ihm zu
lange Datenworte sende. Ich hoffte, er ignoriert die überzähligen Bits,
aber stattdessen akzeptiert er das ganze Datenwort nicht.
Nun wurde es doch "SPI over SPI", Bitbanging mit den bereits über SPI
angesteuerten Registerausgängen. Ist nicht schlimm, nichts wird
langsamer, der Zugriff paßt locker in die Zeit die eh auf die Relais
gewartet wird. Etwas blöd ist nur, daß man sich 2 Signale von der
anderen Seite der Platine holen muß.
An der Hardware der Platinen ist noch Feintuning nötig. Momentan sind
das kleine UKW-Sender, sie schwingen etwas. Andre und sogar Walter
helfen mir netterweise (siehe Skype-Chat), die kriegen das bestimmt hin.
Wenn ich in dieser Software rumfummele kriege ich Zustände. Eigentlich
wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion
hätte und sich dran halten würde. Aber hier sind die Dinge unnötig
kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was
von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den
seriellen Download. Es juckt, da neu anzufangen und eine Codebasis zu
schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem
Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten
beider zugegeben nicht. Hayo, wärst du dabei?
Grüße,
Jörg
Hey Jörg,
ich finde es klasse, welche Fortschritte du erzielst. Nicht nur, dass es
mich freuen würde, wenn die vier Platinchen auf meinem Schreibtisch
irgendwann einsetzbar wären, es freut mich auch für Walter und branadic,
wenn ihre Arbeit Früchte trägt.
Tolle Sache!
Gruß
Michael
Hallo ihr Teilnehmer an der Sammelbstellung der Bauteile für die
Huckepackplatine!
Es hat seitens Digikey einen Fehler beim abpacken gegeben. Aus diesem
Grund sind die Widerstände in 0402 mit 6k8 und 220k vertauscht!
Vor dem bestücken solltet ihr zumindest diese beiden Werte nochmal
nachmessen.
Falls ihr schon bestückt habt und Ersatzwiderstände braucht schicke ich
euch diese kostenlos zu.
Mfg,
Kurt
Hallo an alle,
tut mir leid, dass Ihr momentan so wenig von mir hört. Bin die nächsten
zwei Wochen in Thailand. Melde mich danach wieder. So muß jetzt zum
Flughafen.
Bis dann
Hayo
Hi there,
gruss aus dem sonnigen Thailand - es ist kurz vor 20:00 Uhr und es sind
30 Grad hier - schwitz!
Nach einer Woche Strand habe ich jetzt auch den Kopf wieder frei und
habe eine menge Ideen bezueglich (Umlaute gibts hier nicht auf der
Tastatur) der neuen USTB-Engine. Alles was mir einfiel habe ich
natuerlich sofort am Strand direkt auf das gute alte Offlinemedium
Papier niedergeschrieben. Wenn ich in einer Woche zurueck bin werde ich
mal wieder etwas Bewegung in die Sache bringen.
Vielleicht ist dann ja auch Joerg schon soweit das seine neue
Hardwareansteuerung mit einfliessen kann (sz gibt es auch nicht).
Lasst Euch solange auch die Sonne auf den Bauch scheinen
Gruss Hayo
Don't worry!
I got some new ideas in the meantime on the beach... :)
I will be be back soon and looking forward to go on with the new
version.
Be relaxed and enjoy the summer time meanwhile
Hayo
p.s. going to the beach now to get some more good ideas :)
Hayo W. schrieb:> es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz!
Hallo Hayo,
erwartest du jetzt soetwas wie Mitleid? ;-)
Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand
verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu
sein. Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar
Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen
lassen.
Gruß
Rainer
Rainer W. schrieb:> Hallo Hayo,> erwartest du jetzt soetwas wie Mitleid? ;-)
Nicht wirklich - aber fuer einen Norddeutschen ist das hier schon eine
harte Nummer mit den Temperaturen. Da heisst es langsam bewegen oder
besser garnicht.
> Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand> verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu> sein.
Unbedingt! Die beste aller Ehefrauen hat ca. 24 kg Kriminalromane dabei
und ist froh wenn sie in Ruhe lesen kann - da eroeffnen sich mir
ungeahnte Moeglichkeiten ;-)
> Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar> Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen> lassen.
Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da
schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das
Coding mal auf SFN ansehen.
Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der
RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Ich
hatte leider noch keine Zeit dazu.
Gruss Hayo
p.s. es ist garnicht so leicht an nichts zu denken ;-)
Dann will ich mal was gegen mögliche Langeweile tun. Ich habe die BF.3.0
C5 drauf, weil bei der C6 irgendwas (USTB?) gar nicht lief.
Hayo W. schrieb:> Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da> schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das> Coding mal auf SFN ansehen.
1. Wenn man das (sogenannte) Delayed Fenster geöffnet hat, haben die
dort dargestellten Cursorpositionen nichts mit der Realität zu tun. Im
Screenshot (CursorPos_Delayed) liegt das Fenster in der rechten Hälfte
des Signale. Die beiden Cursur x1 und x2 stehen im Main an der ersten
steigen Flanke bzw. 80 µs dahinter, also außerhalb des Delayed-Fensters.
Die im "Delayed"-Fenster dargestellten Cursor sind im richtigen Abstand,
aber an einer völlig falscher Position dargestellt.
Gerade ist mir aufgefallen, das möglicherweise für die Cursordarstellung
im Fenster einfach auf die falsche Bezugsposition zugegriffen wird: Ein
Cursor, der im "Main" dicht vor dem Fensteranfang steht, wird im
"Delayed" kurz vor dem Fensterende eingezeichnet. (CursorPos_Delayed2)
2. Wenn man die Cursorposition verdreht, werden oft die Zahlenwerte
nicht aktualisiert (z.b. X2 in CursorValue_wrong). Erst wenn man nach
einer Gedenksekunde (gefühlte 3s?) den Universalregler noch einmal etwas
dreht, springen die angezeigten Zahlenwerte auf den richtigen Wert
(CursorValue_ok.png). Wenn man ohne die genügend lange Pause immer
wieder die Position verdreht, findet gar kein Update statt.
>> Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der> RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft?
Das sieht IMHO gut aus, bei AC-Signal ist RMS = 1/2 Peak-Peak
(RMS_ok.png)
Ich wünsche euch noch schöne Tage in Thailand und gutes Tüfteln
Gruß Rainer
So die Angebetete laesst sich am Strand grillen, da hab ich mal die Zeit
genutzt um den Hotelrechner zu maltraetieren. Schnell mal die
wichtigsten Programme installiert und das Coding runtergeladen - so kann
man ja nicht arbeiten ;-)
@Rainer
Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider
grundsaetzlich etwas langsam. Im Delayed-Modus muss man da noch etwas
mehr Geduld haben, da noch mehr bremsende Grafikausgabe dazukommt. Die
Cursorpositionen kann ich aber leider erst zu Hause am Geraet
ueberpruefen - also in 3 Tagen :)
@Joerg
Jörg H. schrieb:> Wenn ich in dieser Software rumfummele kriege ich Zustände.
Willkommen in meiner Welt ;-)
Du Solltest Dir mal den Spass machenb und Dir das alte Origanalcoding
ansehen. Da bekommt man direkt Ausschlag im Gehirn. Mittlerweile ist das
ja schon einigermassen strukturiert.
> Eigentlich> wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion> hätte und sich dran halten würde.
Ich hatte mal angedacht einen Hardware Abstraction Layer (HAL) zu bauen,
es dann aber aus Performancegruenden wieder verworfen.
> Aber hier sind die Dinge unnötig> kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was> von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den> seriellen Download.
Das war zu Anfang noch viel schlimmer. Ich habe zig hunderte Zeilen
"blinden" copy & paste code rausgeschmissen und durch Schleifen bzw.
Arrays ersetzt -> to be continued...
> Es juckt, da neu anzufangen und eine Codebasis zu> schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem> Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten> beider zugegeben nicht. Hayo, wärst du dabei?
Ich hatte davon erstmal abgesehen, weil die Hardware (WELEC FPGA-Design)
des NIOS voellig undokumentiert ist und man vorher die Funktionalitaeten
genau ermitteln muesste. Um schnell brauchbare Ergebnisse zu bekommen
habe ich mir dann immer einige Hotspots gesucht die ich dann Stueck fuer
Stueck ueberarbeitet habe.
Ich hatte mir das fuer das LEON-Design eine entsprechende
Implementierung vorgenommen da es hier wohl eine komplette Doku der
Funktionen geben wird.
Grundsaetzlich waere ich aber dabei. Das duerfte allerdings eine ganze
Zeit dauern bis wir da was lauffaehiges zusammen haben.
So muss jetzt Coctails besorgen...
Gruss Hayo
Hayo W. schrieb:> Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider> grundsaetzlich etwas langsam.
Langsam wäre ja nicht sooo schlimm, aber der Werte-Refresh kommt garnicht, wenn man den Drehregler nach den mindestens 3 s nicht noch
einmal bewegt.
Gruß Rainer
Hayo W. schrieb:> ... Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich> etwas langsam.
So, nach etwas Probieren scheint das Update-Problem deutlich klarer.
Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der
Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem
Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das
Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei
Reglerbegung wieder ein Werte-Update angestoßen.
Ich hoffe, der Sun-Downer hat gemundet.
Gruß Rainer
Rainer W. schrieb:> So, nach etwas Probieren scheint das Update-Problem deutlich klarer.> Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der> Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem> Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das> Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei> Reglerbegung wieder ein Werte-Update angestoßen.
Ok, das ist ein guter Hinweis, da kann ich gleich mal das Coding
durchstoebern nach den Verdaechtigen. Hier ist dank Regenzeit bedeckter
Himmel mit kraeftigen Schauern - das Ganze bei 33 Grad. Da bietet sich
ein kleiner Code-Review geradezu an :)
> Ich hoffe, der Sun-Downer hat gemundet.
Hat er. Geht doch nichts ueber einen Kaipi bei der Waerme.
Nebenbei habe ich mir auch noch Gedanken zum Thema Triggerlevel gemacht.
Es wurde ja schon mehrfach kritisiert, dass der Triggerlevel beim
Umschalten des Spannungsbereiches nicht konstant bleibt sondern
stattdessen die Position auf dem Bildschirm. Das fuehrt dazu das der
Level beim Umschalten jedesmal seinen Wert aendert - anders als bei
einem analogen Oszi zum Beispiel.
Grundsaetzlich liesse sich ein konstanter Level schon implementieren,
aber das Problem ist, dass das Triggerlevel-Register nur 8 Bit breit ist
sprich 256 Werte abbilden kann. Das wuerde dazu fuehren, dass beim
Herunterschalten aus einem hohen Spannungsberech der Trigger in die
Begrenzung faehrt und der angezeigte Level nicht mehr mit dem
tatsaechlichen Trigger uebereinstimmt.
Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die
momentane Loesung also technisch bedingt.
Ich hatte mir allerdings ueberlegt ob ich einen "partiell konstanten"
Triggerlevel implementiere, der z.B. beim Hochschalten von niedrigen zu
hohen Spannungsbereichen konstant bleibt. Das Ganze natuerlich per
Triggermenue auswaehlbar.
Werd mal sehen ob das brauchbar ist.
Gruss Hayo
Hi there!
Hayo W. schrieb:
>Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die>momentane Loesung also technisch bedingt.
Hi Hayo.
Could this be related to the fact that with the Welec's oscilloscopes,
the displayed signal's size depends on the position of the trigger's
threshold?
If the trigger's threshold is low, the signal's amplitude is so and the
waveform is moving, whereas if the amplitude is high it becomes high
itself and the waveform is more steady.
I noticed this when I tested both the W2022A and W2012A for the pulse
responce.
Please, refer to my previous message here
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
Mit Freundlichen Grüßen,
Luc
Hallo Hayo et al,
ich bin selber kurz vor Urlaub, da versuche ich doch mal eine Übergabe
bevor ich die Software nicht mehr wiedererkenne, mit Hayos neuem
Tatendrang!
Der Status zur neuen Eingangsstufe ist wie folgt:
- Im Gehäuse eingebaut habe ich keine Oszillation oder Einstreuung mehr.
Das lag an meinem offenen Aufbau, der hat sich die Signale der
Tastenplatine eingefangen.
- Die Eingangsstufen sind empfindlich. Wogegen ist noch unbekannt, ESD
oder Überspannung. In einem Meßbereich ohne die Relais-Vorteiler habe
ich mir bei Kalibrierübungen mit kleiner Gleichspannung je den
Eingangs-FET zerschossen. Mittlerweile habe ich von Kurt Ersatzteile und
kann die unter kontrollierteren Bedingungen zerstören. ;-)
- Jede Platine verbrät etwa ein Watt, größtenteils am Verstärkerchip.
Der wird in freier Luft über 100°C heiß, in der engen Gehäuseposition
sicher mehr. Wärmekontakt zu dem Stahlblech wäre gut, da liegt er eh
fast an.
- Die Hardwareansteuerung ist in der Software vollständig (Basis BF 3.0
C6), inklusive Programmierung der verschiedenen Gains (1/2/5) und der
Bandbreitenbegrenzung.
- die zur veränderten Empfindlichkeit passenden Skalierwerte in den
Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe
Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen.
- an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch
nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir
derzeit hart reincompiliert.
- Die Software kann keinen echten "Mischbetrieb" der verschiedenen
Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben
diskussionswürdig, ob das überhaupt sein soll und kann. An diesem
prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.
Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins
Flash kommen) und pro Kanal anzeigen, ob neue oder alte Eingangsstufe.
Das wird in Hardware::SetSwitches() abgefragt und je nachdem die neue
oder alte Routine aufgerufen.
Das führt aber nicht so recht weiter, man müßte die Flags überall
abfragen, wo derzeit die Variable "GainIdx" bewertet wird. Zu allem Übel
wird an GainIdx auch noch "herumgefummelt", in Hardware::AutoScale()
wird der vorübergehend auf 1 gesetzt.
In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also
ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen
"ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe
noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und
2er Bereiche, und einen für die 5er Bereiche. (BTW, die Indizes sind
ungünstig, wären besser vertauscht, damit der innere Zugriff schnell
geht. Der letzte Index sollte die 0..255 Tabelle sein. Ferner würde ich
diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann
alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die
Zeichenschleife das nicht tun.)
Nun ja, auch diese Tabelle müßte ich verdoppeln (einmal pro
Eingangsstufe), vor dem Speicherverbrauch schreckte ich noch zurück. Mit
einer Tabelle pro Kanal landet man da allerdings auch.
Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht
korrigiert:
1.) in Hardware::RestoreFromFlash()
statt:
Hardware::SetSwitches(2, -1);
besser:
Hardware::SetSwitches(2, Selected_Voltage_CH2);
2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf,
das tut dem Chip wohl nicht gut. Nur nebenbei, in meinen Projekten habe
ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte
Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem
Timeout, verhindert versehentliches Dauer-Schreiben.
3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß
aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die
Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl
ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am
Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich
drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach
Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt.
Genug für heute, den Sourcecode hänge ich morgen an.
Grüße an nah und fern,
Jörg
Hallo,
wird mir jetzt zeitlich doch arg knapp, deshalb kann ich hier nur noch
einen "Snapshot" hochladen. Ich wollte dass eigentlich noch besser
aufbereiten.
Jörg
Back from Thailand!
Und auch schon wieder aktiv...
@Luc
I guess it is another matter, but I will check this. Thanks for Your
hint.
@Jörg
Das sind eine ganze Menge Hinweise und offene Fragen. Ich werde die mal
durcharbeiten und versuchen alle zu prüfen/beantworten. Mal sehen was
ich schon einbauen kann. Schönen Urlaub.
Gruß Hayo
Hi there!
Welcome back Hayo!
@Hayo
I guess it also and about another matter, I noticed that waveforms shape
are crude and not smooth compare to other DSO when I tested both the
W2022A and the W2012A for the pulse responce.
Is maybe this due to the sin(X/X)'s lack?
I guess the poor graphic representation problem might just to be due up
to now there is not a sin(X/X) interpolation available.
What about this?
Gute Sonntag für alle.
Mit Freundlichen Grüßen,
Luc
Hallo allerseits,
kurzer Report zum aktuellen Stand. Die neue USTB-Engine läuft bereits.
Zur Zeit mache ich noch Fein-Tuning und implementiere die neuen Menüs.
(den Fehler in der alten C6 der die USTB-Funktion blockiert hat habe ich
gefunden und beseitigt).
Wer das in der Zwischenzeit für sich korrigieren möchte:
- in der hardware_t.cpp -> Methode Start_Record habe da leider was
"kaputt optimiert". Richtig muß es so aussehen:
void Hardware::Start_Record(void)
{
if(acq_ready->np_piodata == 0x01)
{
la_pulse->np_piodata = 0x01; //stop record Port On
la_pulse->np_piodata = 0x00; //stop record Port Off
}
READADC(1);
if (NumberOfChannels == 4) // JK
{ READADC(3); } // JK
ADC_Data_Available = 0;
adc_started = true;
start_acq->np_piodata = 0x01; //start record Port On
start_acq->np_piodata = 0x00; //start record Port Off
//printf("Start Record\r\n");
}
Zu den neuen Errungenschaften von Jörg bin ich noch nicht gekommen, ist
aber im nächsten Final Release auf jeden Fall mit drin.
Auch die Cursor und die Werteanzeige im Delayed Modus stehen noch auf
dem Pflichtenzettel.
@Luc
Hi, I'm sorry but until now I didn't check Your problem because I'm
working on the new USTB engine which is just working with its main
functions. I will check that and - if possible - fix it for the next
main release.
Gruß / regards
Hayo
Hayo W. schrieb:> Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte.
Diese FW-Revision hab ich jetzt auf dem 2024 drauf und kämpfe gerade ein
wenig mit der Single-Shot-Funktion. Wahrscheinlich verstehe ich nur an
der Bedienphilosophie etwas verkehrt, vielleicht kann mir ja einer auf
die Sprünge helfen.
Ich habe auf Ch1 mit 2V/div und bei 10MSa/s (glaube ich, ich habe da gar
nicht so genau drauf geachtet, weil ich einfach nach optischen
Gesichtspunkten so lange dran gedreht habe, bis das Signal schön
formatfüllend aussieht ;-)) an einem CAN-Bus gehorcht und wollte das
Datagramm direkt nach dem Einschalten fangen.
Also habe ich den Single-Knopf gedrückt und beim ersten Versuch fängt
das Scope die erste Flanke meistens wunderschön (das klappt aber nicht
immer, und das auch ganz ohne für mich nachvollziehbares Muster). Wenn
ich Single erneut drücke, um die nächste Flanke zu fangen, steht das
Scope ewig scharfgeschaltet da und der Singleknopf leuchtet rot. Ich
habe es noch ab und zu hinbekommen, dass wieder eine Flanke gefangen
wird, wenn ich (teils mehrmals) Run/Stop drücke und dann erst wieder
Single.
Der Triggerlevel steht ca. bei 60-70% der Signalamplitude. Wenn ich das
Ganze mit Tippen des Tastkopfes an Probe Comp versuche, klappt das
Fangen auf jeden Fall öfter, aber auch nicht immer. Daraus schließe ich,
dass es entweder mit der Abtastrate zu tun hat oder ich irgendwas
verkehrt mache.
Wo klemmt's?
Hallo Johannes,
da ich sowieso gerade die Start/Stop Funktion für die neue USTB-Engine
überarbeite, kann ich mir das mal ansehen. Kann sein, dass der Fix den
ich oben als Code gepostet hab das Problem schon löst.
Ansonsten bräuchte ich noch Deine Triggereinstellungen. Am besten einen
Screenshot mit dem Triggersubmenü drauf (Quick Print doppelt drücken)
posten.
Ansonsten komme ich gut voran obwohl es noch einiges anzupassen gibt.
Gruß Hayo
Das große Schweigen im Walde...
Um nicht den Verdacht zu nähren ich würde faul rumhängen hier ein kurzer
Zwischenstand. Ich bin seit drei Wochen fleißig am Programmieren und es
hat sich sehr viel getan. Aktueller Versionsstand ist 3.3 beta. Bis zum
Final Relase 4.0 HE gibt es aber noch viel zu tun. Ich hoffe ich bin zum
Ende der Sommerpause fertig. Da dürfte wieder für jeden was dabei
sein...
For our "out country" friends... ;-)
I'm working hard on the next final release 4.0 HE. Many things have been
changed or fixed. I hope to be ready after german holidays. I think You
will like it...
Gruß / regards
Hayo
der Hayo, es lebt... :-))
und 'nein', du bist wohl das Letzte, der Letzte, was faul rum hängt. :-)
Mal eine kleine Kostprobe von dem, was du verändert hast?
Ansonsten wünsche ich noch einen schönen Sonntach!
Gruß Michael
Moin moin,
da ich gerade größere Umbauten an der Menüstruktur vornehme, ist die 3.3
zur Zeit nicht lauffähig.
Daher hier die 3.2 beta die schon Einiges zu bieten hat. Bitte beachten
- da sich recht viel geändert hat mußte ich wieder einen Config-Reset
durchführen. Ihr müßt also beim ersten Start neu kalibrieren und die
Hardwareeinstellungen neu machen.
Hier in Kürze die Neuerungen:
- Math gefixt
- Zeichenroutinen sind nochmals schneller geworden
- es gibt eine neue Funktion "Center Window" im Displaymenü, die den
Bildschirmausschnitt bei normalen TB auf den Pretrigger zentriert und
bei USTB auf den aktuellen Samplezeitpunkt.
- neue USTB-Engine V2.1 mit 16K Signalbuffer. Sehr viel höhere
Zeitgenauigkeit, unterstützt Memorybrowser, volle
Zerolevelunterstützung, Math-Unterstützung, Quick Print Datenübertragung
wird unterstützt, Invertierung wird unterstützt,
Details im changelog
Über Vorabtestberichte und Fehlerreports freue ich mich natürlich wie
immer.
Gruß und viel Spaß
Hayo
@Charlie
Die kleineren Fixes und Änderungen und auch die Hardwareunterstützung
von Jörg kommen erst wenn die größeren Umbauten beendet sind. Daher auch
der beta-Status.
Gruß Hayo