Hier ist die Fortsetzung von:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"

Und noch die Hardware Diskussion:
Beitrag "Wittig(welec) DSO W20xxA Hardware"

> Das heißt du könntest nur die Kompressionsroutine übernehmen?

Eigentlich ja, aber das Coding von Falk ist doch ziemlich "kompakt"
geschrieben und daher nicht ganz einfach nachzuvollziehen. Es gibt auch
noch einige weitere Änderungen die ich dann anpassen müßte.

Ich hatte mir das schon mal angesehen, aber dann doch keine Zeit/Lust
gehabt.
Vielleicht baue ich das demnächst trotzdem mal um.

>>Hayo W. schrieb:
>> Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS
>> die Buttons eine jeweils eigene Beschriftung und Funktion haben

>Gute Idee! Bekomme ich dann den 5. Soft-Button als "Save to USB"?

Klar kein Problem. Ich vermute mal nur für die OS-Version solange ich
die Kompressionsroutine noch nicht upgedatet habe?

Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung
stellen?

Gruß Hayo

Hayo W. schrieb:
> Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung
> stellen?

Na klar!

Ich versuche mal das zum nächsten Release vorzubereiten, für die
Funktion mach ich Dir dann einen leeren Methoden-Body.

Hayo

OK, danke.

Habe nur ich ein Problem beim Norm-Trigger vom W2024 Ch3/4?

Mit der FW 2.9.C2 W2024 beobachte ich folgendes Problem: Ein normaler
Edge-Trigger auf Kanal 3 bzw. 4 funktioniert bei Umschaltung der TB nur
in jeder zweiten Stellung, also z.B. bei ... 20, 5 und 1 us/div kommt
der Trigger durch und bei ... 10, 2 und 1 us/div kommt er nicht durch.

Dagegen hilft: Run/Stop auf 'Stop' und wieder auf 'Run'. Dann geht's auf
den anderen Stufen, als ob dabei irgendetwas wesentliches wieder richtig
gesetzt wird. Trigger auf Ch1/2 tut's immer.

Hat jemand eine Idee oder ist das ein (bekanntes?) FPGA-Problem?

Gruß
Rainer

Du hast recht, bei mir ist das auch zu beobachten. Ich kümmere mich
darum.

Danke für den Tip

Hayo

Bei mir tritt das nur bei Zeitbasen von 5ms bis 500ms auf. Hat hier
jemand andere Erkenntnisse?

Das Problem müßte eigentlich auch bei älteren FW-Versionen auftreten.
Muß ich nochmal prüfen.

Hayo

Ok, Problem ist behoben.

Hayo

Hayo W. schrieb:
> Ok, Problem ist behoben.

Klasse, hatte gerade alles von 2 ns/div bis 200 ms/div durchprobiert -
trat überall auf. Aber du warst schneller.

Danke
Rainer

Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem
Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war
alles ok.

Es ist auch schon die zusätzliche manuelle Triggerung via Single-Button
und die Hardwareunterstützung des LTC 2602 drin.

Gruß Hayo

Hallo Hayo,
nächstes Problem:
Ich muss auf ein (beliebiges) Zeichen vom UART warten.
Dazu habe ich eine globale Variable angelegt die in der
Hardware::ISR_UART() auf 1 gesetzt wird. Die Abfrage sieht dann einfach
so aus:

rx=0;            //Globale Variable zurücksetzen
while(!(rx));    //Warte bis sie von der ISR gesetzt wird
rx=0;            //Wieder zurücksetzen (eigentlich hier unnötig)

Gibt es da eine elegantere Möglichkeit oder kann das so bleiben? Ginge
auch eine Abfrage von  puart->np_uartstatus und puart->np_uartrxdata?

Das beliebige Zeichen ist zur Zeit ein Leerzeichen (0x20). Besteht die
Gefahr dass ich damit etwas durcheinanderbringe?

Mfg,
Kurt

Hayo W. schrieb:
> Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem
> Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war
> alles ok.

Der Trigger über Ch3/4 scheint zu funktionieren.
Aber ganz weit bin ich mit Testen nicht gekommen, weil die Kiste jetzt
sehr gerne total einfriert. Bis auf Softkey-Reset geht dann gar nichts
mehr.

Gruß
Rainer

Sorry,

hatte vorhin quick & dirty die Sache ausprobiert und dabei eine
Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles
sollte gut sein.


@Kurt

Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und
wenn nix kommt, hast Du das Gleiche wie ich vorhin!

Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen,
denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird
jedesmal gemacht.

Hayo

Hayo W. schrieb:
> hatte vorhin quick & dirty die Sache ausprobiert und dabei eine
> Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles
> sollte gut sein.

Hajo, da kommt noch kein weißer Rauch.
Irgendwie scheint die Falle immer noch drin zu sein. Nur manchmal
(etliche Sekunden) kommt die Bedienung durch, so dass man eine Chance
hat die TB zu verstellen. Nix mit locker durchdrehen ...

Gruß
Rainer

Hi Rainer,

gib mir mal ein paar Details zu den verwendeten Einstellungen
(Hardwaremenü, TB, aktive Kanäle, Spannungsbereich), denn bei mir lief
das irgendwie problemlos.

Gruß Hayo

So - hab nochmal eine kleinigkeit geändert, damit die Bedienung bei
Zeitbasen mit langer Abtastzeit etwas flüssiger wird. Bitte
berücksichtigen, dass aber grundsätzlich das Ganze ab 20ms an aufwärts
etwas langsamer wird, und damit auch die Reaktionsgeschwindigkeit auf
das Human Interface.

Gruß Hayo

Hi Hayo,

mmh, keine besonderen Einstellungen:
- Default Setup
- Trigger Norm, Ch.4 rising Edge, Level 2.5 V
- TB um die 1us/div, sofern machbar ;-)
- Signal: 5V Einzelpulse 1us auf Ch.4

Problem scheinen die Einzel-Events zu sein. Dabei verfängt das DSO sich
gerne. Wenn ich aber statt dessen nach einem Soft-Reset das Probe Comp
Signal dran habe, läuft alles.

Gruß
Rainer

Noch einer!

Ich habe jetzt einen völlig anderen Lösungsansatz gewählt. Die Bedienung
wird dadurch flüssiger und ich hatte auch keine Aussetzer bei meinen
Tests. Diese Variante gefällt mir bislang am besten.

Probierts doch bitte mal aus.

Hayo

Hayo W. schrieb:
> Probierts doch bitte mal aus.

Signal: Probe Comp an Ch1, Einzelpulse an Ch4

Die Hänger sind in der 2.10.Pre4 weg, aber wenn Trigger auf Ch4 steht
und ich die TB langsamer mache, kommen ab 10us/s bei Einzelpulssignal
kein Trigger mehr durch, d.h. 2ns/div ..5us/div geht, 10us/div ... geht
dann nicht mehr. Allerding: Wenn ich dann bei z.B. 20us/div auf
Ch1-Trigger schalte (Erfassung läuft wg. Ch1.Signal) und wieder zurück
auf Ch4, funktioniert auch Trigger auf Einzelpulse wieder, solange ich
nicht von 5us/div auf 10us/div umschalte.

Wird an dieser Grenze irgendetwas Grundlegendes geändert?

Gruß
Rainer

Ja zwischen 10µs und 5µs wird anscheinend die Betriebsart der ADC
umgeschaltet, denn bei 5µs werden 16k Werte gesampelt und ab 10µs sind
es dann nur noch 4k.

Genauer kann man das in der Programmers Reference sehen auf dem Reiter
"Timebase Table".

Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das
Signal zu klein kleiner als ein Div hoch. Dann setzt der trigger schon
mal aus. Aber sobald das Signal größer ist läuft alles ohne Aussetzer.

Können die Anderen hier das auch mal testen bitte? Nicht das ich der
Einzige bin bei dem es keine Aussetzter gibt.

Gruß Hayo

Hayo W. schrieb:
> @Kurt
>
> Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und
> wenn nix kommt, hast Du das Gleiche wie ich vorhin!
>
> Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen,
> denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird
> jedesmal gemacht.
>
> Hayo

Den Timeout mit if() habe ich schon drin, oben war nur ein (zu) stark
verkürztes Beispiel. Sorry.

Es ging mir nur darum ob die Sache mit der globalen Variablen so in
Ordnung ist oder man es besser machen kann.

Hayo W. schrieb:
> Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das
> Signal zu klein kleiner als ein Div hoch.

An der Signalhöhe liegt es definitiv nicht (2,5 div und TL ca. 50%). Ich
kann auch reproduzierbar zwischen 5 und 10us/div umschalten, Trigger Ch4
mit Einzelpuls kommt nur bei 5us/div durch, dto. die
rote/Ch4-Trigger-LED. Bei 10us/div rauscht nach gefühlten 30 s ein Puls
durch (Spike auf Ch4) und dann triggert das DSO auch wieder aufs
Einzelsignal.

Hilft das?

Im Prinzip mache ich das auch so mit globalen Flags. Allerdings solltest
Du bei globalen Variablen den Namen möglichst sprechend wählen - z.B.
USB_rx_flag oder USB_rx_request oder so, Dann wird das etwas
übersichtlicher und besser lesbar.

Gruß Hayo

@Rainer

Ich hatte etwas schwierigkeiten Deinen Fall nachzustellen, hab es aber
jetzt hingekriegt. Die Pulse müssen schon sehr langsam kommen damit das
Problem auftritt (1 Puls pro Sekunde).

Aber dann passiert es bei mir auch wie beschrieben. Mal sehen ob ich die
Ursache lokalisieren kann.

Gruß Hayo

Hayo W. schrieb:
> Die Pulse müssen schon sehr langsam kommen damit das
> Problem auftritt (1 Puls pro Sekunde).
Tun sie, ich löse die von Hand aus.

Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf
10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es
sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der
eigentlich hätte auf 0 gestellt werden müssen?

Gruß Rainer

> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf
> 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es
> sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der
> eigentlich hätte auf 0 gestellt werden müssen?

Keiner den ich benutze, aber es ist schon mal ein Ansatz für die Suche.

Gruß Hayo

Na Du bist aber fix. Da passt das ja das heute meine Lötstation gekommen
ist.

Gruß Hayo

moin moin Hayo,

hier was fuers Wochenende, hat mich ein paar stunden suche
gekostet obwohl meine Soft 'unschuldig' war

was du auf dem Bild siehst ist ein SYMETRISCHES Signal,
nur das Oszi zeigt was anderes, irgendwie als waehre dein
Puffer zu kurz oder wird ueberschrieben, oder ?

FW = BF2.8

vlG
Charly

@Charly, Hayo

Der am rechten Rand dargestellte Datenmüll stammt zeitlich aus einem
anderen Bereich des Signals und taucht am rechten Rand immer auf, wenn
das Fenster mit der Horizontalverschiebung ganz nach Rechts geschoben
ist, d.h. am Ende der gesampleten Daten liegt. Horizontalregler a bissl
nach links drehen und schon ist es nicht mehr zu sehen ;-)

Schönen Sonntag

Rainer

Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal
ausprobieren.

Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht
weitergekommen. Ich denke aber dass es sich eher um ein minder
priorisiertes Problem handelt oder?

Ich habe erst mal am Quick Print Menü weitergemacht, was schwieriger war
als ich dachte, da ich (eigentlich wie immer) auf Altlasten in der
Menüsteuerung gestoßen bin. Jetzt hab ich da aber aufgeräumt und alles
ist gut. Ich werde nachher mal die fertige 2.10 hier hochladen.

Gruß Hayo

Hayo W. schrieb:
> Ich habe erst mal am Quick Print Menü weitergemacht

Super,

ich werde die später meine neuen Funktionen schicken:
UC_rle_enc(...)
UC_SCREENSHOT_BW()
UC_SCREENSHOT()
UC_DUMPCSV()

Mfg,
Kurt

So, der Reihe nach:

- @Charly -> das Datenmüllproblem habe ich eben noch beseitigt.

- @Mirko -> ja ist irgendwie ärgerlich, aber wenn man einen
zuverlässigen Trigger braucht muß man eben Kanal 1 oder 2 nehmen.
Vielleich stoße ich noch auf eine Lösung.

- @Kurt -> alles klar, ich habe Dir eine leere Methode gebaut, die
angesprungen wird wenn der USB-Button gedrückt wird. Zur Zeit gibt sie
nur einen Text auf dem Terminal aus. Du Findest sie in der commif_t.cpp
ganz am Ende -> void CommIF::Save2USB(void)

- @Branadic -> tja entweder funktioniert es mit dem 16 Bit DAC - oder
nicht. Kann sein das ich den Registerwert noch um zwei Bit verschieben
muß, das muß ich aber noch ausprobieren. Zur Zeit kann ich das ja leider
noch nicht testen. Wenn Du umschaltest auf 16 Bit werden die drei
anderen Kanäle sich nicht mehr verstellen lassen. Wenn es gut Läuft geht
dann aber der Kanal 4.

Ansonsten einfach bescheid sagen, dann ändere ich das.

Zur 2.10:

- Es gibt jetzt zwei unterschiedliche Quick Print Menüs für OS und BF.
Die Umschaltung erfolgt wie gehabt.

Gruß Hayo

Hallo Hayo,
hier sind die geänderten Dateien. Ausgangsbasis war die 2.9_C2

Mfg,
Kurt

Jetzt warst du schneller. Mal sehen was du angestellt hast. ;-)

Sieht doch schon gut aus!
Aber wäre nicht ein eigener Eintrag im Screenshot-Versions Softbutton
besser?
Und dann die 3 linken Softkeys wie in der OS-Version (Color, BW, CSV).

Hi Kurt,

ich hatte Dich in Deinem Post neulich so verstanden, dass Du da an der
freien Stelle einen Button für den USB-Transfer hinhaben wolltest.

Hab ich Dich da falsch verstanden?

Wir können das natürlich noch ändern bei Bedarf.


Gruß Hayo

Kann sein dass ich mich da etwas undeutlich ausgedrückt hatte.
Das Dateiformat in dem gespeichert wird kann ich auf meinem µC
einstellen.

Aber für die Art der Datenübertragung (Farbe, S/W, CSV) bauche ich je
einen eigenen Softbutton.

Ich könnte zwar meine UC_ Funktionen mit den OS_ Funktionen
zusammenlegen (die sind im Prinzip kompatibel, nur die RLE unterscheidet
sich) aber das halte ich in der Entwicklungsphase nicht für sinnvol.

Ok, dann baue ich das nochmal um und spendiere Deiner Funktion ein
eigenes Menü.

Gruß Hayo

Jetzt noch 2 (optische) Kleinigkeiten:
In OS_SCREENSHOT_BW(void) und UC_SCREENSHOT_BW(void) muss die UI_Plane1
noch mit in das Array. Also:

unsigned long *planes[] = {
    UI_Plane1, UI_Plane2, UI_Plane5, // UI_Plane3, UI_Plane4
    Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4,
    Channel_Math_Plane,
    Memory_Plane1, Memory_Plane2, Memory_Plane3,
    Marker_Plane1, Marker_Plane2,
    Grid_Plane,
    NULL
  };

In der UI_Plane1 scheint auch noch ein Fehler beim Zeichnen der
Umrandung des rechten Softbutton zu sein. Auf dem Bild im Anhang sieht
man dass die Umrandung nicht geschlossen ist.

Danke Hayo,
hab grad die neue Ver. eingespiel, werd heut mal testen...

aber 2 neue Fehler / 'Unschoenheiten'

1. ab einer TB >1ms muss man f. manuelles triggern im Single
mode die Single Taste mehrmals druecken ;(

2. der Pretrigger Wert wird beim langsamen durchdrehen der TB
nicht aktualisiert

vlG
Charly

@Hayo

Rainer schrieb:
> Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am
> Ende mit ins Display rutscht? Sieht bei mir so aus...

Das was da auf dem letzten Pixel noch zu sehen ist, stammt wohl vom
Noise-Filter bei Einstellungen "smooth" oder "strong".

Gruß
Rainer

@Kurt

baue ich mit ein.


@Charly

Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein.


Danke für die Rückmeldung

Hayo

Hi branadic,

sorry, der Post war tatsächlich etwas an mir vorbeigerauscht. Bin
momentan immer noch etwas in Stress hier beim Rollout meines Projektes.

Welchen Kanal (bzw. Kanäle) hattest Du denn nun auf 16 Bit umgerüstet?

War das nicht Kanal 4?

Übrigens ist heute Deine Sendung bei mir angekommen - danke!

Muß mal sehen wann ich das einbauen kann, da muß man sich ja schon etwas
Zeit für nehmen.

Gruß Hayo

Wenn es bei Dir momentan noch nicht funktioniert werde ich Dir bei
Gelegenheit mal eine modifizierte Version bauen. Bin aber momentan echt
im Streß, da ich ab morgen für den Rest der Woche eine Schulung gebe und
mich auch noch vorbereiten muß.

Gruß Hayo

Hayo W. schrieb:

> @Charly
>
> Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein.

Danke Meister ! <tiefes verbeugen>

& viel erfolg bei der schulung, und hoffentlich haste keine
mit 'Teflonpfannenkopf' dabei :)

So, bin gerade nach Hause gekommen - und was finde ich im Briefkasten?
Post von Linear Technology! Die Jungs haben mir doch tatsächlich zwei
LTC2602 als kostenloses Sample geschickt und das ziemlich zügig.

Danke noch mal für den Tip!

Schade, dass ich momentan überhaupt keine Zeit habe etwas zu basteln.
Naja, muß halt noch etwas warten.

Gruß Hayo

Ich möchte nochmal an die Sammelbestellung für die Bauteile der
Huckepackplatine erinnern. Die Frist endet Freitag Abend.

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


Mfg,
Kurt

Hi,

bin wieder mal gerade erst zu hause angekommen und wollte mal kurz die
Gelegenheit nutzen zu fragen wo ich denn den LTC2612 auf der Platine
finde. Ist ja doch recht klein das Teilchen.

@Branadic

Du hast da doch bestimmt aktuell den Überblick oder?

Sonst such ich mir da bestimmt nen Wolf.

Gruß Hayo

Hallo Hayo,
der LTC2612 ist im roten Kringel.

Mfg,
Kurt

Ach, das ist ja gleich um die Ecke bei den Vorwiderständen die ich schon
getauscht hatte.

Danke.

Kurt Bohnen schrieb:
> Ich möchte nochmal an die Sammelbestellung für die Bauteile der
>
> Huckepackplatine erinnern. Die Frist endet Freitag Abend.
>
>
>
> Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Oh, danke, wäre mir sonst durchgegangen. Ich komme gerade aus dem Urlaub
wieder und konnte das aktuell nicht verfolgen.

Mehr dort.

Jörg

Wenn Hayo grade nichts dran tut würde ich mich anbieten mal meine
Grafikfunktionen in seine Quellen zu mergen, die ich vor 1,5 Jahren in
Subversion eingecheckt hatte.
Wie sieht der Entwicklungsflow derzeit aus? Hayo, kann ich mit die
Quellen von dir "ausleihen" und dir das Resultat zurückschicken? Oder
gibt es mittlerweile eine Versionsverwaltung?

Jörg

Guido schrieb:
> Rechne mit 2 Wochen Vollzeit bis du leidlich
> nachvollziehen kannst, wo was erledigt wird.

Außerdem müsste Hayo entscheiden, wer wo was ändern darf. Und dafür
braucht er auch wieder Zeit. Vor allem braucht man auch SELBER Zeit. Ich
hatte seinerzeit vorgehabt, Alex008 beim FPGA-Design zu unterstützen,
aber aufgrund zuwenig Zeit davon Abstand genommen. Es macht keinen Sinn,
wenn man nur halbe Arbeit abliefern kann.

Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal
eine kleine Pause einlegt. Dass es überhaupt schon soweit vorangekommen
ist - alle Achtung! Dickes Kompliment an die Entwickler!

> Nur wenige werden je verstehen wie was erledigt wird.

Hat Hayo inzwischen eine Liste erstellt, wo was zu erledigen wäre? Wenn
es viele kleine Teile wären, könnte man sich eher mal dran setzen.

Gruß Ingo

Da kommt auch die Frage auf, was ist mit den ganzen anderen
Programmierern der OS-Firmware?
Vor längerer Zeit gab es Zoff weil Hayo "sich quergestellt" hat. Danach
haben anscheinend 5-10 Programmierer ihr Welec auf den Schrott geworfen
und haben kapituliert. Nur Hayo hat tapfer weitergearbeitet und treibt
auch jetzt noch das Projekt vorwärts. Das ist schon eine merkwürdige
Geschichte!?
Wenigsten Jörg möchte "zurückkommen", vielen Dank!

Den Einwand von Guido muss ich leider bestätigen. Der Quelltext umfasst
ca. 48000 Zeilen. Das ist etwas mehr als die normalen µC Projekte.

Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder
VHDL? Eine kleine Statusmeldung seinerseits wie weit er mit der
Dokumentation gekommen ist, wäre auch schön.

Ist euch eigentlich aufgefallen dass die Auktionspreise für die Welecs
deutlich gefallen sind? Früher waren es immer so 350€. Jetzt nur noch
250-280€. Verlieren die Leute das Vertrauen in unser Projekt?



Sobald die Sammelbestellung für die Teile der Huckepackplatinen
abgeschlossen ist werde ich noch eine Sammelbestellung für den USB-Host
organisieren. Die Hardware ist fast endgültig fertig, die Firmware hat
schon einen brauchbaren Funktionsumfang und läuft stabil genug.

Kurt Bohnen schrieb:
> Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder
> VHDL?

Gibt es irgendwo eine Übersicht, was noch zu erledigen wäre?

Gruß Ingo

Hallo Jungs,

nur keinen Stress. Bin zwar momentan noch etwas knapp an Zeit, aber nur
keine Panik, es geht bald weiter. Ich sag morgen noch mal was dazu bis
dann

Hayo

Hallo allerseirs,

ich sehe ich muß mir mal die Zeit nehmen einen längeren Beitrag zu
schreiben.

Da meine Beweggründe für die eine oder andere Entscheidung anscheinend
immer noch nicht ganz transparent für alle sind werde ich das noch mal
erläutern:

Ich bin schon recht lange in der Softwareentwicklung tätig und weiß
daher das ein Projekt welches von mehreren Entwicklern bearbeitet wird
eine steuernde Instanz braucht die:

- Vorgaben macht
- koordiniert
- Ergebnisse prüft
- entscheidet welche Änderungen übernommen werden
- neue Releases herausgibt nachdem die Änderungen getestet wurden

Das gilt nicht nur für kommerzielle Projekte sondern auch für Open
Source. Bei unserem Projekt gab es (auch wegen relativ dünner
Personaldecke) sowas nicht. Das führt zum Teil zu etwas unkoordinierter
Entwicklung und Wildwuchs.

Um hier unabhängig zu sein habe ich meine Version getrennt von der
OS-Version weiterentwickelt und dann gegenseitig sinnvolle
Verbesserungen ausgetauscht. Das ist auch immer noch der aktuelle Stand,
obwohl zur Zeit an der OS-Version relativ wenig gearbeitet wird.

Zum Beitrag hier drüber:

Lieber T.Dübel,

Programmieren gehört zu den komplexesten Ingenieursleistungen überhaupt.
Dass es nicht ganz so einfach ist wie Du behauptest sieht man an dem
Ergebnis das die Firma WELEC nach mehreren Jahren Entwicklung
abgeliefert hat und auf dem unsere Entwicklungen hier basieren.

Und gesetzt den Fall ich höre auf, so stehen alle bisherigen Arbeiten
als Source mit Dokumentation zur Verfügung, so dass es keinen Grund gibt
die Entwicklung nicht fortzuführen. Ich habe 2008 mit sehr viel weniger
angefangen!


Zu SFN:

Ich finde es unbedingt wichtig, das wir alle Ergebnisse und
Informationen an einer zentralen Stelle wie SFN zusammentragen um diese
allen geordnet verfügbar zu machen. Das hat nichts damit zu tun, das ein
großer Teil der Kommunikation hier im Forum stattfindet. Meine aktuellen
Releases sind immer auch auf SFN zu finden. Hier im Forum habe ich
einfach direkteren Kontakt zu allen Betroffenen.


@Jörg, Ingo, Guido, Kurt und alle die mithelfen wollen:

Meine aktuelle To Do Liste die mir so gerade einfällt sieht ungefähr so
aus:

- Pretriggerwerte aktualisieren wenn TB geändert wird (ist in Arbeit)

- Unterstützung für 16 Bit DAC. Die erste Anpassung scheint noch nicht
zu funktionieren. Ich hätte eine Idee wo noch etwas geändert werden
müßte. Wenn sich jemand des Themas annehmen möchte kann ich gerne
Hinweise zu den entscheidenden Stellen geben.

- Unterstützung für die Addon-Platine von branadic. Auch hier ist
kurzfristige Hilfe willkommen damit die hardwareseitige Entwicklung
weitergehen kann. Ich helfe auch gerne bei der Orientierung in der
Source.

- Druckmenü für Kurt erweitern -> ist in Arbeit

- Manuellen Trigger prüfen und evtl. anpassen (geringe Prio)

- Math-Funktionen (+  -  *) prüfen überarbeiten (falsche Ergebnisse?)

- Neues USB-Interface weiterentwickeln und PC-Software erstellen.

- FFT-Bereich weiter entwickeln.

- Screenshot BF-Version auf die aktuelle Komprimierungsroutine der
OS-Version updaten um etwas schneller zu werden und kompatibel zu sein.

Fehlt was entscheidendes?
Wenn Ihr Ergebnisse habt, baue ich die gerne mit in die Source ein.


Zu Subversion:

Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber
die Synchronisation hat nur zwei mal geklappt, dann habe ich aus
Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr
hinbekommen. Ich müßte das also versuchen wieder neu einzurichten.


So erstmal genug

Gruß Hayo

Hi Hayo,
ich habe mich gestern Abend mal mit Walter über die Ansteuerung der
Huckepackplatine unterhalten und er hat versucht mir die nötigen
Änderungen zu erklären. Leider habe ich es nur zu 90% verstanden und
muss nochmal nachfragen.

Danach werde ich ein Bildchen malen wie die Platinen angesteuert werden
müssen.

Mfg,
Kurt

Hi Kurt,

das klingt gut. Wenn ich mich da nicht komplett neu reindenken muß kann
ich da auch schneller eine Implementierung anbieten - bzw. jemand
anderes hier.


@All

Ach ja, falls der Eine oder Andere Bedenken hat, dass ich mit der
Entwicklung hier aufhöre, so möchte ich darauf hinweisen, dass ich mir
extra für die Entwicklung und zum Testen der WELECS umfangreiches
Equipment im Wert von über 1000 Euro zugelegt habe. Das haut man nicht
mal eben so in die Tonne.

Also locker bleiben und Ruhe ausstrahlen ;-)


Gruß Hayo

Hallo,

zu deinem Problem:

Hayo W. schrieb:
> Zu Subversion:
>
> Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber
> die Synchronisation hat nur zwei mal geklappt, dann habe ich aus
> Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr
> hinbekommen. Ich müßte das also versuchen wieder neu einzurichten.

Mögliche Abhilfe:
1.) Projekt von Sourceforge neu auschecken(in neuen lokalen Ordner).
2.) Sourcen, usw. vom Ordner ohne Steuerdaten direkt in den
ausgecheckten Stand kopieren.
3.) dann ist ein Commit wieder möglich und sollte gleich vorgenommen
werden.

zuküntig: Oft Committen und ggf. branches bei Teständerungen o.ä.
verwenden.

weitere Fragen zu Subversion:
bitte gerne hier stellen...

MfG
Werner S.

Hallo Rainer,
hast du darauf geachtet das die Screenshot Version (BF oder OS) von PC
und Oszi übereinstimmen?
Mfg,
Kurt

Hallo Rainer,

die Funkion sollte wie gehabt arbeiten. Wie Kurt schon sagt muß aber die
richtige Version eingestellt sein (passend zur PC-Software).

Ich bin ja ohnehin gerade dabei die Druckfunktion für Kurt anzupassen,
da kann ich das sonst noch mal testen.

Gruß Hayo

Ich prüf das mal und sag dann Bescheid.

Hayo

Ja Du hast recht. Das hatte ich bislang noch nicht bemerkt. Ich vermute,
dass ich durch den Umbau für Kurt da einen Fehler eingebaut habe. Das
korrigiere ich natürlich zur nächsten Version.

Danke für den Hinweis

Hayo

So,

hab mich heute mal drangesetzt und einige Punkte abgearbeitet:

- neues Quick Print Menü mit Unterstützung für Kurts Projekt
- Pretrigger wird jetzt immer korrekt upgedatet
- 16 Bit DAC wird jetzt (hoffentlich) korrekt unterstützt. Ich habe mir
mal die Spezifikation runtergeladen und das Registersetting angepasst
- Quick Print double push funktioniert wieder

Und jetzt geht es wieder ab zum Griechen. Bis nachher


Gruß Hayo

Hallo Hayo,
das gefällt mir sehr gut und es funtkioniert!

Leider hast du vergessen die handleInChar anzupassen. Hier nochmal die
benötigten Zeilen:

case    5:
    CommIF::UC_SCREENSHOT(); // -> UC version
break;
case    6:
    CommIF::UC_SCREENSHOT_BW(); // -> UC version black and white
break;
case    7:
    CommIF::UC_DUMPCSV();  // -> UC version
break;

Dann habe ich noch eine neue uc_dumpcsv die bei 2 Kanal Geräten auch nur
Daten der 2 Kanäle überträgt.

Mfg,
Kurt

Ok,

bin gerade vom Griechen zurück. Hatte ich übersehen. Ich bau das morgen
mal ein und gebe dann eine neue Compilation raus.

@branadic
Es würde mich mal interessieren ob die 16 bit DAC-Ansteuerung jetzt
funktioniert.


Gruß Hayo

Der frühe Vogel fängt den Wurm!

Alles schläft - einer fährt, oder so ähnlich. Also, hab noch ne
Nachtschicht eingelegt und die Korrekturen eingebaut.

Gruß Hayo

branadic schrieb:
> Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem
> 16bit DAC zusammen, die Signallinien landen nicht auf 0.

Das hab ich mir gedacht. Die Kalibrierroutine ist auf den 14 Bit DAC
optimiert. Das müßte ich dann anpassen wenn ich das Teil bei mir
einglötet habe. Wie groß ist denn die Abweichung? -> Screebshot

> Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u.
> rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt
> doppelt so schnell auf dem Bildschirm hoch und runter.

Das ist klar, denn die Schrittweite hat sich ziemlich stark geändert.
Das muß ich auch noch anpassen.

Aber die Verstellung an sich funktioniert korrekt? Wie sieht es mit der
Verstellgeschwindigkeit  Ansprechverhalten  Einstellgenauigkeit aus?
Macht der Umbau Sinn?

> Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger
> Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event
> LED solange dauerhaft leuchten zu lassen, solange hintereinander
> Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen
> ist auf Trigger Wait umgeschaltet wird?

Das fände ich persönlich nicht so gut. Die Anzeige macht für mich so
schon Sinn, auch wenn es zugegebenermaßen manchmal etwas hektisch
blitzelt.

> Das Flackern ist echt hart, man könnte meinen man schaut einen dieser
> asiatischen SciFi-Trickfilme.

Deshalb habe ich die Möglichkeit vorgesehen die LEDs separat
abzuschalten.

Gruß Hayo

So Branadic,

damit Du nicht so gefrustet bist über die Diskobeleuchtung habe ich Dir
eine neue Kompilation gemacht mit überarbeiteter 16 Bit
DAC-Unterstützung.

Eigentlich müßte es jetzt alles korrekt funktionieren. Ich habe die
Ansteuerung jetzt so gemacht, dass man auf den Umschalter im
Hardwaremenü eigentlich verzichten könnte. Die Ansteuerung ist nämlich
eigentlich Sofwarekompatibel für alle drei DAC-Typen ausgelegt, so dass
man sie beliebig tauschen kann ohne etwas anpassen zu müssen -
vorausgesetzt man hat das von vornherein in der Ansteuerung
berücksichtigt.

Ich muß wohl nicht erwähnen, dass WELEC das natürlich nicht so
implementiert hat.

Sollte also jetzt alles korrekt sein werde ich in der nächsten Version
den Schalter wieder rausnehmen.

Gruß Hayo

By the way - ich habe mir das Hirn zermartert was der 16 Bit DAC
eigentlich bringen soll. Mir ist nix eingefallen. Vielleicht kannst Du
mir da auf die Sprünge helfen.

Die Schrittweite ist nämlich nicht von der DAC-Auflösung abhängig,
sondern wird in "Pixelschritten" vorgenommen. Und die sind bei den
korrespondierenden Spannungsbereichen (5er/2er/1er) immer gleich.

Beim 16 Bit DAC sind dann die Werteschritte einfach nur Faktor 4 größer.

Oder hab ich da einen Denkfehler???

Gruß Hayo

Moin moin,

ich hab mich noch mal drangesetzt und einige Testreihen zum DAC gemacht
bzw. die Werte nachgerechnet und die techn. Specs verglichen.

Grundsätzlich bringt der 16 Bit DAC in den 5er Ranges keinen Vorteil und
in den 2er Ranges nur wenig.

Die elektrischen Eigenschaften der drei Typen sind identisch.
Die Schrittweite beträgt beim 14 Bit DAC in den 5er Ranges 3/Pix und in
den 2er Ranges 1 bzw. 2/Pix.

Beim 16 Bit Dac liegt die Schrittweite in den 5er Bereichen bei 12 bzw.
13/Pix und in den 2er Bereichen bei 5/Pix.

Einen Auflösungsvorteil bringt es in den 1er Bereichen, da hier die
Schrittweite des 14 Bit DAC bei 1/2Pix liegt. Heißt übersetzt, nur alle
2 Pixel wird der DAC um 1 weitergestellt.

Das ist natürlich beim 16 Bit DAC besser. Hier liegt die Schrittweite
dann bei 2 bzw. 3/Pix.

Die Werte kann jeder leicht selbst ermitteln, wenn er sich über ein
Terminalprogramm die Variablenwerte ausgeben läßt (","). Die DAC-Werte
findet man im fünften Abschnitt.


So Branadic,

nun zu Deinem Problem auf Kanal 3. Das scheint mir ein Hardwareproblem
zu sein - kalte Lötstelle, Brücke etc.. Bei mir funktioniert sowohl der
Zero-Abgleich als auch alles Andere. Keine Spikes oder sowas Ähnliches.

Die firmwareseitige Implementierung ist also ok.

Ich werde mir den DAC also auch einbauen um in den 1er Bereichen eine
feinere Auflösung zu erzielen.

In der nächsten Version wird die Ansteuerung so sein dass keine
Umschaltung mehr erforderlich ist und auch ein gemischter Betrieb (bei
den 4 Kanalern) möglich ist.


Gruß Hayo

Geschickter Einwand - aber wie erklärst Du Dir dass es nur bei
bestimmten Zeitbasen auftritt obwohl die Zeitbasen keinen Einfluß auf
die DAC-Ansteuerung haben?

Ich bin gerade bei der neuen Version, damit kannst Du das nochmal prüfen
- und alle Anderen auch, da jetzt die DACS immer gleich angesteuert
werden.

Gruß Hayo

Ich arbeite in einer kleineren Chipentwicklungsfirma, bin selbst aber
embedded Softwerker.

Nachdem was ich so manchmal mitkriege: VHDL ist kaum noch üblich, wird
eher als Lehrsprache betrachtet. Die produktive Arbeit wird in Verilog
erledigt. Das ist vielleicht so wie Pascal (oder Modula-2) vs. C.

War mal anders, als ich anfing war VHDL höher angesehen.

Jörg

Ok werte Gemeinde,

ich war fleißig und habe die letzten Tage durchprogrammiert. Leider hat
die Zeit nicht gereicht alle Punkte auf der Liste abzuarbeiten, aber die
neue Version kann sich trotzdem sehen lassen.

Hier die Highlights:

- automatischer Support für 12/14/16 Bit DAC ohne Umschaltung! Auch
gemischte Bestückung.

- neue Kalibrierroutine die für die neue DAC-Ansteuerung optimiert wurde
und eine neue Kalibrierlogik hat, die jetzt den Offset dynamisch gegen
Null approximiert. Weiterhin habe ich den ADC-Abgleich und den
DAC-Abgleich zusammengelegt. Es gibt also nur noch einen Button für den
Abgleich. Damit Ihr die neue Routine besser testen könnt habe ich die
Debug-Ausgaben auf RS232 dringelassen. Ihr könnt Euch also den
Abgleichvorgang in einem Terminalfenster ansehen und prüfen ob er
wirklich auf Null geht.
D.h. der Offset liegt dann unterhalb der Anzeigegenauigkeit in allen
Spannungsbereichen! Besser geht es nicht...

- Der freie Platz neben dem Kalbrierbutton hat auch schon eine neue
Funktion bekommen. Hier kann man zwischen 4 verschiedenen
Kalibriersätzen wählen (für branadic und alle die aktive Tastköpfe
benutzen)

- Main Wheel Support für die Channel Delay Popups und für Average und
Noise Filter.

- Weiterhin noch einige kleine Änderungen. (siehe changelog und
special_functions.txt)

Gruß Hayo

Hallo Branadic,

Dein Kanal 4 liefert wie erwartet keine Werte. Aber Kanal 3 wird korrekt
kalibrtert.

Gruß Hayo

Da haben sich unsere Posts wohl überschnitten. Ich hatte beim zweiten
Überlesen schon gesehen dass Du den Kanal 4 rausgelötet hast.

Hast Du die Kalibrierung mal für alle 4 Kalibrier-Sets gemacht? Deinem
Protokol entnehme ich aber, dass mit Deinem Kanal 3 alles genau richtig
klappt. Also hakt es wohl woanders.

Gruß Hayo

Es könnte sein, dass die DAC-Skalierungsfaktoren für die 16 Bit DACs
angepasst werden müssen. Dafür muß ich aber bei mir den 16 Bit DAC
einbauen um das zu überprüfen.

Gruß Hayo

Warte mal,

ich seh mal kurz nach. Ich hatte die manuelle DAC-Kalibrierung extra
drin gelassen.

Moment...

...ok hab's,

also mit shift + Z kannst Du den Testkanal verstellen der den wirksamen
Kanal vorgibt.

Den Spannungsbereich für den kalibriert wird mußt Du von Hand einstellen
(5er oder 2er oder 1er) mit der normalen Bereichseinstellung auf dem
Frontpanel.

Du mußt natürlich auch ein Kalibrierset ausgewählt haben mit dem Du
testest.

Die kalibrierung kannst Du dann mit Shift + E hochzählen und mit Shift +
W runterzählen.

Das Ergebnis kannst Du Dir dann mit "," ansehen.

Bei mir liegen die Offsetkorrekturen bei:

* CH1 DAC correction 1:   406     * CH3 DAC correction 1:   448    *
* CH1 DAC correction 2:   478     * CH3 DAC correction 2:   506    *
* CH1 DAC correction 3:   400     * CH3 DAC correction 3:   427    *
* CH2 DAC correction 1:   358     * CH4 DAC correction 1:   418    *
* CH2 DAC correction 2:   422     * CH4 DAC correction 2:   478    *
* CH2 DAC correction 3:   373     * CH4 DAC correction 3:   427    *


Gruß Hayo

Ok,

hast Du mal Dein Hardwaresetting geprüft?

Welchen Pre Gain hast Du eingestellt?

Das was Du da beschreibst deutet auf die Skalierungsfaktoren hin!

Gruß Hayo

Ok, das sind ganz klar die Skalierungsfaktoren, die nicht passen.

Wenn auf Gridmitte die Offsets Null sind aber oben und unten im Grid
Aweichungen auftreten dann ist es das.

Die sind ja auch nur für den 14 Bit DAC ermittelt worden. Leider kann
ich da erst tätig werden sobald ich den 16 Bitter bei mir drin habe.

Ich könnte sonst noch versuchen so nach Gefühl die Werte für Dich
anzupassen, damit Du was zum Probieren hast.

Wie sehen denn die 5er und 2er Bereiche aus?

Gruß Hayo

Hast Du die Möglichkeit zu kompilieren? Die Faktoren findest Du in der
tc_vars.cpp ab Zeile 1165.


float DAC_ScaleFactor[3][5] =

  gain 1/gain 1.25/24 Ohm/33 Ohm/addon
{{ 2.480, 2.480, 2.6456, 2.520, 2.476 },  // 1er ranges
 { 4.940, 4.940, 5.2912, 4.980, 4.952 },  // 2er ranges
 {12.360,12.360,13.2280,12.432,12.432 }};  // 5er ranges


Du könntest sie Dir einfach selbst anpassen.

Hayo W. schrieb:
> Hast Du die Möglichkeit zu kompilieren?

Kann ich übernehmen. Welche Werte müssen denn geändert werden? Jeweils
der letze in der Zeile?

Mfg,
Kurt

PS: Die Digikey Lieferung ist schon in Köln und müsste morgen ankommen.

Nein etwas anders,

am Besten Du suchst Dir eine Spalte aus - z.B. die Letzte. Die läßt sich
dann anwählen über das Hardwaremenü Pre Gain -> "Addon".

Die drei Werte sind dann für jeweils einen Spannungsbereich. Der Oberste
für die 1er Spannungsbereiche, der mittlere für die 2er und der unterste
ist für die 5er.

Ich vermute, dass die Werte für den 16 Bit DAC einfach noch nicht genau
genug sind und nur feinjustiert werden müssen.

Zum Justieren muß die Nullposition des Kanals möglichst weit oben oder
unten sein um die maximale Abweichung zu haben.

Gruß Hayo

Was mich aber etwas wundert, ist der Unterschied zwischen Kanal 2 und
den beiden andern Kanälen. Kanal 2 sieht ja eigentlich ganz ok aus. Es
sollte bei gleicher Eingangshardware eigentlich keinen Unterschied
geben.

Ist da was an den Widerständen geändert worden?

Gruß Hayo

Na dann ist ja alles klar. Es liegt also nicht am DAC. Mit der 24/150
Ohm Bestückung passen die Faktoren der 24 Ohm Pre Gain Einstellung. Die
habe ich auch drin.

Rüste die doch einfach um, das ist vom Aufwand her am einfachsten denke
ich.

Gruß Hayo

Kanal 2 sieht doch gut aus. Must Dir das mal im 5er Bereich ansehen, da
ist weniger Rauschen drauf.

Sonst rüste das doch erstmal zurück auf Originalbestückung, dann können
wir besser vergleichen.

Hayo

Nein, nein,

nicht den DAC zurückbauen, nur die Widerstände von Kanal 1 + 3. Oder
damit leben, dass nur Kanal 2 richtig anzeigt.

Jedenfalls zeigt mir Dein Ergebnis, dass die DAC-Ansteuerung korrekt
funktioniert. Ich werde das bei meinen Geräten auch mal umrüsten.

Gruß Hayo

Die FFT-Sektion ist noch "under construction", d.h hier wird sich noch
einiges tun.

Was meinst Du denn mit feiner einstellen? Die Auflösung der
Spektrallinien ist durch die kleinste Abtastrate (500Sa/s) und die
Bildschirmauflösung begrenzt. D.h. ich kann maximal eine FFT mit 1024
Werten machen und habe dann 512 Spektrallinien.

War es das was Du meintest?

Gruß Hayo

So, für das Wochenende gibt es wieder was zum spielen.

Diesmal habe ich mich der Screenshot-Funktion angenommen und einen
Rundumschlag gemacht (aufgeräumt und erweitert).

Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS
und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC
und USB-Host zu wählen. Für alle Screenshots wird jetzt die schnellere
Kompressionsroutine der 0.92.OS Version verwendet.

Auf PC Seite gibt es zwei neue Screenshot-Versionen. Beide können
wahlweise eingesetzt werden und verwenden beide den gleichen
Kompressionsalgorithmus.

- die neue OS-Version 0.93 hat sich bei der Parametererkennung über
RS232 etwas geändert. Das heißt sie ist weiter abwärtskompatibel zu
älteren Firmwareversionen (BF und OS), aber sie läßt sich genauso mit
der neuen FW ansteuern und kann wie gehabt auch remote triggern.

- die neue BF-Version 2.0 hat jetzt den schnellen
Kompressionsalgorithmus der OS-Version. Der Aufruf ist noch schlanker
geworden, es kann optional der Port (bzw. das device) übergeben werden,
muß aber nicht. Defaultmäßig wird wie bei der OS-Version COM1 bzw.
/dev/ttyS0 verwendet.

Bei ASCII und CSV Format werden zusätzlich die aktuellen
Einstell-Parameter übertragen und ans Ende der Datei gehängt.

Die alten Screenshotversionen können nicht mehr verwendet werden!!!

Gruß Hayo

Hallo Hayo,

bzgl. Firmware v2.13:

Ich habe da einen merkwuerdigen Bug gefunden, den ich wie folgt
100%tig reproduzieren kann:

(1) Zeitbasis <= 50ns/Div
(2) Kanal 3 oder 4 aktivieren
(3) "Center Channel" Softbutton druecken

Bildschirmausgabe dann wie im ersten Screenshot. Tritt jedoch nicht
bei Kanal 1 u. 2 auf.

Verschiebe ich Kanal 3 per Hand ein paar Pixel nach oben, kann ich gar
die Ausgabe wie im zweiten Screenshot provozieren.  Dies funktioniert
jedoch nicht bei Kanal 1, 2 und 4.

Verschiebe ich die Kanaele wieder woanders hin sind die Fehler weg.

Ob ich im Display Menue bei "Switch Drawing" Line() oder vertical pixel
eingestellt habe macht keinen Unterschied.

Der Bug tritt auch bei anderen, etwas langsameren Zeitbasen auf,
allerdings nicht genau in der Mitte.

Default-Setup und Abgleich habe ich vorgenommen.  Ich habe das W2024A.
Vorherige Firmware-Version war die 2.10, dort habe ich den Fehler
nicht beobachtet.

Niklas

Zusatz:  Lasse ich mir den Trace im Bug-Zustand auf RS232 als CSV
ausgeben finden sich viele Werte fuer den betroffenen Kanal mit 0
und 254, d.h., vermutlich ist es kein reiner Fehler bei der Zeichnung.

Hallo Ihr Beiden,

danke für die Rückmeldung. Ich bin leider dieses Wochennde etwas knapp
an Zeit, aber Eure Beiträge sind zur Kenntnis genommen. Ich muß mal
sehen ob ich morgen oder übermorgen Abend dazu komme mich damit etwas
näher zu beschäftigen.

Gruß Hayo

Hallo Niklas,

es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen,
aber ich kriege es nicht hin. Welche Hardwareeinstellung hast Du
gewählt?

Kann das noch jemand hier nachstellen, oder ist das ein spezielles
Problem von Niklas?

Gruß Hayo

Hallo Hayo,

> es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen,
> aber ich kriege es nicht hin.

Mhm, gerade, nachdem das Geraet fuer eine Stunde aus war, habe ich
es auch nicht sofort wieder reproduziert bekommen, erst nach
"Utility->Calibrate Offsets" klappt es wieder 100%tig.

(Nach "Warmlaufen" des Oszis kann ich btw. eine Verschiebung der
Nullinien gegenueber Kaltzustand feststellen, vllt. ist
zum Reproduzieren daher ein frisches "Calibrate Offsets" noetig.)

> Welche Hardwareeinstellung hast Du gewählt?

Du meinst "Utility->More->Hardware"?
ADC -> Factory
PreGain -> Factory

zudem in "Utility->More":
Delays: Ch1: 8ns / Ch2: 0ns / Ch3: 5ns / Ch4: 5ns

Das Geraet ist bis auf Schirmblech und zwei SMD LEDs beim Trigger
unveraendert.

Ich sehe auch gerade das branadic oben in seinem Beitrag vom 19.2.:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
einen aehnlichen Effekt beobachtet hat.

Niklas

Hallo nochmal,

ich habe die alte v2.10 mal ins RAM geladen, um zu schauen,
ob das Problem wirklich dort nicht auftaucht.

Ergebnis:  Auch bei v2.10 habe ich den Effekt bei Kanal 3 und 4,
allerdings nicht genau auf der Bildschirmmitte sondern etwas
versetzt (3-10 Pixel) nach oben.  Da ich meist "Center Channel" bzw.
"Dispatch Channels" benutze ist es mir wohl bislang nicht
aufgefallen.

Ebenso wie Hayo frage ich mich ob es ein isoliertes Problem bei
mir ist oder auch bei anderen 4-Kanal-Geraeten auftritt.

Wer testen moechte:
(1) Zeitbasis auf 50ns/Div einstellen, Trigger auf "Auto"
(2) Kanal 3 oder 4 auf Bildschirmmitte ("Center Channel")
(3) Pixelweise nach oben (oder unten) verschieben

Weiter frage ich mich, ob es sich um ein thermisches Problem
handeln koennte, da die Anzahl Ausreisser mit Aufwaermen des Oszis
zuzunehmen scheinen.  Allerdings erklaert das nicht, warum der Fehler
beim Verschieben des Traces verschwindet bzw. ueberhaupt anscheinend
nur in der Bildschirmmitte auftritt.

Das sieht fuer mich daher eher nach einem Bug in der
Softcore-Firmware aus.

Anbei nochmal ein charakteristischer Screenshot, FW v2.10.

Niklas

Bevor ich verschwinde und bei meinen Schwiegereltern die Bude entrümple
noch ein Gedanke:

Stell doch mal alle Delays auf 0ns und probier es nochmal.

Gruß Hayo

Hallo Hayo,

> Stell doch mal alle Delays auf 0ns und probier es nochmal.

Macht leider keinen Unterschied.  Auch die anderen Einstellungen
zu ADC und PreGain scheinen keinen Einfluss zu haben.

Niklas

Niklas O. schrieb:
> Wer testen moechte:

Hab' ich getan mit 'Default Setup' und dann wie oben. Bei mir am W2024A
mit FW BF2.13 ohne Befund. Kommt mir wie ein klemmendes oberstes Bit
vor? Hast du mal von außen ein Analogsignal (Sägezahn/Sinus)
draufgegeben und beim Nulldurchgang geguckt?

Gruß
Rainer

Den gleichen Verdacht mit dem verklemmten Bit hatte ich auch schon.

Vorschlag zur Fehlersuche:

Auf der Platine des geöffneten DSO auf die Chips drücken. Teilweise sind
die Lötverbindungen an den SMD-Bauteilen nicht optimal und verursachen
dann so komische Effekte. Ich glaube Kurt hatte das mal an den
RAM-Bausteinen.

Gruß Hayo

Hallo Hayo und Rainer,

scheint in der Tat ein klemmendes Bit zu sein.

Gerade wie vorgeschlagen nen Sinus angelegt.  Die Fehlwerte
treten genau wie erwartet beim Nulldurchgang auf.

Anbei Screenshot.  Nicht wundern, ich habe leider hier nichts
besseres als 750 kHz aus nem XR2206-basierten Generator und
bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf
als das ich das mit einem Screenshot haette aufzeichnen koennen.

Die Ursache ist damit wohl geklaert, danke an euch fuer den Tipp.
Kalte Loetstellen wuerden dann auch die beobachtete
Verschlimmerung bei Erwaermung erklaeren.

Aufschrauben und evtl. Nachloeten verschiebe ich aber erstmal
bis auf unbestimmt.

Niklas

Update:  Urgs, zweimal den selben Screenshot.  Kann man anscheinend
auch nicht wieder entfernen.

Niklas O. schrieb:
> Anbei Screenshot.  Nicht wundern, ich habe leider hier nichts
> besseres als 750 kHz aus nem XR2206-basierten Generator und
> bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf
> als das ich das mit einem Screenshot haette aufzeichnen koennen.

Sieht doch super aus. Meine Interpretation ist, dass das oberste Bit
etwas verspätet schaltet und dadurch am Nulldurchgang steigend (0xFF ->
0x00) gerne 0x80 auftritt bzw. fallend (0x00 -> 0xFF) der Wert 0x7F. Das
wären dann Peaks nach Minus-FS bzw. nach Plus-FS. Der erste Fall ist
genau in deinem Bild zu sehen. Am fallenden Nulldurchgang würde ich
entsprechend einen Peak nach "+" erwarten. Das Problem wäre dann an
einer Stelle, wo die Werte als 2er-Komplement vorliegen.

Die Verzögerung muß natürlich nicht zwingend durch eine schlechte
(hochohmigere) Lötstelle entstehen, sondern kann auch an einem
Timingfehler und temperaturabhängigen Toleranzen im FPGA liegen, was
sich dann mit branadics Interpretation decken würde.

Hast du einen anständigen Lüfter drin?

Gruß
Rainer

Hallo nochmal,

Rainer schrieb:
> Der erste Fall ist genau in deinem Bild zu sehen.
> Am fallenden Nulldurchgang würde ich entsprechend
> einen Peak nach "+" erwarten.

Ich habe das ganze mal >5 Minuten mit "Display->Persist"
aktiviert bei 1us/Div aufzeichnen lassen.  Deine
Erwartung trat dort nicht ein, wobei wie gesagt
bei diesen langsamen Zeitbasen die Ausreisser selten
auftreten.  (Screenshot 1)

Ich habe auch mal die Amplitude (und damit die Steilheit
auf dem Screen) stark erhoeht und mir den fallenden
Nulldurchgang bei 50ns/Div angeschaut.  Dort sehe ich
dann die von Dir erwarteten "+" Peaks.  (Screenshot 2)
(Im aufsteigenden Durchgang entsprechend "-".)

Was ich nicht verstehe ist aber, warum ich, wenn ich den
Trace nach unten verschiebe, die Spikes weiterhin in
der Bildschirmmitte, und nicht wie ich erwarten wuerde
beim wahren Nulldurchgang, sehe?  (Screenshot 3)

Jetzt bin ich schon sehr irritiert.  Was passiert denn
mit den Werten der 4 interleaveten ADCs pro Kanal bis sie
irgendwann im Softcore ankommen und gezeichnet werden?
(Ich vermute mal dass die Softcore zeichnet, bitte
korrigiert mich wenn ich falsch liege, den Teil der
Firmware habe ich mir nie angeschaut.)

> Hast du einen anständigen Lüfter drin?

Originalluefter mit der Klebestreifen-Modifikation, jedoch
ohne vergroesserte Schlitze aussen.  Also "nein" :)

Niklas

Niklas O. schrieb:
> Ich habe das ganze mal >5 Minuten mit "Display->Persist"
> aktiviert bei 1us/Div aufzeichnen lassen.  Deine
> Erwartung trat dort nicht ein, ...

Mmmh. Da müßte man jetzt wissen, welche der Abtastwerte bei 1us/div für
die Darstellung benutzt werden. Die Chancen die entscheidende Wandlung
zu verpassen, ist da vielleicht schon zu groß und die Peaks, die da in
die "falsche" Richtung gehen, könnten durch Rauschen entstehen, das da
gerade in Gegenrichtung läuft (???).

> Was ich nicht verstehe ist aber, warum ich, wenn ich den
> Trace nach unten verschiebe, die Spikes weiterhin in
> der Bildschirmmitte ... sehe?  (Screenshot 3)

Ohne jetzt in den Schaltplan geguckt zu haben, vermute ich, dass die
Signalverschiebung durch Addition eines Offsets aus dem DAC gemacht
wird. Die ADCs messen immer bezogen auf die Bildschirmmitte (Man möge
mich bitte korrigieren, wenn ich da falsch liege)

> Jetzt bin ich schon sehr irritiert.  Was passiert denn
> mit den Werten der 4 interleaveten ADCs pro Kanal bis sie
> irgendwann im Softcore ankommen und gezeichnet werden?

Gute Frage. Eine Möglichkeit wäre, dass der Peak immer vom selben ADC
kommt. Aber dann wäre mir nicht klar, wieso Kanal 3 und 4 betroffen
sind.

Werden die Peaks eigentlich plattgebügelt, wenn du ein Noise Filter
aktivierst?

Als Lüfter bin ich mit dem "NOISEBLOCK 8X1R" von ex. Angelika sehr
zufrieden (80 mm und nicht zu hören)

Gruß
Rainer

Also mein Vorschlag ist immer noch (kostet auch nix) - schraub die
Rückwand ab, starte das Gerät und provoziere den Fehler. Dann drückst Du
auf den ADCs des dritten oder vierten Kanals etwas herum - die sind da
frei zugänglich.

Wenn sich da nix ändert würde ich bei Gelegenheit die Chips auf der
Rückseite der Platine in Angriff nehmen, aber dazu muß man etwas mehr
auseinanderschrauben.

Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass
das durchaus kein Einzelfall ist.

Gruß Hayo

Hayo W. schrieb:
> Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass
> das durchaus kein Einzelfall ist.

Nein, das war wahrscheinlich Bruno. Ich hatte nur mal Lötzinnbrücke
zwischen 2 Eingängen eines Schieberegisters.

Hallo,

mal was anderes:  Man kann ja, wenn man bereits im
Mode/Coupling-Menue ist, durch abermaliges Druecken
der Taste Mode zwischen Auto, Normal und Combi umschalten.

Ich faende es sinnvoll, wenn eine Umschaltung analog
dazu auch bei Edge (Rising->Falling->Rising->...)
und Pulse Width (Time Qualifier-Variationen), als sowohl
fuer Main/Delayed (Main->Delayed->Main->... (nicht X-Y))
moeglich waere.

Das ganze habe ich gerade mal in 20 Zeilen eingebaut
(alles Ergaenzungen, keine Zeilenaenderungen).
Diff ist im Anhang.  Vllt. kann Hayo das ja bei der
naechsten Version einbauen.

Ansonsten, bzgl. Screenshot/Datendump:  Mittlerweile
benutzen wohl sowohl das Original als auch die
abgewandelte BF-Version die selbe Kompression (und
wohl auch selbes Protokoll).  Unterschied scheint
mir nach kurzem Blick eigentlich nur Verhalten
gegenueber dem Nutzer und moegliche Optionen zu sein.
(Plus Neuerungen wie Ausgabe Einstellungsparameter
bei CSV/ASCII.)

Ich finde es unschoen, da immer noch zwei Versionen
zu haben -- bei fast identischer Codebasis.

Wenn nichts dagegen spricht wuerde ich mich daran
machen, diese wieder zusammen zu fuehren.  Das
gewohnte unterschiedliche Verhalten "OS" vs. "BF"
gegenueber dem Nutzer kann man sicher durch Mitliefern
von zwei Batchdateien mit entsprechend gesetzten
Kommandooptionen beibehalten.

Niklas

Hi,

bin gerade erst zurück.

@Niklas

Die Funktionen die Du da als Diff mitgeschickt hast baue ich natürlich
mit ein, macht ja auch Sinn.

Auch das mit der Screenshotversion hab ich mir schon überlegt, da hast
Du natürlich recht. Wir könnten die BF-Version auslaufen lassen und die
OS-Version auf den Releasestand 1.00 bringen. Mittlerweile ist es ja ein
"stable release".

Was dann noch übernommen werden müßte ist die Erweiterung bei ASCII und
CSV, ansonsten funktioniert die OS genauso wie die BF-Version und kann
aber noch zusätzlich remote triggern und Schwarzweiß-Shots machen.
Machst Du das?

Gruß Hayo

Ach ja, Du könntest den Namen verkürzen wie bei der BF-Version, dann muß
man nicht immer so viel eintippen, sondern kann das Teil einfach ohne
Parameter im Defaultmodus starten.

Gruß Hayo

Hallo Hayo,

> [Screenshot/Dump]
> [Uebernahme Erweiterungen]
> Machst Du das?

Ja.

Niklas

Hallo Hayo,

zur Vereinfachung der Bedienung habe ich folgenden wahrscheinlich
einfach umsetzbaren Vorschlag:

Wenn man eine Kanal-Tasten (1..4) zur Aktivierung bzw. Deaktivierung
eines Kanals drückt, werden in der aktuellen FW die Softkeys für die
zugehörigen Kanaleinstellungen angezeigt. Wenn man jetzt einen Kanal
deaktiviert, werden automatisch alle Softkeys disabled, was eigentlich
niemand wirklich etwas bringt.

Sehr viel praktischer wäre, wenn entweder die Taste "Dispatch Channels"
aktiv bliebe oder das ganze Menü auf einen der noch aktiven Kanäle
geschaltet würde. Das ist immer richtiger/besser als ein komplett
deaktiviertes Menü.

Gruß
Rainer

Hallo Rainer,

da hast Du eigentlich recht. Ich versuche das mal zum nächsten Release
einzubauen.

Gruß Hayo

@brandic

> Man sollte dann keine Angst davor haben, dass Design ruhig mal
> einzuspielen.

Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte
W2000a.SOF und -BIN ?
Oder hattest du die vom letzten jahr eingespielt?

Gruß Michael

Hayo W. schrieb:
> Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS
> und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC
> und USB-Host zu wählen.

Hallo Hayo,
wo schaltet man das denn um? Wenn ich Quick Print drücke passiert
garnichts.

Mfg,
Kurt

Hallo,

anbei das vereinigte "OS+BF" W2000A Screenshot Programm in
der Version 0.94.

In Kuerze das Wichtigste:

Es gab einiges aufzuraeumen.  Im Wesentlichen sollte sich
das Programm wie gewohnt verhalten.  Die Dokumentation ist
updatet und die Kommandooption -h sollte jetzt wieder der
Realitaet entsprechen (wenn nicht ist das ein Bug, bitte melden).

Traces werden jetzt als trace-nnnn.suf und nicht als
screenshot-nnnn.suf gespeichert.  Die Option -r fuer Raw
funktionierte in der OS nicht mehr mit der Firmware und fiel
weg.  Es gibt eine neue Option -a, die, wie bei der BF Version,
so sie fuer Windows kompiliert wurde (und dann auch nur bei
Screenshots), zweimal \a, also Bell/Piepser, ausgibt nach jeder
Uebertragung.  Zudem werden wie bei BF Parameter wie Zeitbasis,
Ranges, Kopplungen usw. ausgeschrieben.

Die .bat/.sh sind updatet, so dass diese auch funktionieren sollten
wenn man sie von einem anderen Verzeichnis aus ausruft.  Achja,
und die Parameter werden jetzt auch weiter uebergeben.

Damit zukuenftig klar ist, ob die Programmversion zur Firmware
passt, wird dies nun beim Start automatisch abgefragt.

Die Windows-EXE konnte ich nicht mit Scope testen.

Ansonsten:

Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne
hier melden.  Wenn alles passt und nichts grossartiges mehr
fehlt koennen wir die Version dann demnaechst 1.0 nennen.

Niklas

Super!

Das ging ja schnell!

Hayo

@Kurt

Es passiert nix? Bei mir sieht es so aus wie auf dem Screenshot, den ich
übrigens mit der coolen neuen 0.94 gemacht habe - läuft gut!

Wie ist das bei den Anderen? Habt Ihr da Probleme?

Hayo

@Niklas

bei mir kommt während der Versionsprüfung die Meldung

 - unknown token:  handleInChar(FF), UartRxGuiCmd: 69

Hat das was zu bedeuten?

Ansonsten funktioniert aber alles bestens.

Gruß Hayo

Hallo Niklas,

fleißig, fleißig. Danke

Niklas O. schrieb:
>
> Die Windows-EXE konnte ich nicht mit Scope testen.

Da geht der Daumen auch hoch - läuft

> Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne
> hier melden.

Mit der Formatierung des Headers bei ASCII und CSV kann ich noch nicht
ganz warm werden. Wie wäre es mit etwas Kompakterem/Strukturierterem
(ggf. <Tabs> vor den Argumenten), z.B.

[Header]
number_of_channels=4
channel_status=on;on;off;on
channel_ranges=5V/div;5V/div;0;5V/div
...
timebase=500KSa/s
values=Ch1;Ch2;Ch3;Ch4

[Data]
83;130;255;171
83;129;255;172
...

Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu
können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges'
und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl.
praktisch.

Gruß
Rainer

Rainer W. schrieb:

> Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu
> können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges'
> und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl.
> praktisch.

Ja das hatte ich mir auch schon überlegt, da ja die jetzigen
Parameterangaben nur informativen Charakter haben, aber nicht gut
automatisch auswertbar sind.

Hayo

Hallo,

@Hayo:
> bei mir kommt während der Versionsprüfung die Meldung
>  - unknown token:  handleInChar(FF), UartRxGuiCmd: 69
> Hat das was zu bedeuten?

So wie ich das sehe sind in der aktuellen Firmware
Debugging-Ausgaben eingeschaltet, zumindest teilweise.
(Siehe commif_t.cpp, Zeile 4'181.)
Wenn man auf der seriellen Konsole etwas eingibt, z.B. 'h',
kommt auch entsprechend 'handleInChar(68)' zurueck,
gefolgt von der Hilfe-Tabelle.  Dem Screenshot-Program
sind die zusaetzlichen Ausgaben an sich egal.

@Rainer:
> [Formatierung Header]
> Wie wäre es mit etwas Kompakterem/Strukturierterem
> (ggf. <Tabs> vor den Argumenten), z.B. [..]

Ja, das waere sinvoll.  Fuer ASCII sieht Dein Beispiel
schon gut aus, aber ich frage mich wie man das bei CSV
am Besten machen koennte, so dass man nicht manuell
nachbearbeiten und formatieren muss.  Gibt es vllt.
ein nicht zu schwer zu erzeugendes Tabellenformat das
Excel, OpenOffice Calc und so weiter einlesen koennen
welches einfache Formatierungen erlaubt?

@Rainer, @Hayo:
> Um die Daten in einer Tabellenkalkulation einfach
> richtig skalieren zu können und eine Zeitachse zu
> generieren, wären die Angaben zu 'Ranges' und 'timebase'
> in zusätzlichen Parametern als reine Zahlen evtl. praktisch.

Ja das sehe ich auch so.  Sollte man das noch weiter treiben
und gleich im Screenshot-Programm (optional) anbieten die
8-Bit-Zahlen in Spannungswerte umzuschreiben?  Zudem muessen
sicher nicht 16k Samples rausgeschrieben werden wenn die
Zeitbasis in Wirklichkeit mit weniger arbeitet.

Abgesehen davon:
Generell kann ich das Ganze auch so bauen, dass man mit
Templates arbeiten kann.  Man hat also z.B. eine Datei
rainer.tpl, mit Inhalt wie folgt:

[Header]
number_of_channels=%numchannels%
channel_ranges=%ch1range_str%;%ch2range_str%;5%ch3range_str%;%ch4range_str%
[..]
[Data]
_FOREACH_%ch1%;%ch2%;%ch3;%ch4%

...die dann zu Rainers Beispielausgabe expandiert.

Allerdings sollten meiner Meinung nach erst die vorherigen
Punkte klaeren und dies als zukuenftige Erweiterung ansehen.

Niklas

Hallo Niklas,

als importfreundlichen Header könnte ich mir soetwas vorstellen:

[Header]
number_of_channels=<tab>4
channel_status=<tab>on<tab>off<tab>off<tab>off
channel_bandwith_limits=<tab>off<tab>off<tab>off<tab>off
values=<tab>Ch1<tab>Ch2<tab>Ch3<tab>Ch4
[Data]
160<tab>159<tab>152<tab>188

Excel liest das bei Einstellung Trennzeichen="Tab" gut ein.

Für die richtige Skalierung würde ich einfach Sampleabstand in
Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere
Headerzeilen aufnehmen.

Der ASCII-Export mit Templates wäre natürlich der wahre Luxus.

Gruß Rainer

@Hayo

ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung
eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft
nicht invertiert dargestellt.

Gruß
Rainer

Rainer W. schrieb:

> Für die richtige Skalierung würde ich einfach Sampleabstand in
> Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere
> Headerzeilen aufnehmen.

Der Sampleabstand ergibt sind ja aus der Timebase die bereits übertragen
wird. Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel,
hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite
in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß.
Grundsätzlich aber eine gute Idee, kann ich auch noch nachreichen (auf
DSO-Seite).



> ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung
> eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft
> nicht invertiert dargestellt.

Sehe ich mir an und versuche es zu fixen.

Gruß Hayo

Hallo,

@Rainer:
> Excel liest das bei Einstellung Trennzeichen="Tab" gut ein.

Ah, jetzt verstehe ich auch wie Du das mit den Tabs vor den
Argumenten heute Morgen meintest.

Eigentlich koennten wir das Trennzeichen auch gleich frei
konfigurierbar machen.

@Rainer und @Hayo:
> Für die richtige Skalierung würde ich einfach Sampleabstand in
> Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere
> Headerzeilen aufnehmen.

Ich habe gerade mal geschaut wie ich an die Zero-Offsets
(ZeroLevelCh1-4) kommen kann.  Irgendwie scheint man da direkt
nur ueber USB dranzukommen, ansonsten muesste man bei RS232
den Output von ',' parsen.

Uebersehe ich da etwas?  Sonst muessten wir das wohl noch einbauen.

Ansonsten:  Gehe ich richtig der Annahme das ich den Spannungswert
ueber Z/(400/(24*8))+32-X/24*R, wobei Z=Zerolevel [0;400] fuer den
jeweiligen Kanal, X der ausgelesene Wert und R Range, also z.B.
5V/div, errechnen kann?

Niklas

Hayo W. schrieb:
> Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel,
> hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite
> in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß.

Kann man da nicht einfach einen passend normierten Int32 übertragen. Das
sollte doch reichen, um soetwas wie 1 mV/div bis 500 V/div abzudecken.

Gruß Rainer

@Niklas

Da zackern wir nicht lange rum. Alle Werte die Du brauchst schieben wir
mit über die Schnittstelle als Shot. Sag mir was Du brauchst, ich bau
das ein.

Gruß Hayo

Das Problem mit dem fehlenden Quick Print Menü ist erledigt. Nachdem ich
nochmal die 2.12 und dann nochmal die 2.13 installiert hatte war es
wieder da.

Nanu,

ein scwarzes Loch für Menüs? Is ja strange. Aber wenn's jetzt geht ist
ja alles ok.

Gruß Hayo

Hallo,

ich habe die Umrechnung zu Spannungswerten am Laufen.
Die noetigen Skalierungsfaktoren und die Zero-Offsets
uebertrage ich im Rahmen der anderen Parameter nach
dem Tracedump.

Es stellen sich jetzt fuer mich, bevor ich weiter
mache, folgende grundsaetzliche Fragen:

(1)  Die unkonvertierten Werte sind ja invertiert,
d.h., fuer eine positivere Spannung sinken die
Werte und vice versa -- was beim direkten Zeichnen
dann natuerlich auch invertiert ist gegenueber dem
Scope-Bild.

Soll dies so bleiben (es kann ja sein, dass es dafuer
einen guten Grund gibt) und nur optional umkehrbar
sein, oder sollten wir, wo wir gerade dabei sind,
das auch "beheben"?

(2)  Schon immer uebertragen wir stets stur 4x16kSa,
auch wenn wir weniger Kanaele haben und auch wenn
wir eine Zeitbasis eingestellt haben die nur mit 4kSa
pro Kanal arbeit (<=25MSa/s).  Das sollten wir
meines Erachtens auch gleich beheben und dem Programm
vom DSO sagen lassen, wie viele (aktive) Kaenele und
wie viele Samples es empfangen wird.

Ansonsten:
Ich wuerde vorschlagen eine neue Kommandooption
einzubinden die festlegt, wie die Daten bei einem
Tracedump (vor)verarbeitet werden.  Ich stelle mir
hier folgendes vor:
  -o [i][mv]
wobei:
  i -> invertieren (siehe oben)
  m -> Werte in mV als ganze Zahlen,
  v -> Werte in V mit 3 Nachkommastellen

Niklas

Hallo Niklas,

* Bei den unkonvertierten Werten wäre ich generell für Invertierung,
d.h. hohe Werte oben.

* Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und
die Kanalanzahl steht ja sowieso schon als Parameter "number of
channels" im Header. Unter "Values" würde ich immer die originale
Gerätekanalnummer nennen, damit man ggf. immer die Hardwarezuordnung
hat.

* Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit
dem neuen Frontend knapp sind.

* Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien dann
zumindest unter Windows nicht mehr austauschbar sind, wenn auf den
Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde
das vermeiden.

* Beim unkonvertierten Tracedump würde ich im Header die
Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B
(jeweils Integer) angeben, so dass gilt

  Y = ( X + B ) * A / N    mit z.B. N = 1 / uV

Evtl. ist auch Y = ( X * A + B) / N  günstiger.

Dann hätte man keine Floats und die Umrechnung wäre elementar.

Gruß
Rainer

Hi Niklas,

ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch
gleich die DSO-Seite mit abfackelst?

Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von
Dir einzupflegen?

Den Invert-Bug habe ich übrigens schon behoben. Morgen habe ich tagsüber
etwas Zeit, da werde ich mal die bisher aufgelaufenen Punkte abarbeiten.

Ich sag ja, nach der Winterpause geht es wieder richtig los!

Gruß Hayo

Wie steht es denn um die Ansteurung der Huckepack Platine?

Hallo Rainer,

> * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und
> die Kanalanzahl steht ja sowieso schon als Parameter "number of
> channels" im Header.

Allerdings wird dieser erst am Ende uebertragen (Hayo hat das so
gemacht damit die OS und aeltere Versionen weiter funktionieren),
aber das koennen wir ja gleich auch aendern.

> Unter "Values" würde ich immer die originale Gerätekanalnummer
> nennen, damit man ggf. immer die Hardwarezuordnung hat.

Da stimme ich zu.

> * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit
> dem neuen Frontend knapp sind.

Sollten wir bei -o dazu noch u fuer uV anbieten?

> * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien
> zumindest unter Windows nicht mehr austauschbar sind, wenn auf den
> Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde
> das vermeiden.

Mhm, das ist wirklich unschoen.  Gerade geschaut: ist bei OpenOffice
unabhaengig von Plattform auch so.  (Beim Oeffnen der CSV ist im
Konfigurationsdialog auch gleich die Sprache auswaehlbar, mit
entsprechend spezifisch gesetztem Default.)

> * Beim unkonvertierten Tracedump würde ich im Header die
> Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B
> (jeweils Integer) angeben, so dass gilt
>   Y = ( X + B ) * A / N    mit z.B. N = 1 / uV
> Evtl. ist auch Y = ( X * A + B) / N  günstiger.
> Dann hätte man keine Floats und die Umrechnung wäre elementar.

Mhm.  Ich waere fuer die erste Variante, da man mit -B dann
den unskalierten Nullpunkt haette.  Fuer einfache Analysen und
Zeichnung reicht dieser Wert zusammen mit den unkonv. Werten aus.

Niklas

Noch ein Nachschlag zu den übertragenen Kanälen,

grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt
übertragenen Parameter Timebase und channel_x_active eingeschränkt
werden.

Ab Zeitbasis 10µs bis 500ms werden ja nur noch 4K pro Kanal abgetastet
und wenn man noch die aktiven Kanäle abfragt sollte das die
Geschwindigkeit im Schnitt doch deutlich erhöhen.

Ich bin gespannt auf die Neuerungen...

Hayo

Hallo Hayo,

> ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch
> gleich die DSO-Seite mit abfackelst?
> Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von
> Dir einzupflegen?

Ja.  Ich gebe Dir dann fuer die Firmware ein Diff.

> grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt
> übertragenen Parameter Timebase und channel_x_active eingeschränkt
> werden.

Ja.  Kann man sich natuerlich auch drueber streiten ob das Programm
die Grenze fuer 4kSa vs. 16kSa kennen muss oder nur die Timebases
an sich...

Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher
der erste Schnellschuss.

Niklas

Niklas O. schrieb:

> Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher
> der erste Schnellschuss.

Ja das hatte ich wegen der Abwärtskompatibilität so gemacht. Dadurch
verträgt sich das auch mit alten Versionen die nur die Werte übertragen.

Den Zopf können wir aber auch abschneiden...

Hayo

Hayo W. schrieb:
> Den Zopf können wir aber auch abschneiden...

Wer etwas dagegen hat, möge jetzt sprechen oder für immer schweigen

Gruß Rainer

Schon mal vorab - ich habe heute eine ganze Menge geschafft (viele
kleine Baustellen). Wenn dann noch die Erweiterungen von Niklas dazu
kommen kann ich nur sagen es gibt wieder viel auszuprobieren :-)

Wenn Niklas das zeitlich hinbekommt könnte das neue Release evtl.
Sonntag fertig werden.

Gruß Hayo

Hallo,

anbei die neue v0.95 vom W2000A Screenshot Program mit dem
voellig ueberarbeitetem Tracedump.  Dazu das Diff gegen
die Original Firmware v2.13.  Dieses enthaelt auch die
Aenderungen aus
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"

Zum Ausprobieren dann noch ein Kompilat zum Einladen ins RAM.

Notizen:
- Leider konnte ich die Windows-EXE auch bei diesem Release
  nicht mit dem Scope testen.
- Zum Einbau der Ausgabe der A und B Skalierungswerte, wie
  Rainer sie im letzten Punkt von
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
  vorgeschlagen hat, bin ich nicht mehr gekommen.
- Mit dem Parameter -p und den darin gueltigen Flags
  v (Volt), m (mV), u (uV)
  sowie q ("quiet", keine Ausgabe des Headers)
  koennen die Daten bei der Ausgabe entsprechend
  vorverarbeitet werden.
  Bsp.:
     ./w2000a-screenshot -d -t ascii -p mq
  schreibt eine trace-0000.asc mit mV-Skalierung
  ohne Header.
- Da -p v mit ganzzahligen Werten wenig Sinn ergibt
  werden bei diesem Modus Stellen nach Komma (Punkt)
  ausgegeben.  (Siehe auch Rainers Hinweise bzgl.
  Float und CSV.)

Niklas

Hallo Niklas,

unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung
irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und
Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:

* Found Data Start Marker after 10s
  - Receiving trace data...
    4100 bytes..._

Der Cursor bleibt hinter "bytes..." stehen und es wird eine leere
Ausgangsdatei angelegt. Bei vier aktiven Kanälen läuft der Zähler
entsprechend bis 16400 bytes und dann passiert nichts weiter.
Der Screenshot in eine PPM-Datei ist ok.

Gruß
Rainer

P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch
vermißt

Hallo Rainer,

> unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung
> irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und
> Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:
> * Found Data Start Marker after 10s
>   - Receiving trace data...
>     4100 bytes..._

Kann es sein, dass Du tatsaechlich, wie Du schreibst,
versehentlich die v0.94 benutzt statt der neuen v0.95?
Die Ausgabe waere bei der neuen Version auch anders.

> P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch
> vermißt.

Die sollte unter Misc erklaert sein.

Starte mal bitte die .exe mit -v.

Niklas

P.S.: Ich frage mich gerade ob wir nicht auf DSO-Seite fuer
Screenshot und Tracedump eine Header-Version ausgeben sollten.
Wenn die Version neuer ist als das Programm kennt, verweigert
es den Dienst. Im Moment prueft das Programm nur ob die
Firmwareversion den Mindesanforderungen genuegt und nicht
neuer als 10 Versionen ist.

Hallo Rainer,

> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?

Mhm, wo mache ich das denn?

Meinst Du vllt. die printf() in Schleifen mit \r (0x0d) vorne?
Das dient dazu, dass ich dieselbe Zeile in der Ausgabe mehrfach
schreiben kann, z.B. um eine Statusanzeige hochzuzaehlen.

Niklas

Update:  Ich glaube Du meintest Hayo.

Kurt Bohnen schrieb:
> Wie steht es denn um die Ansteurung der Huckepack Platine?

Ist wohl untergegangen.

Niklas O. schrieb:
>> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
>> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
>> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?
>
> Mhm, wo mache ich das denn?

Die unüblichen <lf><cr>s war mir direkt in den Daten auf der
Schnittstelle bei den Versionstexten aufgefallen. Da hast du wohl Recht,
ist wohl Hayo's Baustelle. (siehe Anhang)

Zum Datenformat habe ich noch folgende Anmerkungen:
1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in
den Header nehmen, damit unter /[Data]/ reine Zahlen stehen

2) Bei channel_delays würde ich channel_delays_ns angeben, auch
damit hinten reine Zahlen stehen (Wer weiß wozu?)

3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das
Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben
verschoben" assoziiert. Wenn man die Daten in einer Tabellenkalkulation
skaliert, spielt das sowieso keine Rolle ob "+" oder "-".

Dann bin ich gespannt, wie das mit den fertigen Skalierungsfaktoren
wird.

Insgesamt - superschnell und großer Fortschritt auf der Baustelle.

Gruß
Rainer

Rainer schrieb:

> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle
> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d
> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)?

Nein, hat keinen Grund, ich mache das frei von der Leber weg, da dort
auch keine Kompatibilitätsprobleme zu befürchten sind.

Ob ich erst den Wagenrücklauf mache und dann die neue Zeile oder
umgekehrt bleibt unterm Strich gleich.

Gruß Hayo

Kurt Bohnen schrieb:
> Kurt Bohnen schrieb:
>> Wie steht es denn um die Ansteurung der Huckepack Platine?
>
> Ist wohl untergegangen.

Ja sorry die Frage hatte ich übersehen. Da ich noch keine Zeit hatte die
Platine bei mir einzubauen ist das noch in Warteposition. Als Erstes
wollte ich auch mal den 16 Bit DAC einbauen um zu prüfen ob das richtig
funktioniert. Bei branadic ist ja nicht so richtig klar geworden ob das
ok ist.

Gruß Hayo

@Niklas

Super wie schnell Du vorankommst und was die Screenshot-Schnittstelle
inzwischen alles kann. Ich freue mich schon auf das nächste FW-Release.

Noch eine Bitte, kannst Du mir zusätzlich zum Diff auch noch die Sourcen
zukommen lassen? Dann kann ich mir das im Kontext vorher ansehen.

Gruß Hayo

@Niklas

Diff ist eingebaut und getestet - läuft gut!

Gruß Hayo

Hallo Rainer,

> Zum Datenformat habe ich noch folgende Anmerkungen:
> 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in
> den Header nehmen, damit unter /[Data]/ reine Zahlen stehen

Beim naechsten Release, bei diesem hatte ich das vergessen.

> 2) Bei channel_delays würde ich channel_delays_ns angeben, auch
> damit hinten reine Zahlen stehen (Wer weiß wozu?)

Ja.

> 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das
> Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben
> verschoben" assoziiert. [..] Dann bin ich gespannt, wie das mit
> fertigen Skalierungsfaktoren

Der channel_vzero_levels und channel_scale_factors Kram faellt eh
komplett weg sobald ich die Skalierungswerte A und B eingebaut habe,
von daher keine Anpassung mehr daran.

Niklas

@Niklas
ich hatte vermutet, dass die channel_vzero_levels und
channel_scale_factors schon die Anfangsstrukturen für die neuen
Skalierungsfaktoren sind. Aber dann ist ja alles auf gutem Wege.

@August
Die Idee mit der Meßdatenübertragung an den PC finde ich sehr gut.
Eine Sache die ich mir vorstellen kann, wäre ein Kommando, dass man vom
PC an das DSO schickt und dann kommen die aktiven Quick Measure Werte
zurück. Wäre das LabView-tauglich?

Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
Fernsteuerung des gesamten W2000A vom PC aus aus?

Hallo August,

> [..] Impedanz Messungen durchführen(über den gesamten Frequenzgang).
> Ich möchte die Auswertung und Darstellung mit LabView machen.
> Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten.
> Gibt es eine Möglichkeit diesen Datentransfer durchzuführen?
> Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine
> Funktion hinzufügen die, die selektierten Messdaten von der Funktion
> „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC
> weitergibt.

(1) Zur "Quick Measure"-Datenuebertragung:

Ja, das ist eine gute Idee, schaue ich mir an.  Welches Format
waere da interessant?  Aehnlich wie es bei den Tracedaten
ablaeuft?  Also z.B.:

<code>
[Measurements]
frequency_str=<tab>2.5MHz
frequency_num=<tab>2500000
[..]
</code>

Das Ganze dann zusaetzlich zu einem Trace?  Optional?

(2) Zu LabView und kontinuierliche Messdaten:

Ich selbst habe leider keine Ahnung von LabView.  Ich weiss nicht,
ob sich hier jemand aus dem Forum vllt. schon einmal daran gemacht
hat, einen LabView-Treiber zu implementieren, um das DSO darueber
zu steuern.

Bzgl. der kontinuierlichen Uebertragung der Daten ist zu sagen das
dies zwar bei "Quick Measure" noch gut funktionieren wuerde,
es aber unmoeglich wird bei den Traces, aufgrund (a) der begrenzten
Speichertiefe des Oszis (16kSa/Kanal) (b) der Schnitstelle und nicht
zuletzt (c) wegen des langsamen Softcores.  Ich glaube auch nicht
dass das bei USB grossartig besser wird.

Ob es bei 4 Traces alle 6s noch sinnvoll ist diese "kontinuierlich"
zu uebertragen weiss ich nicht.

Niklas

> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
> Fernsteuerung des gesamten W2000A vom PC aus aus?

Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
eine einfache Implementierung, die auf Tastatureingaben eines Terminals
reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung
hat auch schon jemand für sein Projekt benutzt (Kurt Du?).


> Ich möchte die Auswertung und Darstellung mit LabView machen.
> Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten.
> Gibt es eine Möglichkeit diesen Datentransfer durchzuführen?

Ist auch machbar und war auch mal für USB von WELEC implementiert -
leider so schlecht dass man es rausnehmen mußte. Nur wie Niklas schon
sagte wird die Wiederholrate extrem langsam wenn zu viele Daten
übertragen werden.

Eine Lösung wäre vielleicht wenn nur die 600 Werte des aktuellen Screens
übertragen würden.

Gruß Hayo

Hallo Hayo,

>> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
>> Fernsteuerung des gesamten W2000A vom PC aus aus?
Das funzte mal mit der originalen Soft von Wittig, allerdings nur mit
der FW 1.4, hatte aber nur funktioniert, wenn sie dazu Lust hatte, dann
trampelte die Software manchmal auf der Stelle und es regte sich nichts
mehr!

> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
> eine einfache Implementierung, die auf Tastatureingaben eines Terminals
> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
> Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung
> hat auch schon jemand für sein Projekt benutzt (Kurt Du?).
...wo liegt die denn rum???

Gruß Michael

@Niklas

Es gibt noch zwei Werte, die evtl. für die Parameterübergabe interessant
wären:

- die Pretriggerposition im Speicher (Memory Index 0....16383 /
0....4095)
  Format ist Integer.

- der Pretriggerwert als float. Während dieser vorher nur lokal
berechnet wurde habe ich Ihn jetzt global deklariert, so dass er
jederzeit zur Verfügung steht.

Ich habe die Variablen mal auskommentiert in die CSV-Routine eingetragen
falls das von Interesse sein sollte.

Hayo

Es ist soweit,

wie versprochen die neue Version bei der sich einiges getan hat.

Die Highlights sind:

- Natürlich die neue Screenshot-Version von Niklas mit neuer
  CSV-Übertragung
- neue double push Funktionalität bei Edge-Button, Pulswidth-Button und
  Main-Button ebenfalls von Niklas
- invert Bug ist gefixt
- neuer stabil arbeitender manueller Trigger
- neues Trigger-Submenü mit diversen Einstellmöglichkeiten, zu finden im
  Mode/Coupling Menü. Da sollte für jeden Geschmack was zu finden sein.

Weitere Details entnehmt bitte dem changelog und der Datei
Special Functions.txt



@eProfi

Die Schrittweite der Pre Trigger Einstellung habe ich nicht auf die
letzte Stelle des Zeitwertes bezogen, sondern auf die Zeitauflösung pro
Pixel, da mir das sinniger erschien.


Gruß Hayo

Hallo Hayo,

Hayo W. schrieb:
>> ... Und wie sieht das eigentlich mit einer
>> Fernsteuerung des gesamten W2000A vom PC aus aus?
>
> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
> eine einfache Implementierung, die auf Tastatureingaben eines Terminals
> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
> Falk, die recht umfangreiche Möglichkeiten bietet.

Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im
Moment als "suggestion" unter
http://sourceforge.net/apps/trac/welecw2000a/wiki/...
beschrieben ist? Dast ist ja noch arg rudimentär und Zukunftsmusik.

Das von Falk außeinandergedröselte USB Protokoll bietet da ja schon
einiges mehr. Gibt's da Quellcodebeispiele, wie man das unter Win vom PC
aus nutzen kann?
http://sourceforge.net/apps/trac/welecw2000a/wiki/...

"Set timebase" über Terminal habe ich gerade probiert (mit BT.2.13 FW).
Da tut sich auch etwas, aber außer Debugausgaben kommt nichts weiter
zurück. Dabei bin ich auf folgende offene Baustelle gestoßen: Die
Umschaltung ist etwas "eigenwillig", d.h. die Kommandowirkung hängt von
der vorher eingestellten Zeitbasis ab.
Wenn man z.B. <stx>ET<0x18>... schickt, schaltet das DSO auf
unterschiedliche Bereiche um, je nachdem wo es vorher stand. (z.B.
5us/div -> 5s/div, 20s/div -> 1s/div, 100ns/div -> 500ms/div). Außerdem
kommt man nicht in die ganz langsamen Bereiche, weil Parameter über
<0x1F> nicht angenommen werden.

Aber ich vermute mal, dass die Baustelle z.Z eher brach liegt, oder?

Schönen Sonntag
Rainer

Edit: Danke für die neue Wochenend-Edition

Hi,

ich vergaß noch anzumerken, dass ich aufgrund der umfangreichen
Änderungen gezwungen war die Flasheinstellungen zurückzusetzen. Also
nicht vergessen das Gerät neu zu kalibrieren und die
Hardwareeinstellungen neu zu machen.



Please notice that I had to reset the flash. So calibration and hardware
adjustment is recommended.


@gyppe

- no donation, it is just for fun!

Hayo

Thanks for Your kind response Paolo

Hayo

Leider habe ich noch einige Bugs entdeckt.

Z.B. arbeitete der manuelle Trigger immer noch nicht so richtig unter
allen Umständen. Jetzt sollte er es aber tun.

Daher noch mal ein Update in dem nur einige Fixes sind aber sonst nix
Neues.

Hayo

Paolo schrieb:
> New 2.15 version tested. On the welcome screen appear to be a "beta"
> version...

don't worry, I just forgot to delete the "beta"

> What's the next step?

Several little improvements at math-functions and FFT. Hardwaresupport
for the new input stage of branadic.

> Excuse me for the question, but i don't understand German language and
> google translate make a bad job:
> What are the benefits on ADC/DAC substitutions that is described on some
> previous messages?

the 16 Bit DAC has a finer division at zerolevel adjustment. This is
only relevant to the 2/0.2/0.02 and 1/0.1/0.01 ranges. It is not really
necessary but nice to have.

I got the LT2602 as free sample from Linear Technology. They are very
small and You need to have some experience in soldering SMD parts if You
want to replace them.

Kind regards
Hayo

Hallo Hayo,

die neue Auto-Pre-Trigger Funktion finde ich ausgesprochen praktisch.
Beim Messen in der Einstellung "Left Edge" hat sich aber gezeigt, dass
es vielleicht günstiger wäre, das "Left" nicht ganz wörtlich zu nehmen,
sondern den Trigger auf den ersten Grid Raster zu legen
(Left_Edge_1_12.png).

Meistens interessiert doch ein bisschen, was vorne los ist ;-)

Gruß
Rainer

Hi Rainer,

gleich vorweg - ich sehe mal zu dass ich das noch als extra Menüpunkt
mit einbaue.

Zum "Left Edge":

Das ist ja den alten Analog-Oszis nachempfunden. Man stellt ja
normalerweise die Zeitbasis so ein, dass nach dem Triggerdurchgang etwas
mehr als eine Periode auf dem Schirm zu sehen ist. Dann hat man nämlich
auch den am Anfang fehlenden Teil der nächsten steigenden Flanke locker
mit auf dem Screen.

Dazu kommt, dass viele Signale auch nicht so steil ansteigende Flanken
haben, so dass auch vom Triggerlevel an die ganze Flanke zu sehen ist.

Gruß Hayo

Etwas Anderes,

ich mache mir gerade Gedanken über die Ansteuerung der Addon Platine.
Hat schon jemand das Teil eingebaut und kann mir gegebenenfalls
Testergebnisse liefern?

Hayo

So ich hab mal wieder was zum ausprobieren für Euch. Ich habe etwas
rumgespielt nachdem ich für Rainer den neuen Menüeintrag eingebaut
hatte.

Dabei sind wieder die Spikes aufgetaucht und ich konnte feststellen dass
die Spikes durch das Verstellen der Timebase verursacht werden.

Einstellung:

- Triggersource Kanal 4
- Combi oder Norm Trigger
- Timebase 50ns
- Signal auf Kanal 4


Alles ist gut. Dann Zeitbasis auf 50µs verstellt und wieder zurück auf
50ns siehe Bild Test01.

Dann Zeitbasis auf 5µs verstellt und dann zurück auf 50ns - siehe
Test02.

Dann wieder verstellt und so weiter Test03...Test05.

Wenn man das Gerät ausschaltet und wieder einschaltet ist alles wieder
gut.

Ist das bei Euch auch so?

Gruß Hayo

Jo, hatte ich letzte Woche und gerade dann, wo ich es nicht brauchen
konnte!
Allerdings sporadisch, manchmal auf Kanal 1 dann mal auf Kanal 2
(W2022), wie es gerade Lust hat!
Gemessenes Signal war 57 kHz Rechteck an einem LM2576 Adj. Dachte schon,
jetzt ist er hinuber!!
 Die Grundlinie über das Display scheuchen, brachte auch keine
Besserung.
An der Warmlaufphase scheint es aber nicht zu liegen, da das DSO schon
über eine Std. lief. Nach neuem hochfahren, war wieder alles hübsch...

Gruß Michael

Aha,

ich bekomme das nur auf Kanal 3 + 4 hin.

Gruß Hayo

Sehe gerade, du hast 16V Sägezahn!?! Ich hatte bei der Restripplemessung
dieselbe Einstellung wie du 2V/DIV, 50nS und Combitrigger "AC", ob das
bei "DC" auch der Fall ist?
Wenn du das provozieren kannst, dann prüf' das doch mal...

Gruß Michael

Hallo,

ich melde mich mal kurz.

Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
gebraucht (Wegspeichern der in RenderText() berechneten Werte
fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
Dimensionierung).

Die Ausgabe sieht dann so aus (echte Werte):

meas-000.txt
[measurements]
str=;dX =   5.4 us;1/dX = 185 kHz;dY 1 =  29 mV
desc=;dX = ;1/dX = ;dY 1 = 
dimension=;u;k;m
unit=;s;Hz;V
value_bd=;5;185;29
value_ad=;4;0;0
value_float=;5.4;185.0;29.0

Konkrete Vorschlaege/Anregungen gerne willkommen.

Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",
"Save to PPM", "Save to CSV" usw. einfach "Screenshot",
"Trace" und "Measurements" machen, wobei dann das Format
ueber ein Untermenue konfigurierbar wird.

@August:
Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram
geben damit Du das Ganze schon nutzen kannst.

Bezueglich meiner Spikes auf Kanal 3+4 beim Nulldurchgang
auf dem DSO:

Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,
wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was
aendert.  Negativ.  Da das ganze Board ziemlich warm war
hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt
und bei offenen Geraet direkt gegen die Platine blasen
lassen.  Das verminderte die Anzahl Spikes jedoch nur gering.
Nochmal komplett Front abnehmen, um auf die andere Seite
der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.

Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn
reproduzieren kann, kann ich mangels schnellem Signalgenerator
nicht pruefen.  Bei mir treten die Stoerungen aber wie gesagt
auch erst bei 50ns sehr haeufig auf.

Niklas

Niklas O. schrieb:
> Hallo,
>
> ich melde mich mal kurz.
>
> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
> gebraucht (Wegspeichern der in RenderText() berechneten Werte
> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
> Dimensionierung).

Währe es nicht einfacher den Float-Wert global zu deklarieren und dann
per Multiplakation als Integer zu übertragen?


> Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",
> "Save to PPM", "Save to CSV" usw. einfach "Screenshot",
> "Trace" und "Measurements" machen, wobei dann das Format
> ueber ein Untermenue konfigurierbar wird.

Das wäre eine Möglichkeit, ich mach mir mal ein paar Gedanken dazu

> @August:
> Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram
> geben damit Du das Ganze schon nutzen kannst.
>
>
> Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,
> wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was
> aendert.  Negativ.  Da das ganze Board ziemlich warm war
> hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt
> und bei offenen Geraet direkt gegen die Platine blasen
> lassen.  Das verminderte die Anzahl Spikes jedoch nur gering.
> Nochmal komplett Front abnehmen, um auf die andere Seite
> der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.

Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so
gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert
hatte waren etwas nervig). Das ist wirklich angenehm und es wird
wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.

Der Wackler könnte natürlich durchaus auch auf der anderen Platinenseite
liegen. Ausprobieren lohnt sich allemal.

Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:

von oben in den Spalt zwischen Knopf und Frontplatte linsen während man
den Knopf dreht. Irgendwann kommt die abgeflachte Seite der Achse
vorbei...

Dann mit einem dünnen Schraubendreher dazwischengehen und mit der
flachen Seite des Schraubendrehers den Rand an der Achse als
Abstützpunkt beim Hebeln benutzen. Dadurch entlastet man den Rest des
Drehgebers.


> Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn
> reproduzieren kann, kann ich mangels schnellem Signalgenerator
> nicht pruefen.  Bei mir treten die Stoerungen aber wie gesagt
> auch erst bei 50ns sehr haeufig auf.

Es tritt nicht nur bei 50ns auf, aber bei 50ns und kleiner werden alle
vier ADC dargestellt und dadurch auch alle Störungen, während bei
den TB > 50ns immer nur 1 oder 2 ADC zur Anzeige kommen.

Da "verschwinden" die Spikes teilweise scheinbar.


Gruß Hayo

Hallo Hayo,

>> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
>> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
>> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
>> gebraucht (Wegspeichern der in RenderText() berechneten Werte
>> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
>> Dimensionierung).
>
> Währe es nicht einfacher den Float-Wert global zu deklarieren und dann
> per Multiplakation als Integer zu übertragen?

Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.
Es sieht im Moment so aus:

void FloatStr::RenderText(void)
Am Ende:
        // copy values to protected variables for readout via Read_Int(B/A)Dot()
        Value_BDot = intbd;
        Value_ADot = intad;

> [..]
> Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so
> gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert
> hatte waren etwas nervig). Das ist wirklich angenehm und es wird
> wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.

Ja.  Rainer hat mir oben auch schon einen leisen Luefter bei Reichelt
vorgeschlagen den er bei sich verbaut hat.  Das Problem mit dem 80er,
den ich Sonntag benutzt habe:  Der zieht 0,47A.  (Abgesehen davon
dass er hoellisch laut ist.)
Der Original war iirc. weit unter 0,1A.  Bei der naechsten Pollin-
oder Reichelt Bestellung bestelle ich einen entsprechenden Luefter
mit.

> Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:

Beim letzten Mal, Anloeten der zwei Trigger-LEDs, Osrams in SMD,
hab' ich da schon viel Freude mit gehabt...  (sind btw. hell
genug dass die ohne Modifikationen durch den Silkscreen
durchscheinen.)

Wo wir bei den Drehgebern sind:

Bei Yokogawa hab' ich eine nette Vereinfachung bzgl. des
Verschiebens der Traces gesehen:
Wenn man die Drehencoder schnell dreht springen die Traces
von Gridline zu Gridline, bei langsamen Drehen wie gewohnt
Pixelweise.  Vmtl. haben das die anderen hochwertigen
Scopes aber auch.

Ich hab' das ganze auch schon mal kurz angetestet,
sieht dann im Code so aus:

void UserIF::ON_Zero_Channel_1(void)
[..]
   if (Rotary_Direction == 0)      //clockwise rotary direction
[..]
        else    //Main mode TY
        {
                if (rotbuf > 8) { // rotbuf -> Anzahl Schritte
                        int a, b, c;
                        // a positiv machen
                        a = Virtual_ZeroLevelCH1 + 4096;
                        // naechstgelegene Gridlinie,
                        // vllt. hier noch anders runden
                        b = a/50;
                        // zur naechsten Gridlinie springen
                        c = (b+1)*50;
                        // Zurueckskalieren und Wert setzen
                        Virtual_ZeroLevelCH1 = c - 4096;
                } else {

Analog dasselbe fuer die andere Drehrichtung.  Der ganze
bestehende Code hierzu liesze sich btw. deutlich verkuerzen.

...Und funktioniert soweit.  Ist etwas "wackelig", was aber
an dem miserablen Response des Scopes liegt, woran wir
aber wohl ohne das neue FPGA Design nichts aendern koennen.

Ansonsten muss ich wohl eh nochmal an die Front dran, da
beim W2024A fuers JTAG eine Loetbruecke fehlt und ich sonst
nicht das neue Design ausprobieren kann.

Niklas

@Niklas

> Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.
> Es sieht im Moment so aus:void FloatStr::RenderText(void)
> Am Ende:
>  // copy values to protected variables for readout via Read_Int(B/A)Dot()
>      Value_BDot = intbd;

Verstehe, Du benutzt die Instanzmethode readout() um Dir den Wert zu
besorgen, das scheint mir ganz elegant zu sein. Wenn Du mit Deinen
Änderungen soweit bist kann ich das ja mit einbauen.


> Wenn man die Drehencoder schnell dreht springen die Traces
> von Gridline zu Gridline, bei langsamen Drehen wie gewohnt
> Pixelweise.

Hört sich interessant an, werde ich mal übernehmen und testen.


@Roberto

> Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher
> Zeiteinstelleung am DSO

Das muß ich mal testen, hört sich ja merkwürdig an.

Gruß Hayo

es gibt einen 80er Lüfter von Papst glaube der macht nur 9 dB, habe 2
davon in meiner PC Front die sind nur hörbar wenn  man den Kopf an die
Front des PCs steckt. Man muss allerdings auch sagen das der nicht ganz
so viel Durchsatz hat wie andere 80er Lüfter.

By the way...

> was aber
> an dem miserablen Response des Scopes liegt, woran wir
> aber wohl ohne das neue FPGA Design nichts aendern koennen.

Ich habe mal die USTB-Timerwerte nachgerechnet und habe die akute
Vermutung, dass unsere Büchse nicht wie bisher angenommen mit 33MHz
läuft, sondern nur mit 25MHz.

Das würde natürlich auch Einiges erklären...

Hayo

also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder
taktet der FPGA intern?

Ich hatte auf dem Board einen 25MHz Quartz gesehen. Die Frage ist aber,
ob dann das Timing mit den ADCs noch stimmt.

Hayo

@Niklas

Ich habe Deine Idee mal aufgegriffen und etwas umgestrickt. Das sieht
dann so aus und funktioniert ganz gut:


else  // main mode
{
   if (rotbuf > 10)
   {
      int div, cmp;
      div = Virtual_ZeroLevelCH1/50;  // in which div we are?

      if(Virtual_ZeroLevelCH1 > 0)  // positive
      {
     cmp = div * 50;
     if (cmp == Virtual_ZeroLevelCH1){div--;} // zero level was on grid
division before
       }
       else                 // negative
       { div--; }    // next grid division

      Virtual_ZeroLevelCH1 = (div)*50;    // set zerolevel to next grid
division
  }


Hayo

> also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder
> taktet der FPGA intern?

...den Vorschlag hatte ich letztes Jahr schon mal gemacht! Im Datenblatt
müsste ja stehen, was der Prozessor maximal so abhaben kann.

Gruß Michael

Normal ist der für 33MHz ausgelegt (im NIOS I Design). Deshalb bin ich
ja auch erstmal davon ausgegangen dass es so ist. Nur haben mich die
Timerwerte bei den USTB etwas irritiert, da die iterativ ermittelten
Werte nicht zu den vorher berechneten Werten passten. Die jetzt
verwendeten Werte passen zu einer Taktfrequenz von 25MHz und einem Timer
der mit halber Taktfrequenz läuft.

Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen
und dann mal gucken ob es funktioniert (alle Timerwerte müßte man
natürlich anpassen).

Evtl. könnte es Problem mit den ADCs geben. Irgend einen Grund muß es ja
geben, dass die auf einen Teil der Performance verzichtet haben (man
läßt sich ja auch nicht freiwillig ein Bein in Beton eingießen oder?).

Gruß Hayo

nun ja, vielleicht wollten die "Welec-Designer", zur Sicherheit unter
dem Limit bleiben, damit das Teil nicht abschmiert?!?
Ein höherer Takt zieht mehr Leistung und somit auch mehr
Wärmeentwicklung, also muß auch mehr Kühlung her, dürfte ja kein Problem
sein
Den Mega8-16PU, habe ich mal mit 33MHz takten lassen, der wurde nicht
mal warm.

Ich lege mal 2 Auszüge des Altera EPCS16 bei, schau mal rein.
Da steht nur was von der Write Clock Frequency...

Gruß Michael

oh, habe ich hier das falsche Datenblatt erwischt???

Hayo W. schrieb:
> Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen

Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird
garnichts mehr funktionieren!
Eine weitere Frage ist, was die DCM(PLL) macht, wenn sie plötzlich
übertaktet wird.

Mfg,
Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.

> Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird
> garnichts mehr funktionieren!

Das vermute ich auch, aber es wäre vielleicht einen Versuch wert. Ich
denke kaputt gehen wird wohl nichts, aber es wird wohl nicht sauber
laufen.


> Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.

Gute Besserung!

Hayo

vielleicht sollte man das neue FPGA-Design gleich auf die höhere
Taktrate ausrichten 33 MHz sind immerhin ein Zuwachs über 30%

der Leon braucht keinen externen Takt mehr?

Eure Meinung ist gefragt.

Ich habe die Idee von Niklas mit den Rasterschritten beim Verstellen des
Zerolevels mal für Kanal 1 und 3 eingebaut.

Bei Kanal 2 + 4 ist noch alles beim Alten. Ich bin etwas unschlüssig ob
das besser ist als das Alte oder nicht. Wie seht Ihr das?

-> Die Triggermenüerweiterung für Rainer ist auch schon drin zum
Probieren.

Gruß Hayo

habe gerade das Prellverhalten eines Jalousinenschalters getestet und da
sind mir wieder einige Bugs aufgefallen. Und zwar erhalte ich im Single
Trigger Modus auf Kanal 1 (Kanal 2 nicht getestet) bei einer
eingestellten Horizontalauflösung von 1V/Div und einer Abtastrate von 1
mSek/Div keine Auslösung bei einer fallenden Flanke, das Signal ist 5V
DC das wie gesagt über einen Taster geleitet wird. Bei 2mSek/Div löst
der Trigger auch häufig nicht aus. Bei den andere Abtastraten geht es
einwandfrei, bis auf den Umstand das am Ende der Aufzeichnung die ca.
letze 5 Stellen im Display immer ein Spike 5V vorhanden ist.  Ich
vermute das die Zeichenroutine hier etwas verhaut und sich oder
irgendwie ein Überlauf der Adressen stattfindet und wieder Daten aus dem
vorderem Speicherbereich gezeichnet werden. Beim laden des gespeicherten
Traces ist dieser Spike plötzlich weg. Gespeichert wird also der
richtige Bereich, beim Betrachten direkt nach dem Auslösen hingegen
passt der Speicherbereich nicht 100%tig

Oszi: W2022
Firmwareversion: 1.2.BF.2.7

Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound
erst damit zu aktivieren oder eine Screenshot.cfg um dort die
Einstellung dauerhaft vorzunehmen?

Beispiel 1:
scrennshot.exe /s = startet die screenshot.exe Datei mit Soundausgabe
Beispiel 2:
scrennshot.cfg Datei wo Screenshot.exe erst nachschaut was gewünscht
wird bevor etwas piepst oder nicht
Sound=0 oder 1

Die Familie schläft gerade und nach jeder Dateiübertragung piepst der PC
Lautsprecher und da hat man ja leider keinen Einfluss auf die
Lautstärke, wenn ich nicht umbedingt einen Poti einbauen will.

Hallo Thomas,

> Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound
> erst damit zu aktivieren oder eine Screenshot.cfg um dort die
> Einstellung dauerhaft vorzunehmen?

Die BF-Version wurde wieder mit der OS vereint.  Die neuen
Versionen haben einen entsprechenden Schalter, dieser lautet
"-a" (Alarm).  Nur wenn "-a" gesetzt ist bimmelt es.

Eine Konfigurationsdatei wird ohnehin in Zukunft kommen.  Bis
dahin kannst Du die Optionen weiter in die .bat eintragen.
Die ist jetzt auch so gebaut dass man sie von anderen
Verzeichnissen aufrufen kann und ihr zusaetzliche Parameter
uebergeben kann.

Aktuelle Screenshot-Programme sind wie gewohnt auch in den
Firmware-Releases.

Niklas

Hallo nochmal Thomas,

> [Triggerverhalten]
> Oszi: W2022
> Firmwareversion: 1.2.BF.2.7

Probier' mal die .15 oder .16 aus, am Trigger hat Hayo
in der letzten Zeit geschraubt.

Niklas

Hayo W. schrieb:
> Gute Besserung!
Danke!

http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum
Unter Hardware/aktuellste Daten habe ich mal den aktuellen Schaltplan
und ein Bild vom Layout hochgeladen. Layout und Schaltplan sind fast
fertig und brauchen nur noch kleine Schönheitskorrekturen.

Mfg,
Kurt

Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Ich
habe das aber jetzt trotzdem mal für alle Kanäle eingebaut mit dem
Zusatz, dass ab einer bestimmten Menge Drehimpulse nicht nur ein Raster
weiter gesprungen wird, sondern zwei. Dann kann man auch etwas schneller
über den Screen hoppeln.

Ansonsten mache ich gerade eine Komplettrenovierung bei der
Autoscalefunktion und im Timebasecontroller.

Gruß Hayo

Thomas O. schrieb:

> Oszi: W2022
> Firmwareversion: 1.2.BF.2.7

Hi Thomas,

danke für die Rückmeldung. Aber wie Niklas schon sagte bitte immer die
aktuellste freigegebene Version bei Firmware und Screenshot verwenden.

Gruß Hayo