Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht
realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf
unserer Hardware-Plattform nicht umsetzbar.
branadic
Hi Hayo and guys all!
Hayo schrieb:
> So hier wie angekündigt die C15>> - einige neue Fixes
Hayo, only as a curiosity, has been the external trigger improved?
I think that now it functions much better.
Vielen Dank!!!
Gruß Luc
Hi,
beim weiteren Ausprobieren der neuen Funktionen gefiel mir das
Scrollverhalten der Triggerlinie nicht. Daher bin ich zur Zeit dabei das
zu verbessern. Weiterhin wird derzeit das Invertierte Signal nicht
richtig unterstützt - ist in Arbeit und gibt es nachher.
Leider fallen einem durch die genauere Anzeige mit der Linie auch einige
Unzulänglichkeiten des Triggers mehr ins Auge - ist ebenfalls in Arbeit,
wird aber wohl heute nicht mehr fertig da ich auch noch einige echte
physische Baustellen hier habe die ich abarbeiten muß.
@Luc
All trigger functions have been modified a little bit since last 3
versions so it may be that something changed in the behaviour of the
external trigger.
Hayo
Hallo boys!:)
Luc writes:
With some oscilloscope models amplitude adjustment (Volt/DIVS) may be
going out of calibration passing from coarse to fine and vivecersa, this
can be helpful in the manually measure of the rise or fall time.
Uhmmm, good idea, is no bad to have selectable resolution of the
Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps
between the coarse settings), but perhaps it's impossible.
Hayo writes:
Seht mal im Edge-Menü nach und spielt mal mit dem Triggerlevel. Mir
gefällt das ganz gut. Ich hoffe es kommt bei Euch auch so gut an.
Very nice, thanks!:)
weitererGast writes:
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.
I don't understand, what you mean?
Also Hayo's answer isn't clear for me, please help about this.
branadic writes:
Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht
realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf
unserer Hardware-Plattform nicht umsetzbar.
Interesting considerations.
What about LEON-Design?
Is there a tutorial to upload LEON?
Where?
And about the read elsewhere pickaback is there a tutorial?
Luc writes:
Hayo, only as a curiosity, has been the external trigger improved?
I think that now it functions much better.
Uhmmm, I don't see differences.
And finally, what about LED mods, what is it?
Saluti from Italy.
Antonio.
Hi @all
die aktuellen Neuerungen habe ich leider heute nicht mehr
fertigbekommen, aber ich versuche mal morgen die neuie Version
fertigzustellen
- überarbeitetes Scrolling der neuen Triggerlinie
- neu überarbeitete Zerolinemarker Routine
- gefixte Zeroline Marker im Delayed Mode (y-Position war falsch)
I did not get the new version ready today but tomorrow it should be
available. Changes as above.
Hayo
Hi Antonio!
> Luc writes:> With some oscilloscope models amplitude adjustment (Volt/DIVS) may be> going out of calibration passing from coarse to fine and vivecersa, this> can be helpful in the manually measure of the rise or fall time.>> Uhmmm, good idea, is no bad to have selectable resolution of the> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps> between the coarse settings), but perhaps it's impossible.
I have that function on my analog oszis, but it may be a little bit
tricky to realize it on our Welec-DSO.
> Hayo writes:> Seht mal im Edge-Menü nach und spielt mal mit dem Triggerlevel. Mir> gefällt das ganz gut. Ich hoffe es kommt bei Euch auch so gut an.>> Very nice, thanks!:)
It is only the first try (the trigger line). The scrolling is bad and
inverted signal and delayed mode are not supported correctly. In the
next version it will be implemented correctly.
> weitererGast writes:> 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.>> I don't understand, what you mean?> Also Hayo's answer isn't clear for me, please help about this.
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.
> branadic writes:> Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht> realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf> unserer Hardware-Plattform nicht umsetzbar.>> Interesting considerations.> What about LEON-Design?> Is there a tutorial to upload LEON?> Where?> And about the read elsewhere pickaback is there a tutorial?
I think on the hardware thread You may be lucky. Branadic is one of the
"knowing" guys there.
Beitrag "Wittig(welec) DSO W20xxA Hardware"> Luc writes:> Hayo, only as a curiosity, has been the external trigger improved?> I think that now it functions much better.>> Uhmmm, I don't see differences.
may be dependent of the circumstances
> And finally, what about LED mods, what is it?
See also the hardwarethread.
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
we added two LEDs at the trigger range on the front pannel which are
indicating a waiting trigger and a trigger event. The mod is is very
easy and nice to see!
There are some more mods about that described there.
> Saluti from Italy.> Antonio.
Saluti from Hamburg (Germany)
Hayo
Hello Hayo.
Hayo writes:
> Uhmmm, good idea, is no bad to have selectable resolution of the> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps> between the coarse settings), but perhaps it's impossible.
I have that function on my analog oszis, but it may be a little bit
tricky to realize it on our Welec-DSO.
In fact, I have seen it only in analog oscope.
Are you saying that, although with difficulty, could be added to the
Wittig?
Nice!:)
Hayo writes:
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.
Clear, thanks a lot!:)
Hayo writes:
I think on the hardware thread You may be lucky. Branadic is one of the
"knowing" guys there.
Beitrag "Wittig(welec) DSO W20xxA Hardware"
I'll give it a look, I have some questions, thanks.
Hayo writes:
> Uhmmm, I don't see differences.
may be dependent of the circumstances
I already know is a hardware lack and can't be corrected by the
firmware, I only see the crazy way in which levels change by turning the
trigger level knob: 0mV, 100mV, 300mV, 350mV, 700mV, 1,25V and so:(
...and you must use the normal trigger:(
Hayo writes:
we added two LEDs at the trigger range on the front pannel which are
indicating a waiting trigger and a trigger event. The mod is is very
easy and nice to see!
Ok, thanks.
Good for 4 channel Wittig oscope, but in 2 channel type there are
already the CH 3 and CH 4 LED, why not use them?
And anyway isn't more easy add icons on the screen?
Hayo writes:
Saluti from Hamburg (Germany)
Maybe you don't know but here in Italy you have many fans!:)
There's even a group that talks about your work!:)
Unfortunately it's currently not very active:(, it dozes, but as exit
news after the people awake!:)
Saluti,
Antonio.
Antonio schrieb:> Ok, thanks.> Good for 4 channel Wittig oscope, but in 2 channel type there are> already the CH 3 and CH 4 LED, why not use them?> And anyway isn't more easy add icons on the screen?
yes this suggestion was made by some guys here too. I could do it for
those who want to test it without modifying the scope.
> Maybe you don't know but here in Italy you have many fans!:)> There's even a group that talks about your work!:)> Unfortunately it's currently not very active:(, it dozes, but as exit> news after the people awake!:)
That is nice to hear. So many regards to them from the german forum.
Saluti,
Hayo
Hallo Hayo,
Hayo W. schrieb:> I could do it for> those who want to test it without modifying the scope.
macht das wirklich Sinn oder trennen sich die Versionen der 2 und 4
Kanalgeräte dann?
Wenn man schon mit dem Gedanken spielt eine Huckepackplatine
nachzurüsten, dann sollten die LEDs doch wohl die kleinere Übung
darstellen.
branadic
Ich hatte da drei Ansätze,
- einmal eine Spezialversion, die fest die LED der Kanäle 3 + 4
ansteuert, damit alle das ausprobieren können.
- dann eine hardwareabhängige Version, die nur bei Zweikanalgeräten die
LED von Kanal 3 + 4 ansteuert.
- ein Auswahlmenü im Hardwaremenü, wo man dann beliebige Knfigurationen
aussuchen kann.
Letzteres hatte ich ohnehin schon angedacht um die LED bei Bedarf
abschalten zu können wenn einem das Gflackere auf den Keks geht.
Allerdings muß ich sagen, dass die LED schon einige Mal recht Hilfreich
waren.
Gruß Hayo
Ok, hat etwas länger gedauert, aber hier ist sie die C16.
Die Zero-Marker Routinen sind komplett überarbeit und der Bug im Delayed
Mode ist beseitigt. Die Positionen stimmen jetzt. Weiterhin ist die neue
Triggerlinie jetzt vollständig implementiert und das Scrolling
optimiert.
Das ist gar nicht so einfach, da man hierfür in zwei unterschiedliche
Graphiklayer pro Kanal schreiben muß um ein Flimmern zu vermeiden.
Die Darstellung von Zero-Markern und Triggerlinie ist doch aufwändiger
als man so denken sollte - die Funktion hat mehr als 1800 Zeilen Code
(abzüglich Leerzeilen). Das erklärt auch den Zeitaufwand, denn ich bin
im Prinzip jede einzelne Zeile durchgegangen und habe optimiert bzw.
geändert. Wenn ich das vorher gewußt hätte...
So und als kleines Schmankerl hab ich noch was ins Hardwaremenu
eingebaut. Die LED-Steuerung ist jetzt tatsächlich einstellbar. Wer also
mal ohne Modifikation die Trigger-Indikatoren testen will kann hier die
Optionen "Map CH3" bzw. "Map CH4" wählen.
Viel Spaß
Hayo
Hi Hayo,
wieder mal eine tolle Arbeit von dir.
Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden
Kanälen!
Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level
betätigt, geht der Level unter das Signal.
Siehe Shot.
Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich
nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch
schon so.
Gruß Michael
Edit: Noch was,
...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von
Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen
erlischt, so wie es sein sollte!
Ach ja noch eine Frage,
da wir ja jetzt per Menu die LED-Funktionen steuern können, hat noch
jemend eine Idee was man noch an sinnvollen Ereignissen oder Zuständen
mit den LEDs anzeigen kann?
Hayo
Michael D. schrieb:> Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden> Kanälen!> Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level> betätigt, geht der Level unter das Signal.> Siehe Shot.
Hmm, ich kriege Dein Problem nicht nachgestellt. Bei mir funktioniert
alles wie es soll. Gib mir mal nen Tip was ich machen muß damit Dein
Problem auftritt.
> Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich> nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch> schon so.
Auch hier kann ich das Problem nicht nachstellen. Nach dem Zentrieren
kann ich den Level in beliebige Positionen kurbeln.
Nur noch mal zur Info falls hier ein Mißverständnis vorliegen sollte:
Wenn nur ein Kanal aktiv ist, dann ist Dispatch Channels = Center
Channel, da das ja dann die optimale Verteilung auf dem Screen ist.
> Gruß Michael>> Edit: Noch was,> ...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von> Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen> erlischt, so wie es sein sollte!
Fehler ist schon lokalisiert und beseitigt. Kommt heute Abend mit dem
nächsten Update.
Hayo
Hayo W. schrieb:> Michael D. schrieb:>>> Der Trigger Auto Level funzt nicht im Channel Center modus, bei beiden>> Kanälen!>> Sobald einer der Kanäle im Center Modus sind und dann Trigger Auto Level>> betätigt, geht der Level unter das Signal.>> Siehe Shot.>> Hmm, ich kriege Dein Problem nicht nachgestellt. Bei mir funktioniert> alles wie es soll. Gib mir mal nen Tip was ich machen muß damit Dein> Problem auftritt.>
Ok, Kanal 1=Centermodus, Kanal 2=Centermodus. Jetzt sind beide Signale
(1KHz-Prob) im Center.
Jetzt "Triggerauto-Level drücken dann haut die Levellinie nach unten ab!
Natürlich kann ich dann den Triggerlevel manuell korrigieren, sollte
jedoch automatisch in die richtige Levelpos. gehen, oder?
>> Wenn nur ein Kanal aktiv ist und dieser im "Center" ist, lässt er sich>> nicht wieder in die Ausgangsposition bringen, das war bei der C15 auch>> schon so.>> Auch hier kann ich das Problem nicht nachstellen. Nach dem Zentrieren> kann ich den Level in beliebige Positionen kurbeln.
Jetzt meine ich nicht den Triggerlevel, sondern den Center-Modus!
Ich habe nur "einen" Kanal aktiv, bringe diesen mit dem Softkey in die
Centerpos.!
Drücke ich "Dispatch Channels", müsste er doch wieder in die
Grundstellung gehen??? Dies funzt nur, wenn beide Kanäle aktiv sind,
dann gehen beide Kanäle vom Center Modus auch wieder in die
Grundstellung.
>> Nur noch mal zur Info falls hier ein Mißverständnis vorliegen sollte:> Wenn nur ein Kanal aktiv ist, dann ist Dispatch Channels = Center> Channel, da das ja dann die optimale Verteilung auf dem Screen ist.
Das heißt, das dieser Kanal dann im Center bleibt?
>>> Gruß Michael>>>> Edit: Noch was,>> ...schaltet man die Trigger-LED's im HW-Menu um, bleibt die LED von>> Kanal 3 an und geht nicht wieder aus, die LED von Kanal 4 hingegen>> erlischt, so wie es sein sollte!>> Fehler ist schon lokalisiert und beseitigt. Kommt heute Abend mit dem> nächsten Update.>> Hayo
Hallo Hayo,
gehe mal volgendermassen vor:
Aktiviere beide Kanäle, gib das 1KHz Prob-Signal drauf.
Shot 1
Drücke "Trigger Auto Level" (Alles ist hübsch)
Verschiebe z.B. Kanal 1 in eine andere Position des Display's (nach oben
oder unten), Drücke jetzt wieder "Trigger Auto Level",
jetzt geht der Trigger-Level in die Mitte des Display's und das Signal
zappelt ab.
Shot 2
EDIT:
Sicher kann ich den Trigger-Level manuell korrigieren.
Die Funktion Trigger Auto Level sollte ja dies Automatisieren, oder?
Gruß Michael
Ok ich hab's,
das hängt mit der Zeitbasis zusammen, deshalb hat es bei mir alles
funktioniert und bei Dir nicht.
Ab 25 MSa/s (10µs) hin zu niedrigeren Abtastraten tritt das Problem auf.
Vermutlich liegt das irgendwie am Speicherbereich der für die Berechnung
verwendet wird.
Ich check das!
Hayo
Die Sonntags-Edition C17 hat jetzt eine nochmal überarbeitete Auto Level
Routine.
- die Probleme bei TB < 25 MSa/s sind gefixt
- es werden jetzt auch invertierte Signale mit DC-Offset unterstützt
- die gemapten LED von Channel 3+4 werden jetzt korrekt zurückgesetzt
Die nächste Zeit bin ich wegen einiger IT-Projekte seltener zu Hause und
bin daher hier erstmal nur noch Abends online.
Gruß Hayo
WOW is das ruhig geworden...........
dann fang i mal wieder an, mein liebling der Single mode
Single gedrueckt, dann eine sofkey (unterm display) dann
triggert er nicht mehr ;(
Single gedrueckt, dann Ch1 oder Ch2 dann geht Single aus
unn er triggert auch nicht mehr ;(
was i sonst so probiert habe Hayo, super, tnx!
vlg
Charly
Hi Hayo, Antonio and guys all!
First, thanks You very, very much Hayo for the great job and free time
You provided generously to us!!!
Hayo, I tried your new BF20_prev_C17 release and about it I have a few
things to say.
Hayo W. schrieb:
> - die gemapten LED von Channel 3+4 werden jetzt korrekt zurückgesetzt
I did not expect it to be so useful, maybe because I usually do not
watch the READY and TRIGGERED indicators when I use other oscilloscopes,
but with Welec there are situations where they become valuable: for
example in the EXTERNAL TRIGGER's use (for this also see below, please).
In my opinion this happens because with the EXTERNAL TRIGGER use in the
Welec the NORMAL trigger is preferable so visual trigger's indication
helps a lot.
I have the two channels DSO version so also without any modification the
two LEDs are well visible and the new feature works great just need to
activate it in the HARDWARE menù!
So simple and so useful, now I can not do without TRIGGERED and READY
indicator !
Great job Hayo!!!
Also about LEDs improvement:
@Antonio
Antonio schrieb:
> Good for 4 channel Wittig oscope, but in 2 channel type there are> already the CH 3 and CH 4 LED, why not use them?> And anyway isn't more easy add icons on the screen?
Hi Antonio.
About your last question, I believe the use of two LEDs is better of the
on screen icons because I believe that icons slow the DSO.
You can realize it by yourself looking at the DSO's behavior with 1 and
2 channels and using the automatic measurements and cursors: more are
things on the screen and most the DSO is not fast, I think an updated
icon with the trigger time slow down a lot of the DSO, much better the
two LEDs.
Hayo W. schrieb:
> - die Probleme bei TB < 25 MSa/s sind gefixt> - es werden jetzt auch invertierte Signale mit DC-Offset unterstützt
Hayo thank You very much also for this!
A clarification about a my previous related reply.
It is true there were some small problems, problems I had not noticed,
however what I have expressed about the implementation goodness it was
more related to the way in which the desired result was obtained.
In those circumstances I repeat again:
Luc schrieb:
> Longer I use the two new functions (SET LEVEL TO 50% and TRIGGER VIEW)> and more I am pleased with them.> I think the way they are implemented is truly brilliant, definitely much> better than what Tektronix did for his oscilloscopes TDS200, TDS1000 and> TDS2000 family.> In fact, in this case TRIGGER VIEW is always active, which is good, and> so You save a button!> Of course all of this in my humble opinion.
As I mentioned above, now let's talk a little about the EXTERNAL TRIGGER
and some things I have found.
In order to test the EXTERNAL TRIGGER I bought a simple and inexpensive
function generator.
This my new tool provides sine , square and triangular waves with
frequency up to 2MHz and amplitude up to 10Vpp on 50 ohm load.
With it, also thanks to the implemented READY and TRIGGERED LEDs, I saw
now for my purpose the EXTERNAL TRIGGER work fine, while before did not
always happen to me.
I do not think it is luck, before it did not work even with the 1KHz
probe's compensation signal, now it works also with the signal generator
and other signals.
Of course I have to use the NORMAL trigger and the level adjustment is a
bit difficult, however the EXTERNAL TRIGGER works.
For exampe I put CH1 on clock, CH2 on data and EXTERNAL TRIGGER on the
chip select of a 25AA010A SPI EEPROM and I able to see all the data
packet.
But I sometimes noticed that the little bug in the Mode/Coupling button
reappears.
When External Trigger or LINE is selected in the EDGE menù, COMBI mode
item becomes unavailable in MODE COUPLING menù.
COMBI item turns gray and can not be selected in MODE menù by the
softkey, with the softkey is only possible to select NORMAL and AUTO in
MODE menù.
But repeatedly pressing the MODE COUPLING softkey You can set the COMBI
parameter, as well as NORMAL and AUTO.
when this happens the EXTERNAL TRIGGER stops working, READY and
TRIGGERED LEDs working properly then the trigger is successfully
acquired, but on the screen waveforms are not triggered.
By changing the trigger source to CH1 or CH2, and then putting it as
EXTERNAL TRIGGER sometimes the COMBI MODE bug's problem is fixes, other
times it remains, however, the EXTERNAL TRIGGER stops working and to
make it back to work You must perform a reset.
Still about the EXTERNAL TRIGGER, although this has nothing to do with
the COMBI MODE's problem, seems to me EXTERNAL TRIGGER work only with
positive signals but I must pursue the matter.
With respect to other:
Hayo W. schrieb:
> - neu überarbeitete Zerolinemarker Routine
Hayo, about this I now noticed sometimes ADC and DAC calibrating is not
working well, the offset is difficult to remove even after warmup and in
AQUIRE menù You can not change the filters setting so You press the
softkeys but nothing happens: reset fix the problem.
I do not know if this is important, however I always have the noise
filter activated.
Passing over.
Hayo W. schrieb:
>> Antonio writes:>> Uhmmm, good idea, is no bad to have selectable resolution of the>> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps>> between the coarse settings), but perhaps it's impossible.> I have that function on my analog oszis, but it may be a little bit> tricky to realize it on our Welec-DSO.
Oh, well Hayo, this makes me hopeful.
Hayo, as usual these my observations do not want to be a criticism nor a
imperative for any corrections.
When You're free and especially when You want to do this take a look
around to what I written.
I repeat it is not an obligation, You do it only if You want to do it.
I think You have already done a lot for us and for this I'll never stop
thanking You Hayo!!!
Now enjoy a deserved rest!!!
Hayo again many thanks to You, really thanks very much!!!
RESPECT!!!
Vielen Dank!!!
Gruß Luc
Hi Antonio and guys all!
Antonio schrieb:
>>> Uhmmm, good idea, is no bad to have selectable resolution of the>>> Volts/Div knob (coarse as a 1–2–5 sequence and fine as to small steps>>> between the coarse settings), but perhaps it's impossible.>> I have that function on my analog oszis, but it may be a little bit>> tricky to realize it on our Welec-DSO.>> In fact, I have seen it only in analog oscope.
Not only analog oscilloscopes have that function, for example TDS220
DSO's by Tektronix and other have it.
The problem is that since the implementation of the SET LEVEL TO 50% and
TRIGGER VIEW functions required 1800 lines of code
Hayo schrieb:
> Die Darstellung von Zero-Markern und Triggerlinie ist doch aufwändiger> als man so denken sollte - die Funktion hat mehr als 1800 Zeilen Code> (abzüglich Leerzeilen).
I dare not think how many are needed to implement the function of the
COARSE and FINE in the Volt/DIV's knobs!!!
Other things are interesting and perhaps easier.
Michael D. schrieb:
> Ich hätte da mal einen Vorschlag:> im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x> Messbereiche zur Verfügung!> Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern> und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja> voranden.
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.
However, if one day the COARSE and FINE function will be included also
it would not be bad.;-)
Unlucky for the DPO (Digital Phosphor Oscilloscopes) feature.
Mirko B. schrieb:
> Jetzt die Frage - kann man mit dieser Hardware so etwas wie "Digitales> Phosphor" per Software realisieren?
branadic
> Ist aufgrund der geringen Speichertiefe pro Kanal leider nicht> realisierbar. So wie es ausschaut selbst mit dem neuen LEON-Design auf> unserer Hardware-Plattform nicht umsetzbar.
However hats off to the hardware guys in the forum, it is amazing to
know They also had arrived to assess the possibility of being able to
transform the Welec's DSO in to a DPO!
VERY IMPRESSIVE!!!
Anyway we'll see, surely we will see beautiful things!:-)
I think for now We can be satisfied with what these amazing guys have
made available to us, so many, many thank to all Hardware and Software
guys and to all those who contributed to achieve these great results:
THANKS TO ALL YOU!!!
Vielen Dank!!!
Gruß Luc
Hi Charly hi Luc,
Eure Posts habe ich notiert, sind also in Arbeit. Leider bin ich
momentan tagsüber ziemlich eingespannt und komme nur abends zum
Programmieren.
Zur Zeit baue ich den USTB-Mode (TB > 500ms) um, da dieser, wie einige
von Euch sicher bemerkt haben, durch die schnelleren Zeichen und ADC
Routinen völlig aus dem (Timing) Tritt gekommen ist.
Also nicht wundern wenn ich mich hier etwas rahr mache.
I took notice of Your posts and the bugs are under construction, also
the new Ideas for some additional functions. At the moment my time is a
little bit limited. So don't wonder if I am answering not so quickly.
Actually I'm redesigning the USTB-Mode (TB > 500ms) which is not running
correctly since I speeded up the drawing and ADC routines some Cxx
versions before.
Grüße saluti regards
Hayo
Hallo miteinander, da es immer wieder angesprochen wird: es ist sehr
nützlich, wenn man die x- und y-Einheiten variabel machen kann, z.B. um
beim Betrachten eines V24-Signals genau 1 - 4 Bits pro Kästchen sehen
kann.
Der LeCroy kann das zwar im Main-Display nur in y-Richtung, aber im
Zoom-Display kann man sowohl x als auch y stufenlos zoomen.
(Leider ist dort das Umschalten stufig / stufenlos umständlich (Menü
muss geöffnet werden). Es wäre traumhaft, wenn der Zoom-Knopf auch eine
Drückerfunktion hätte.)
Dazu habe ich mal eine kleines DOS-C programm gesschieben, wie ich mir
das vorstelle. Habe ich leider gerade nicht zur Hand, schicke ich aber
demnächst.
X-Richtung funktionert auf DDS-Basis, der Index in das Sample-Array wird
mit DDS erzeugt, ähnlich wie der lineare Bresenham.
Das ganze ist so einfach, dass man es kaum glaubt.
Y-Richtung ist eine einfache Multiplikation.
Ich habe keine Ahnung, in wieweit stufenlos überhaupt bisher
implementiert ist. Da ich überraschende Reaktionen mit meiner LED-Idee
ausgelöst habe, könnte ich mir vorstellen, dass aus dieses nette Feature
Anklang findet.
ich habe auch noch einen Bug:
Szenario: alle 4 Kanäle am Rechteck Ausgang
Schalten in den Delayed Mode
an der Zeitbasis rumdrehen (da passiert bei mir nur ca. bei jedem 3.
drehen überhaupt was)...irgendwann hat man dann Artefakte im Signal (auf
allen Kanälen) - Triggerung ist auch nicht stabil
Schalte ich dann zurück zu Main, ist immer Kanal 2 um ca. eine halbe
Phase verschoben!
Dies ändert sich auch nicht, wenn ich das Oszi aus und ein schalte.
Nach einem Default Setup ist dann wieder alles ok.
Trotzdem schon sehr schön - die automatische Anordnung der aktiven
Kanäle auf dem Display war das was ich immer vermisst haben (aber noch
nicht wusste ;-))
Viele Grüße,
Mirko
Hi Hayo and guys all!
Hayo W. schrieb:
> I took notice of Your posts and the bugs are under construction, also> the new Ideas for some additional functions. At the moment my time is a> little bit limited. So don't wonder if I am answering not so quickly.
Hayo, again thanks You very, very much for the kind assistance and free
time You provided generously to us!!!
I do not want to be boring and I do not want to appear rude, but I have
another request.
Since we are talking about new ideas for some additional functions I
try, so please excuse me Hayo and excuse me all.
I'm playing around the EXTERNAL TRIGGER and I ask me if possible to add
displaying of the EXTERNAL TRIGGER on the DSO's screen.
I do not mean show the EXTERNAL TRIGGER's level, I mean show the
EXTERNAL TRIGGER's waveform on the screen.
Some oscilloscopes (for example the TDS220 by Tektronix) have this
function, pushing a button on the oscilloscope's screen appear the
EXTERNAL TRIGGER's waveform.
I hope You understand what I mean.
I do not know if it is possible or not, nor if it is hard to do, mine is
only just an idea so sorry to all.
Hayo again many thanks to You for the kindness and patience!
Vielen Dank!!!
Gruß Luc
wäre ein schönes feature - aber meine Meinung ist -erst die Pflicht,
dann die Kür- will heißen, Bugfixing geht vor.
Da aber da ja alle (vor allen Dingen Hayo) hier aus Spaß an der Sache
dabei sind, sind natürlich Ausnahmen legitim.
Viele Grüße,
Mirko
Hi eProfi and guys all!
eProfi schrieb:
> Da ich überraschende Reaktionen mit meiner LED-Idee> ausgelöst habe,
So You've had the excellent idea of the LEDs...
...many thanks eProfi!
Vielen Dank!
Gruß Luc
Hi Luc,
as fare as i remember the circuits, this won't be possible. The
external triggersection is a seperated circuit working around
ttl-levels and tv-triggering. It's output isn't wired to the
adc's input but one of the fpga's inputpins directly.
Regards, Guido
So, im Anhang das TurboC-Programm ddsScope.
Das Programm berechnet einen virtuellen Wellenzug (linear abklingender
Sinus) mit 16k Samples.
Tastenfunktionen:
a,s,d,f: nach links scrollen (verschiedene Schrittweiten)
g : zurück ins Zentrum (Sample 8192)
h,j,k,l: nach rechts scrollen (verschiedene Schrittweiten)
y,x,c,v: x Zoom in
b : x Zoom reset
n.m,,,.: x Zoom out
A,S,D,F: y scroll up
G : y scroll reset
H.J.K.L: y scroll down
Y,X,C,V: y Zoom out
B : y Zoom reset
N,M,;,:: y Zoom in
Enter : redraw Grid
Esc : quit Program
Wie die Zeit vergeht, habe ich vor 14 Monaten programmiert.
Berichtet mir, ob das auf den modernen PC überhaupt noch läuft.
Guten Appetit.
Hallo,
ich wollte generell mal fragen, ob das Scope denn mittlerweile
einigermaßen zu dem gebrauchen zu ist, wozu es eigentlich mal gedacht
war - nämlich messen?
Ich habe zwar schon viel in den entsprechenden Threads gelesen, aber da
braucht man ja mittlerweile mehrere Tage für, wenn man die von oben bis
unten durchlesen und dann auch noch verstehen will.
Nach dem, was ich hier lese, scheint die FW ja mittlerweile schon recht
weit zu sein (wenn Luc sogar schon erste Vergleiche mit LeCroy
anstellt). Wie ist denn im Moment die Geschwindigkeit der Darstellung,
die Reaktionszeiten auf die Bedienelemente usw.?
Bei YouTube findet man ja nur Videos mit der Originalen FW (furchtbar
langsam) oder mit dem neuen VHDL Design (Sauschnell).
Nach dem Abrauchen meines alten 5MHz Scopes klingt das Welec ganz
verlockend: ein Scope (das, wenn es denn taugt, eh nicht mehr als
vielleicht max. 10MHz sehen wird) und eine nette Spielwiese in einem...
;-)
Schönen Gruß an die fleißige Community.
Moin,
ist ein bisschen OT, aber mal eine Frage an die 'Wittig Gurus'
was ist der unterschied zw. dem 2012 und 2022, ausser jetzt das
das 2022 ein 200 Mhz ist, ist das teil wirklich viel besser und
was ist mit der bedienung ? ist die genauso zaeh wie beim 2012 ?
vielen dank & ein schoenes WE
Charly
Hallo Charly,
bei den Untersuchungen in der Anfangsphase dieses Projektes konnte ich
keinen HW- Unterschied zwischen den Modellen 2022A u 2012A feststellen.
Wenn du die unter SF veröffentlichten Schaltpläne betrachtest, dann
siehst du das es nur einen für das Modell 2022A UND 2012A gibt.
Der Einzigste Unterschied der meines Wissens bis dto. offenkundig ist,
sind die besseren Tastköpfe beim 200MHz Modell. Es gab mal Messungen die
gezeigt haben das die 100MHz Tastköpfe nicht nur eine tiefere
Grenzfrequenz haben, sondern es fehlt ihnen ja auch die erweiterte
Abgleichmöglichkeit der 200MHz Modelle (das Zweite C-Poti im BNC
Anschluß)
Irgendwo hatte ich auch mal Fotos von einem zerlegten Tastkopf rein
gestellt...
@ Schlumpfine
Das Welec hat meiner Ansicht nach den Vorteil: es ist relativ günstig
UND man kann seine Wünsche und Verbesserungsvorschläge direkt in die HW
u FW Entwicklung mit einbringen. Für einen Frequenzbereich bis ca. 50Mhz
lassen sich die Welec's inzwischen schon wirklich gut nutzen. Der
Bedienkomfort und die Funktionsvielfalt übertrifft meiner Meinung nach
die Konkurrenz vom China- Billigmarkt Sektor klar.
Gruß, Brunowe
Hi,
nur kurz ein Feedback von mir.
Die Hinweise und Bugs sind notiert.
@Luc
As Guido wrote above, this is a hardware feature, not a firmware
feature. So I am sorry about that, for I must agree that it might be
useful.
@Schlumpfine
Für Deine Anwendungszwecke ist das WELEC mehr als ausreichend. Das Preis
-Leistungsverhältnis ist meiner Meinung nach, seit es Alternativen zur
originalen Firmware gibt, ungeschlagen.
Und es bietet etwas was die Anderen nicht haben: Open Source Firmware +
Community + Support + Experimentierspaß. Nebenbei lernt man auch noch
eine Menge über Meßtechnik und Oszilloskope. Wo kriegt man das sonst?
@Charly
Diese Frage stellt sich wohl jeder WELEC Besitzer und Interessent. Ich
habe ein W2014 und ein W2022. Der Bandbreitenunterschied ist so minimal,
dass ich jedem empfehlen würde Geld zu sparen und lieber die 100MHz
Variante zu nehmen.
Anscheinend wird bei WELEC nur getestet welche Geräte im Rahmen der
Toleranzen bestimmte Werte erreichen und welche nicht und dann
entsprechend gelabelt.
Die Messergebnisse der WELECS bei Frequenzen über 100MHz sind ohnehin
eher als experimentell zu bezeichnen. Ich wollte in dieser Richtung aber
noch mal weiter testen sobald ich über das geeignete Testequipment
verfüge.
Bei mir laufen aber beide Geräte bis 60 MHz völlig problemlos (Höhere
Frequenzen kriege ich momentan nicht hin).
So ich tauche mal wieder ab, die Projektarbeit als SAP-Berater frißt
mich zur Zeit leider auf. Aber keine Sorge, auch wenn es von meiner
Seite momentan etwas ruhig ist, es geht auf jeden Fall weiter.
Gruß an Alle
Hayo
p.s. Respekt an alle die versucht haben den Thread komplett zu lesen ;-)
Haio Thanks! Thanks all! :) This tool now with bf2.0 is reaching amazing
levels, and congratulations for the commitment to also give us the
opportunity to use this to your wonderful work.
Excuse me for the english.....
Hello and thank you! :)
Hallo,
inwieweit kann die neue Eingangsstufe nun mit der bestehenden Hardware
angesteuert werden?
Können wir uns da auf eine gemeinsame Lösung einigen?
branadic
Buona Domenica.
I'm from italian roboitalia forum
(http://forum.roboitalia.com/showthread.php?t=5530&page=45) where from
long time there is a thread devoted to Welec's DSO and where people
often read your forum looking for news.
All roboitalia's users are very satisfied with the results you gained
and for the commitment and expertise you put to improve Welec's DSO, so
we all thank you!
But now I'm not here just to thank you, I'm here also to ask a few
things, things may be possibles or may be impossibles, I don't know.
Possibles or not the question is: can some specific items for measuring
signal such as CAN, I2C, LIN, SPI, USB and so be added in to the
trigger's menù?
Something like this:
http://www.tequipment.net/pdf/Agilent/7000Series_datasheet1.pdf and
http://www.tequipment.net/pdf/Agilent/7000Series_manual.pdf.
Of course not necessarily all mentioned types but only those who can be
easy added.
Due to the trigger weakness in the Welec's DSO I believe it isn't
possible but maybe I'm wrong.
It would be nice if you could do it, otherwise will mean to measure CAN,
I2C, LIN, SPI, USB and so signals will go on as it always has been: will
adjust manually everything, no problem.
Thanks in advance and best regards,
kcirreD
@Hayo: Danke für die Beschreibung und die Antwort. Dann will ich mal
hoffen, daß es für meine Anwendungsfälle wirklich gut geeignet ist.
Ich habe mir mal den Source-Code der BF20-prev12 angesehen. Sehe ich das
richtig, daß in der Firmware kein Gebrauch von Interrupts gemacht wird
und die Bedienelemente fleißig gepollt werden?
Hi @all,
bin leider zur Zeit etwas busy und komme gerade nicht zum
Weiterprogrammieren - ist aber nur vorrübergehend, da das Projekt das
mich zur Zeit etwas in Anspruch nimmt in Kürze beendet ist. Immerhin
sorge ich dafür, dass es bei Feinkost Albrecht leckere Knabbersachen im
Regal gibt ;-)
@Schlumpfine
Nein da liegst Du falsch. Es wird sehr wohl mit Interrupts gearbeitet
(Keyboard, Rotation Interface, Timer, UARTs etc.). Du findest die
Interupt Service Routinen in der hardware_t.cpp und die Interrupthandler
zum Teil in der userif_t.cpp.
Gruß Hayo
Hallo!
Ich verfolge diesen Thread jetzt so ziemlich seit Anfang an
und muß mal ein dickes Lob aussprechen für das Engagement
das in dieses Projekt gesteckt wurde und zu einer Firmware
geführt hat, die der Originalsoftware weit überlegen ist!
Darum habe ich mir vor etwas über einem Jahr auch ein W2024A
zugelegt und dies mehr oder weniger regelmäßig mit den BF Releases
geflashed und mich über die immer bessere Benutzbarkeit und
zahlreichen Features gefreut.
Leider habe ich aber jetzt ein kleines Problem mit dem Scope und
möchte die Experten hier in der Runde um ihren Rat fragen.
Vorgestern habe ich die aktuelle Version geflashed und danach
das Skope für einige Messungen an einem Schaltregler genutzt.
Als ich dann eine Pause gemacht habe, habe ich das Scope (wie vorher
schon mehrmals) abgeschaltet. Beim Wiedereinschalten startete
das Scope dann nicht mehr.
Beim Einschalten wird der Bildschirm kurz hell und wieder dunkel.
Die Run/Stop Taste leuchtet grün. Das wars.
Keinerlei Reaktion auf Tastendrücke. Lediglich die Softkeys für
den Flashloader und Reset funktionieren. Nach einem Reset leuchtet
dann eine zufällige Kombination der LEDs.
Der Flashloader funktioniert einwandfrei. Ich kann flashen, den Speicher
auslesen und auch den Speicherinhalt über ein Terminalprogramm listen.
Ab $40000 stehen auch Werte im Speicher.
Trotzdem startet die Kiste nicht.
Habe auch mal verschiedene Firmwarestände geflashed - keine Änderung.
Hat jemand eine Idee, was ich noch testen kann?
Ich würde mich über Tipps sehr freuen!
Sorry für's off-topic. Die Mods mögen mir verzeihen.
Danke!
Frank
Hmmh,
ob das Display Ärger macht? Da hatte doch schon jemand Probleme, ist
aber länger her.
Gibt es über RS232 noch Meldungen wenn du die Bedienelemnte (vor
allem den Timbase-Drehgeber) betätigst? Dann würde die Firmware
noch laufen.
Nee, das Displlay ist's wohl nicht.
Wie gesagt: Es leuchtet nur die Run/Stop Taste und keine andere
Taste/Drehgeber zeigt irgendeine Reaktion.
Terminal bleibt auch stumm, bis ich in den Germ-Monitor Modus wechsle.
Ich denke, daß die Firmware au irgendeinem Grund nicht gebootet wird.
Wie war das noch: Nach dem Start wird die Firmware aus dem Flash
in's RAM kopiert und dann da gestartet, richtig?
Habe deshalb auch mal die RAM-Variante der BF 1.11 reingeladen. Leider
auch kein Erfolg.
Es scheint fast so, als würde die Software aus irgendeinem Grund
nicht nach einem Reset starten.
Gibt es eine Möglichkeit, im Monitorprogramm manuell die Firmware zu
starten?
Kann es sein, daß der Reset-Vektor nicht korrekt ist?
Frank
Hab' gerade nochmal geschaut.
Am Schluß des Firmware-Files steht ein 'r0'
Das interpretiere ich mal als "Run from address $000000".
Wenn ich aber im GERMSmonitor "m0" eingebe, gefolgt von etlichen
<Returns>, sehe ich lauter FFFF
Ist das normal? Kann das mal jemand verifizieren?
Sollten da nicht irgendwelche Reset-Vektoren stehen?
Oder bin ich auf dem Holzweg?
Frank
Hallo Frank,
das r0 setzt einfach nur das Offsetregister zurück.
Aber nun zu Deinem Problem.
Es kann sein, dass die Werte aus dem Config-Bereich nicht mehr zu Deiner
Firmware passen weil sie irgendwie zerschossen sind. Beim Startup wird
zwar ein Teil neu initialisiert, aber nicht alles.
Probiere folgendes:
Spiele erstmal die beigelegte C18 ein und sieh mal ob das schon hilft.
Wenn das noch nicht hilft, dann spiele Dein komplettes Flashbackup ein
(bei mir war das mit Firmware 1.4, sind ca. 3,1 MByte).
Danach spielst Du nochmal die C18 ein.
Ich habe das eben genauso gemacht und alles klappte prima.
Falls Du kein Backup hast sag nochmal Bescheid.
Gruß Hayo
@Jürgen
Hast Du die Skalierung für Deine 24 Ohm Widerstände schon kalibriert?
Wenn ja, dann lass mir doch mal die neuen Faktoren zukommen, damit ich
die mit in die neuen Versionen einbauen kann.
Gruß Hayo
Hallo Hayo
Vielen Dank für Deine schnelle Hilfe!
Habe das C18 (die Flash Version) eingespielt mittels
./GERMSloader.pl /dev/ttyS0 -w C18/TomCat.flash
Upload wurde normal beendet. Das Scope zeigte keine Reaktion, also
Power-Cycle. Selbes Bild.
Dann auf dieselbe Weise mein seinerzeit gedumptes welec_1.4_dump.flash
(Größe: 3359297 Byte) eingespielt.
Wieder keine Reaktion. Sofort ohne Powercycle nochmal das C18 (flash)
hinterher.
Weder direkt nach dem Flashvorgang noch nach dem anschließenden Reset
gab es irgendeine Reaktion.
Also probehalber noch die C18 RAM Version eingespielt.
Nach Upload leuteten ALLE LEDs. Aber ansonsten kein Erfolg. :-(
Frank
Kleine Ergänzung:
Ich schrieb:
> Nach Upload leuteten ALLE LEDs.
Stimmt nicht ganz. Habe es nochmal probiert.
Während des RAM-Uploads ist wie nach dem Einschalten nur die Run/Stop
LED an.
Ist der Upload abgeschlossen, gehen alle LEDs für ca. 0.5 Sekunden an,
dann sind wieder für ca. 0.5 Sekunden alle LEDs aus und schließlich
gehen wieder alle an und bleiben an.
Kann ich irgendwas helfen? Z.B. einen Speicherdump uploaden o.ä.?
Frank
Hallo Frank,
das heißt, dass der LED Test auf jeden Fall durchlaufen wird. Probiere
mal die beigelegte Emergency Version, bei der die Funktion zum Laden des
alten Zustandes aus dem Flash deaktiviert ist.
Hilfreich wäre es wenn Du die Meldungen die wärend des Starts ausgegeben
werden posten könntest. Wie das mit einem Terminal geht weißt Du nehme
ich an?
An alle anderen: Diese Version bitte nicht benutzen! Es kann zwar
eigentlich nichts passieren, aber es bringt Euch auch nicht weiter.
Gruß Hayo
Hallo Hayo,
habe die im ZIP enthaltene .flash Version wie gehabt eingespielt.
Keine Änderung.
Dann die .ram Version probiert.
Reaktion wie zuvor: Alles LEDs an, aus, an.
Was die Bootmeldungen betrifft:
Beim Einschalten bekomme ich keinerlei(!) Ausgaben vom Scope.
Nur zum Verständnis: Ich habe das gtkterm gestartet, /dev/ttyS0 auf
115200
Baud N,8,1 gestellt und schalte dann das Scope ein.
Keine Ausgaben im Terminalfenster.
Dücke ich die Softkey-Kombination, meldet sich der GERMSmonitor mit
#1F3A3048
TC CPU
+
Danach werden die eingegebenen Zeichen geechot und ich kann auch
kommandos
wie m, r etc. absetzen, die auch beantwortet werden.
Was passiert denn nach dem LED-Test? Vielleicht hängt die Soft ja auch,
weil
irgendwo eine Hardware nicht initialisiert werden kann.
Nochwas: Das LED-Blinken passiert NUR nach dem Einspielen einer
RAM-Firmware.
Löse ich einen Softkey-Reset aus, leuchtet stets eine jeweils zufällige
Kombination von LEDs.
Frank
Hallo Frank,
ich hatte auch mal solche Symptome mit meinem W2012A. Ich habe daraufhin
auf Lötstellen FPGA oder RAM als Fehlerursache geschlossen. Habe die
Originalfirmware 1.4 wieder aufgespielt und mein Gerät nach
email-Anfrage zurück zum Hersteller gesendet. Habe keine Möglichkeit
einen FPGA nachzulöten :-) Das Gerät kam nach ca 14 Tagen zurück und der
RAM war nachgelötet!
Gruß Jürgen
Hallo Hayo,
Hayo W. schrieb:> @Jürgen>> Hast Du die Skalierung für Deine 24 Ohm Widerstände schon kalibriert?> Wenn ja, dann lass mir doch mal die neuen Faktoren zukommen, damit ich> die mit in die neuen Versionen einbauen kann.>> Gruß Hayo
hab ich leider noch nicht gemacht! Bin wohl irgendwie davon
abgekommen...
:-(
Ich nutze z.Zt. die Factory Einstellung. Die passt so leidlich, da ich
ja noch keinen 150 Ohm Abschluss eingebaut habe.
Deshalb bin ich mir noch nicht klar, ob eine Scalierung ohne den 150 Ohm
jetzt Sinn macht?
Gruß Jürgen
Hallo Jürgen,
könnte mir gut vorstellen, daß es sowas auch bei meinem Gerät ist.
Hatte ja schon geschrieben, daß das Scope nicht beim Flashen, sondern
während normaler Benutzung ausgefallen ist.
Das RAM würde ich sogar nachlöten können, wenn ich nur wüsste, daß es
wirklich die Fehlerursache ist.
Eigentlich möchte ich das Gerät ungern einschicken.
Hätte ja auch sein können, daß es mit einem Flashen z.B. des geschützten
Bereiches getan ist.
An dieser Stelle nochmals Dank an Hayo für seine Mühe und prompte Hilfe!
Wenn es wirklich das RAM sein sollte, müsste man das im Prinzip doch mit
dem GERMSmonitor sehen können, indem man das RAM dumped und schaut, ob
das Richtige drin steht.
Irgendwo gab's habe ich doch auch mal eine Memory Map gesehen. Finde
ich aber leider bei SourceForge nicht mehr.
Das Flash liegt ja ab $40000
Darum auch nochmal die Frage: Hilft's, wenn ich einen Memory-Dump
hochlade?
Wenn ja, welche Bereiche?
Frank
@Frank
Einen Memory-Dump scheint mir etwas fraglich. Ich weis jedenfalls so aus
dem Stand nicht, wo was stehen muss. Der GERMS-Monitor hat kein direktes
"Fill" Kommando. Also könntest Du nur versuchen über eine selbst
erstellte S-Record Datei den RAM zu füllen, um danach auszulesen und
einen Fehler in den Daten zu finden... Sehr aufwändig :-(
Gruß Jürgen
Mirko B. schrieb:
> Schon mal mit Fön / Kältespray versucht den Chip (mit der ev. kalten> Lötstelle) zu lokalisieren?>> Nur so als Idee....>> Viele Grüße,>> Mirko
...genau, nimm das Ding auseinander und drücke mal ein wenig auf den
Bauteilen, Steckern etc. herum, es könnte auch ein thermisches Problem
sein.
Die Welec's scheinen bei der Endprüfung der Platinen etwas geschludert
zu haben.
Ich hatte mal einen abstehenden Kondensator auf der Platine und dachte,
ich sehe nicht richtig...
Hi Hayo, was gibt's denn so Neues in der C18 ?
Gruß Michael
Leute,
*** IHR SEID KLASSE ***
Danke für die Hilfe!
Habe mir die Platine jetzt mal genauer angesehen, insbesondere das RAM
(Danke Jürgen!).
A0 von einem der RAM Chips sah sehr verdächtig aus.
Nachgelötet - Bingo! Es rennt wieder.
Die anderen Pins sind auch nicht wirklich toll gelötet.
Verdammtes bleifreies Lot! Damit habe ich schon häufiger Ärger gehabt.
Werde die RAM Chips mal sauber nachlöten.
Nochmal 1000 Dank an alle für Eure Tipps!
Liebe Grüße
Frank
na also, geht doch...
Mach mal ein oder zwei Shots, damit man mal sehen kann, was da los war,
könnte ja sein, das es den Einen oder Anderen mal betreffen könnte!
Ich habe hier noch ein paar Knöppe entdeckt, für was die wohl sind?
Resets vielleicht?
+++++++++ Alles wird gut!!! ++++++++++++
Freut mich dass das Problem gelöst ist!
Zur C18:
Ich probiere noch an den USTB-Routinen, es hat sich für Euch also nichts
Wesentliches geändert.
Gruß Hayo
Hallo zusammen,
arbeitet eigentlich jemand an dem Programmierinterface für die
Huckepackplatinen?
Wäre schön wenn es da auch Fortschritte gibt. :-)
Mfg,
Kurt
Hi Guido, Hayo and guys all!
@ Guido and @ Hayo
Thank You very much for the valuable information about my request to add
displaying of the EXTERNAL TRIGGER on the DSO's screen.
Pity it is not possible to do it, but no problem! :-)
@ Hayo
Again, thanks You very, very much Hayo for the great job and free time
You provided generously to us!!!
Hayo, I tried your new BF20_prev_C18 release and the DSO seems to me
more noisy, perhaps it is only an impression.
I could be wrong, I must investigate it.
Hayo what's new in this version?
I have a question and a request for all who can answer.
Question.
In the AQUIRE's AVERAGE tag how much are the averages?
Request.
Would it be possible to modify the AVERAGE's menu in order to adjust the
averages number?
Seems to me the averages are few and fast signals are distorted.
But perhaps it is make for not slow the DSO.
Still in AQUIRE's menù would it be possible to add Peak Detect
acquisition mode?
But perhaps NORMAL tag in the AQUIRE's menù already make that function.
Hayo again many thanks to You for the new firmware's release!
RESPECT!!!
Vielen Dank!!!
Gruß Luc
Hi Frank, Hayo and guys all!
@ Frank
Frank You were really good, my most sincere congratulations to You!
My most sincere congratulations also to all those who helped You!
I am really very happy! :-)
RESPECT to You and who helped You!
Hayo W. schrieb:
>Zur C18:>>Ich probiere noch an den USTB-Routinen, es hat sich für Euch also nichts>Wesentliches geändert.
Thank You very much for the information!
Vielen Dank!!!
Gruß Luc
Hello everybody,
I just can fall into Luc's line. Amazing!!!!! Thank you all very much,
particularly Hayo!
On Skype and here I try to follow. Since I'm moving to another place,
I'm a little short of time.
Branadic and Kurt Bohnen asked about support for the Huckepackplatinen,
but right now Hayo may have no time implementing that?
Since having that leak of time right now, is there any ordering thing
for components of the Huckepackplatine going on?
Cheers, Peter
Hallo Kurt,
Kurt Bohnen schrieb:> Hallo zusammen,> arbeitet eigentlich jemand an dem Programmierinterface für die> Huckepackplatinen?> Wäre schön wenn es da auch Fortschritte gibt. :-)
Solange wir hier das "Henne-Ei"-Problem pflegen wird das wohl nichts!
Soll heißen, die Softwerker warten auf die Hardware-Infos und die
Hardwerker wartet auf die Software.
Wie soll jemand die Software schreiben wenn er keine funktionieren
Platine aufbauen kann weil die Bestückungs-Informationen nicht
veröffentlicht werden?
Aus meiner Sicht lässt sich die Software nicht entwickeln ohne Tests mit
der Hardware.
Ich verstehe auch nicht, warum der letzte Hardware-Stand der Platine
nicht veröffentlicht wird, damit Testplatinen aufgebaut werden können.
Gruß Bert
Hallo zusammen,
habe gemerkt, daß in C16 die langsamen Zeitbasen nicht stimmen.
Bei 5sek/ und langsamer wird immer mit ca. 2sek/div gemessen.
Ab C17 friert mein 2024A komplett ein, wenn ich 2sek/ oder langsamer
anwähle und 2-3 Sekunden laufen lasse.
Ist das nur bei mir so?
Danke!
Lothar
Nur die Ruhe Lothar, Hayo arbeitet doch an dem Problem. Er
kürzt halt diesen Bereich mit USTB (UltraSlowTimeBase) ab,
damit es nur eingeweihte verstehen. ;-)
Gruß, Guido
Großartig Bert, so wird einem also das Engagement gedankt. Du hast
meinen tiefsten Dank dafür, ganz ehrlich!
Das der Bestückungsplan zur Platine, die wir übrigens in unserer
Freizeit entwickeln, weil wir so unendlich viel Langeweile haben, noch
nicht veröffentlich ist liegt, wie ich schon einmal geschrieben habe,
daran, dass ein paar wenige Bauteilwerte noch evaluiert werden müssen.
Walter ist momentan dabei sein Oszi so zu modifizieren, dass er die
Programmierung von außen vornehmen kann, um Messungen durchzuführen.
Und weil wir natürlich so unendlich viel Langeweile haben und nur zu
faul sind, sind diese Messungen noch nicht abgeschlossen und somit die
finale Bestückung noch nicht klar. Wir sollten uns wirklich schämen.
Und somit hast du natürlich vollkommen recht, es ist unverständlich,
dass wir noch nicht alles veröffentlich haben was Layout, Schaltplan und
Bestückung angeht. Wenn ich fünf Minuten Zeit finde werde ich mich in
die Ecke stellen, ist das okay für?
Jetzt mal im ernst, schämst du dich nicht hier so aufzutreten?
Das der LH6518 über eine SPI-kompatible-Schnittstelle verfügt wurde hier
schon diskutiert und zig mal erwähnt und wie diese grundsätzlich
anzusprechen ist wurde in den Messprotokollen beschrieben und findet man
auch im Datenblatt des Bausteins. Und diese Info ist nicht neu!
Aber, es wurde hier noch nicht endgültig festgelegt, welche Anschlüsse
für diese SPI-Schnittstelle auf dem Mainboard des Welecs zum Einsatz
kommen sollen. Und das ist ein Punkt, das schrieb ich auch bereits, den
wir gemeinsam diskutieren und festlegen müssen.
Ich bin ein Freund von Jungs, die sich ins gemachte Boot setzen und dann
Forderungen stellen. Da triffst du mich genau auf dem richtigen Senkel.
Wenn du zu bequem bist die Diskussion aufmerksam zu verfolgen und zu
sehen, dass ich diese offenen Punkte mehrfach angesprochen habe, aber
niemand drauf einsteigen wollte, dann halte dich mit solchen
Formulierungen in Zukunft bitte zurück, das stinkt mir nämlich und zwar
gewaltig!
branadic
Alles klar Guido,
hatte die Abkürzung tatsächlich nicht verstanden.
Wollte auch nicht hetzen und gebe zu, daß ich in letzter Zeit den
Thread nicht aufmerksam gelesen habe.
Übrigens: Ich bin begeistert, was die Software inzwischen alles kann!!
Wünschte, ich könnte was beitragen.
Lothar
Hi Folks,
don't worry. All that is under construction, but the time is a little
bit short in the moment because of my main business as SAP consultant.
Hi Leute, keine Aufregung, einige Sachen brauchen halt etwas länger, da
ja der Beruf auch seinen Tribut fordert.
@Kurt
Bin noch nicht dazu gekommen. Hatte gehofft, dass Stefan vielleicht in
der Zwischenzeit dazu käme, aber er ist wohl auch ziemlich busy
momentan.
Ich muß mir mal die bisherige Ansteuerung raussuchen und dann mal mit
Eurer Hilfe versuchen die Ansteuerung anzupassen.
@Luc
Thanks for the Ideas, I will check if it is possible to implement it.
The noise may be indeed a little bit more, because of a hardware
settings reset!! You have to adjust Your Oszi oncemore! I'm sorry, I did
that for Frank to try a new initialization.
@Lothar
Sorry für die Abkürzungen, nochmal zur Erklärung: Ab Timebases 1s/div -
100s/div schaltet das Oszi automatisch in eine andere Betriebsart um.
Die Abkürzung steht halt für "Ultralangsame Zeitbasen" (USTB). In den
originalen WELEC-Firmwares werden die Zeitbasen überhaupt nicht
unterstützt. Hier wird die Hardware einfach auf 50ns/div geschaltet -
wenig hilfreich.
Wie Guido schon sagte, bin ich zur Zeit dabei. Durch die neuen
schnelleren Zeichen- und ADC-Routinen hat sich das sensible Timing der
USTB-Bereiche ziemlich verschoben. Ich probiere momentan einen ganz
neuen Ansatz, der aber noch bisweilen hakt.
Was Ihr beitragt, nämlich Eure intensiven Tests und Rückmeldungen helfen
mir enorm weiter!
@all
noch mal für alle die die C18 eingespielt haben:
Ich habe die Hardwaresettings zurückgestellt um bei Frank zu prüfen ob
das hilft. Ihr müßt Euch also nochmal ins Hardwaremenü hinabhangeln und
alles neu einstellen (ADC-Offset, DAC-Offset, Hardwaresettings). Tut mir
leid aber das mußte ich ausprobieren.
Gruß Hayo
Hi Hayo,
wollte nicht quengelig sein. Es fiel mir nur auf.
Hatte halt den Neueren Teil des Threads nicht aufmerksam gelesen.
Als der Frank und ich gestern an seinem Oszi gebastelt haben, fiel uns
noch was auf: Auf seinem Oszi ist Kanal 2 nach dem Einschalten stark
dejustiert. Bei meinem Gerät nicht.
Bei ihm läuft C18 bei mir C16.
Liegt das an den von Dir zurück gestellten Hardware Settings?
Dann sollten wir bei Frank's Oszi wohl auch besser wieder die C16
aufspielen.
Lothar
Hi Lothar,
Ihr könnt die C18 ruhig weiter benutzen, Ihr müßt nur das Gerät einmal
neu kalibrieren wie oben beschrieben dann ist alles wieder gut.
Gruß Hayo
>Bin noch nicht dazu gekommen. Hatte gehofft, dass Stefan vielleicht in>der Zwischenzeit dazu käme, aber er ist wohl auch ziemlich busy>momentan.
Das Hauptproblem ist momentan eigentlich eher, dass mein "svn update"
ins leere läuft und ich nicht 8 Wochen alte Sourcen ändern will.
Gruß,
Stefan
Ok,
hier ist die aktuelle C18 Source. Momentan ändere ich nur die USTB
Routinen, alles Andere ist erstmal stabil.
Da ich momentan nur wenig Zeit habe werde ich mich um die
Hardwareansteuerung erst in ein oder zwei Wochen kümmern können. Wenn Du
das vorher schaffst, wär das natürlich super!
Der Gedanke war, wenn im Hardwaremenü die Option "Addon" gewählt wurde
(MenuStatus[18][1] == 234), das dann die alternative Hardwareansteuerung
zum Zuge kommt. Also einfach IF...ELSE....
Mir ist nur noch nicht ganz klar ob das in der
<Hardware::SetDacOffset()> gemacht wird oder woanders.
Gruß Hayo
Hallo,
aufgrund der Klasse Arbeit von euch hab ich mir in der e-bucht von Herr
Wittig ein w2022 ersteigert, vorne am Gehäuse fehlt das (a), beim booten
zeigt es aber w2022a und 8C7.0E v1.4 an.
Bedeutet das, das Herr Wittig bereits den Hack W2022 -> W2022a
durchgeführt hat und ich Problemlos eure Firmware aufspielen kann?
Aber Achtung, bevor jetzt einige in die Bucht rennen:
Das Gerät war definitv nicht neu - Stromkabel in Frühstückstüte
verpackt,...
Beste Grüße
Mike
@Mike
Ich zitiere in Auszügen aus einer Mail von Wittig:
"... das W2022 ist das selbe DSO wie das DSO W2022A. ... denn meine
Aufkleber sind ausgegangen."
Sind wohl immer noch aus.
@Walter
Der U24 wird, soweit ich das derzeit beurteilen kann, in der Firmware
nicht angesprochen. Sollte also unbenutzt sein. Aber dahinter kann man
den LMH nicht klemmen, weil dann hätte ich ja ein 32 bin-Datenwort. Von
den 32-bit, die in der Firmware gesetzt werden, gehen aber 3bit auf die
Adresse. Also kommen wahrscheinlich nur 24bit draußen an. Und das
Datenwort in zwei Teile aufzuteilen, geht glaube ich nicht so trivial.
@Mike
Das Thema gab es schon zu Anfang dieses Threads - vor 2 Jahren!
Meine Geräte haben auch kein "A", sind aber definitiv A-Geräte. Also
keine Sorge. Alle Geräte die jetzt vertrieben werden sollten A-Geräte
sein.
Gruß Hayo
Hi Hayo and guys all!
Hayo W. schrieb:
>The noise may be indeed a little bit more, because of a hardware>settings reset!! You have to adjust Your Oszi oncemore! I'm sorry, I did>that for Frank to try a new initialization.
Hayo, as usual You are right!
Yes, that's it.
Actually after my post I had figured out why of the noise but I have not
had time to correct me and You were faster than my fix!
Anyway thanks for the help Hayo!!! :-)
Hayo W. schrieb:
>Thanks for the Ideas, I will check if it is possible to implement it.
Thank You for your great kindness and patience!!!
It would be nice it could be done, as it would be nice would be
implemented the above suggestions also: I do not lose my hope! :-)
Hayo again, thanks You very, very much for the time You provided
generously to us and for your great job !!!
RESPECT!!!
Vielen Dank!!!
Gruß Luc
Hallo Hayo,
ich habe inzwischen die Platine in Kanal 1 integriert und die Steuerung
hinausgeführt mit der Absicht, die finale Anpassung durchzuführen.
Danach käme der Bericht damit es auch alle nachbauen können … aber erst
muß ich es zum Laufen bringen…
Ich hab die BF20_prev_c17 drauf und den LTC2612 (14bit DAC) gegen den
LTC2602 (16bit DAC) ausgetauscht – dieser DAC ist nur für Kanal 1 und
Kanal 2 zuständig, bei Kanal 3 und 4 habe ich keine Änderungen gemacht.
Die Spannung am 16bit - DAC Ausgang kann ich direkt messen- diese sollte
zw.
-2.5V und +2.5V einstellbar sein.
Nun zu den Problemchen und Fragen:
1. die Ausgangsspannung des DAC nach Einschalten ist 1,25V (sollte 0V
sein). Nach langem drehen komme ich nach unten auf 0V und das ist der
Anschlag – darunter geht nicht. Vermutlich steuert die SW den Bereich 0V
bis 2.5V durch – sollte aber von -2.5 bis +2.5 gehen (MSB nicht
beeinflußbar?). Kann das jemand bestätigen?
- den gesamten Offsetbereich zu verfahren kann bei 14bit schon lange
dauern, bei 16bit noch schlimmer.
Bei anderen Geräten benutzt man die Knopf-Dreh-Geschwindigkeit als
Skalierung für den increment/decrement … Auch die eingestellte
Empfindlichkeit sollte darauf Einfluß haben…
2. Ich bekomme keinen Strahl angezeigt (genauer – eine gerade Linie ganz
oben im Bildschirm, als ob das Signal einen positiven Offset hätte – was
nicht zutrifft. Die Offseteinstellung hilft mir nicht, das Signall
mittig zu bekommen. Auch nicht für Kanal 3 wo ich keine HW-Änderungen
gemacht habe (s.Foto). ADC Kalibrierung hab ich auch ausprobiert –
erfolglos. Hast Du ein Tip für mich?
Falls ich die Antwort meine Fragen irgendwo übersehen habe, bitte ich um
Entschuldigung.
Gruß
Walter
Hallo Hayo,
hab heute die 150 Ohm Widerstände eingebaut. Die Faktoren für 2 x 24.9
Ohm und 150 Ohm lauten:
ScaleFactor: 3.674 fuer 1-er und 2-er und 2.949 fuer 5-er
DAC-Scalefactor: 0.612, 1.224 und 3.059 entsprechend
Schönen Abend!
Jürgen
@Walter
Wenn ich das richtig verstanden habe ist der LTC2612 pinkompatibel gegen
den LTC2602 getauscht worden.
Der DAC (LTC2612) im original WELEC wird mit 8192 auf die Hälfte des
Grids eingestellt und hat bei 16384 seinen Fullscalewert, der aber schon
außerhalb des Grids liegt.
Der LTC2602 hat seinen Fullscalewert aber bei 65536 und müßte demnach
für die Gridmitte mit 32768 angesteuert werden. Hier müßten also die
Werte angepasst werden, damit der DAC im richtigen Arbeitsbereich
landet.
Soll ich da mal eine Testversion mit den entsprechenden Werten basteln,
oder ist Stefan da schon dran?
Gruß Hayo
habe heute mal die aktuellese draufgespielt, Wahnsinn was sich alles
verbessert hat, danke Hayo. Wollte dich aber trotzdem nochmal fragen ob
du das mit der geringeren Auflösung mal probiert hast, da du meintest
der Aufwand wäre nicht so groß. Vielleicht ist es auch wieder
verschwunden da ich nicht alle Firmwares ausprobiert habe.
Wegen aktueller Anfragen zum Umrüsten der Widerstände und des Anpassens
der Skalierung:
Ich habe gestern endlich adäquates Testequipement erworben um
Hochfrequenzmessungen bis 140MHz durchführen zu können. Im Laufe der
Woche sollte der Signalgenerator bei mir ankommen.
Bitte wartet noch mit der Umrüstung der Widerstände bis ich da nähere
Infos zum Nutzen gesammelt habe, es ist immer noch nicht klar ob das
wirklich Vorteile bringt.
Wer schon umgerüstet hat und seine Faktoren selbst anpassen möchte
braucht die Möglichkeit die Sourcen zu kompilieren. Es wurden ja schon
Anleitungen für Windows und Linux gepostet. Ansonsten einfach nochmal
anfragen.
Die Anleitung zum Justieren der Faktoren hatte ich weiter oben schon mal
für Jürgen gepostet, ansonsten auch hier einfach nochmal fragen.
Gruß Hayo
Thomas O. schrieb:> Wollte dich aber trotzdem nochmal fragen ob> du das mit der geringeren Auflösung mal probiert hast, da du meintest> der Aufwand wäre nicht so groß. Vielleicht ist es auch wieder> verschwunden da ich nicht alle Firmwares ausprobiert habe.
Hi, ja ich habe es ausprobiert und mir fiel auch wieder ein, dass ich es
schon mal ausprobiert hatte. Leider hat es nicht so funktioniert wie
erwartet, es gab leider keine Verbesserung. Daher habe ich weiterhin den
Filter drin, da dieser zuverlässig das Rauschen vermindert.
Gruß Hayo
Hallo Hayo,
„Wenn ich das richtig verstanden habe ist der LTC2612 pinkompatibel
gegen den LTC2602 getauscht worden.“
- der ist auch SW-kompatibel. Soll heißen, MSB (D13 bei LTC2612 bzw. D15
bei LTC26102) befindet sich an der gleichen Position.
Aussteuerungsbereich (ausgangsspannung) dürfte mit gleicher SW
unverändert bleiben, nur dass Du die letzten 2 bits auch noch
programmieren kannst – das macht 4 Schritte dort, wo jetzt nur 1 möglich
ist. Siehe auch S.11 der spec…
Das Problem, was ich angesprochen habe dürfte auch den LTC2612 betreffen
– deswegen habe ich das Bild von Kanal 3 gepostet, der ist bei meinem
Oszi unverändert – und trotzdem bekomme ich den Strahl nicht mittig?
Gruß
Walter
Hallo Walter,
habe ich da einen Denkfehler?
Also das Datenwort wird doch seriell eingespeist. Beim Einen ist es 14
bittig beim Anderen 16 bittig.
D.h. doch nach meinem Verständnis, bei einem Range von -2,5...+2,5 dass
bei
- 14 Bit 0x0000 = -2,5V und 0x3FFF = +2,5V -> 0x1FFF = 0V
- 16 Bit 0x0000 = -2,5V und 0xFFFF = +2,5V -> 0x7FFF = 0V
oder andersherum bei Nullansteuerung des 14 Bit DAC (8191 = 0x1FFF) gibt
der 16 Bit DAC -1,87V aus, was im Grid einen Vollausschlag bedeutet,
deshalb "klebt" die Linie auch bei Dir am Gridrand würde ich sagen.
Liege ich da jetzt völlig falsch?
Warum der Kanal 3+4 auch Probleme machen trotz unveränderter Hardware
kann ich mir momentan auch nicht erklären.
Gruß Hayo
Hallo Hayo,
die Sache ist die, dass die beiden leeren Stellen beim LTC2612 hinter
dem LSB sind.
D.h., die Schreibweise ist rechts bindend bzw. FFFF bedeutet das gleiche
beim LTC2602 wie beim LTC2612, nur das letzterer die beiden letzten
Stellen ignoriert.
Gruß
Walter
Das hieße ja, dass für die 14 Bit Version die Werte immer um 2 Bit nach
links geschoben werden müssen bevor sie in den seriellen Eingang
gefüttert werden. Da muß ich mal in der Firmware nachsehen ob ich da
sowas finde.
Trotzdem ändert das aber doch nichts daran, dass der Nullpunkt und der
gegenüberliegende Endwert bei 16 Bit nicht mit den gleichen Werten zu
erreichen ist wie bei 14 Bit, oder habe ich da ein Brett vorm Kopf.
Hilf mir mal auf die Sprünge.
Gruß Hayo
Habs nochmal kurz gecheckt, der Wert wird tatsächlich um 2 Bit nach
links verschoben, wobei die Shift-Operation von mir stammt, vorher wurde
mit 4 multipliziert - was ja völlig bekloppt ist. Hier die Routine für
Kanal 1:
BufInt = CH1_DAC_Offset;
//BufInt2 = (0x00310000 | (BufInt * 4));
BufInt2 = (0x00310000 | (BufInt << 2));
// Bei gelegenheit gegen Turnbits tauschen
outbuf = (0x60000000 | BufInt2);
serdata->np_piodata = outbuf;
serstartsw->np_piodata = 1;
serstartsw->np_piodata = 0;
Gruß Hayo
Hallo Hayo,
mit Deiner SW sollten sich beide LTC26x2 absolut gleich verhalten, es
braucht nichts verschoben zu werden.
- 14 Bit 0x0000 = -2,5V und 0x3FFF = +2,5V -> 0x1FFF = 0V
- 16 Bit 0x0000_ = -2,5V und 0x3FFF_ = +2,5V -> 0x1FFF_ = 0V
der Unterstrich markiert 2 zusätzliche Bits, die bei 14bit egal sind,
bei 16bit nicht. Die können wir erst mal außer Acht lassen, sonnst
verrutscht die ganze hexa-portionierung.
Aus irgendeinem Grund starten aber die DACs bei 3/4 Bereich (ev.0x2FFF
oder 0x3000) statt bei 50% Bereich wie oben. Kann es sein dass sich eine
1bit Verschiebung irgendwo eingeschlichen hat?
Gruß
Walter
wenn ich die Offseteinstellung ausreichend drehe, müsste ich irgendwann
negative Werte erreichen können. Das klappt nicht. Das kann mit keinen
Einstellungen zusammenhängen, es kann nur daran liegen, daß die 2 MSB im
DAC auf 1 bleiben...?
@ Stefan
"Machen das beide DACs, also neu und alt? Ich schau mal nach."
Genau habe ich es nur mit dem 16-bitter gemessen, der andere verhält
sich ähnlich (Strahl am Anschlag oben)
Gruß
@Walter
Probier mal diese bin-Datei. Beim Verändern des Offsets wird dem DAC von
Kanal 1 0 als Wert gesendet und Kanal 2 auf 0x8000 gesetzt unabhängig
vom Knopf. Schau mal, was da rauskommt.
Hallo Hayo und Stefan,
Entwarnung! Hab den Übeltäter gefunden – das Notebook, welches ich als
serielle Eingabequelle benutze hat die -2.5V (interne Masse für den
Oszi) mit 0V (externe Masse für’s Notebook) kurzgeschlossen.
In Akkubetrieb funktioniert aber alles prima. Ich kann das
Eingangssignal sehen und kontrollieren, demnächst fange ich also mit den
finalen Anpassungen an.
Für alle diejenigen, die das PCB jetzt schon bestücken wollen – anbei
meine aktuelle Schaltplan-Version sowie ein unvollständiges
Bestückungsplan vom PCB und meine Löthilfe für den LMH6518.
Eine Korrektur ergab sich an Pin 3 des MAX4477 – der Pin sollte etwas
nach oben gebogen werden damit kein Kontakt zum unterliegenden Pad
entsteht. Später wird er per Draht an der Oszi-Platine angeschlossen,
weitere Details werden folgen.
In Abhängigkeit von den Messergebnissen könnten sich einige Widerstands-
und Kondensatorwerte noch ändern.
Gruß
Walter
Hallo.
@Hayo:
Vorab: Ich will nicht Klugscheißen, sondern Dir Arbeit ersparen. Wenn
ich hier überflüssiges oder selbstverständliches poste, ignoriert das
bitte.
Wenn ich das richtig sehe, wird zum Übersetzen der Quellen ein
gcc-Derivat verwendet. Ich vermute mal Du hast dir das Kompilat Deiner
Quellen (im Assembler) noch nicht angeschaut, sonst wäre Dir
wahrscheinlich aufgefallen, das so ein moderner Kompiler durchaus gut
optimieren kann. D.h. unter anderem, das der Kompiler automatisch 2^n
Multiplikationen/Divisionen (von Intergerwerten) durch die
entsprechenden Shift-Operationen ersetzt.
Wenn ichs richtig erkenne, übersetzt Du üblicherweise mit -O2, das ist
die zweithöchste Optimierung, es gäbe noch -O3 (wird noch schneller...)
oder alternativ gibt es noch -Os, für das kleinste Kompilat.
Ich möchte nur, das Du Deine Zeit nicht damit verbringst Optimierungen
vorzunehmen, die vermutlich keine sind und Dich lieber den funktionalen
Verbesserungen widmest. Lieber sauber lesbar Codieren, den Rest erledigt
der Compiler. (Geschwindigkeits-) Optimieren kann man dann da wo es
langsam wird bzw. wirklich zu langsam ist.
Viele Grüße,
Rainer
Hayo W. schrieb:> Habs nochmal kurz gecheckt, der Wert wird tatsächlich um 2 Bit nach> links verschoben, wobei die Shift-Operation von mir stammt, vorher wurde> mit 4 multipliziert - was ja völlig bekloppt ist. Hier die Routine für> Kanal 1:>>> BufInt = CH1_DAC_Offset;>> //BufInt2 = (0x00310000 | (BufInt * 4));> BufInt2 = (0x00310000 | (BufInt << 2));>> // Bei gelegenheit gegen Turnbits tauschen> outbuf = (0x60000000 | BufInt2);>> serdata->np_piodata = outbuf;> serstartsw->np_piodata = 1;> serstartsw->np_piodata = 0;>>>>> Gruß Hayo
Hallo Rainer,
danke für den Tipp. Ich muß zu meiner Schande gestehen, dass ich mich in
der Richtung noch nicht so richtig schlau gemacht habe - auch wenn ich
schon seit über 2 Jahren mit gcc arbeite. Ich hatte mir das aber schon
gedacht, dass der Kompiler hier etliche Optimierungen vornimmt.
Trotzdem würde ich an dieser Stelle die Shift-Operation vorziehen, da es
ja auch genau diesen Zweck hat, nämlich die Bits nach links zu
verschieben. Hier handelt es sich ja nicht um eine verkappte
Multiplikation.
Gruß Hayo
Apropo,
> // Bei gelegenheit gegen Turnbits tauschen> outbuf = (0x60000000 | BufInt2);
mal abgesehen davon, dass Gelegenheit groß geschrieben wird und solche
Kommentare in englisch verfaßt werden sollten - weiß jemand was der
WELEC-Programmierer hier mit Turnbits gemeint haben könnte?
Gruß Hayo
Hallo allerseits,
heute ist mein neues HF/RF Equipement angekommen. Ich konnte natürlich
nicht umhin gleich mal ein paar Vorabmessungen vorzunehmen.
Hier schon mal einige grobe Erkenntnisse:
- Die WELECs schlagen sich in der High Frequency Einstellung gar nicht
mal so schlecht wie allgemein vermutet
- die geänderten Widerstände scheinen sich tatsächlich positiv auf
Messungen in höheren Frequenzbereichen auszuwirken (f > 30 Mhz)
Testumgebung:
- Signalgenerator Leader 3216 (bis 140 Mhz Sinus)
- Referenzoszi Tek 2465A (350Mhz)
- W2014A mit Originalbestückung
- W2022A mit 33 Ohm und 150 Ohm Widerständen in der Eingangsstufe
Das W2014A läßt sich bis 20 Mhz durchaus ganz gut einsetzen, danach wird
die Dämpfung zu stark. Bei 50 Mhz sind von 2,7Vpp nur noch 1,9Vpp übrig
Bei 100Mhz noch 1,35Vpp.
Alles ohne Schwingungsneigung oder andere Verzerrungen. Der Trigger ist
manchmal etwas unruhig und erwischt nicht immer die richtige Flanke.
Mit geänderten Eingangswiderständen dürfte sich der nutzbare
Frequenzbereich deutlich erhöhen.
Das W2022A geht dank der geänderten Widerstände problemlos bis 100 Mhz
mit konstanter Amplitude. Erst ab 120 Mhz bricht hier die Amplitude
spürbar ein.
Genaueres mit detailierten Screenshots folgt.
Gruß Hayo
Sehr interessant, wenn das mal endgültig geklärt würde. Bis jetzt gab es
da ja recht verschiedene Aussagen.
Die Sache mit den Huckepack-Platinen ist mir zu aufwändig (und zu
teuer), aber ein paar Rs wechseln, das bekomme ich bestimmt noch hin.
Es wäre schön, wenn jemand da mal so etwas wie eine Step-by-step
Anleitung für den Gelegenheitslöter posten könnte (oder gabs das
schon?).
Viele Grüße,
Mirko
Hayo W. schrieb:>> Das W2022A geht dank der geänderten Widerstände problemlos bis 100 Mhz> mit konstanter Amplitude. Erst ab 120 Mhz bricht hier die Amplitude> spürbar ein.>
Na das hört sich gar nicht schlecht an! Deshalb nochmal etwas geänderte
Kalibrierfaktoren für 2 x 24.9 Ohm und 150 Ohm:
ScaleFactor: 3.309 fuer 1-er und 2-er und 2.697 fuer 5-er
DAC-Scalefactor: 0.6614, 1.3228 und 3.307 entsprechend
So passen die Amplituden besser.
Gruß Jürgen
@Hayo: Wollte mal fragen, was nicht so funktioniert hat, lags an der
Skalierung weil diese dann erhöht werden muss? Wenn ja könnte man doch
auch Nullen reinschieben bis das MSB eine 1 ist und die unteren 7 bits
löschen oder würde das die Geschwindigkeit des Oszis so weit
runterdrücken?
Oder vielleicht eine 2te Filterauswahl die noch schärfer arbeitet.
Kannst du mir sagen wo die Filtergeschichte im Code sitzt damit ich mir
das mal anschauen kann.
Hi Thomas,
die Filterroutine findest Du in der Datei signal_t.cpp etwa bei Zeile
840. In dieser Datei sind alle Signal-Processing Routinen untergebracht.
Wenn Du da Ideen oder Verbesserungen hast nur zu. Wenn es gut
funktioniert kippen wir das alles mit rein.
Man könnte natürlich den Filter noch in einer zweiten Stufe mit mit
engerer Bandbreite ansetzen, um bei niedrigen Frequenzen die
Filterwirkung verbessern zu können. Das wäre auf jeden Fall recht
einfach.
Reicht denn der Filter so noch nicht aus?
Ich habe da übrigens noch einen kleinen Bug im Filter entdeckt, er geht
bei den interpolierten Zeitbasen nicht mit dem Fensterausschnitt,
sondern bleibt immer am Anfang. Bin ich dran...
Hayo
danke Hayo ich werde mir das ganze mal ansehen wobei ich nicht so C
bewandert bin. Also Ideen hätte ich genug und in ASM wäre das auch kein
Problem, ich werde mir das ganze mal anschauen in ein paar C-Schnipsel
beitragen die du vielleicht einfügen könntest.
Schon mal schönen Dank (war bestimmt eine ziemliche Arbeit, das aus
diesem Monsterthread rauszusuchen), muss mir das noch genauer
anschschauen (und Widerstände bestellen), mal sehen, was Hayo so
rausfindet.
Viele Grüße,
Mirko
...das ist wohl war, hatte gerade mal lust dazu...
So als Low-Budged Tip, für die Bröckchen kämen alte CD-Rom Laufwerke
oder kaputte Festplatten in Frage, da ist auf jeden Fall was für dich
dabei!
Ich habe gerade mal mit der neuen C18 gespielt...1KHz-Pro-Signal und
jetzt steht das Teil, keine Reaktion mehr und völlich eingefroren!!!
Einstellungen sind auf dem 1. Shot zu sehen!
Auf dem 2. Shot sieht man noch die Trigger-LED, die steht auch...
Was ist denn da jetzt los?
Gruß Michael
Buona sera.
Hayo W. schrieb:
>Testumgebung:>>- Signalgenerator Leader 3216 (bis 140 Mhz Sinus)>- Referenzoszi Tek 2465A (350Mhz)>- W2014A mit Originalbestückung>- W2022A mit 33 Ohm und 150 Ohm Widerständen in der Eingangsstufe
Well, well, congratulations for the equipment!
Hayo W. schrieb:
>Das W2014A läßt sich bis 20 Mhz durchaus ganz gut einsetzen, danach wird>die Dämpfung zu stark. Bei 50 Mhz sind von 2,7Vpp nur noch 1,9Vpp übrig>Bei 100Mhz noch 1,35Vpp.
From the image I can't understand how the Leader 3216 is set.
The frequency indicator is covered by the coaxial cable, I guess the
frequency is 10MHz.
Output level is 126, I guess 126dBuV, so about 1.99Vpp.
Modulation is 22,5 so I guess for this reason the sine wave isn't pure.
On the oscilloscope's input there is a 50 ohm through termination.
For the same signal the W2014's screen shows 2,73Vpp at 20MHz, 1,9Vpp at
50MHz and 1,35Vpp at 100MHz, is it correct?
Hayo W. schrieb:
>Der Trigger ist manchmal etwas unruhig und erwischt nicht immer die >richtige
Flanke.
Unfortunately this is true.
Congratulations for the test.
Thanks and best regards,
kcirreD
Jetzt habe ich einen Warmstart gemacht, das DSO weit über eine Std.
laufen lassen, sobald ich in den Bereich (wie oben im Shot 1) 250Sa/s,
1s komme, friert das DSo komplett ein!
Bei einigen Versionen vor der C18 war das nie der Fall, soweit ich mich
erinnern kann...
Hat das Jemand mal getestet?
Gruß Michael
@kcirreD
The picture is only a sample to show the equipemnt. For the measurements
the modulation was switched off. The Frequency on the picture was 8.96
Mhz.
@Michael
Der USTB-Bereich ist noch "Under Construction". Hier geht momentan noch
nichts - ist also nicht benutzbar!. Daher nicht wundern, das kommt noch.
Gruß Hayo
Hayo W. schrieb:
> @Michael> Der USTB-Bereich ist noch "Under Construction". Hier geht momentan noch> nichts - ist also nicht benutzbar!. Daher nicht wundern, das kommt noch.
Ok, ich höre auf mich zu wundern... :)
Ich dachte der USTB-Modus wäre schon fast abgeschlossen?
Wie auch immer, der "USTB-Modus" ist dann aktiv wenn gleichzeitig der
"Roll-Modus" aktiviert ist?
Ab welcher Zeitbasis ist denn der "USTB-Modus" aktiv? Ab--- 250Sa/s, 1S
---was ich oben schon angegeben hatte?
Vielleicht könntest du evtl. einen kleinen Hinweis in den Bildschirm mit
einbauen, wann "USTB-Modus" aktiv ist und wann nicht?
>> Gruß Hayo
Gruß Michael
Ok, der USTB-Modus scheint etwas Aufklärung zu brauchen.
Also nochmal: USTB <==> Ultra Slow Timebase
D.h. alle Zeitbasen kleiner als 500ms/div. Die Umschaltung erfolgt
automatisch.
Im USTB-Modus gibt es zwei verschiedene Darstellungsarten:
- den Rollmode
- den Shiftmode
Das hängt mit dem grundsätzlichen Prinzip des USTB-Modus zusammen der
ganz anders arbeitet als der normale Zeitmodus.
Während beim normalen Zeitmodus immer ein kompletter Datensatz ermittelt
wird und dann als Linie ausgegeben wird, wird beim USTB-Modus immer
Punkt für Punkt ermittelt und ausgegeben.
Beim Rollmode wird der Punkt immer ans Ende gehängt und daher rolliert
der gerade aktive Punkt immer von links nach rechts über den Screen.
(Also wie beim analogen Oszi)
Beim Shift-Mode wird der Punkt immer am Anfang (also ganz links)
eingefügt und der Rest um einen Punkt nach rechts geschoben - daher der
Name Shiftmode.
Ich hoffe das war jetzt nicht zu umständlich erklärt. Sollte man
vielleicht ins Wiki mit aufnehmen...
Hayo
Ach ja, falls Ihr Euch wundert warum das so lange dauert:
Das Timing ist ziemlich sensibel. Da spielt die Zeichenroutine eine
Rolle, die Übertragung in die Grafiklayer, die ADC-Auswertung und
natürlich der Timer.
Das muß alles genau aufeinander abgestimmt werden. Nicht so einfach,
wenn man bedenkt, dass je nach Anzahl de aktiven Kanäle diese
Zeitkonstante unterschiedlich ist. D.h. ich habe das Oszi an einer
Präzisionssignalquelle hängen (siehe Bild) und probiere unterschiedliche
Einstellungen aus, die aber auch jedesmal neu ins Oszi geladen werden
müssen. Das kann schon mal mehrere Tage dauern bis man das alles im
durch hat.
Gruß Hayo
Ohh Hayo, so langsam werde ich neidisch auf deinen Messplatz.
Sobald ich wieder etwas mehr Zeit habe, schau ich mich mal in
der Bucht um. Das sieht wirklich sehr gut aus.
Frohes Messen, Guido
Ja und es ist erschütternd (und natürtlich für uns erfreulich) welchem
Preisverfall diese tollen und ehemals sündhaft teuren Geräte
unterliegen.
Der Leader Signalgenerator z.B. stammt vom norddeutschen Rundfunk und
ist in einem hervorragend gepflegten und gewarteten Zustand - hat
weniger gekostet als das WELEC...
Und auf meine Mailanfrage in den USA hat mir Leader auch sofort ein
Manual (PDF) zugeschickt, das nenne ich Kundenservice.
Gruß Hayo
Hi gyppe,
the C## Versions are only experimental versions with some changes. Since
the drawing and acquisition speed increased (about C5) the Ultra Slow TB
are working incorrect. So this part is still under construction.
Don't worry about that, in the next days I will publish the final BF2.0
as stable version. As I wrote some posts above (with picture) it takes
much time to calibrate every TB in all working conditions precisely.
The TB above 10s/div lets You become older and grayer while watching the
signal creeping over the screen... ;-)
Ciao Hayo
Hayo W. schrieb:> Der Leader Signalgenerator z.B. stammt vom norddeutschen Rundfunk und> ist in einem hervorragend gepflegten und gewarteten Zustand - hat> weniger gekostet als das WELEC...
Da mussman aber auch das Glück haben, ein Gerät so günstig von einer
sochen Anstalt zu erhaschen. Wie bist du dazu gekommen?
Thanks now I understand everything:)
Sorry if I disturbed, but the German can not decipher it well even with
a translator and a lot of things I do not understand:)
Gyppe.
@gyppe
No problem. Please ask at every time if You have questions.
@Alex
Reiner Zufall. Hab einfach mal mal bei der Bucht reingeschaut und dachte
mir - biete mal einfach. Das es der NDR ist wußte ich nicht, das stellte
sich erst raus als meine Frau das Teil abholte.
Ist also wirklich etwas Glück.
Der Anbieter bietet noch mehr an, hier der Link zu meiner Auktion:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=160493003238&ssPageName=ADME:X:AAQ:DE:1123
Hayo
Hallo allerseits,
wie versprochen hier die finale 1.2.BF.2.0 - soweit ich testen konnte
läuft alles recht stabil. USTB ist jetzt ebenfalls ok und läuft besser
als vorher.
Allerdings beachtet bitte, dass die TB 1s/div und 2s/div recht
empfindlich auf äußere Einflüsse reagieren, so wie Temperatur und
Interupts von Keyboard oder Drehgebern. Dies führt hier zu einer
Frequenzungenauigkeit von ca. 5%. Je langsamer die Zeitbasis, desto
genauer wird es, da hier die Einflüsse immer weniger eine Rolle spielen.
Die Posts von:
- Charly -> 5.10.2010
- Luc -> 5.10.2010
- Mirko -> 6.10.2010
habe ich versucht nachzuvollziehen, konnte die Bugs aber nicht
nachstellen.
Prüft bitte ob sie noch aktuell sind, und wenn ja möglichst mit genauer
Beschreibunbg der Einstellungen oder Screenshot nochmal posten.
@Luc
couldn't repeat Your bug from 5.10.2010, so please check it again and
post it with detailed description of Your settings (or screenshot).
Gruß Hayo
Hallo Hayo,
erstmal großes DANKE für die 1.2.BF.2.0
Hayo W. schrieb:> wie versprochen hier die finale 1.2.BF.2.0 - soweit ich testen konnte> läuft alles recht stabil.
Mit dem Wort "finale" ist das wie mit "nie": Die Worte soll man nie
sagen ...
Beim Puls-Width-Trigger bin ich noch auf eine Kleinigkeit gestoßen:
Mit Probe Comp z.B. an Ch2 und Triggereinstellung wie im Bild 1 läuft
alles prima. Wenn ich dann das Signal mit dem Offset-Regler hoch- oder
runterschiebe, wandert die Anzeige für 0-Linie und Triggerlevel mit,
aber ab einer gewissen Verschiebung setzt der Trigger aus (dto. bei
Center Channel 2). Das kommt mir so vor, als ob der Triggerlevel für die
Pulserkennung nicht automatisch mit verschoben wird. Wenn ich
zwischendurch kurz auf Edge und dann wieder auf Puls Width Trigger
schalte, wird der Level anscheinend neu gesetzt und es läuft wieder.
Schönen Sonntag an alle.
Gruß Rainer
auch von mir ein Dankeschön, mir ist auch ein eher optischer Mangel
aufgefallen, wenn ich im aufgezeichnetem Signal eines Singelshoots
blättere sieht das Signal manchmal so aus als ob es lebt, also das
Rechteck das ich verschiebe beginnt plötzlich zu rauschen
(Zeichenroutine) vielleicht wird hier wegen der Geschwindigkeit nicht
gelöscht, glaube das war nur in eine Richtung der Fall, werde es heute
Abend nochmal genauer beschreiben inkl. Zeitbasen....
Thomas O. schrieb:> ... sieht das Signal manchmal so aus als ob es lebt ...
Das ist ja auch so: Es lebt vom Speicherinhalt, der dann unterschiedlich
dargestellt wird. Das "leben" verschwindet, wenn man ganz reinzoomt.
Damit das nicht passiert, müßten wohl der Verschieberaster im Speicher
und auf dem Bildschirm genau zusammenpassen. Schlimm find' ich's nicht.
Rainer
wenn ich ein Rechtecksignal verschiebe dann sollte das Rauschen auch
mitgeschoben werden. Da scheint aber in einer Zeichenroutine was nicht
zu stimmen und das fällt dann auf der waagrechten Linie des Rechtecks
auf wenn man schiebt. Ich werde heute Abend mal versuchen das zu filmen
läßt sich per Bild schwer erklären. Es sieht halt so aus als ob es live
rauscht auf einem Signal welches aufgezeichnet ist und sich eigentlich
nicht verändern sollte.
Wenn ich mir ein aufgezeichnetes Probe Comp Signal in
Originalzeitauflösung ansehe, springt das auf dem Signal sichtbare
Rauschen beim langsamen Verschieben der Zeitachse immer zwischen genau
den zwei in den Screenshots gezeigten Zuständen hin- und her.
Rainer
auf deinen Bildern sieht es so aus als ob einmal das Signal mit dem
Filter und einmal ohne dargestellt wird. Könnte gut sein das das Signal
deshalb so lebhaft aussieht, weil immer zw. gefilter und ungefilter
hergeschalten wird.
du hast recht. Anscheinend ist das eine dargestellte Signal gefiltert
und das andere nicht. Wenn ich in das aufgezeichnete Signal reinzoome
(100 bzw. 50 us/div), sieht es so aus, als ob immer ohne Filter
dargestellt wird. Gemessen hatte ich es mit aktiviertem Noise Filter.
Wenn ich Aquire auf "Normal" stehen habe und dann ein im Single Shot
erfaßtes Signal zeitlich schiebe, springt das Bild zwischen zwei
unruhigen Darstellungen hin- und her.
Hallo Ihr Beiden,
@Rainer
Deinen Bugreport habe ich notiert, werde ich mir mal in Kürze ansehen,
zum Thema "Final" - das bezieht sich ja auch nicht auf den Gesamtzustand
der Firmware, denn die wird eigentlich (und da sind wir auch schon beim
zweiten Wort) NIE fertig. Gemeint ist damit nur der Arbeitsvorrat der in
die 2.0 einfließen sollte. Wobei ich zugeben muß, dass die Neuerungen in
der FFT-Sektion dabei hintenübergefällen sind. Die werden dann in den
nächsten Versionen nachgereicht. Wie Ihr im Changelog sehen könnt, hat
sich aber dennoch einiges unter der Haube getan.
@Thomas
Wie Rainer ganz richtig anmerkt liegt das "Eigenleben" des Signals beim
Scrollen am Speicherinhalt. In den normalen Zeitbasen werden aus dem
Speicher, je nach TB nur jeder 4te, 5te bis zu jedem 25ten Punkt
dargestellt. Genau könnt Ihr das in den beigelegten Tabellen sehen. Wenn
Du jetzt also durch den Speicher scrollst und das Signal verrauscht ist,
so sieht die Darstellung natürlich bei jeden Schritt anders aus, weil er
dann nicht das Pixel 1-5-9-13 usw. darstellt wie vorher, sondern Pixel
2-6-10-14 usw. beim nächsten Schritt 3-7-11-15 usw.. Das ist aber kein
Fehler in der Zeichenroutine.
So ich werde mich mal ransetzen und ein paar HF-Messungen machen, die
Bilder könnt Ihr Euch dann gleich im HW-Thread ansehen.
Gruß Hayo
@Hayo
Hayo W. schrieb:> Wie Rainer ganz richtig anmerkt liegt das "Eigenleben" des Signals beim> Scrollen am Speicherinhalt.
Thomas Einwurf mit dem Filter fand ich sehr überzeugend. Da scheint
wirklich etwas schief zu gehen. Im einen Fall (living2.png, glatteres
Signal) werden die Flanken des Probe Comp Signals auch systematisch und
reproduzierbar flacher dargestellt. Mit Display > Vectors off ist das
noch deutlicher.
Rainer
Noch eine Ergänzung zu gefiltert/nicht gefiltert:
In einem Teil des nicht dargestellten zeitlichen Bereichs wirkt das
Filter anscheinend gar nicht.
z.B.
- Zeitfenster ganz nach links schieben,
- Single Shot,
- Zeitfenster ganz rechts drehen.
Dann tauchen ungefilterte Daten in der Anzeige auf (im Screenshot rechts
vom Cursor).
Rainer
Stimmt,
das Filter arbeitet aus Performancegründen nur im Fensterausschnitt.
Wenn der Stopmodus aktiv ist wird ja nicht neu gefiltert. D.h. wenn dann
der Fensterausschnitt geändert wird, dann schiebt man sich aus dem
gefilterten Bereich heraus - muß mal sehen ob man das ändern kann.
Danke
Hayo W. schrieb:> muß mal sehen ob man das ändern kann
Damit das Drehen an der Zeitverschiebung flüssig auf die Anzeige wirkt,
kann man ja erst ungefilterte Daten darstellen. Wenn dann am Drehregler
Ruhe herrscht, könnte man noch mal eine Darstellung mit gefilterten
Daten nachschieben. Wäre das eine Möglichkeit?
Rainer
@Hayo: Ich verstehe deinen Erklärung nicht genau, da ich ja beim
scrollen keine Zeitbasis ändere. Wenn also die Pixel 1-5-9-13
(angenommen obere waagrechte Linie eines Rechtecks) oder sagen wir
Speicherstelle 1-5-9-13 dargestellt werden und ich im Bildschirm scrolle
sollten doch die Pixel 1-5-9-13 nach links oder rechts geschoben werden
und nicht neue Pixel 2-6-10-14 aus dem Speicher eingebracht werden. Ich
denke beim ändern der Zeitbasis würde das eh nicht auffallen da das
Signal viel mehr versetzt wird als beim langsamen scrollen.
Dann habe ich nochmal eine Frage zu der Filterroutine da ich mit C
nichts am Hut habe. Sehe ich das richtig das nur Signaländerungen größer
lmin -1 oder lmax +2 in die Darstellung einfließen oder kannst du das
Entrauschen kurz erläutern?
Hi Hayo, Rainer W. and guys all!
Hayo W. schrieb:
>wie versprochen hier die finale 1.2.BF.2.0
First, again thanks You very, very much Hayo for the great job and free
time You provided generously to us!!!
I tried your new 1.2.BF.2.0 release and for me it works very well, it
work like a charm, so Hayo thank You very, very much for the really
amazing great work done!!!
As usual I'm speechless, RESPECT!!!
Hayo W. schrieb:
>da hier die Einflüsse immer weniger eine Rolle spielen.>>Die Posts von:>>- Charly -> 5.10.2010>>- Luc -> 5.10.2010>>- Mirko -> 6.10.2010>>habe ich versucht nachzuvollziehen, konnte die Bugs aber nicht>nachstellen.
Prüft bitte ob sie noch aktuell sind
Very good, again thanks You very, very much Hayo for the kind
assistance!!!
I tried and tried several times and with this new 1.2.BF.2.0 version is
no longer appeared to me!:-)
Rainer W. schrieb:
>Das kommt mir so vor, als ob der Triggerlevel für die>Pulserkennung nicht automatisch mit verschoben wird. Wenn ich>zwischendurch kurz auf Edge und dann wieder auf Puls Width Trigger>schalte, wird der Level anscheinend neu gesetzt und es läuft wieder.
Hello Rainer W.
I see the trigger is set to NORMAL, could be this the reason.
Perhaps with the button RUN/STOP fix the problem also.
Would be interesting to see if the trigger is still acquired or not, the
LED trigger's function can help to understand.
Maybe the signal track will move but the trigger do not follow it so
with the trigger set to NORMAL the signal track does not repaint.
However I too have found some anomalies with the use of the PULSE WIDTH.
">" works fine, "<" not always work to me, "><" not work to me: I tried
with the probes compensation signal, trigger mode is set to NORMAL.
I have to study the question, maybe I have something wrong.
Rainer W. schrieb:
>Noch eine Ergänzung zu gefiltert/nicht gefiltert:>>In einem Teil des nicht dargestellten zeitlichen Bereichs wirkt das>Filter anscheinend gar nicht.>z.B.>- Zeitfenster ganz nach links schieben,>- Single Shot,>- Zeitfenster ganz rechts drehen.>Dann tauchen ungefilterte Daten in der Anzeige auf (im Screenshot rechts>vom Cursor).
A similar thing happens to me when I use the PULSE WIDTH trigger mode, I
have to pursue the matter.
Hayo W. schrieb:
>Bilder könnt Ihr Euch dann gleich im HW-Thread ansehen.
Good work Hayo!!!
I have also obtained similar results with W2022A and W2012A up to
170MHz.
My equipment is very low compared to your but the results are similar.
What I found is that Welec have not a hard time with the high
frequencies, the real problem are the true amplitude signal values which
is difficult to infer because of the linearity's lack.
Unfortunately I can only generate high frequency sine waves, whereas I
think it would be better to use square waves.
However, comparing the signals with other oscilloscopes, ignoring the
amplitudes speech , what I observe with the W2022A and W2012A is the
same as what I see with other oscilloscopes, neither more nor less: this
is undoubtedly due to the quality of work you Hayo, along with all
others who contributed, you have done, then RESPECT!!!
I can say that thanks to your work You are able to make the
Welec/Wittig's DSO competitive with what the market currently offers, so
again many thanks to You Hayo, really thanks very much to all You!!!
Vielen Dank!!!
Gruß Luc
Hallo Hayo,
vielen Dank für die neue Version!
Bin sehr angetan davon.
Nach Anpassung der DAC Scales an die in meinem Gerät verbauten
Widerstände
ist jetzt alles "rund".
Klasse!
Danke!
Lothar
@Luc
NORMAL trigger should work, as the Probe Comp signal is a normal square
wave of +/-400 mV and a trigger level of 0 mV is well in the middle of
that range. But setting trigger to AUTO didn't change anything.
In case I change the offset of a channel, i.e. the position on the
display, IMO this should not have any influence on my trigger settings
(and temporarily switching to EDGE trigger set the correct level for the
pulse width detection).
If trigger has stopped due to channel offset, the LED1 is ON.
"><" works well using the correct settings, but with an a few quirks:
To see the Probe Comp signal, the ">"-value should be well below the
positiv pulse width, ">" + "deltaT" should be well above the positiv
pulse width (e.g. 450us, 100us in Puls_Width_Trigger1.png above). I
temporarily switch to EDGE trigger to get the correct decision level for
the pulse detection. After messing around with "<" or ">"-trigger
settings, i have to touch the ">"-value to start triggering in "><"
mode.
"<" do not works for me (Probe Comp triggers always, independent of "<"
value, trig. NORMAL)
@Hayo
Beim OS-Screenshot mit Pulse-Trigger Menü kommt anscheinend die
Zeichenebene mit dem inaktiven "Delta t" nicht mit rüber (alter Bug?,
s.o. Puls_Width_Trigger1.png). Ist das deine Baustelle oder liegt das am
Empfänger?
Gruß, Rainer
Jetzt habe ich nach einigen Messungen doch ein kleines
Verständnisproblem:
Wenn ich die Widerstände in den Vorverstärkern ändere, muß ich auch die
Skalierungsfaktoren in der Software ändern - klar.
Jetzt gibt es deren 2:
In tc_vars.cpp den DAC_ScaleFactor musste ich ändern, damit die
Nullinien
nach der DAC-Kalibrierung stimmen. Also die Pfeile links und rechts auf
dem
Bildschirm bei offenem Eingang an jeder beliebigen Y-Position mit der
angezeigten Linie der Messwerte überein stimmen. Habe bei mir die Werte
der Dimension 0 (Standard Gain 1) ausgetauscht.
Bei mir (habe 22 Ohm verwendet) sind das jetzt:
float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 },
{ 1.68, 1.235, 1.3228, 1.245, 1.238 },
{ 4.2, 3.090, 3.3070, 3.108, 3.108 }};
Dann habe ich beim Messen von verschiedenen Spannungen festgestellt, daß
der angezeigte Wert in allen Bereichen deutlich zu niedrig ist.
Beispiel: Bekannte Spannung: 4.35 Volt, angezeigter Wert: ca 3.0 Volt
Also habe ich den Abweichungsfaktor (1.45) berechnet und damit
exemplarisch den für den 2V-Bereich zuständigen Wert im Array
ScaleFactor multipliziert.
(3.25 -> 4.713)
Geflashed, getestet und gewundert:
Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher.
Durch Zufall habe ich dann das QuickMeasure aktiviert und siehe da:
QuickMeasure zeigt als Maximum Wert ziemlich genau den gewünschten Wert
von 4.35 Volt an.
Aber: Die roten Linien von QuickMeasure weichen deutlich von der
Messkurve ab. Liegen also weit oberhalb der Messkurve in der oberen
Hälfte des Screens und weit unterhalb in der unteren Hälfte.
Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut,
lediglich die grafische Ausgabe der Messkurve ist davon unberührt.
(siehe Anhang)
Wo ist mein Denkfehler?
Lothar
Hi Rainer W. and guys all!
Rainer W. schrieb:
>NORMAL trigger should work, as the Probe Comp signal is a normal square>wave of +/-400 mV and a trigger level of 0 mV is well in the middle of>that range.
I agree with You Rainer W.
Rainer W. schrieb:
>But setting trigger to AUTO didn't change anything.
Sorry Rainer W., I thought the problem could be related to the type of
trigger used.
Mine was only a hypothesis.
Rainer W. schrieb:
>In case I change the offset of a channel, i.e. the position on the>display, IMO this should not have any influence on my trigger settings
Rainer W., I agree, should not have any influence on trigger settings.
Rainer W. schrieb:
>(and temporarily switching to EDGE trigger set the correct level for the>pulse width detection).
Get you the same effect by pressing the RUN/STOP's button?
It seems the trigger is no longer acquired so the signal track does not
repaint.
This would be normal with the trigger set to NORMAL but very strange
with the trigger set to AUTO.
Rainer W. schrieb:
>If trigger has stopped due to channel offset, the LED1 is ON.
Well, if I remember correctly LED1 lit is TRIGGER READY for acquisition
and LED2 lit is TRIGGERED condition, so the trigger is not captured when
the problem occurs or so it seems.
Rainer W. schrieb:
>"><" works well using the correct settings, but with an a few quirks:>To see the Probe Comp signal, the ">"-value should be well below the>positiv pulse width, ">" + "deltaT" should be well above the positiv>pulse width (e.g. 450us, 100us in Puls_Width_Trigger1.png above). I>temporarily switch to EDGE trigger to get the correct decision level for>the pulse detection. After messing around with "<" or ">"-trigger>settings, i have to touch the ">"-value to start triggering in "><">mode.
Very good Rainer W., thanks You very, very much for the kindly
explanation!
You were very detailed.
Thanks again for the tip Rainer W., now I understand better, so many
thanks again Rainer W.!
Rainer W. schrieb:
>"<" do not works for me (Probe Comp triggers always, independent of "<">value, trig. NORMAL)
Thanks also for this other useful information Rainer W.!
Vielen Dank!!!
Gruß Luc
Luc schrieb:> Rainer W. schrieb:>>(and temporarily switching to EDGE trigger set the correct level for the>>pulse width detection).>> Get you the same effect by pressing the RUN/STOP's button?
No, RUN/STOP didn't do the trick after changing the channel offset ...
Rainer
Thomas O. schrieb:> @Hayo: Ich verstehe deinen Erklärung nicht genau, da ich ja beim> scrollen keine Zeitbasis ändere.
Ich habe mich da etwas verkehrt ausgedrückt. Es müßte nicht "Pixel"
heißen sondern "Wert".
Also Wert 1 wird auf Pixel 1 abgebildet, die nächsten 4 Werte werden
übersprungen und Wert 5 wird auf Pixel 2 abgebildet, dann Wert 9 auf
Pixel 3, Wert 13 auf Pixel 4 usw..
Die Filterroutine basiert auf genau dem gleichen Umstand, nämlich dem
ungenutzten Wertevorrat.
Die Filterung entsteht dadurch, das die Werte links und rechts vom
eigentlichen Ausgangswert zu diesem Wert hinzuaddiert werden und dann
das arithmetische Mittel gebildet wird. Solange hierfür nur Punkte
verwendet werden die ungenutzt sind und keine Überschneidungen
auftreten, liegt die Flanke des dadurch erzeugten Tiefpassfilters
oberhalb der halben Abtastbandbreite, es gibt also keine Verluste.
Bei einigen TB gibt es aber nur einen kleinen oder gar keinen
Wertevorrat (100ns, 50ns -> 2ns). Hier sind Überlappungen nicht zu
vermeiden, und die effektive Bandbreite wird etwas eingeschränkt (nur
wenig).
Gruß Hayo
noch ein kurzer Nachschlag:
Die genauen Wertevorräte könnt Ihr Euch in der beigelegten "Programmers
Reference" ansehen. Auf dem Arbeitsblatt "Timebase Table" findet Ihr
eine Übersicht über die jeweiligen Parameter jeder Zeitbasis. Die Werte
in der Spalte "Factor" entsprechen dem Wertevorrat. Je größer der
Wertevorrat, desto effektiver kann man ohne Verluste filtern.
Der Noisefilter arbeitet daher Je nach eingestellter Zeitbasis
unterschiedlich intensiv.
Hayo
Hallo Hayo,
Ich habe mir etwas den Effekt des "verrauschten" Signals wenn ein mit
"Noise Filter" gespeichertes Signal horizontal verschoben wird. Dabei
habe ich gesehen das du den gebildeten Mittelwert in den original
speicher zurück schreibst, das hat zur folge das im speicher gefilterte
und ungefilterte werte stehen, solange nicht horizontal verschoben wird
werden die gefilterten werte dargestellt, wenn man aber verschiebt
werden je nach pos. die nicht gefilterten werte dargestellt. Dies führt
zu dem "rauschen". Eine einfache Lösung währe es die Verschiebung immer
um ein vielfaches von "draw_factor" zu machen. (userif_t.cpp Zeile
7503,7504, 7515 7116 und 7526?) Ich hab das mal ausprobiert, scheint
soweit zu funktionieren.
Danke noch mal für die grosse arbeit die du leistest,
Martin
Lothar Merl schrieb:> Jetzt habe ich nach einigen Messungen doch ein kleines> Verständnisproblem:>> In tc_vars.cpp den DAC_ScaleFactor musste ich ändern, damit die> Nullinien> nach der DAC-Kalibrierung stimmen. Also die Pfeile links und rechts auf> dem> Bildschirm bei offenem Eingang an jeder beliebigen Y-Position mit der> angezeigten Linie der Messwerte überein stimmen.
Korrekt. Die Anpassung der DAC-Faktoren führt aber gleichzeitig zu einer
Änderung der Scalefaktoren und umgekehrt. Man muß sich hier langsam
iterativ herantasten.
> Habe bei mir die Werte> der Dimension 0 (Standard Gain 1) ausgetauscht.
D.h. im Hardwaremenu die Einstellung Gain auf "Factory".
> Bei mir (habe 22 Ohm verwendet) sind das jetzt:
Mit oder ohne 150Ohm Längswiderstand?
> float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 },> { 1.68, 1.235, 1.3228, 1.245, 1.238 },> { 4.2, 3.090, 3.3070, 3.108, 3.108 }};
Deine Faktoren kommen mir sehr groß vor. Ob das wirklich so passt?
> Dann habe ich beim Messen von verschiedenen Spannungen festgestellt, daß> der angezeigte Wert in allen Bereichen deutlich zu niedrig ist.> Beispiel: Bekannte Spannung: 4.35 Volt, angezeigter Wert: ca 3.0 Volt>> Also habe ich den Abweichungsfaktor (1.45) berechnet und damit> exemplarisch den für den 2V-Bereich zuständigen Wert im Array> ScaleFactor multipliziert.> (3.25 -> 4.713)
Auch dieser Faktor scheint mir sehr groß zu sein.
> Geflashed, getestet und gewundert:
Hast Du nach dem Flashen das Gerät resettet? Ansonsten zum Ausprobieren
lieber ins RAM laden, das geht schneller und benötigt keinen Reset.
> Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher.
Achtung: Neuen DAC-Abgleich nicht vergessen!
> Durch Zufall habe ich dann das QuickMeasure aktiviert und siehe da:> QuickMeasure zeigt als Maximum Wert ziemlich genau den gewünschten Wert> von 4.35 Volt an.> Aber: Die roten Linien von QuickMeasure weichen deutlich von der> Messkurve ab. Liegen also weit oberhalb der Messkurve in der oberen> Hälfte des Screens und weit unterhalb in der unteren Hälfte.> Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut,> lediglich die grafische Ausgabe der Messkurve ist davon unberührt.> (siehe Anhang)
Wenn beide Faktoren stimmen, dann stimmen auch die Cursor mit der
Messkurve überein.
Hayo
Hallo Martin,
deine Analyse klingt sehr treffend.
Martin H. schrieb:> ... hat zur Folge das im speicher gefilterte> und ungefilterte Werte stehen ...
D.h. beim Reinzoomen wird z.Z. eine Mischung von Originalwerten und
gemittelten Werten dargestellt, oder?
Martin H. schrieb:> Eine einfache Lösung währe es die Verschiebung immer> um ein vielfaches von "draw_factor" zu machen.
Für die Verschieberei bei der Originalzeitskala hört sich das gut an.
Aber beim Zoomen in der Zeitachse bleibt es, wenn ich das richtig
verstehe, trotzdem bei den gemischten Daten.
Gruß
Rainer
Martin H. schrieb:> Hallo Hayo,>> Ich habe mir etwas den Effekt des "verrauschten" Signals wenn ein mit> "Noise Filter" gespeichertes Signal horizontal verschoben wird. Dabei> habe ich gesehen das du den gebildeten Mittelwert in den original> speicher zurück schreibst, das hat zur folge das im speicher gefilterte> und ungefilterte werte stehen,
Ja das ist korrekt. Mein Ansatz wäre daher auch ein Anderer. Ich bin am
Überlegen, ob ich den gefilterten Werten einen eigenen Speicher
spendiere (so wie den interpolierten Werten), da ich damit gleich
mehrere Probleme gleichzeitig erledigen könnte. Ich prüfe noch ob ich
evtl. den Speicherbereich der interpolierten Werte mitbenutzen könnte.
Gruß Hayo
@Rainer
damit wäre Dein Thema dann auch erledigt
Hayo W. schrieb:> Korrekt. Die Anpassung der DAC-Faktoren führt aber gleichzeitig zu einer> Änderung der Scalefaktoren und umgekehrt. Man muß sich hier langsam> iterativ herantasten.
Ay Caramba!
>> Habe bei mir die Werte>> der Dimension 0 (Standard Gain 1) ausgetauscht.>> D.h. im Hardwaremenu die Einstellung Gain auf "Factory".
Genau. Da die Werte ohnehin mit 1.25 identisch und somit eigentlich
obsolet sind (?).
>> Bei mir (habe 22 Ohm verwendet) sind das jetzt:>> Mit oder ohne 150Ohm Längswiderstand?
Mit 150 Ohm Abschluss.
>> float DAC_ScaleFactor[3][5] = {{ 0.84, 0.620, 0.6614, 0.630, 0.619 },>> { 1.68, 1.235, 1.3228, 1.245, 1.238 },>> { 4.2, 3.090, 3.3070, 3.108, 3.108 }};>> Deine Faktoren kommen mir sehr groß vor. Ob das wirklich so passt?
100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich
hin.
>> Also habe ich den Abweichungsfaktor (1.45) berechnet und damit>> exemplarisch den für den 2V-Bereich zuständigen Wert im Array>> ScaleFactor multipliziert.>> (3.25 -> 4.713)>> Auch dieser Faktor scheint mir sehr groß zu sein.
Naja, kam mir ehrlich gesagt auch etwas groß vor, aber nur damit
stimmen die Werte vom QuickMeasure anschließend.
>> Geflashed, getestet und gewundert:>> Hast Du nach dem Flashen das Gerät resettet? Ansonsten zum Ausprobieren> lieber ins RAM laden, das geht schneller und benötigt keinen Reset.
Schneller ist's nicht, da ich den Windows Firmware-Loader nutze.
Würde auch lieber die Entwicklungsumgebung unter Linux laufen
lassen, als unter Cygwin. Habe aber in der Richtung noch nichts
unternommen. (Gibt es irgendwo ein entsprechendes Package?)
Aber das ist 'ne andere Baustelle.
Oszi (immer!) nach dem Flashen aus...21...22...23...an.
>> Die Messkurve sieht im 2V Bereich exakt genau so aus wie vorher.>> Achtung: Neuen DAC-Abgleich nicht vergessen!
Mache ich ebenfalls nach jedem Flashen:
Utility Menu -> Default Setup -> Cal. ADC -> Cal. DAC
>> Es ist wohl so, daß der Korrekturwert in ScaleFactor das Richtige tut,>> lediglich die grafische Ausgabe der Messkurve ist davon unberührt.>> (siehe Anhang)>> Wenn beide Faktoren stimmen, dann stimmen auch die Cursor mit der> Messkurve überein.
Genau das ist mein Problem: INTERN scheint alles zu stimmen.
Bei Quick Measure werden die roten Cursor Linien bei den richtigen
Werten eingeblendet und auch die Digitalanzeige zeigt die richtigen
Werte.
Nur die Messkurve weiss davon nichts. Siehe auch mein Attachment im
letzten Posting.
Zur Verdeutlichung habe ich nochmal was angehängt.
Ein 4 Vpp Sinus, den ich mit einem Philips Skope zur Kontrolle gemessen
habe.
Im ersten Bild sieht man das Signal im 1V/div Messbereich.
Eingangsverstärker mit 22 Ohm / 150 Ohm modifiziert, aber nur Anpassung
der DAC_ScaleFactor Werte. Wie erwartet wird ein zu kleiner Wert
angezeigt.
Im zweiten Bild dieselbe Messanordnung. Lediglich den Bereichsschalter
habe ich auf 2V/div umgeschaltet. Der 2V Bereich hat die oben erwähnten
neuen Skalierungsfaktoren. Man sieht, dass der Quick Measure Wert und
die roten Cursor Markierungen halbwegs passen, nicht aber die Messkurve.
Scratching my head...
Lothar
Lothar Merl schrieb:> Genau. Da die Werte ohnehin mit 1.25 identisch und somit eigentlich> obsolet sind (?).
Nein, nur die 5V-Bereiche sind gleich, da diese immer mit Gain 1,25
laufen. 2V und 1V sind unterschiedlich. Hast Du Dich da in den Spalten
und Zeilen verhauen?
> 100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich> hin.
Da Du den 150Ohm Widerstand drin hast, müßten die Faktoren von Jürgen
eigentlich fast passen, da er diese für 24,9 Ohm augetüftelt hat. Der
Unterschied dürfte nur minimal sein. Hast Du die 24 Ohm Einstellung in
der aktuellen 2.0 mal ausprobiert?
> aber nur damit> stimmen die Werte vom QuickMeasure anschließend.
Nimm nicht Quickmeasure. Nimm die manuellen Cursor! Damit lässt sich
genauer arbeiten und man vertut sich nicht so leicht mit der
Messfunktion.
> Schneller ist's nicht, da ich den Windows Firmware-Loader nutze.> Würde auch lieber die Entwicklungsumgebung unter Linux laufen> lassen, als unter Cygwin.
Der Loader ist unabhängig von der Entwicklungsumgebung. Du must nur
Active Perl installieren und kannst dann das beigelegte Perlskript
benutzen. Anleitung findest Du im Doc-Ordner.
> Oszi (immer!) nach dem Flashen aus...21...22...23...an.
Reset reicht, das schont den Schalter (Erst den 2ten Softkey drücken und
halten, dann den ersten Softkey kurz drücken also genau andersherum als
beim Flashen)
Hayo
Hayo W. schrieb:> Nein, nur die 5V-Bereiche sind gleich, da diese immer mit Gain 1,25> laufen. 2V und 1V sind unterschiedlich. Hast Du Dich da in den Spalten> und Zeilen verhauen?
Kann ich nicht ausschließen - muß ich prüfen.
>>> 100%ig. Nur mit diesen Werten bekomme ich die Nullinie nach DAC Abgleich>> hin.>> Da Du den 150Ohm Widerstand drin hast, müßten die Faktoren von Jürgen> eigentlich fast passen, da er diese für 24,9 Ohm augetüftelt hat. Der> Unterschied dürfte nur minimal sein. Hast Du die 24 Ohm Einstellung in> der aktuellen 2.0 mal ausprobiert?
Habe ich jetzt mal probiert. Passt tatsächlich in etwa.
In den 5/2/1V Bereichen habe ich eine relativ konstante Abweichung.
Statt der anliegenden 4.08V Gleichspannung zeigt das Oszi 3.79/3.76/3.78
Volt an. Gemessen mittels manuelle Cursor.
Ein bisschen daneben steht der Nullpunktabgleich im 5V Bereich.
Vertikal zentriert liegt die Kurve genau auf der GND-Markierung.
Verschiebe ich aber die Kurve an den oberen/unteren Rand, liegt die
angezeigte Kurve um geschätzte 0.7 Volt über bzw. unter der
GND-Markierung.
Aber das ist zu verschmerzen.
> Der Loader ist unabhängig von der Entwicklungsumgebung. Du must nur> Active Perl installieren und kannst dann das beigelegte Perlskript> benutzen. Anleitung findest Du im Doc-Ordner.
Ja, ich weiß. Active Perl könnte ich auch installieren.
Entwickle nue generell lieber unter Linux.
Werde einstweilen mal bei der 24Ohm Einstellung bleiben.
Wäre interessant zu wissen, mit welchem Verfahren Jürgen seine Werte
gefunden hat. Oder habe ich das überlesen?
Mein Ansatz: Aus angezeigtem und Sollwert Korrekturfaktor berechnen und
diesen Faktor auf die bestehenden Scale-Werte anwenden scheint ja wohl
suboptimal zu sein.
Lothar
Berechnen kannst Du Dir schenken, das hab ich auch mal versucht, ging
aber auch in die Hose. Die Abhängigkeiten sind sind so fein miteinander
verwoben, dass es am Besten geht, wenn man sich von bestehenden Werten
Stück für Stück vortastet.
Also am Besten die Spalte für die 24 Ohm jeweils für beide Arrays
kopieren in die erste Spalte und dann die Werte für jeden Messbereich
einzeln anpassen.
Als Erstes die DAC-Scalefaktoren im Nachkommabereich leicht verändern
und dann am Gerät überprüfen. Dann die Scalefaktoren nachziehen. Danach
wieder die DAC-Scalefaktoren prüfen, denn die Nulllage verändert sich
unter Umständen bei der letzten Änderung nochmal.
Ist etwas fummelig, aber mittlerweile deutlich einfacher als früher.
Dafür brauchst Du aber auf jeden Fall das Perlskript, sonst bist Du da
mehrere Wochen dran. Das Perlskript braucht für das Flashen nur knappe 3
Minuten.
Hayo
Lothar Merl schrieb:> Werde einstweilen mal bei der 24Ohm Einstellung bleiben.>> Wäre interessant zu wissen, mit welchem Verfahren Jürgen seine Werte> gefunden hat.
Aber gern :-)
- einen Kanal in die Mitte kurbeln
1. zuerst Verstärkungsabgleich ( Scalefactor )
- AC mit bekannter Amplitude ( oder auch DC ) an den Kanal anlegen
- die Spitzen sollen möglichst oben oder unten am Bildschirmrand liegen
- Faktor zwischen Soll- und Istanzeige ermitteln und mit vorhandenem
Faktor aus der Liste multiplizieren = neuer Scalefactor
- fuer 1-er und 2-er ein Faktor und fuer 5-er ein Faktor!
2. dann DAC_Scalefaktor im 5-er Bereich ermitteln
- dazu Kanal ohne Signal an den oberen Bildschirmrand kurbeln und Faktor
zwischen 0-Linie und vorhandener Strahlline berechnen und mit
vorhandenem 5-er Faktor aus der Liste multiplizieren = neuer
DAC_Scalefaktor fuer 5-er
- der 2-er und der 1-er ist jeweils genau 0,5 x dem 5-er Faktor
3. Software übersetzen und flashen und DAC-Abgleich durchführen
4. die Prozedur noch 1x bis 2x durchführen
5. Fertig
Alles ohne Garantie und gültig für 24,9 Ohm und 150 Ohm!
Gruß
Jürgen
Hi Rainer W., Hayo and guys all!
Rainer W. schrieb:
>No, RUN/STOP didn't do the trick after changing the channel offset ...
Many thanks for the information Rainer W.!
I tried with my W2022A and I too have encountered the same problem.
Exact, RUN/STOP button do not fix it also for me instead temporarily
switching to EDGE trigger set the correct level for the pulse width
detection.
It seems the trigger is no longer acquired but I do not know, I am
sorry...
You can see a screenshot.
However, thanks to your suggestions I did some tests with my W2022A and
finally I was able to use the trigger in PULSE WIDTH mode without
problem!
It works on my W2022A but with a W2012A is what I wrote in previous
posts.
The only problem is the same as you've reported Rainer W., so thank You
very much!:-)
@Hayo.
I'm still playing with the external trigger.
This time I used my W2022A so I found some curious things.
First, the W2022A seems to me works better with EXTERNAL TRIGGER
compared to my friend's W2012A.
LF Reject and HF Reject work very well!!!
I am not sure because I have no tried with the W2012A and new 1.2.BF.2.0
firmware release, so could be the new firmware that runs better the DSO.
However, again congratulations for the excellent work Hayo!!!
Talking about other.
In SAVE/RECALL menù what the function of the Restore Settings button is?
Once I pressed that button, the relays are triggered and then the
waveforms were distorted with NOISE FILTER inserted but NORMAL and
AVERAGEGE work well.
I was able to make a screenshot but then I've deleted it by mistake.
However, the probes's compensation signal seems to be a low resolution
digital sinusoid, roughly looks like a square wave superimposed on a
sinusoid.
I fix with Default Setup in UTILITY menù.
Now when I press the Restore Settings button in the SAVE/RECALL menù
then the DSO show settings for channel 2.
No really problem but rather curious.
Vielen Dank!!!
Gruß Luc
Hallo Hayo und Jürgen,
danke für die Info!
Habe inzwischen das Perlscript am Start, aber nicht unter Windows,
sondern
unter Cygwin. Da klappt die automatische Installation des Perl-Moduls
nicht, aber von Hand geht's dann. Jetzt bin ich auch mit 3min/Test
dabei.
Jürgen, da war recht genau auch meine Vorgehensweise. Allerdings in
anderer
Reihenfolge. Ich hatte zuerst die DAC-Scales angepasst.
Werde es jetzt mal mmit Deiner Methode versuchen. Macht ja auch mehr
Sinn.
Dank!
Lothar
Hallo!
Nach langer Abstinenz melde ich mich mal wieder.
Ich finde es wäre an der Zeit für das LEON3 Design einmal ein
"Klassendiagramm" zu erstellen. Mir ist schon klar, dass es in C keine
Klassen gibt, aber man kann und sollte diese in einer ähnlichen Weise
nachbauen.
So unterschiedlich die HW-Ansteuerung (Signalerfassung + Display) zum
Nios Design sein wird, so ähnlich kann die Bedienung ausfallen. Am
besten wäre es, die Gemeinsamkeiten zu Kapseln und die Unterschiede als
"Low-Level Treiber" einzubinden.
Mir wäre auch sehr geholfen, wenn es ein fertig dokumentiertes
Klassendiagramm über die NIOS GUI gäbe. Das würde auch der BF-Version
weiterhelfen.
Gibt`s da schon irgendwelche brauchbaren Modellierungsprogramme, die
unter Windows und Linux gleichermaßen laufen?
Ein Tipp für Hayo und alle anderen:
Einen schnellen IIR-Filter (z.B. Noise-Filter) bekommst du mit der
Berechnung: y[k+1] = y[k] + (x[k]-y[k])/(2^x) ... 2 Additionen + eine
Schiebeoperation.
Das würde hier Sinn machen, wenn der NIOSI keinen (schnellen)
Multiplizierer hat.
Falls man mit dem mehrmals über den Puffer fährt, erreicht man ein sehr
steilflankiges Filter ohne Überschwinger.
Als Interpolationsfilter schlage ich einen Polyphaseninterpolator vor
(Effizienter FIR-Filter mit integrierter Interpolation).
Das liegt schon im lange bei mir Repository, sowas habe ich schon für
das erste Demo, welches mir dankenderweise Bruno zusammengeschnitten
hatte, implementiert.
Manchmal möchte man auch so einen stark Bandbegrenzten IIR-Filter als
Math Funktion haben, macht bspw. bei PWM-Signalen oder extrem
verrauschen Signalen Sinn.
@Hayo und Co
Gratulation!
Eure Verbesserungen können sich schon sehen lassen, gegenüber der
Originalversion ist das Oszi schon wirklich gut und gebrauchsfähig
geworden.
Gegen die unlösbaren HW-Bugs (Trigger,...) im NIOS-Design kann nur ein
neues VHDL-Design helfen. Leider wird die Entwicklung hierfür
warscheinlich noch sehr lange Dauern.
MfG
Alexander
Hallo Leute,
lässt sich eigentlich auch noch eine Equivalent Sampling einbauen damit
z.B. die hochfrequenten Sinüsse nicht mehr so eckig sind?
Mfg,
Kurt
@Alex
Im Prinzip rechnet Deine IIR-Routine genauso wie meine Filterroutine
(Erst addieren dann shift), nur dass bei mir die Berechnungstiefe je
nach Zeitbasis variiert. Trotzdem werde ich mal Deine Routine einbauen
und testen, vielleicht lässt sich da noch was rausholen.
Für die Interpolation würde ich lieber eine sin(x)/x Interpolation
verwenden, aber leider habe ich dazu bislang nur theoretische
Abhandlungen gefunden, aber nichts was sich direkt in Coding umsetzen
ließe. Hast Du da vielleicht brauchbares Material?
@Kurt,
> lässt sich eigentlich auch noch eine Equivalent Sampling einbauen
das muß ich mal prüfen. Wenn ja dann machen wir das auch...
Ansonsten macht das Noise Filter doch auch schon ein ganz gute Figur.
Gruß Hayo
Wenn ich das richtig verstanden habe, braucht man für Equivalent
Sampling u.a. ja einen sehr zuverlässigen Trigger - da hapert es ja noch
ein wenig (wenn es durch das Design überhaupt besser geht...)
Viele Grüße,
Mirko
Hallo allerseits.
Ich weiß es gab gerade eine neue Version, aber ich war gerade kreativ.
Was ist neu - what is new?
- Sample rate bug fixed (Sampleraten wurden falsch angezeigt)
- neues zweistufiges Noise Filter (Acquire Menu)
- Vorbereitung für verschiedene Interpolationen (Acquire Menü)
- neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für
die Windows Version (Windows only!)
Gruß Hayo
Ach ja, schnell noch angemerkt:
- nach dem flashen wird die Hardwareeinstellung auf default
zurückgesetzt. Ihr müßt also die Einstellungen neu machen und einen
Abgleich machen
Please notice that the hardware settings will be set to default. So You
have to set again and calbrate Your DSO new.
Hayo
Hi Hayo and guys all!
Hayo W. schrieb:
>Ich weiß es gab gerade eine neue Version, aber ich war gerade kreativ.>>Was ist neu - what is new?>>- Sample rate bug fixed (Sampleraten wurden falsch angezeigt)>- neues zweistufiges Noise Filter (Acquire Menu)>- Vorbereitung für verschiedene Interpolationen (Acquire Menü)>- neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für>die Windows Version (Windows only!)
Oh boys!
Hayo, as usual You leave me speechless!!!
No words...
RESPECT!!!
I'm running now to try this new release!
Hayo, thanks also for the snapshot implementation of my request about
the possibility to have an audible alarm in the screenshots management
software.
You are really great, thank You very, very, very much!!!
RESPECT!!!, RESPECT!!!, RESPECT!!!
Again thanks You very, very much Hayo for the great job and free time
You provided generously to us!!!
Vielen Dank!!!
Gruß Luc
Hi Hayo and guys all!
Hayo W. schrieb:
>- neue Screenshot version 1.6.BF - 2x Beep nach Screenshot -> nur für>die Windows Version (Windows only!)
Hayo, thanks for this new feature in the new 1.2.BF.2.1 firmware
release, it makes me happy!
An audible alarm in the screenshots management software may seem
unnecessary, but not always is so.
I should make room in my laboratory but I do not have time and space is
what it is, so for my test I put the DSO behind the computer.
In this way I can not see the computer's screen and when I send a
screenshot on the computer I have to go from the DSO to the PC's monitor
to verify that the acquisition is complete before sending the next.
This is not easy because there is no room and so to save screenshots
with the DSO is a big problem and a waste of time.
Here is the reason for my unusual request.
Now thanks to your excellent work done screenhot is no longer a problem,
I do it in full relax without wasting time!!!
Really amazing, so thanks You very, very much Hayo also for this your
masterpiece!!!
I'm doing some testing with your new firmware and I'm very satisfied.
For now, I have not done much testing, I think, however, it is perfect
and very stable rock solid I say!!!
Very impressive your implementation of Kurt Bohnen's suggestion.
Very well also for the alex008's suggestion add, even if this is no
active now.
Over the weekend I hope to do some tests.
However I repeat that this your latest firmware version is very
impressive, the difference with the original Welec's firmware is
dramatic!
Hayo, You are really great, thank You very much!
Vielen Dank!!!
Gruß Luc
Es ist mal wieder soweit,
die BF.2.2 ist fertiggestellt mit zahlreichen Verbesserungen und Fixes.
Heute bin ich zu müde, aber morgen (eigentlich heute) werde ich die neue
Version mit den entsprechenden Erklärungen hochladen.
New BF.2.2 is ready now. For I'm too tired now I will load up the new
version tomorrow (today)
Gruß und guten morgen
Hayo
Hi Hayo and guys all!
Hayo W. schrieb:
>Es ist mal wieder soweit,>>die BF.2.2 ist fertiggestellt mit zahlreichen Verbesserungen und Fixes.>Heute bin ich zu müde, aber morgen (eigentlich heute) werde ich die neue>Version mit den entsprechenden Erklärungen hochladen.
Hayo, thank You so much!
I'm eager to try it, thank You very, very, very much!!!
You are very kind and tireless.
Hayo i wish You a good weekend.
RESPECT!!!
Vielen Dank!!!
Gruß Luc
Ok, genau richtig zum Abendlichen rumspielen die neue Version.
Es gibt jetzt eine reichhaltige Auswahl an Filtern, es sollte für jeden
was dabei sein. Neu sind die IIR-Filter, angeregt durch Alex.
Die Filter haben folgende Eckfrequenzen (cutoff frequency) bei 1GSa/s:
- Smooth ca. 80 - 90Mhz -> in allen anderen TB liegt die Cut Off Frequ.
bei
der halben Abtastrate, ist also verlustfrei.
- Strong ca. 30 Mhz -> durch die große Überlappung wird hier ordentlich
was
abgeschnitten
- IIR 1 Stage ca. 70 - 80Mhz einstufiges IIR-Filter mit Koeffizient 0.5
- IIR 2 Stage ca. 35 - 40Mhz zweistufiges IIR-Filter Koeffizienten 0.5
- IIR 3 Stage ca. 20MHhz dreistufiges IIR-Filter - echt brutal!! Das
Teil
bügelt alles platt. Koeffizienten 0.5/0.5/0.25
Ich habe den Filtern jetzt eigene Speicherbereiche für den Ausgang
spendiert. Was heißt das?
Man kann jetzt im Stop-Mode nach Herzenslust scrollen, es wird jetzt
durch den Filterbuffer gescrollt. Man kann sogar im Stop-Mode den Filter
umschalten und sieht sofort die Veränderung - echt cool finde ich.
Weiterhin habe ich die Cursorroutinen überarbeitet, neue
Drehgeberkennlinie, schnellere Werteberechnung und was mich vorher immer
gestört hat - in den TB 20ns/10ns/5ns/2ns konnte man nur in einem sehr
groben Raster hoppeln. Jetzt geht es Pixelgenau.
Da ich aus Zeitgründen nicht alles bis ins Detail testen konnte schaut
doch bitte mal ob ich noch was übersehen habe.
Noch zwei Hinweise:
- bei Kanal 1 läßt sich der Spannungsbereich bis 1 mV herunterdrehen,
das ist aber ohne brauchbaren Effekt und nur zum Testen. Ich hab einfach
vergessen es wieder abzuschalten. Mach ich bei der nächsten Version.
- Wegen der neuen Werte im Flash wird wieder alles auf default gesetzt.
Ihr müßt also alles neu einstellen und kalibrieren!
All settings are resetted to default. Please adjust your
hardwaresettings!
Calibration is recommended!!
Gruß Hayo
Hi Hayo and guys all!
Hayo again thanks You very, very much for the great job and free time
You provided generously to us!!!
You are tireless and very kind!
No words.
Hayo W. schrieb:
>Es gibt jetzt eine reichhaltige Auswahl an Filtern, es sollte für jeden>was dabei sein. Neu sind die IIR-Filter, angeregt durch Alex.>>Die Filter haben folgende Eckfrequenzen (cutoff frequency) bei 1GSa/s:>>- Smooth ca. 80 - 90Mhz -> in allen anderen TB liegt die Cut Off Frequ.>bei der halben Abtastrate, ist also verlustfrei.>>- Strong ca. 30 Mhz -> durch die große Überlappung wird hier ordentlich>was abgeschnitten>>- IIR 1 Stage ca. 70 - 80Mhz einstufiges IIR-Filter mit Koeffizient 0.5>>- IIR 2 Stage ca. 35 - 40Mhz zweistufiges IIR-Filter Koeffizienten 0.5>>- IIR 3 Stage ca. 20MHhz dreistufiges IIR-Filter - echt brutal!! Das>Teil bügelt alles platt. Koeffizienten 0.5/0.5/0.25
Very impressive.
Hayo, since You're improving the Acquire menu and even though I've
already asked, would it be possible to add Peak Detect and modify the
AVERAGE's menu in order to adjust the averages number in acquisition
mode?
I apologize for my rudeness, so sorry Hayo.
Hayo W. schrieb:
>Ich habe den Filtern jetzt eigene Speicherbereiche für den Ausgang>spendiert. Was heißt das?>>Man kann jetzt im Stop-Mode nach Herzenslust scrollen, es wird jetzt>durch den Filterbuffer gescrollt. Man kann sogar im Stop-Mode den Filter>umschalten und sieht sofort die Veränderung - echt cool finde ich.
Hayo You are right, it is really very cool, thank You very much!
I do not know how You can do these things, I can not wait to try it!
Hayo W. schrieb:
>Weiterhin habe ich die Cursorroutinen überarbeitet, neue>Drehgeberkennlinie, schnellere Werteberechnung und was mich vorher immer>gestört hat - in den TB 20ns/10ns/5ns/2ns konnte man nur in einem sehr>groben Raster hoppeln. Jetzt geht es Pixelgenau.
This is really incredible!
Hayo, I wanted to ask You if You could do it but I did not have the
courage...
Hayo You're too big!
Thanks You very, very much for the great improvement!
Hayo W. schrieb:
>- bei Kanal 1 läßt sich der Spannungsbereich bis 1 mV herunterdrehen,>das ist aber ohne brauchbaren Effekt und nur zum Testen. Ich hab einfach>vergessen es wieder abzuschalten. Mach ich bei der nächsten Version.
OK this is only for testing and of no useful effect but it is
interesting to be able to take a look at it.
Also this is something I've always wanted to try even if only for test.
Hayo I wish You a good Sunday.
RESPECT!!!
Vielen Dank!!!
Gruß Luc
Luc schrieb:> Hayo, since You're improving the Acquire menu and even though I've> already asked, would it be possible to add Peak Detect and modify the> AVERAGE's menu in order to adjust the averages number in acquisition> mode?
I will try to improve the Average Function, but it is realized in
Assembler. So it might be a little bit tricky...
Please describe the function of Peak Detect. What should it do? What
should be shown on the screen?
Regards Hayo
Komisch, kann das jetzt garnicht mehr reproduzieren, vielleicht ein
Schluckauf?
>Hast Du den richtigen Source Channel eingestellt?
Wenn ein Kanal weggeschaltet wird, ändert sich der Source Channel
automatisch auf den noch vorhandenen Channel.
Ansonsten ist der Triggerlevel Gelb oder Grün...
Hier mal ein 48MHz (soll ein Rechteck sein) Signal mit deinen Filtern!
Ch.1 ist ein Selbstbaukopp mit 10/1 Teiler
Ch.2 ist der Welec-Prob/200MHz mit 10/1 Teiler
Noise OFF, SMOOTH, STRONG, 1-STAGE, 2-STAGE, 3-STAGE
zum Schluss ein Bonbon :)
Gruß Michael
Hi Hayo and guys all!
Hayo thanks for your prompt reply, You're very kind!
Hayo W. schrieb:
>I will try to improve the Average Function, but it is realized in>Assembler. So it might be a little bit tricky...
Sorry Hayo, I did not know.
I do not want to abuse your kindness and your patience.
However, as usual, I thank You!
Hayo W. schrieb:
>Please describe the function of Peak Detect. What should it do? What>should be shown on the screen?
something like this:
Hayo W. schrieb:
>Der TDS220 kann die Signaländerungen zwischen den später gespeicherten>Abtastpunkten erkennen, wenn er im Peak Detect Mode läuft:>"Peak Detect - High frequency and random glitch capture; captures>glitches as narrow as 10 ns using acquisition hardware at all time/div>settings between 5 µs/div and 5 s/div."
From the TDS 200-Series Service Manual:
Peak Detect Response captures 50% or greater amplitude of pulses ≥10 ns
wide (5 s/div to 5 us/div) in the center 6 vertical divisions.
The oscilloscope reverts to Sample mode when the sec/div (Horizontal
scale) setting is from 2.5 us/div to 5 ns/div. The Sample mode can still
capture 10 ns glitches.
From the TDS 200-Series User Manual:
Peak Detect.
In this acquisition mode, the oscilloscope finds the highest and lowest
values of the input signal over a sample interval and uses these values
to display the waveform.
In this way, the oscilloscope can acquire and display narrow pulses,
which may have otherwise been missed in Sample mode.
Noise will appear to be higher in this mode.
Many thanks Hayo and best regards.
Vielen Dank!!!
Gruß Luc
Hi Hayo and guys all!
@Hayo
I am trying new software and I find it perfect!
It is impressive, it seems to me to use a different DSO!!!
If I did not see at it with my eyes I can not believe at it, really
incredible!!!
Then all the trigger's functions seem to me much more stable, the
trigger works fine even at high frequencies and in all circumstances!!!
Is really how to use a different DSO, a new DSO!!!
No words, RESPECT!!!
Gute Sonntag an alle
Vielen Dank!!!
Gruß Luc
Hi Hayo,
DANKE für den Großumbau bei der Filterei. Die Lösung mit den getrennten
Speichern und der Möglichkeit zur Offline-Änderung der
Filtercharakteristik finde ich sehr gut.
Folgendes Schönheitsproblem hat sich da noch aufgetan:
Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer
Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend
am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als
auch ohne Filter.
Z.B.
1. Messung Single, Trig norm mit 2 ms/div
2. Pan auf Speicherende (ganz nach rechts, Zoom3.png)
3. Zoom auf 500 us/div und Pan ganz nach rechts
4. Zoom auf 1 ms/div (Zoom1.png, -> Fehlerhafte letzte Pixel)
5. Zoom auf 2 ms/div (Zoom2.png, -> Fehlerhafte letzte Pixel)
6. Pan Knopf berühren (Zoom3.png, -> Signal springt nach rechts,
Darstellung ok)
Der Sprung unter (6) deutet fast auf einen zunächst falsch
initialisierten Pointer/Schleifenzähler hin, oder?
p.s. Mit Probe Comp Signal und Messung bei 200 us/div sieht man's
genauso.
IIR3-Bias:
Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen
Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und
Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem
erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt. In
Filt2_xxx.png sind die Y-Cursor auf das ungefilteren Probe-Comp-Signal
eingestellt. Besonders beim IIR3 rutscht das Signal deutlich hoch und
ganz vorne sieht man ein Einpegeln, was sich vielleicht mit einer
geeigneten Filterinitialisierung (z.B. mit Signalmittel der ersten
Punkt?) noch etwas aufhübschen läßt.
Anregung zu X-Cursorn:
Momentan beziehen sich die als Cursorposition angegebenen Zeiten immer
auf die Bildschirmposition, was eigentlich ziemlich belanglos ist. Ich
wäre dafür, die Zeiten auf den Triggerzeitpunkt zu beziehen, so dass man
unabhängig von Zoom- und Panfunktionen einen festen Bezug zum Signal
hat.
Wie ist die allgemeine Meinung dazu?
Danke noch mal für dein klasse Arbeit.
Gruß
Rainer
Hallo Allerseits,
auf die Frage nach freie Programmieradresse(n) für die LMH6518 –
Platinen:
Ich hab mein 4-Kanal Oszi untersucht und einiges über die
Schieberegister-Struktur ermittelt. Es scheint mir jetzt, die
Programmierung doch einfach integrieren zu können – dazu brauche ich
aber noch einige Informationen bzw Bestätigungen:
Auf Adresse 0 habe ich keinen angeschlossenen Schieberegister finden
können.
- Meine Frage an alle Programmierer: taucht die Adresse 0 in den
Programmiersequenzen überhaupt auf und wofür?
- 2. Frage: Welche Funktionen beeinflusst U26 (Adr. 2) – das IC befindet
sich neben der RS232 - Buchse?
Und wie viel bits werden dafür belegt – 8 16 24 ? - nach meinen
Messungen und laut Schaltplan nur 8?
- 3. Frage: Adr. 3 scheint nur für 4-Kanal-Geräte benutzt zu werden. Wie
viel bit werden dafür belegt – 8 16 24 ? - nach meinen Messungen
nur 8?
- 4. Frage: Auf Adr. 5 werden U22 (8bit) sowie U24(8bit) programmiert.
Sind es tatsächlich nur 16 bit, die auf diese Adr. eine Bedeutung haben?
- 5. Frage: - an alle, die ein 2-Kanal-Gerät haben und Fotos von der
PCB-Bestückung posten können damit ich sehen kann, welche ICs bei den
Kanälen 3 und 4 bestückt sind (der Bereich um die AD8131 - ICs)?
Gruß
Walter
Hi Hayo,
mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf.
Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B.
1.45 ms einzustellen.
Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab
1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms
weiter.
Gibt es da einen Trick?
Schönen Sonntag an alle.
Gruß
Rainer
Rainer W. schrieb:> Folgendes Schönheitsproblem hat sich da noch aufgetan:> Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer> Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend> am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als> auch ohne Filter.
Hmm, hat bei mir irgendwie nicht geklappt.
> IIR3-Bias:> Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen> Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und> Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem> erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt.
Ich hab mal etwas genauer getestet. Das könnte der Gleichspannungsanteil
des Rauschens sein. Der Offset der da auftritt ist abhängig von der
Stärke der Filterung und ist nur maximal so groß wie der Rauschpegel.
Das Einschwingen hab ich beseitigt indem ich einfach etwas früher (also
außerhalb des Bildschirms) mit der Berechnung anfange.
> Anregung zu X-Cursorn:> Momentan beziehen sich die als Cursorposition angegebenen Zeiten immer> auf die Bildschirmposition, was eigentlich ziemlich belanglos ist. Ich> wäre dafür, die Zeiten auf den Triggerzeitpunkt zu beziehen, so dass man> unabhängig von Zoom- und Panfunktionen einen festen Bezug zum Signal> hat.
Wäre machbar, aber bringt das denn einen Vorteil? Bislang fand ich das
so ganz ok.
Gruß Hayo
Rainer W. schrieb:> Hi Hayo,>> mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf.> Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B.> 1.45 ms einzustellen.> Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab> 1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms> weiter.>> Gibt es da einen Trick?
Kein Trick! Diese Zählweise hat der WELEC-Programmierer bei allen
vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte
Werte nicht einstellen!!!
Offenbar hat er sich wohl gedacht, dass man es oberhalb der jeweiligen
3er Potenz nicht genauer braucht. Da grübel ich schon einige Zeit drüber
nach, wie man das verbessern könnte ohne sich einen Wolf kurbeln zu
müssen.
Hast Du Vorschläge?
Gruß Hayo
Ciao a tutti e grazie ancora ad Hayo per il grandioso lavoro! Grazie
grazie, ora è ancora migliore!
Segnalo un piccolo problema, visualizzando il segnale di test a 1KHz,
dopo lo stop e lo switch della base dei tempi o dei filtri, il segnale
visualizzato è completamente sbagliato.
Ops, sorry for Italian.
Hello everyone and thanks again to Hayo for the great job! Thank you
thank you, now it's even better!
Report a small problem, shows the test signal at 1KHz, after the stop
and the switch time base or filters, the displayed signal is completely
wrong.
Hi Rainer W., Hayo and guys all!
Rainer W. schrieb:
>Folgendes Schönheitsproblem hat sich da noch aufgetan:>Nach Signalerfassung (Single) greift die Darstellungsroutine nach einer>Verkleinerung des Zoom-Faktors unter bestimmten Bedingungen anscheinend>am Ende auf ungültige Speicherbereiche zu. Das passiert sowohl mit als>auch ohne Filter.>Z.B.>1. Messung Single, Trig norm mit 2 ms/div>2. Pan auf Speicherende (ganz nach rechts, Zoom3.png)>3. Zoom auf 500 us/div und Pan ganz nach rechts>4. Zoom auf 1 ms/div (Zoom1.png, -> Fehlerhafte letzte Pixel)>5. Zoom auf 2 ms/div (Zoom2.png, -> Fehlerhafte letzte Pixel)>6. Pan Knopf berühren (Zoom3.png, -> Signal springt nach rechts,>Darstellung ok)
hallo Rainer W.
I do not know if it is related but in the last part of the displayed
waveforms there are some ripetitive glitches, some spike I say.
These glitches are present regardless of the type of filter inserted and
also when no filter is inserted, please look at my screenshoot.
This is also observed by others?
I could be wrong but I never noticed them before now but at the same
time I think I read here something about it.
I'm a bit confused.
Rainer W. schrieb:
>p.s. Mit Probe Comp Signal und Messung bei 200 us/div sieht man's>genauso.>>IIR3-Bias:>Dann ist mir beim IIR3 Filter noch aufgefallen, dass die ausgegebenen>Werte nicht ganz bias-frei sind. Ein Vergleich von Filter_IIR2.png und>Filter_IIR3.png zeigt, dass zu Anfang die Nulllinie stimmt und nach dem
erstem Puls mit IIR3 ein nach oben verschobener Pegel auftritt. In
>Filt2_xxx.png sind die Y-Cursor auf das ungefilteren Probe-Comp-Signal>eingestellt. Besonders beim IIR3 rutscht das Signal deutlich hoch und>ganz vorne sieht man ein Einpegeln, was sich vielleicht mit einer>geeigneten Filterinitialisierung (z.B. mit Signalmittel der ersten>Punkt?) noch etwas aufhübschen läßt.
I agree, I find this thing even.
Rainer W. schrieb:
>mit dem Puls Width Trigger habe ich gerade ein Brett vorm Kopf.>Mir gelingt es nicht, eine minimale Pulsbreite (">"-Wert) von hier z.B.>1.45 ms einzustellen.>Unterhalb von 1.0 ms ändert sich der Wert in Schritten von 1 us und ab>1.0 ms geht es gleich mit Siebenmeilenstiefeln in Schritten von 1 ms>weiter.>>Gibt es da einen Trick?
Me too, I confirm so I agree with the question:
Gibt es da einen Trick?
Hayo W. schrieb:
>Kein Trick! Diese Zählweise hat der WELEC-Programmierer bei allen>vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte>Werte nicht einstellen!!!>>Offenbar hat er sich wohl gedacht, dass man es oberhalb der jeweiligen>3er Potenz nicht genauer braucht. Da grübel ich schon einige Zeit drüber>nach, wie man das verbessern könnte ohne sich einen Wolf kurbeln zu>müssen.>>Hast Du Vorschläge?
Hallo Hayo.
Ok, I understand but unfortunately I can not help, I am sorry Hayo.
Schönen Abend an alle.
Gruß Luc
Hi gyppe, Hayo and guys all!
gyppe schrieb:
>Report a small problem, shows the test signal at 1KHz, after the stop>and the switch time base or filters, the displayed signal is completely>wrong.
@ gyppe
Ciao gyppe.
Provato e riuscito solo con STOP + FILTRO + cambio TEMPO di BASE.
Per piacere guarda mia immagine e conferma.
@all
Hi gyppe,
I tried but I succeeded only in this way:
1)I capture the image of the compensation signal of the probe by
pressing the RUN/STOP's button
2)I insert or I change the filter
3)with the DSO still in STOP I change the TIME BASE.
4)On the screen appears the without sense waveform that You can see in
my screenshot.
Please gyppe, is this what you mean?
Hayo W. schrieb:
>Do You have a Screenshot for us?
@gyppe
Questo volta avere io!:-)
@Hayo and all
I have it!:-)
Buona sera a tutto.
Schönen Abend an alle.
Gruß Luc
Hallo Hayo,
Hayo W. schrieb:> ...Diese Zählweise hat der WELEC-Programmierer bei allen> vergleichbaren Funktionen so implementiert. Dadurch kann man bestimmte> Werte nicht einstellen!!!
Das kann doch wohl nicht sein Ernst gewesen sein :-(
Von einem Pulsweitentrigger erwarte ich einfach, dass man z.B.
Intervalle wie [1.4 ms .. 1.6 ms] einstellen kann!!!
Nochmal Pulstrigger:
Mit dem Puls Width Trigger scheint noch mehr schief zu gehen:
Bei obigen Einstellungen sollte ein 1.7 ms Puls sauber triggern.
Weit gefehlt - [1.0 .. 1.47] ms kriegt er zu fassen.
(Display persist, Pulsbreiten [0.95 .. 2.05] ms reingefütter)
Über eine Eingabemethode für die Parameter werde ich auch mal
nachgrübeln.
Gruß
Rainer
Ciao luc, parli Italiano? :)
Unfortunately I can not make screenshots, i use linux, and bf1.6 does
not work, I do not know if it depends on my system or if there are
problems in the Linux version.
Yes, the images are similar, I discovered that I also only happens with
the filters turned on, even as delayed same effect.
Spero di riuscire a farmi capire, non parlo inglese molto bene.
Gyppe.
Nice Screenshos....I like them, looks like modern art!! ;-)
Tomorrow I will try to reproduce them and if possible - to fix the
problem.
@Rainer
Das Problem ist, wenn die Schritte zu fein sind, dann kurbelt man sich
eine Wolf, und wenn sie zu grob sind kann man es nicht genau genug
einstellen. Man muß eigentlich die Schrittweite bei jedem beliebigen
Wert frei einstellen können - ich denk drüber nach.
In english:
The problem is, if the steps are too small, You will get gray and old
while changing the value from 0.001 to 1000. Otherwise if the steps are
to big it is not possible to adjust the values accurately.
So the solution must be to be able to choose the step width free at
every value - I'm thinking about it.
Noch einen schönen Abend - nice evening to all - Buona sera a tutto
Hayo
gyppe schrieb:> Ciao luc, parli Italiano? :)>> Unfortunately I can not make screenshots, i use linux, and bf1.6 does> not work, I do not know if it depends on my system or if there are> problems in the Linux version.
Hmm, whats going wrong? Doesn't it start or doesn't it start after
triggering a screen shot? Did You switch to the BF-Version in the Quick
Print menu?
On my Suse Linux 11.1 it works without problems (AMD Mainboard 3 Ghz
direct RS232 connection - no USB-converter)
Hayo
>Auf Adresse 0 habe ich keinen angeschlossenen Schieberegister finden>können.>- Meine Frage an alle Programmierer: taucht die Adresse 0 in den>Programmiersequenzen überhaupt auf und wofür?>BIs jetzt nicht.>- 2. Frage: Welche Funktionen beeinflusst U26 (Adr. 2) – das IC befindet>sich neben der RS232 - Buchse?
Das sollte der externe Trigger-Level sein
>Und wie viel bits werden dafür belegt – 8 16 24 ? - nach meinen>Messungen und laut Schaltplan nur 8?
Keine Ahnung. Ist ein Integer. Müsste ich erst genauer suchen.
Morgen misst Crazor die genaue Funktion der seriellen Schnittstelle aus.
Dann sehen wir weiter.