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

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

Na dann kriegen wir hier ja bald wieder Zuwachs...

Hayo

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

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

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!

Alles klar,

danke für den schnellen Test und Feedback.

Gruß Hayo

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

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

Ich arbeite gerade an einer Lösung, der Test dauert aber einen Moment.

Ich melde mich gleich.

Hayo

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

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

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

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

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

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

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

habe Eure Posts gelesen, bin aber etwas in Zeitdruck. Ich melde mich 
morgen nochmal.

Hayo

kann mir jemand aus dem Inhalt der BF20_C18_src.zip eine TomCat.flash 
bzw. auch TomCat.ram erstellen, bin mit dem compilieren nicht vertraut.

Findest Du hier:


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

Gruß Hayo

danke

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

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

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

Mirko B. schrieb:
> 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

Hi Mirko,
bitteschön, hier is'-------------------------------------

die besagten 0 Ohmler befinden sich im Schaltplan hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Auf der Platine hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Getauscht sieht das so aus:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Ein kleines Ergebnis hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Den ADC's verpasst du gleich etwas Kühlung wenn du schon dabei bist:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

und der 150 Kilo Ohmler Abschluss sitzt hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Feine Lötspitze mit 360 Grad, Aceton, Wattestäbchen, Löthonig, Lupe oder 
Mikroskop und eine ruhige, sehr ruhige Hand.
Die verklebten Leitungen neben den AD8131 haben einen Kleber, der beisst 
wie s.. in der Nase, wenn der Lötkolben dran kommmt...

Viel Spaß beim Tauschen

Hoffe ich habe da nix vergessen?!?

Gruß Michael

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

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

Hi,

ich habe mal was zum Thema Widerstände im HW-Thread gepostet:

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

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

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?

@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

Ist etwas schwierig, aber ich werde mal sehen ob mir da was einfällt.

Gruß Hayo

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

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

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

das wäre eine Lösung den vom langsamen Speicher ist ja genug da.

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

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

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

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

Danke Hayo,
ich warte schon ganz gespannt :)

einen schoenes WE

vlg
Charly

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,
der Autotriggerlevel funzt nicht mehr, kann das sein?

Gruß Michael

Das würde mich doch wundern, muß ich mal prüfen, aber an der Sache war 
ich nicht dran.

Hayo

Hab's grad mal geprüft, bei mir funktioniert alles wie es soll.

Hast Du den richtigen Source Channel eingestellt?

Gruß Hayo

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,

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

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

Do You have a Screenshot for us?

Hayo

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