Wittig(welec) DSO W20xxA Open Source Firmware

[Blue F. (blueflash)]

Die sind bestimmt alle in Italien...   ;-)

Hayo

[Blue F. (blueflash)]

Hier nochmal schnell vor dem Schlafen gehen ein kurzer Blick auf den 
Zwischenstand:

Was Ihr seht ist das Spektrum eines 500Hz Rechtecksignals bei einer 
Abtastung von 25 MSa/S. Die Gridbreite entspricht der halben Abtastrate 
- d.h. ganz links ist der Gleichanteil 0 Hz (DC-Offset) und ganz Rechts 
die Frequenz 12,5 MHz.

Das ganze bei Vollaussteuerung im Zeitbereich und einer 512 Punkte FFT.

Im nächsten Bild...

[Blue F. (blueflash)]

...seht Ihr die gleiche Situation mit einer 1024er FFT. Man sieht schon 
die etwas feinere Auflösung.

Die Routine habe ich damals für ein System mit mathematischem 
Coprozessor geschrieben. Die vielen Fließkommaberechnungen waren da kein 
Problem. Auf unserem NIOS liegt die Wiederholrate z.Zt. bei 2 - 4 S pro 
FFT.

Da muß ich mal die Berechnungen auf Integer umstellen, das dürfte 
einiges bringen.

Gruß Hayo

[Guido (Gast)]

Hallo Hayo,

aus dem Bauch raus würde ich sagen das ist sogar schon
gefenstert?  Ob die vertikale Skalierung linear oder
Logarithmisch ist, erkenne ich so schnell nicht.

Auf alle Fälle ist es schön anzusehen.

Gruß, Guido

[Blue F. (blueflash)]

Das Fenster hatte ich für diese Bilder abgeschaltet, da das von WELEC in 
der tc_vars.cpp definierte Fenster Störlinien verürsacht. Ich werde da 
meine eigenen Fensterdefinitionen einbauen (habe da noch von meinem 
damaligen Projekt etliche 1024er Fensterdefinitionen).

Die Darstellung ist linear, die logarithmische Darstellung erkennt man 
daran dass die Linien nicht so schmal sind, sondern eher bauchige 
Buckel.

Es gibt allerdings noch viele Details die ich noch programmieren muß 
bevor das Ganze rund genug für die nächste Beta ist. Ich halte Euch auf 
dem Laufenden.

Wie sieht es denn an den anderen Fronten aus?

@Guido

Was machen die C-Routinen? Es sieht so aus, dass wir eine Korrektur für 
die Signalverschiebung einbauen müssen, da böte es sich an das mit in 
die C-Routinen einfließen zu lassen.


@Jürgen

Hast Du da mit der Umschaltung was rausgefunden?


@Stefan

Wie sieht es an der QM-Front aus?

Gruß Hayo

[Blue F. (blueflash)]

Zum Thema Signal-Delay zwischen den Kanälen:

Ich habe mal bei meinen Geräten nachgemessen und war doch ziemlich 
erstaunt. Es gibt da erhebliche Delays zwischen den Kanälen. Und wie 
einige von Euch auch schon festgestellt haben scheint in der original 
WELEC FW eine Korrektur eingebaut zu sein (vermutlich in der alten 
Graphikroutine).

Damit wir eine einigermaßen gemeingültige Korrektur durchführen können 
bräuchten wir möglichst viele Daten von Euren Geräten. Ich habe mal eine 
Excelliste erstellt und angehängt in der ich mal meine Werte eingetragen 
habe. Tragt einfach Eure Werte dazu und stellt die Liste dann wieder 
hier ein. Ich trage dann die Ergebnisse zusammen in eine Gesamtliste.

Gruß Hayo

[Martin H. (martinh)]

@ hayo

wie ungewünscht meine offset's
(-2ns bedeutet Kanal 2 ist 2ns früher als Kanal 1)

Martin

[Niklas O. (nevm)]

Hallo,

erstmal Danke fuer eure tolle Arbeit an der Firmware,
bin seit einem halben Jahr Besitzer eines W2024A und
beobachte schon eine Weile die Entwicklung.

Waere es moeglich, den Bildschirminhalt als einfache
Bitmap ueber RS232 (oder USB) auszugeben, damit das
Abfotographieren des Bildschirms entfallen kann?

(Entsprechendes Programm auf PC-Seite zum Auslesen
kann ich selbst schreiben.)

Das waere nicht nur fuers Debugging interessant sondern
auch bei der normalen Benutzung und wesentlich einfacher
als ueber die Originalsoftware von Wittig/Welec.

Gruss,
Niklas

[Blue F. (blueflash)]

@Martin

Ja genauso wars gedacht. Danke.


@Niklas

Willkommen in der Gemeinde ;-)

Tja, grundsätzlich gibt es ja ein entsprechendes Programm von WELEC, mit 
dem die Bildschirminhalte angezeigt werden können. Allerdings habe ich 
noch nicht ausprobiert ob das auch mit der Beta FW funktioniert. Es 
kursierten mal Gerüchte, dass bei der FW 1.2 die ja der Beta FW zugrunde 
liegt genau diese Übertragung buggy war.

Das wäre also ein Punkt an dem z.Zt. jegliche Erkenntnisse fehlen und 
wenn sich da jemand (Du??) berufen fühlt Hand anzulegen, dann haben wir 
wieder eine Ecke abgedeckt (zumindest könnte man das mal testen). Man 
kann sich da natürlich auch zu zweit zusammentun - einer auf PC-Seite 
und einer
auf DSO-Seite.

Mir selbst fehlen Windows Programmierkenntnisse, also wäre es eine 
willkommene Hilfe.

Mein eigenes Fernziel war es eigentlich mal nach schon vorhandenen 
PC-Programmen von renomierten Herstellern zu suchen, und dann das 
WELEC-Protokoll so anzupassen, dass man diese Programme nutzen kann 
(z.B. von Agilent/HP/Tektronix etc.).

Gruß Hayo

[Blue F. (blueflash)]

@Martin

wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da 
eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW 
eingebaut hat.

Hayo

[Guido (Gast)]

Hallo,

also ich bin immer noch völlig ratlos, wie ich die Verschiebung
messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
1 V/ns. Das aber kann das Welec doch garnicht darstellen?

Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
betroffen sind, dann bleibt mir das erspart.

Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
ob es da eine Einheilichkeit gibt.

@ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
C-Routine mal etwas auf und poste dann den aktuellen Stand.

Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
möglich sein, nach Druck auf den Button "Quick-Print" die
Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
würde man ja sehen, was der eine oder andere damit anfängt.

Gruß, Guido

[Niklas O. (nevm)]

Hallo,

im Anhang noch die Delays von Ch zu Ch bei meinem Geraet.

@Hayo:

Das Programm von Welec importiert soweit ich das sehe
die Rohdaten vom Oszi und bastelt sich dann (wenn
man die Scope Ansicht aufmacht) wieder nen Oszillogram
daraus.

Direkt aus dem Utility-Menue heraus "Save to..." passiert
auch nicht wirklich das, was man (ich) erwarten
wuerde, naemlich dass die Bildschirmausgabe, inkl.
gesetzter Cursor, gemessener Werte usw., genau wie
angezeigt gesichert wird.  Da wird auch nur wieder ein
Dump der Rohdaten gezogen.

Das Protokoll so anzupassen, dass es mit gaengigen Programmen
funktioniert waere wie Du schon sagst ein gutes Fernziel,
fuer meine Belange waere eine reine 1:1 Screenshot Funktion
und einfacher Datenexport schon ausreichend.

Ich habe auch gerade mal das Welec-Programm mit Deiner Firmware
getestet (die 0.75), es erkennt dass das Oszi am USB haengt und
verbindet sich, der Datenimport dauert aber ewwwwig (noch viel
laenger als mit der Originalfirmware) und am Schluss scheint
das Programm zu haengen, jeweils werden die Daten nicht angezigt,
das Oszi ist jedoch wieder "verfuegbar" (waehrenddessen lahmgelegt).
D.h., wie Du schon vermutest hast, funktioniert so nicht.

Ich habe schon gesehen das auf RS232 Testroutinen verfuegbar sind,
die die ADC Werte ausgeben, zudem hat Jochen Schaeuble mal das
USB-Protokoll reverse-engineered und auch eine LabVIEW Bibliothek
angelegt, mit der schonmal Importe funktionieren sollen:
http://schaeuble.info/de/category/jochen/w2000a

Auch liegt ja bei der Google Groups Gruppe ein C-File was
mit libusb unter Linux die Daten dumpt, was ich bei mir
allerdings noch nicht zum Funktionieren gebracht habe (ich muss
auch gestehen das ich mit USB noch nicht gearbeitet habe).

Ich denke, den Export der Kurven ueber RS232 und darstellen
mit Hilfe von evtl. gnuplot und die 1:1 Screenshot-Funktion
sind gute Erstziele.  Zu letzerem weiszt Du sicher mehr.

BTW: Komme nicht wirklich aus der Windows-Ecke, bin eher
im Unix-Bereich zu Hause.

[Blue F. (blueflash)]

Guido schrieb:

> also ich bin immer noch völlig ratlos, wie ich die Verschiebung
> messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
> kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
> 1 V/ns. Das aber kann das Welec doch garnicht darstellen?

Nein es geht viel einfacher. Man nehme eine Signalquelle mit 
BNC-Ausgang, dann ein Stückchen BNC-Kabel und am Ende ein T-Stück drauf. 
Dann zwei Tastköpfe hergenommen und auf die Enden die mitgelieferten 
BNC-Adapter aufstecken. Jetzt die Tasstköpfe in das T-Stück einführen 
und man hat exakt gleichlange Signalwege. (die Tastköpfe sollten nat. 
abgegl. sein)
Verwendet habe ich ein 5 MHz Rechtecksignal.

Bei der Messung kann man dann auch gleich die Vorzüge der interpolierten 
Zeitbasen der Beta FW nutzen. Im Vergleich dazu läßt sich das mit der 
originalen FW relativ schlecht ablesen.

> Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
> betroffen sind, dann bleibt mir das erspart.

Falsch! Ein Blick ins Excelfile und Du bist schlauer.

> Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
> ob es da eine Einheilichkeit gibt.

Eher einen Mettelwert denke ich.

> @ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
> TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
> C-Routine mal etwas auf und poste dann den aktuellen Stand.

Steht in "Selected_Timebase".

> Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
> möglich sein, nach Druck auf den Button "Quick-Print" die
> Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
> würde man ja sehen, was der eine oder andere damit anfängt.

Könnte man machen, ist nur eine Frage der Prioritäten.

Hayo

[Niklas O. (nevm)]

Hallo,

Hayo W. schrieb:
> @Martin
> wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da
> eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW
> eingebaut hat.

Das wuerde auch den Bug bestaetigen, den ich mit der originalen 1.4 FW
hab', wenn ich bei nem Snapshot (unerlaubterweise vmtl.) die
Zeitbasis aendere.  Dann verschiebt sich Ch2 zu Ch1 nochmal um ~10nS.

Schalte ich wieder auf die Zeitbasis, mit der ich den Snapshot gemacht
habe, ist der zusaetzliche Versatz im Snapshot wieder weg.

[branadic (Gast)]

Halllo Hayo,

ließe sich das nicht "dynamischer" gestalten? Ich könnte mir dazu einen 
"Routine" im Utility-Menu namens "Zeitversatz" vorstellen, mit einer Art 
Untermenu, in der man den zu korrigierenden Kanal wählt.
Kanal 1 dient als Referenz, nun wählt man einen der anderen Kanäle (2 
bis 4) und gleicht über Drehen des Menu-Encoders solange, bis der 
gewählte Kanal zeitlich mit Kanal 1 übereinstimmt.
Das hätte den Vorteil, dass jeder den Zeitversatz an seinem Gerät 
individuell einstellen kann.

Beste Grüße, branadic

[Bruno W. (brunowe)]

Hallo,

@branadic:
Bravo, ganz meine Meinung. So viel Flexibilität wie möglich, 
Beschränkungen nur wo nötig.

Gruß, brunowe

P.S.: Natürlich hab ich heute wieder niemanden telefonisch bei Welec 
erreicht. Es ist einfach ein Trauerspiel!

[Blue F. (blueflash)]

Sag ich ja - sind in Italien!


@branadic

Das mit dem Individuellen Delay-Abgleich können wir natürlich machen, 
das wäre sicherlich die eleganteste Lösung


@Niklas

Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232 
Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das 
wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur 
Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick 
Print Button legen. Wäre Dir das recht?

Hayo

[Stefan E. (stefan_e)]

Hallo Hayo,

an der QM-Front hat sich die Erkenntnis ergeben, dass es möglich eine 
einzigen Funktion über 2423 Programmzeilen zu erstrecken, ohne einen 
einzigen Kommentar zu hinterlassen. g

Die FFT wird wohl früher fertig ;-)

Gruß,
Stefan

[Niklas O. (nevm)]

Hallo,

Hayo W. schrieb:
> @Niklas
> Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232
> Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das
> wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur
> Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick
> Print Button legen. Wäre Dir das recht?

Jau, das passt.  Ich werd' auch am WE mal schauen, dass ich
CDK4Nios bei mir zum Laufen bekomme, dann kann ich evtl.
auch selbst Hand anlegen.

[Kristian T. (krissy1983)]

Hallo,

hier die Werte von meinem Gerät. Bei mir scheint es mit dem 10 ns 
Korrekturwert in der Originalsoftware nicht zu passen.

Gruß

Kristian

[Blue F. (blueflash)]

@Stefan

Dann weißt Du ja auch warum ich da bislang noch nicht rangegangen bin. 
Das mit den nicht vorhandenen Kommentaren zieht sich durch die Ganze 
Software. Ungefähr 95% der Kommentare die Du jetzt in der Software 
findest sind von mir nachträglich eingefügt für besseres Verständnis.

@Kristian

Hm, die Werte weichen ja ziemlich ab. Na mal abwarten was noch so kommt.



Gruß Hayo

[Guido (Gast)]

Hallo Hayo,

hier mal die aktuelle Version. Die Geschwindigkeit ist jetzt
ganz akzeptabel, bisschen was geht wahrscheinlich noch.

Es wäre jetzt interessant für den Rollmode nur noch die
benötigte Bytezahl zu lesen, da dieses insgesamt schon recht
lange dauert.

Gruß, Guido

[Michael W. (slackman)]

Hier meine Delayzeiten.

By the way: mit hohen Frequenzen (50 & 60 MHz Oszillatoren) hatte ich 
einige Probleme mit dem Triggern. Das Signal steht dann nicht still und 
springt hin und her.

Michel

[Kurt B. (kurt)]

Ich hatte gestern mal Verucht Wittig per Mail zu ereichen. Heute kam 
folgende Antwort:



Lieber Kurt,

vielen Dank auch nochmal für Ihre Anfrage zur Veröffentlichung
des Chip-Designs. Wir haben kein Problem von seitens Altera.
Unser Problem besteht bei einer Veröffentlichung, dass wir
eine Gemeinsamentwicklung mit einem namhaften Oszilloskophersteller
hatten, die auch einiges an IP zugesteuert hat. Deshalb konnten
wir keine Unterstützung in diesem Fall beibringen.

Bitte haben Sie Verständnis, dass wir nicht weiterhelfen können.
Wir selbst hätten auch keine Probleme die Veröffentlichung vorzunehmen.
Es sind also rechte an Dritten, die wir verletzen würden...
Das können Sie auch so an Ihre Gemeinschaft weiterleiten, so dass
bekannt wird, dass wir deshalb nicht weiterhelfen können.

Viele Grüße
Thomas

[branadic (Gast)]

Zwei Doofe ein Gedanke...
Ich hatte gestern ebenfalls eine Mail an Wittig geschrieben. Hab exakt 
die gleiche Mail als Antwort bekommen. Man hat sich noch nicht einmal 
die Mühe gemacht die Anrede auf meinen Namen hin anzupassen. Ab heute 
heiße ich also Kurt.

Beste Grüße, branadic alias Kurt

[Stefan E. (stefan_e)]

Dann gibts da draußen noch weitere Oszilloskope mit dem Design? Oh je

Oder sollten wir uns lieber freuen, dass es im FPGA nicht so schlimm 
sein kann, wie allgemein angenommen?

[branadic (Gast)]

So würde ich das nicht unbedingt formulieren, zumindest noch nicht. 
Anscheinend ist man da aber an einer neuen Sache dran. Zumindest die 
Website und ein Blick auf die Bildchen über dem Site Menu lassen darauf 
spekulieren:

http://www.wittig-technologies.com.br/company.php

Beste Grüße, branadic

[Kurt B. (kurt)]

Genau, siehe auch Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

@Stefan,
Es ging ja auch nicht nur darum den FPGA zu debuggen, sondern auch Teile 
der Hardwareansteuerung einzubauen, damit diese den Softcore nicht mehr 
belasten.

[Kurt B. (kurt)]

Die Delays scheinen aber auch vom Tastkopf abzuhängen. In die Lösung des 
Problems sollte man meiner Meinung nach jetzt nicht viel Energie stecken 
weil es für langsamere Signale keine Rolle spielt und das Oszi für HF 
zur Zeit noch nicht zu gebrauchen ist.

[Bruno W. (brunowe)]

Hallo Kurt,

man kann auch richtig schnelle Signale messen, solange man nicht über 
einen best. Signalpegel (am ADC) kommt.
In der Anlage siehst du einen 140MHz_Sinus von meinem selbstgebauten DDS 
Signalgenerator. Wenn ich den Signalpegel aber nur etwas erhöhe, bzw. in 
den 1V/Div Messbereich runter schalte, fängt das Oszillieren an und 
macht eine sinnvolle Darstellung absolut unmöglich.
Eine Schwebung oder Aliasing konnte ich auch nicht feststellen.

Gerade weil die Delays etwas von den Tastköpfen abhängen, halte ich eine 
individuelle, einstellbare Anpassung für so wichtig!

Gruß, brunowe

[Kurt B. (kurt)]

Hallo Bruno,
so gesehen hast du natürlich Recht. Da brauchen wir aber bald schon 
Untermenüs weil die Softkeys knapp werden. ;-)

Gibt es irgendwo eine Beschreibung von deinem DDS?

Mfg,
Kurt

[Blue F. (blueflash)]

Kurt Bohnen schrieb:
> Die Delays scheinen aber auch vom Tastkopf abzuhängen.

Nein bei mir nicht. Ich habe extra die Tastköpfe bei jeder Messung 
getauscht - mit dem gleichen Ergebnis

> In die Lösung des Problems sollte man meiner Meinung nach
> jetzt nicht viel Energie stecken
> weil es für langsamere Signale keine Rolle spielt und das Oszi für HF
> zur Zeit noch nicht zu gebrauchen ist.

Meine Messungen habe ich mit einem 5MHz Rechteck durchgeführt. Selbst 
bei dieser Frequenz fand ich das schon recht störend. Der Aufwand für 
eine Mittelwertkompensation (wie in der originalen FW) ist recht gering 
und reduziert das Problem schon ziemlich. Nur für den manuellen Abgleich 
müßte man einen etwas höheren Aufwand betreiben.

Gruß Hayo

[Cra Z. (crazor)]

An die GERMSloader-Bastler:

Es wäre schön, wenn beim Dumping des Flashes auch die Prüfsummen 
berechnet und vergleichen würden. Im Falle eines Fehlers kann dann die 
Zeile einfach nochmals angefordert werden. Einerseits würde ich damit 
die Funktion überhaupt erst nutzen können (mein toller Port), 
andererseits ist somit für alle sichergestellt, dass der Dump 100% 
korrekt erfolgt ist.

[Cra Z. (crazor)]

Oha, so wie ich das sehe, spuckt der GERMSmonitor gar keine Prüfsummen 
aus?

[Blue F. (blueflash)]

Genau so ist es.

[Cra Z. (crazor)]

Dann werden wir mal kräftig Gas geben mit der Implementierung des 
Flash-Controllers, so geht das ja nicht weiter!

[Blue F. (blueflash)]

Kurzer Zwischenstand:

Ich habe die letzten Tage damit zugebracht die FFT komplett auf Integer 
umzustellen und das letzte an Performance herauszukitzeln. Ich denke es 
kann sich sehen lassen. Der Geschwindigkeitsgewinn liegt bei etwa Faktor 
8 bis 10. Das ist schon recht anständig wenn man bedenkt dass die 
Routine an sich ja eigentlich schon auf Geschwindigkeit optimiert war. 
Die Geschwindigkeit liegt jetzt bei 2 bis 3 FFTs pro Sekunde gegenüber 2 
bis 4 Sekunden pro FFT vorher.

Jetzt werde ich mal das Drumherum programmieren, damit man das auch 
anständig benutzen kann.

Gruß Hayo

[drusius (Gast)]

lechtz...

(ist als Aufmunterung und Dank gedacht!!)

[Blue F. (blueflash)]

Hallo liebe Gemeinde,

dieses Wochenende wird es mal kein neues Release geben, die Menüführung 
und Einstellmöglichkeiten für die FFT im Menü sind noch zu unausgereift. 
Ich denke da ist es besser erst einen etwas runderen Zwischenstand 
abzuwarten. Vielleicht kann ich bis dahin ja auch außer den Neuerungen 
von Guido auch noch weitere Verbesserungen von Euch mit einbauen.

Gruß Hayo

[Stefan (Gast)]

Hallo Hayo,

bin momentan etwas knapp mit der Zeit. Weiß noch nicht, obs deshalb von 
mir was neues gibt. Aber ich habe gerade deinen "Shift Mode" im Einsatz. 
Ist gerade echt nützlich.

Gruß,
Stefan

[Blue F. (blueflash)]

Hi Stefan,

das höre ich gerne. Ja bei mit wird es auch etwas dauern, ich habe 
gerade mal eine To Do Liste gemacht was ich so für eine komfortable 
Bedienung alles noch einbauen muß, da gibt es ordentlich was zu tun.

Guten Start in die neue Woche

Hayo

[Jürgen (Gast)]

Hallo Hayo,

>Jürgen schrieb:
>
>> Hatte gestern irgendwie Probleme mit dem Ch3 und der
>> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW
>> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine
>> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die
>> KOmmentare?
>> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon
>> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
>
>Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her
>damit.
>
>Hayo

habe mal versucht die Sache anhand der Sourcen und des Stromlaufplanes 
nachzuvollziehen. In der o.g. Funktion ist also nur der Kommentar bei 
Ch3 bezüglich der Adresse falsch! Für die Ch-Switches ergeben sich 
folgende Adressen:
Ch1 = adr 7, Ch2 = adr 5, Ch3 = adr 1, Ch4 = adr 3, ext.Trig = adr 2, 
DAC1+2 = adr 6, DAC 3+4 = adr 4. Diese Belegung sieht man auch im 
Stromlaufplan IC U25( 74HC238). Die dort unbezeichneten Ausgänge Y0-Y7 
entsprechen diesen Adressen und Bezeichnungen können ergänzt werden.

Noch eine Eränzung der Bugliste ist mir dabei mit dem Probe-Ausgang 
aufgefallen: Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und 
Ch4 nur jeder zweite Screen korrekt dargestellt. Dazwischen wird für 
CH3+4 immer eine gerade Linie gezeigt. Ch1+2 werden richtig 
dargestellt.Die Triggerung wird aber nicht ordentlich ausgeführt (bleibt 
immer Auto Mode?).

Beste Grüße,
Jürgen

[Blue F. (blueflash)]

Hi Jürgen,

> In der o.g. Funktion ist also nur der Kommentar bei Ch3 bezüglich
> der Adresse falsch!

Immerhin haben wir jetzt wieder weitere Details geklärt und können davon 
ausgehen, dass zumindest hier alles funktioniert wie es soll. Ich werde 
mal die Kommentare in der Funktion überarbeiten (immerhin sind überhaupt 
irgendwelche Kommentare drin!).


> Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und
> Ch4 nur jeder zweite Screen korrekt dargestellt.

Danke für den Hinweis das werde ich mal näher untersuchen. Interessant 
wäre, ob das ein Bug ist den ich eingebaut habe, oder ob der bei der 
originalen FW auch auftritt.

Gruß Hayo

[Jürgen (Gast)]

Ach so ja, der Bug ist auch in der Version 1.4 so enthalten. Ausserdem 
fällt mir jetzt noch ein, daß die Drehrichtung für die externe 
Triggerschwelle ev. entgegengesetzt der übrigen Einsteller ist (Soll: im 
Uhrzeigersinn drehen = erhöhen ? )

Gruß Jürgen

[Blue F. (blueflash)]

Ok, gut zu wissen, dass das auch in der orig. FW auftritt.

Die Drehrichtungen sind zum Teil etwas durcheinander, und waren mir auch 
schon immer ein Dorn im Auge. Das wollte ich evtl. mal umstellen auf 
eine durchgängige Drehrichtung

- im Uhrzeigersinn erhöhen
- gegen den Uhrzeigersinn verkleinern

Gruß Hayo

[Niklas O. (nevm)]

Hallo,

ich hab' heute mal CDK4Nios eingerichtet und kann schon einzelne
Planes in S/W als Stream rausschreiben, ins PPM-Format wandeln
und darstellen.

Soweit ich den Aufbau bis jetzt verstehe besteht die GUI
aus etlichen Planes, die uebereinander gelagert schlieszlich
die sichtbare Ausgabe ergeben.

Um einen 1:1 Screenshot ueber "Quick Print->Save to BMP" usw.
rauszuschreiben muesste man also alle Planes in der richtigen
Reihenfolge aufeinander legen und kombinieren, d.h., Pixel
sichtbar/set oder nicht sichtbar/!set.

Dazu nun folgende Fragen an die Leute die schon laenger mit
der Firmware zutun haben:
* Ist mein Verstaendnis soweit richtig?
* Ist die Darstellreihenfolge der Planes bekannt?

Zudem noch die Frage, inwieweit der ganze Akt in der Firmware oder
einem PC-Programm erledigt werden soll, d.h., wieviel Flashspeicher
geopfert werden soll/kann.

Gruss,
Niklas

[Kurt B. (kurt)]

Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man 
die Screenshots direkt auf den Stick speichern kann.

[Blue F. (blueflash)]

Hi Niklas,

ich denke dass der Aufwand einen direkten Screenshot zu machen recht
hoch ist. Da ist es doch wesentlich einfacher nur die Signaldaten und
Parameter zu übertragen und dann das Signal zu rekonstruieren.

Ja Du hast das schon richtig gesehen mit den Planes. Es gibt eigentlich
für Alles und jede Ausgabe eine eigene Plane. Von der Plane abhängig ist
auch die Farbe, da die Farben immer pro Plane eingestellt werden. Welche
Planes da so auf den Schirm übertragen werden und in welcher Folge 
kannst
Du in TransferPlanes() sehen (in Hardware_t.cpp  Zeile 21245).

Flashspeicher ist knapp, da dort die ganzen Signale gespeichert werden,
siehe die von mir hier schon mehrfach veröffentlichten Memory Maps 
(gibts
auch in Google Groups). Ich habe jetzt schon Probleme die
trigonometrischen Tabellen für die FFT dort abzulegen.

D.h. dafür müßte man dann Signalspeicher hergeben.

Gruß Hayo

[Niklas O. (nevm)]

Hallo Hayo,

ich habe gerade fix mal meinen Code erweitert um "alle" Planes
zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
erstellt.  Dabei habe ich noch nicht die Reihenfolge in
TransferPlanes() beruecksichtigt, daher fehlen offensichtlich
einige Texte.

Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
im Code zurueck liegen, die clFarbe Konstanten sind definiert
und anscheinend nirgendwo referenziert.  Auch stoeren mich
bei dem bissl Code was ich bisher sah viele doppelte oder nicht
durchgehend benutzte Konstanten, wie auch fuer die Planes.

Da muesste mal aufgeraeumt werden.  Wie sieht da die Planung aus?
Ich waere natuerlich bereit da mit anzupacken.  Ich sehe, dass
ihr wohl bisher eher vorsichtig auskommentiert und teilweise
neu implementiert habt, um nicht gleich alles zu brechen.

Anbei der PoC-Screenshot.

[Niklas O. (nevm)]

...und hier noch der Stueck Code mit dem ich den Output erzeuge:

void Display::SCREENSHOT(void)
{
        int x, y;
        int bit, pos, offset;
        unsigned long *planes[] = {
                Grid_Plane,
                UI_Plane1, UI_Plane2, UI_Plane3, UI_Plane4, UI_Plane5,
                Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4,
                Channel_Math_Plane,
                Memory_Plane1, Memory_Plane2, Memory_Plane3,
                Marker_Plane1, Marker_Plane2,
                NULL
        };
        unsigned long *plane;
        int i, set;

        (void)printf("Pixel printout follows\r\n");

        for (y = 0; y < 480; y++) {

                for (x = 0; x < 640; x++) {
                        offset = x >> 5;                // x div 32
                        pos = Display_Line_Adresses[y] + offset;
                        bit = x - (offset << 5);        // x - (offset mod 32)

                        set = 0;
                        for (i = 0; (plane = planes[i]) != NULL; i++)
                                if (*(plane + pos) & BitMasks2[bit]) {
                                        set = 1;
                                        break;
                                }
                        if (set)
                                (void)printf("1");
                        else
                                (void)printf("0");
                }
                (void)printf("\n");
        }

        (void)printf("Pixel printout DONE\r\n");
}

Um das ganze darstellbar zu machen hab' ich einen PPM-Header
hinzugefuegt und 0/1 fuer Pixel gesetzt/ungesetzt in erfundene
Farbwerte gewandelt.  PPM habe ich nur gewaehlt, weil ich mich
da schon auskannte ;)

Natuerlich fehlen da noch die Original-Farben und eine platzsparende
Ausgabe (sind ja so 307200+480 Bytes die geschrieben werden auf RS232),
aber es ist m.E. mit geringerem Aufwand als erwartet machbar.

Gruss,
Niklas

[Guido (Gast)]

Hallo,

@ Niklas O. (nevm): Soweit ich das verstanden habe, wird nicht
alles in die Planes gezeichnet. Die sind ja nur ein Puffer, der
dann in den Videospeicher transferiert wird. Ich meine, dass z.B.
Pixelp direkt in den Videospeicher schreibt, weil da ganz andere
Adressen verwendet werden. Das solltest du vllt. mal anschauen.

Gruß, Guido

[Johannes S. (demofreak)]

Niklas O. schrieb:
> ich habe gerade fix mal meinen Code erweitert um "alle" Planes
> zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
> erstellt.  Dabei habe ich noch nicht die Reihenfolge in

Super! Genau sowas will ich schon immer haben, das ewige Abfotografieren 
des Bildschirms geht mir gewaltig auf den Zeiger. Nun das ganze einmal 
für Linux bitte. :D

/Hannes

[Niklas O. (nevm)]

Hallo,

ich hab' noch fix RLE Kompression fuer die Datenuebertragung(*)
eingebaut und blende ein paar Planes(**) aus damit man bei der
S/W Version die Beschriftungen lesen kann.

Damit kann man nun schonmal ein wenig anfangen.

Das Ganze samt Ausleseprogramm in C und kurzer Beschreibung
im Anhang.

Falls ich heute Abend Zeit habe geht's dann weiter an die
farbige Ausgabe.  Dazu werde ich wahrscheinlich die Planes
einzeln exportieren und ausserhalb des DSOs wieder eingefaerbt
zusammensetzen.  Haette auch den Nebennutzen einzelne unwichtige
Sachen, etwa fuer Dokumentationszwecke, wieder ausblenden zu koennen.

@Guido:
Soweit ich sehe wird PIXELP() mit den selben Speicherstellen
aufgerufen die ich auch verwende. Genau angeschaut habe ich
mir das allerdings noch nicht.

Gruss,
Niklas

(*) Etwa 10-15kB Daten pro Screenshot.
(**) Jene Planes die die Softbutton-Beschriftungen 
einrahmen/untermauern.

[Niklas O. (nevm)]

...und hier noch ein Beispiel-Screenshot.

[branadic (Gast)]

Hallo Zusammen,

für alle die es noch nicht mitbekommen haben, weil sie im 
Hardware-Thread zu selten vorbei schauen, ergeht hier noch einmal der 
Hinweis. Ab sofort könnt ihr euch für Schirmbleche vormerken. Wie und wo 
erfahrt ihr im entsprechenden Beitrag:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Ich hoffe auf zahlreiche Meldungen.

Beste Grüße, branadic

[Blue F. (blueflash)]

Hallo Niklas,

Du gehst ja mächtig zur Sache. Das sieht schon wirklich prima aus. Ich 
hätte nicht erwartet, dass da so schnell solche Ergebnisse zu erzielen 
sind. Echt super.

> Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
> im Code zurueck liegen, die clFarbe Konstanten sind definiert
> und anscheinend nirgendwo referenziert.  Auch stoeren mich
> bei dem bissl Code was ich bisher sah viele doppelte oder nicht
> durchgehend benutzte Konstanten, wie auch fuer die Planes.

Oh ja, wenn wir von etwas ausreichend haben, dann sind es Altlasten. Es 
sind leider so viele, dass wir nur Stück für Stück vorankommen.

> Da muesste mal aufgeraeumt werden.

Allerdings!

> Wie sieht da die Planung aus?

Zur Zeit gibt es im Wesentlichen folgende Hotspots:

- die Hardwareecke versucht Designfehler auf der Platine
  aufzuspüren und zu verbessern.

- ebenfalls der Hardwareecke zugeordnet sind die Kollegen
  die an anderen FPGA-Designs arbeiten.

- in der Softwareecke versuchen wir das Assemblercoding
  möglichst ohne Performanceverluste nach C zu portieren (Guido)

- an der Überarbeitung der Quick Measure Funktion ist Stefan dran

- einige der Forumsbesucher testen und schreiben Fehlerberichte

- einige sind auch einfach nur so im Coding unterwegs geben
  hier und da gute Hinweise auf mögliche Fehler.

- ich bin zur Zeit an der FFT-Implementierung dran

Du siehst es sind noch eine Menge Themen offen.

> Ich waere natuerlich bereit da mit anzupacken.

Das ist prima. Seit sich hier die Anzahl der Hilfswilligen so erhöht hat 
geht es deutlich schneller voran und wir können fast jede Woche ein 
neues Release mit zig Verbesserungen rausbringen.

> Ich sehe, dass ihr wohl bisher eher vorsichtig auskommentiert
> und teilweise neu implementiert habt, um nicht gleich alles
> zu brechen.

Ja, wir wollen das möglichst so machen, dass wir immer ein einigermaßen 
stabiles Release haben mit dem man auch richtig arbeiten kann. Bislang 
haben wir das so gehandhabt, dass ich die neuen Release rausgegeben habe 
und die Änderungen der anderen Entwickler mit eingebaut habe. Das läuft 
auch ganz gut und verhindert, das es zig Versionen mit unterschiedlichem 
Stand gibt. So können immer alle auf den gleichen neuen Stand wieder 
aufsetzen mit Ihrem nächsten Entwicklungsschritt. Auch bei den Tests ist 
das wegen der Vergleichbarkeit der Ergebnisse sehr Hilfreich.

Gruß Hayo

[Cra Z. (crazor)]

Kurt Bohnen schrieb:
> Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man
> die Screenshots direkt auf den Stick speichern kann.

Hallo Kurt,

da muss ich dich leider enttäuschen. Im Gerät steckt ein Cypress EZ-USB 
FX1, der nicht als Hostcontroller taugt. Da müsste also eine 
Zusatzplatine entwickelt werden...

Wenn wir gerade schon dabei sind: Ich habe am Wochenende nach dem 
JTAG-Zugang zum 2. FPGA der 20x4er gesucht. Leider kam heraus, dass 
vergessen wurde, TCK an den 2. FPGA zu routen, aber das kennen wir ja 
nicht anders von den Wittigs.
Nichts desto trotz habe ich eine interessante Entdeckung dabei gemacht. 
Direkt oberhalb des 2. FPGA, neben dem Steckverbinder zum Frontpanel, 
sind 8 ungenutzte Pins des 2. FPGA auf Pads geführt. Hier könnte evtl. 
eine Art Erweiterungsschnittstelle realisiert werden für Nutzer der 
20x4-Geräte (die 20x2-Eigentümer müssten dazu leider schon direkt an die 
BGA-Bälle der Pins, die vom 1. FPGA kommen, ran. Haare spalten (der 
Länge nach) ist glaube ich einfacher).
Mindestens aber könnte dort z.B. ein SD-Cardreader angebracht werden.

Soviel zur Hardware, denn das ist hier der Softwarethread!

P.S. das nächste FPGA-Design zum "Spielen" lässt leider noch auf sich 
warten, da noch einige grundlegende Umstrukturierungen ausstehen, da ich 
mich mit einigen Fiesigkeiten lange aufgehalten habe. Sorry! Aber 
Downsampling und Timebases funktionieren, mittlerweile auch korrekt.

[Kurt B. (kurt)]

Hallo Daniel,
das mit dem EZ-USB ist schon klar.

Für den VNC1L-1A (Vinculum) USB-Controller gibt es eine fertige Firmware 
(VDAP) die alle Aufgaben der Ansteuerung eines USB Sticks inkl FAT 
realisiert.
Man muss nur einige Parameter über SPI oder UART übergeben, und der 
Vinculum schiebt die Daten auf den Stick.
Siehe auch Beitrag "USB-Stick am Mikrocontroller VNC1L"

Ich selbst habe sowas noch nicht gemacht und hoffe es trotzdem richtig 
verstanden zu haben.

Der Hinweis im Firmware-Thread weil es vieleicht sinnvoll ist, einen 
kompletten Screendump inkl. Dateiheader im Oszi zusammenzusetzen. Aber 
darüber muss mann weiter nachdenken...

[elgodil (Gast)]

Meine Wunschvorstellungen für den Screenshot:

-Farbe (ok, ist in Arbeit)

-Auslösen durch Tastenkombination(nen z.B. 1 x RAW (durch ext. Programm 
manipulierbar) 1x als BMP o.ä. (also gleich verwendbar)

-Ausgabe seriell als Z-Modem (also so, das gleich der "Abspeichern" 
Dialog aufpeppt

So ist ein Screenshot imho in der Praxis am schnellsten gemacht.

Was in den Flash passt, müssen nat. die Programmierer entscheiden.....

elgodil

[Blue F. (blueflash)]

Auch wenn Abfotografieren bald nicht mehr State of the Art ist ;-)
(wenn Niklas da so weitermacht) hier ein Screenshot einer
Logarithmierten FFT.

Ich freue mich, dass ich es geschafft habe die Logarithmierung zu 
implementieren, ohne spürbaren Performanceverlust gegenüber der 
liniearen Darstellung.

Das war nicht von Anfang an so! Erste Versuche mit der originalen 
Bibliotheksfunktion log10() haben massive Performanceverluste nach sich 
gezogen und die Wiederholrate auf 5 S pro FFT runtergedrückt - trotz der 
optmierten FFT-Routinen.

Das sieht schon alles soweit ganz gut aus, so dass ich hoffe zum 
nächsten Wochenende die nächste Beta rausgeben zu können.

Gruß Hayo

[Stefan (Gast)]

Bei mir gibts noch nix neues. ;-) Hab gerade wieder ne Stunde damit 
verbracht, denn Code zu verstehen. Aber der übersteigt mein 
Denkvermögen. Hundert Variablen, die irgendwie miteinander verknüpfts 
sind, Variablen die scheinbar nie gesetzt werden, hunderte 
Fallunterscheidungen,...

Ich glaube, es ist leichter den Code neu zu schreiben, als da 
rumzufrickeln.

Gruß,
Stefan

[Blue F. (blueflash)]

Deswegen habe ich ja auch etliche Sachen komplett neu gemacht.

Hayo

[PIZZA-MAMPF (Gast)]

@Hayo
Thema FFT log -> mit Tabelle??

[Blue F. (blueflash)]

Jupp!

[Niklas O. (nevm)]

Hallo,

so, ich bin dann noch dazu gekommen die Screenshot-Funktion
auf farbige Ausgabe zu erweitern.  Wie angekuendigt exportiere
ich die Planes einzeln.  Das Programm speichert diese auch
einzeln ab, was vllt. auch fuer die Entwicklung interessant ist.
Was mir schon auffiel:  Die Plane fuer den Ch 4 wird "missbraucht"
um die roten Pfeile und das Stop(p)-Schild zu malen.

Diff, fertig kompilierte TomCat.ram und C-Programm wie beim
letzten Mal schon im angehaengten .tgz.  Alles weitere und
Changelog in der README-Datei.

Dem C-Programm steht btw. nichts entgegen, nicht auch mit Cygwin
oder MinGW fuer Windows kompiliert zu werden.  In der kurzen
Zeit hab' ich (auch mangels Windows mit installiertem Cygwin
oder anderem Environment) mich noch nicht darum gekuemmert.

Falls fuer Windows-User die PGM/PPM Bildformate ein Problem
darstellen laesst sich das sicher auch zu BMP umstricken, wie
schon gesagt, wird nur verwendet da ich mich damit schon
auskannte.

@elgodil:
> -Auslösen durch Tastenkombination(nen z.B. 1 x RAW
> (durch ext. Programm manipulierbar) 1x als BMP o.ä.
> (also gleich verwendbar)

Tastenkombination waere ' bzw. # derzeit.  BMP weisz
ich nicht was es da fuer Platzeinsparungsmoeglichkeiten
mit RLE und Paletten gibt und wie hoch da der jeweilige
Aufwand in der Firmware waere.

Generell bin ich auch fuer die Option der Ausgabe in einem
wohldefinierten und universellen Format.
Bei USB sehe das vmtl. schon anders aus da dort offensichtlich
die Uebertragungsgeschwindigkeit nicht so ins Gewicht faellt.

> -Ausgabe seriell als Z-Modem (also so, das gleich
> der "Abspeichern" Dialog aufpeppt

Die Idee finde ich gut und es waere ein Schritt dahin,
das DSO mit "Boardmitteln" wie HypterTerm oder
Minicom ueber RS232 ansprechen zu koennen, auch
hinsichtlich der Ausgabe und Speicherung von
Messwerten direkt in eine (CSV-)Datei.

Ich werde dann aber wahrscheinlich X-Modem-1K-(CRC16) benutzen.

Gruss,
Niklas

[Niklas O. (nevm)]

...und hier noch ein Beispielscreenshot mit der Ausgabe
von Hayos Test-Signal-Funktion.

Hinweis:  Auf dem Oszi uebermalt der lila Math-Channel
die Browse-Scroll-Leiste (wie heiszt die korrekt? ;)),
im Ausleseprogramm habe ich die Reihenfolge veraendert
damit die Ausgabe im Screenshot "korrekter" ist.

[Blue F. (blueflash)]

Hi Niklas,

Du bist ja mächtig fix! Ich bin noch nicht zum Ausprobieren gekommen, 
aber ich denke ich werde das mal mit in die nächste Beta einbauen. Da 
bietet es sich ja an das ins Print-Menü zu integrieren, damit man nicht 
immer über das Terminal triggern muß.

Super!

Gruß Hayo

[Stefan E. (stefan_e)]

Schöne Sache dein Screenshoot.

[Blue F. (blueflash)]

Hi,

für diejenigen, die nicht so oft im Hardwarethread unterwegs sind hier 
die Anleitung wie man die Luftzufuhr im Gerät optimieren kann.

Gruß Hayo

[drusius (Gast)]

Könnte man bei der Gelegenheit gleich einen Pabst oder Verax reinhängen 
und (da weniger Saugleistung benötigt wird) gleich noch die Drehzahl 
runtersetzen (oder regeln)....

mal schauen

[drusius (Gast)]

Hab schon mal das Datenblatt des verbauten Lüfters ergoogled (was für 
ein blödes Wort!)

[Bruno W. (brunowe)]

Hallo Hayo,

tolle Beschreibung! Ich hab mir erlaubt das ganze in SF einzufügen.
http://sourceforge.net/apps/trac/welecw2000a/wiki/Modifications

Noch etwas aus meiner Wishlist:
Bei meinen Tests ist es mir schon häufiger aufgefallen, das mein 
HF-Signal von einer  NF-Schwingung überlagert ist. Sehr schwer 
gleichzeitig darzustellen- Man muss die Zeitbasis entsprechend verändern 
und verliert dadurch zwangsläufig die andere Schwingung aus dem Auge. 
Deshalb mein Wunsch nach einer zweiten Zeitbasis. D.h. es wäre doch 
wunderbar wenn ich z.B. den Ch1 mit 50ns/Div und den CH2 mit z.b. 
1ms/Div darstellen könnte. Gute, teure Oszis haben da ja eine echte 
zweite Zeitbasis, aber eine entsprechende Darstellung zweier Kanäle mit 
unterschiedlicher Zeitbasis sollte doch auch bei uns zu verwirklichen 
sein? Im neuen VHDL Design werden wir eine entsprechende Verwirklichung 
dieses Features auf jeden Fall anstreben.

Gruß, brunowe

P.S.: Meine Wunsch nach einer variablen Verstärkung (vertikales zooming) 
ist auch noch in der ToDo list? Nicht das das verloren geht...

[Blue F. (blueflash)]

Hi Bruno,

wie soll denn die zweite Zeitbasis einzustellen sein? Der Einsteller für 
die eigentliche Zeitbasis ist ja schon vergeben.

Eine Möglichkeit wäre ein Umschalter oder sowas in der Art. Wie ist das 
denn an den besagten teuren DSOs realisiert?

Gruß Hayo

p.s. Hier geht nix verloren - letztlich werden alle Wünsche erfüllt 
(hoffe ich)

[PIZZA-MAMPF (Gast)]

Ich würde den Focus erst mal auf Fehlerfreiheit der vorhandenen 
Funktionen legen-aber Bugs (anderer) zu suchen ist nun auch nicht das 
reine Vergnügen.

[Bruno W. (brunowe)]

Hallo,

also ich kenne jetzt konkret das HAMEG 1508-2 (Mixed Signal combi 
scope), das HM 2005-2 (analog scope) und das Philips PM3092 mit 2 
Zeitbasen. Wie die Umsetzung bei den analogen Oszis funktioniert ist 
relativ einfach erklärt. Es gibt eine Haupt- Zeitbasis (die langsamere), 
mit dieser wird das Signal getriggert und dargestellt. Innerhalb dieser 
dargestellten Zeitspanne wird jetzt mit einem bestimmten, einstellbaren 
delay, dieses Signal mit einer schnelleren Zeitbasis dargestellt. Es 
kann damit also eine Ausschnittsvergrößerung dargestellt werden.

In unserem Fall müsste man das interessierende Signal auf zwei Kanälen 
sampeln um eine entsprechende Vergrößerung darstellen zu  können. Ich 
würde auf jeden Fall den Kanal 1 fix mit der Hauptzeitbasis koppeln. Den 
Ch2 dann, mit einer über das Menü (neuer Menüpkt. neben Probe), zu 
aktivierenden zweiten Zeitbasis belegen. Zugegeben ist das 
wahrscheinlich etwas komplexer zu verwirklichen (Trigger und delay 
Problematik...) und bestimmt gibt es noch einen ganzen Stapel anderer, 
wichtigerer Baustellen... Dennoch wollte ich dieses Feature einfach mal 
erwähnen.

gruß, brunowe

[Guido (Gast)]

Hallo,

könnte man nicht den Delayed-Mode so aufbohren, dass er zweimal
hintereinader sampled: Erstes Sample langsame Timebase, oberes
Bild zeichen. Zweites Sample schnelle Timebase unteres Bild
zeichnen, Und wieder von vorne.

Gruß, Guido

[Bruno W. (brunowe)]

@Guido,

das wäre wohl die einfachste und genialste Möglichkeit. Man würde sich 
damit sogar den zweiten Kanal einsparen. Guter Einfall!


gruß, brunowe

[Blue F. (blueflash)]

Den verstehe ich nicht so ganz.

Wo ist da der Unterschied zum jetzigen Delayed Modus, wenn man mal davon 
absieht das es nicht mit zweimal sampeln realisiert ist sondern einfach 
mit unterschiedlichen Zoomfaktoren.

Oder hab ich da was falsch verstanden?

Hayo

[Guido (Gast)]

Der Vorteil liegt einfach in den beliebig vielen Zoomstufen.
In den meisten Bereichen haben wir bisher ja nur eine.
Der Nachteil ist halt die halbierte Aktualisierungsrate.

Vllt. ginge es auch eleganter, ich würde gerne mal mit den
Werten des TimeBaseRegisters spielen. Die nächsten 3/4 Wochen
werde ich aber nicht dazu kommen.

Gruß, Guido

[Bruno W. (brunowe)]

Hallo,

ich hab hier als Beispiel die Darstellung von einem Fernseh-BAS Signal 
angefügt. Mit unseren Mittel ist es derzeit nicht möglich, gleichzeitig 
das komplette BAS Signal für eine Bild-Zeile und das 
Trägerfrequenzsignal darzustellen... um solche und ähnlich komplexe 
Signaldarstellung geht es im Prinzip.

Vielleicht noch ein wichtiger Punkt zur Anmerkung. Die Nutzung des 
Delayed Modus hat natürlich den gravierenden Nachteil, das man für die 
zeitl. gezoomte Darstellung die Spannungsauflösung nicht unabhängig von 
der Hauptdarstellung einstellen kann. Ein echtes Manko meiner Meinung.


gruß, brunowe

[Blue F. (blueflash)]

Hallo werte Gemeinde,

leider bin ich heute nicht mehr ganz fertig geworden, so dass es die 
neue Beta erst morgen geben wird. Schon mal soviel vorweg, das Warten 
hat sich gelohnt. In das neue Release sind zahlreiche Bugfixes und 
Korrekturen eingeflossen (Mathfunktion, Statusbar Kanalanzeige, 
Menü-Updatelogik etc.). Desweiteren habe ich die C-Routinen von Guido 
eingebaut und die neue Screenshot-Funktion von Niklas ins Quickprint 
Menü integriert. Und als Highlight verfügt das W20xxA jetzt über eine 
Spektralanalyse (FFT) die sich nicht vor der teurerer Geräte verstecken 
muß.

Bis morgen

Hayo

[Niklas O. (nevm)]

Hallo,

ich hab' heute Nachmittag damit angefangen, eine minimale
ZModem-Implementation (derzeit ca. 290 Zeilen) fuer das DSO zu bauen. 
Eigentlich wollte ich ja, weil wesentlich einfacher, XModem, aber dann
haette man den Dateiempfang per Hand anstoszen muessen.

Das ganze laeuft schonmal "im Trockenen", ich muss allerdings
noch eine zusaetzliche ISR Routine fuer den UART schreiben, der
die empfangenen Bytes zwischenbuffert bis diese weiterverarbeitet
werden.

(Derzeit mache ich ungefaehr:

static int rd_char(void)
{
        while (!(puart->np_uartstatus & np_uartstatus_rrdy_mask))
                ;
        return nr_rxchar();
}

Hardware::DoDisableUARTInterrupt();
[Verarbeitung]
Hardware::DoEnableUARTInterrupt();

Was, im Schneckentempo ;), zum ersten Testen okay ist.)

Screenshots (und Messdaten) sollen dann wahlweise "roh" wie
gehabt oder per ZModem direkt in eine Datei uebertragen werden
koennen.

Nun stellt sich aber noch ein Problem:  Bei ZModem muss
ich dem Empfaenger den Dateinamen mitteilen.  Wenn der
Dateiname bereits existiert wird je nach Implementation
des Empfaengers unterschiedlich verfahren: HyperTerminal
ueberschreibt wohl ungefragt, lrzsz ueberspringt die Datei.
Immer den gleichen Dateinamen benutzen scheidet also aus.

Optimal waere es natuerlich, wenn wir einen Dateinamen
mit Uhrzeit und Datum generieren koennten, aber das scheidet
wohl auch aus.  Daher wuerde ich vorschlagen, eine mehrstellige,
aufsteigende Zahl anzuhaengen (also z.B. screen-nnnn.dat und
meas-nnnn.dat) aehnlich dem wie es Digitalkameras machen.
Dabei wuerde der letztverwendete Wert fest im Flash
gespeichert und so einen Reboot ueberdauern.

Vllt. hat jemand auch eine andere Idee?

Gruss,
Niklas

[Blue F. (blueflash)]

Hi Folks, new 0.80 Beta out now!

Wie versprochen die neue Version vollgepackt mit Neuerungen.

Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
ganz perfekt, aber schon ganz ordentlich.

Ich bitte explizit um kritische Rückmeldungen.


@Niklas

Zu Deinem ZMODEM/XMODEM Problem kann ich leider nichts beitragen, aber
vielleicht kannst Du mir helfen. Ich habe Deine Routinen ins Quick Print
Menu eingehängt, aber das Programm scheint keine Verbindung zum DSO zu
kriegen.

Ich starte das Programm in einem Shellfenster und es signalisiert, dass
es wartet. Wenn ich dann den Screenshot starte friert der DSO-Bildschirm
kurz ein - und das war's. Das Programm reagiert aber nicht.

Stell ich mich da zu dusselig an oder hab ich was falsch verstanden?

Gruß Hayo

[Blue F. (blueflash)]

Jetzt noch die Datei...

[Blue F. (blueflash)]

Ach ja,

nicht vergessen erstmal Default Setup zu drücken und dann die Timebase 
zu drehen, damit die neuen Flashwerte für die FFT initialisiert werden.

Gruß Hayo

[Johannes S. (demofreak)]

Lässt sich das nicht irgendwie automatisieren? Man kann doch bestimmt 
die Firmwareversion irgendwo unter den Einstellungen ablegen, so dass 
sie bei einem Flash nicht überschrieben wird, und dann beim Boot die 
aktuelle gegen die Version im Configbereich prüfen und die ganze 
Initialisierung dann bei Bedarf starten.

Ok, wirr ausgedrückt, aber sicher kommt rüber, was ich meine?

/Hannes

[Niklas O. (nevm)]

Hallo Hayo,

ich vermute mal, dass Du vergessen hast dem Programm
stdin auf das serielle USB-Device umzuleiten, ansonsten
liest das Programm nur die Tastatureingaben auf der
Konsole und wartet ewig.

Wichtig ist auch, dass das tty richtig konfiguriert ist,
wichtig ist der raw-Modus, da ich ohne Ruecksicht auf
Verluste (etwa Software-Handshake mit XON/XOFF) 8bit binaer
rausschreibe.

Bei mir mit USB<->RS232 Wandler sieht das z.B. dann so aus:

$ stty -F /dev/ttyUSB0 raw 115200 
$ ./w2000a-screenshot < /dev/ttyUSB0
* Waiting for Screenshot...
[Quick Print->Save to PGM]
* Found Screenshot Start Marker
  - Receiving Plane #01...
    Read 12572 bytes.
    (another plane follows)
[..]
* End of Transmission
* Total bytes transferred: 62918
* Combining...
* Done

Ich hoffe es klappt dann bei Dir auch.

Niklas

[elgodil (Gast)]

@Niklas O.

>ZModem-Implementation....XModem, aber dann haette man den Dateiempfang per Hand 
>anstoszen muessen.

Sach ich doch.... (sonst hättest du ja auch Kermit implementieren 
können...)

>also z.B. screen-nnnn.dat und meas-nnnn.dat

Finde ich super, das Datum + Uhrzeit kriegt die Datei doch eh vom BS...

@alle Entwickler

tolle Sache - so wird aus dem Fehlkauf doch noch ein Schnäppchen

Frohes Schaffen!!

[Johannes S. (demofreak)]

Niklas O. schrieb:
> Ich hoffe es klappt dann bei Dir auch.

Bei mir klappt es so auf jeden Fall, allerdings sind eine (bzw. mehrere) 
Planes verschoben und es werden Planes mit ins Endbild reinkombiniert, 
die gar nicht auf dem DSO angezeigt werden.

Auf dem angehängten Bild sieht man das verschobene Grid, das Signal 
dagegen ist nicht verschoben (hab es vorher mit dem Testsignal 
ausprobiert, nicht dass du denkst, ich hätte das Rauschen da im Anhang 
mit dem DSO verglichen :D). Und die Plane mit dem Quickmeasusre-Display 
war auf dem Scope selbst nicht sichtbar. Ich hatte vorher mal irgendwo 
Quickmeas kurz ein- und wieder ausgeschaltet, vllt liegt es daran?

/Hannes

[Niklas O. (nevm)]

Hallo Hannes,

das sollte so natuerlich nicht sein, ich vermute mal, dass da
aus irgendwelchen Gruenden da andere, falsche, Speicheradressen fuer
die Pixeldaten ausgelesen werden -- oder es ist ein Fehler im
Ausleseprogramm.  Offene Menues usw. sind egal.

Ich schaue mir das morgen in Ruhe an, welche Firmwareversion hast
Du denn verwendet?

Niklas

[Johannes S. (demofreak)]

1.2.BF.0.80

/Hannes

[Blue F. (blueflash)]

So der Reihe nach:

@Hannes

Das ist eine nette Idee, aber das funktioniert leider nur rückwärts wenn 
überhaupt. Denn wenn ich neuen Speicherplatz für neue Variablen im Flash 
belege, dann steht da erstmal nur irgendein Zufallswert drin. Durch das 
Default Setup und das Verändern der Zeitbasis  werden dann definierte 
Werte ins Flash geschrieben und in Zukunft ist alles ok. Normalerweise 
verwende ich jedesmal neue Adressen, so dass bei Verwendung älterer 
Versionen keine Probleme auftreten. Nur in Ausnahmefällen ändere ich 
bestehende Belegungen (z.B. bei vorherigen Inkonsistenzen).


@Niklas

Ok, dann hab ich mich wohl dusselig angestellt. Ich gebe zu, dass ich 
nicht so der erfahrene Linux Kommandozeilenfreak bin. Zwar habe ich mich 
langsam mit meiner Suse Distribution angefreundet, aber eigentlich bin 
ich eher Windowsbenutzer und durch die FW-Programmierung auf die Vorzüge 
von Linux aufmerksam geworden.

Danke für den Hinweis, ich werde das mal ausprobieren. Grundsätzlich 
scheint es ja zu funktionieren wie ich dem Beitrag von Hannes entnehme.


@Elgodil

Wieso Fehlkauf? Ich hab mir die Teile gekauft weil ich wußte dass es da 
was dran zu optmieren gibt. Und bevor einer fragt: Ja ich habe auch eine 
Frau und Freunde und auch noch andere Interessen  ;-)


@all

Wer nicht so richtig was mit der FFT-Funktion anzufangen weiß - nicht 
verzweifeln, ich arbeite gerade an einer Anleitung mit 
Hintergrundinformationen, die hab ich aber heute nicht mehr 
fertiggekriegt, kommt aber in Kürze.

Gruß Hayo

[Bernd O. (bitshifter)]

Hayo W. schrieb:
> Hi Folks, new 0.80 Beta out now!
>
> Wie versprochen die neue Version vollgepackt mit Neuerungen.
>
> Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
> ganz perfekt, aber schon ganz ordentlich.
>
> Ich bitte explizit um kritische Rückmeldungen.
Hallo Hayo,

super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was 
mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch 
mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der 
FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024) 
eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und 
rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten 
der beiden Kanäle ging über zunächst einschalten (LED an) und dann 
wiederum ausschalten - dann waren sowohl die LED aus als auch die 
Anzeige des Kanals auf dem Monitor aus.

Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert 
liegt an der fehlenden Anpassung an das neue Grid - oder?

Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin 
(vermutlich noch von der Welec-FW her): "Frequency" heißt dort 
"Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme 
- dafür aber auch in wenigen Sekunden gefixt :-)

Super Arbeit - ist schön zu sehen, wie immer mehr geht!

Gruß,
Bernd

[Niklas O. (nevm)]

Hallo,

(siehe UPDATE unten)

ich hab' mal die Screenshot-Funktion in der aktuellen 0.80
bei mir getestet, im Verdacht, dass das von Hannes beobachtete
Problem etwas mit Aenderungen in der Firmware zutun hat.

Funktioniert allerdings weiter wie gehabt bei mir.  Ich tappe
auch ziemlich im Dunkeln, woran es bei Hannes liegen kann.

Daher mal frage an alle die es testen koennen:   Funktioniert es
bei euch korrekt?

@Hannes/demofreak:
Kannst Du mir ein Log der RS232 Ausgaben vom Oszi zukommen lassen?
(also stty ttyS0 115200 raw, cat /dev/ttyS0 > log,
Quick-Print->Save to PGM, warten bis Oszi wieder reagiert
und CTRL-C zum beenden von cat).
Dann koennte man eine Seite schonmal ausschlieszen.

UPDATE:  Ich hab' gerade mal frisch FW in RAM eingespielt,
keine Veraenderungen an Schaltern, keine Drehgeber bewegt
und auch kein Default-Setup vorgenommen und direkt Screenshot,
und das Oszi schreibt wild komische Speicherinhalte raus mit
Textausgaben aus dem Programmcode.
Ergab 180984 Bytes (!) (statt 60-65K).

Das ganze durch das C-Programm gejagt, und siehe da, es
sieht erschreckend aehnlich zu Hannes Ausgabe aus.

D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
usw. und nochmal Screenshot testen.

Den Effekt verstehe ich nicht so ganz, wo doch egtl. der RAM-Inhalt
ueberschrieben wird.  @Hayo oder jemand anderes eine Idee?

Gruss,
Niklas

[Niklas O. (nevm)]

Mhm, nochmal kurz etwas im Firmware Code rumgeschaut:

In Hardware::Set_Vars_Default() werden zwar die von mir
verwendeten Konstanten mit den Speicheradressen der Planes
nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),
was mir doch spontan in Anbetracht der beobachteten
Effekte ziemlich wichtig erscheint nach dem Laden der FW
ins RAM und vor Screenshot ;)
(Installierte FW ist bei mir btw. die Original 1.4)

D.h., Frage an @Hayo damit wohl erledigt.

Mehr bzgl. ZModem und Messdaten vllt. heute Abend.

Niklas

[Johannes S. (demofreak)]

Niklas O. schrieb:
> D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
> usw. und nochmal Screenshot testen.

Hatte ich selbstverfreilich gemacht, direkt nach'm Boot unten rechts den 
Knopf "Default Setup" und danach oben einmal hin- und hergedreht. Hab 
ich jetzt eben nochmal gemacht, ohne Effekt.

/Hannes

[Niklas O. (nevm)]

Hallo Hannes,

mhm, komisch...

Lass mir dann doch mal die RS232 Ausgabe vom DSO beim
Screenshot zukommen.

Niklas

[Blue F. (blueflash)]

Bernd O. schrieb:
> super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was
> mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch
> mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ja, sowas ging mir auch schon durch den Kopf, allerdings ist das 
statisch nicht möglich, da ja die Frequenzachse je nach eingestellter 
Zeitbasis vatiiert. da müßte man also einen Refresh mit einbauen

> Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der
> FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024)
> eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und
> rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten
> der beiden Kanäle ging über zunächst einschalten (LED an) und dann
> wiederum ausschalten - dann waren sowohl die LED aus als auch die
> Anzeige des Kanals auf dem Monitor aus.

Danke für den Tip, ich habe alle Tests nur auf dem Zweikanalgerät 
gemacht weil es den leiseren Lüfter hat. Daher sind mir diese 
Eigenheiten noch nicht aufgefallen.

> Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert
> liegt an der fehlenden Anpassung an das neue Grid - oder?

Ja so ist es, da hab ich bis jetzt auch nichts geändert oder getestet. 
Stefan hatte sich das mal angesehen und war eher nicht so begeistert...

> Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin
> (vermutlich noch von der Welec-FW her): "Frequency" heißt dort
> "Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme
> - dafür aber auch in wenigen Sekunden gefixt :-)

Kann ich ich mal fixen für die nächste Beta.

> Super Arbeit - ist schön zu sehen, wie immer mehr geht!
>
> Gruß,
> Bernd

Danke,

Hayo

[Johannes S. (demofreak)]

Da ist definitiv noch was krumm.

Wollte direkt nach dem Erstellen des obigen Screenshots nochmal ein Log 
anfertigen, allerdings hat sich das Oszi nach Drücken von "Save to PGM" 
dann aufgehängt. Also rebootet und nochmal versucht, Log zu schreiben.
Dabei wuchs die Logdatei auf über 300kb an, hab das dann ebenfalls 
abgebrochen. Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und 
unten links war ein Softbutton "Cancel" zu sehen, als ich den gedrückt 
habe, bin ich im Quickmeasure gelandet (Cursor sichtbar und unten die 
Einblendung der Messwerte).
Also nochmals rebootet und wieder versucht, Log zu schreiben. Das hab 
ich dann ebenfalls bei reichlich 300kb abgebrochen und hier mal 
angehängt. Das Oszi reagiert nicht, komischerweise war Triggerung auf 
einmal auf PW statt auf Edge, das muss sich im Verlauf des 
Datentransfers irgendwie geändert haben. Musste also wieder rebooten.

Hab jetzt dreimal "Save to PGM" gedrückt, ohne auf der Rechnerseite das 
cat zum Logschreiben zu starten, dabei hängt sich das Oszi nicht auf.

[...]

Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt. 
Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht 
denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine 
Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim 
Rumdrücken auf dem Oszi mehrmals plötzlich im Quickmeasure-Menü 
gelandet, Math hat sich lustig ein- und wieder ausgeschaltet und auch 
die Triggerung war ab und an auf PW. Wenn cat nicht läuft, passiert 
sowas (natürlich) nicht.

Hat cat ein Echo?

/Han-"Der Ratlose"-nes

[Blue F. (blueflash)]

Niklas O. schrieb:

> In Hardware::Set_Vars_Default() werden zwar die von mir
> verwendeten Konstanten mit den Speicheradressen der Planes
> nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),

Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz 
Bescheid sagen damit ich das einbauen kann.

Hayo

[Blue F. (blueflash)]

@Hannes

Das hört sich für mich definitiv danach an, dass Daten in die Serielle 
Schnittstelle (Richtung DSO) geschrieben werden. Denn was Du da 
beschreibst ist genau das was man sonst via Terminal und Tastatur 
fernsteuern kann.

Ansonsten hat es sich schon des Öfteren bei unerklärlichen 
Merkwürdigkeiten bewährt einen frischen Flashdump einzuspielen.

Gruß Hayo

[Günter J. (gjung)]

Johannes Studt schrieb:
> Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt.
> Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht
> denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine
> Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim

ist da irgentwo noch das Echo eingeschaltet ?

Gruß,
Günter

[Johannes S. (demofreak)]

Dass sich das so anhört, als wenn Daten in die serielle Schnittstelle 
geschrieben werden, ist mir klar. :D Und welches Echo soll wo 
angeschalten sein? Ich verwende cat, dass das echot, wäre mir neu.

stty -F /dev/ttyUSB0 raw 115200
cat /dev/ttyUSB0 > log

Desterwegen bin ich ja ratlos. ;)

Hab vorhin einen weiteren Logversuch bei ca. 300kb Dateigröße 
abgebrochen (das Oszi war noch nicht fertig, sprich: reagierte noch 
nicht) und einfach nicht weiter hingeschaut. Ein oder zwei Minuten 
später stand das Oszi wieder im Quickmeasure. :D

Es lebt.

/Hannes

[Günter J. (gjung)]

Johannes Studt schrieb:
> stty -F /dev/ttyUSB0 raw 115200

ergänze das mal:
  stty -F /dev/ttyUSB0 raw -echo 115200

Gruß,
Günter

[Niklas O. (nevm)]

Hallo Hannes,

Dein Log sieht so aus als haette das DSO wie in einer
Endlosschleife immer und immer wieder Screenshots auf
RS232 ausgegeben.

Wenn ich hergehe, und den ersten aus der Log-Datei
wegwerfe, erhalte ich einen korrekten Screenshot
(siehe Anhang).

D.h.:

$ ./w2000a-screenshot < logalt
[..]
* Total bytes transferred: 59326
[..]
$ dd if=logalt of=logalt2 bs=1 skip=59326
[..]
$ ./w2000a-screenshot < logalt2
[..]
* Total bytes transferred: 61556
[..]

(Und das ist der angehaengte Screenshot als .png.
Genau so kann auch verfahren werden um die weiteren
zu extrahieren.)

Wenn man sich die Logdatei im (Hex)-Editor anschaut,
sieht man auch warum da der erste Screenshot bei
Dir kaputt ist.  Nach dem Start-Marker S 0xFF kommen
zwei vmtl. gueltige Bytes und dann die Textausgabe
einer Test-Funktion, gefolgt vom Rest des Screenshots.

Warum die da erscheint/erscheinen kann hab' ich noch
nicht geschaut, vmtl. aus einer ISR heraus.

---

Bzgl. "Oszi aufhaengen" gehe ich daher auch davon aus
das es damit beschaeftigt ist auf RS232 auszugeben.

Da dies nicht passiert wenn kein Programm die Schnittstelle
ausliest deutet tatsaechlich darauf hin, dass da irgendwas
"geschrieben" wird.  Aber cat kann es nicht sein, stdout
und stderr waeren ja die Konsole und nicht /dev/ttyS0.

Auch das unmotivierte Rumspringen in den Menues deutet
darauf hin, denn man kann ueber RS232 das Oszi fernsteuern.
(1-6 sind die Soft-Buttons, i,j,k,l sind die Kanaele usw. usf.)

Ich kann nur mutmaszen, wuerde aber auf falsche Konfiguration
des ttys tippen.  Schau mal nach ob das bei Dir anders aussieht:

$ stty -F /dev/ttyUSB0
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon
$ stty -g -F /dev/ttyUSB0
0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

> Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und
> unten links war ein Softbutton "Cancel" zu sehen [..]

Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
aufrufe.

---

@alle:
Haben noch andere hier Probleme mit der Screenshot-Funktion?

Niklas

[Niklas O. (nevm)]

Hallo nochmal,

ich hab' leider Eure Nachrichten in der Zwischenzeit
erst jetzt gesehen.

Das echo wie Guenter und Hayo vermuten wird's wohl sein.

@Hayo:
> Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz
> Bescheid sagen damit ich das einbauen kann.

Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
das am sinnvollsten anstelle.

Niklas

[Günter J. (gjung)]

Niklas O. schrieb:
>

  $ stty -F /dev/ttyUSB0
  speed 115200 baud; line = 0;
  min = 1; time = 0;
  -brkint -icrnl -imaxbel
  -opost
  -isig -icanon
  $ stty -g -F /dev/ttyUSB0
  0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
>

das ist genau die raw Einstellung und da ist echo noch an,
d.h. der tty-Treiber echo(ed) einkommende Zeichen,
deshalb mein Vorschlag noch ein -echo beim stty Befehl anzuhängen.

Gruß,
Günter

[Johannes S. (demofreak)]

Kaum macht man es richtig, geht es plötzlich. Komisch. :D

@Günter: danke, wieder was gelernt. Das -echo hat's gebracht.

/Hannes

[Johannes S. (demofreak)]

Niklas O. schrieb:
> Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
> aufrufe.

Ah, guter Hinweis. Das könnt ich sicher mit abfangen bzw. zumindestens 
versuchen, herauszubekommen, ob ich ins Menü oder wirklich in den 
GERMS-Monitor "reingucke".

Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...? 
grübel
Ich werd echt alt.

/Hannes

[Niklas O. (nevm)]

Hallo Guenter,

Du hast absolut recht.

Ich nehme jetzt stark an, dass der Effekt den ich heute Morgen beim
eiligen Reproduzier-Versuch hatte genau darauf zurueckzufuehren ist,
ich hab' naemlich das ganze samt Dongle auch am Laptop getestet...

Niklas

[Blue F. (blueflash)]

Niklas O. schrieb:

> Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
> ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
> im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
> das am sinnvollsten anstelle.
>
> Niklas

Jupp, das machst Du in flash_t.cpp:

- Funktion AMDFlash::Write_Config_Flash() Zeile 1408 schreibt Daten in 
den Konfigbereich. Da sind noch einige Plätze frei von buf[268] bis 
buf[299]. Da könntest Du Dir einen von greifen.

- Funktion AMDFlash::Read_Config_Flash() Zeile 1800 liest die Daten 
wieder ein.

Da ich mal annehme, das Du nicht jedesmal den gesamten Konfigbereich 
schreiben und lesen willst, könntest Du die Funktionen einfach als 
Vorlage für eigene Routinen nehmen mit denen Du dann Deine Daten ins 
Flash schreibst und sie wieder ausliest.

Gruß Hayo

[Cra Z. (crazor)]

Johannes Studt schrieb:
> Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...?

Ja, bitte beim Dumping des Flashes einen Plausibilitätscheck einbauen: 
Falls die Anzahl der Zeichen in einer Zeile nicht stimmt (zu viele oder 
zu wenige), die Zeile erneut abfragen.
Ich hatte ja schon festgestellt, dass der GERMSmonitor leider keine 
Prüfsumme ausspuckt, aber mein konkretes Problem ist ja nicht die 
Verfälschung, sondern nur das Verschlucken oder Verdoppeln von Zeichen. 
Schade, dass nichtmal ein Parity-Bit verwendet wird.

> Ich werd echt alt.

Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein 
=)


@Hayo und co, bzgl. Flash:

Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das 
FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE 
Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn 
man auf Default Setup geht oder deine Firmware einspielt oder was auch 
immer. Falls das nicht der Fall ist, sollten wir uns bezeiten schonmal 
einen Up- und Downgrade-Weg zwischen deiner und unserer Firmware 
überlegen.

[Blue F. (blueflash)]

Daniel H. schrieb:
> Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein

Genau meine Taktik!


> @Hayo und co, bzgl. Flash:
>
> Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das
> FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE
> Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn
> man auf Default Setup geht oder deine Firmware einspielt oder was auch
> immer.

- wenn eine neue Firmware eingespielt wird, dann wird auch nur der
  Progrmmbereich beschrieben. Alle anderen Bereiche bleiben unberührt.

- bei Default Setup wird überhaupt nicht auf den Flashspeicher
  zugegriffen, weder lesend noch schreibend, sondern es werden nur
  hart codierte Werte geladen.

- Der Flashspeicher wird eigentlich überhaupt nicht initialisiert.
  Es werden lediglich einige Konfigwerte hineingeschrieben bzw.
  ausgelesen. Desweiteren werden einige Bitmaps beim Start geladen.
  Es können Signal im Speicher abgelegt werden, das wars auch schon.

Gruß Hayo

[Cra Z. (crazor)]

Okay, aber ich gehe eben von dem Fall aus, dass der Flash komplett von 
uns verwurstet wurde und jemand nun zurück zu deinem Branch wechseln 
will. Wir werden mit Sicherheit nicht die Config-Speicherbereiche 
unangefasst lassen (können|wollen), daher meine Anfrage was passiert, 
wenn dort "Müll" steht (oder Nullen oder so).

[Blue F. (blueflash)]

Dann startet das DSO erstmal völlig undefiniert. Im ungünstigsten Fall 
hängt es sich auf -aarrgh, ansonsten hilft Default Setup und einmal an 
der Timebase drehen, dann ist der Konfigbereich wieder initialisiert. 
Das gilt allerdings nicht für den Bereich in dem die Bitmaps abgelegt 
sind, die lassen sich nur durch das Einspielen eines Flashdumps wieder 
restaurieren.

Gruß Hayo

[Stefan (Gast)]

Hallo,

FFT funktioniert wunderbar. Wenn dann noch die Beschriftung kommt und 
evtl. ein Cursor ist es perfekt.

Hab heute was gesehen, was ich auch haben möchte ;-) Der Prof. hat sich 
letzten Signalverlauf gespeichert und im Hintergrund zum aktuellen 
Signal eingeblendet. Sehr praktisch, wenn man eine Veränderung 
visualisieren möchte. Hoffentlich reicht der Speicher dafür noch g

Gruß,
Stefan

[Blue F. (blueflash)]

Das hört sich gut an - gleich in die Wishlist eintragen!

Hayo

[Kurt B. (kurt)]

Hallo Niklas,
mach die Dateinamen nicht zu lang. 8.3 muss reichen.

Hast du brauchbare und verständliche Infos zum ZMODEM?

Gute Arbeit!

Mfg,
Kurt

[elgodil (Gast)]

für Telix unter DRDOS??  ;-))

[Kurt B. (kurt)]

Nö, für den USB-Host oder das speichern auf SD-Karte. Viele fertige 
Routinen mögen nur die kurzen Namen.

[Blue F. (blueflash)]

@Niklas

Nach Deinem Tip für die stty-Umleitung hat es dann auch bei mir 
geklappt. Sehr praktisch. Ich mache damit gerade die FFT-Doku.

Prima Arbeit!

Hayo

[Niklas O. (nevm)]

Hallo Kurt,

> Hast du brauchbare und verständliche Infos zum ZMODEM?

ich schaetze mal Du spielst auf die IMHO nicht sonderlich
gute Originalbeschreibung von Forsberg an:
http://pauillac.inria.fr/~doligez/zmodem/zmodem.txt
(was anderes habe ich auch nicht gefunden)

Wenn man sich dazu vllt. noch ein paar fertige Implementationen
anschaut (andere als (l)rzsz) blickt man dann schon durch.

Gruss,
Niklas

[Roberto (Gast)]

Hallo
Habe die 0.80 probiert.
Funktioniert sehr gut :-) Auch das FFT :-)-- > Gratuliere!!
(Freue mich schon auf die Doku dazu :-) )
Was mir so beim Testen aufgefallen ist:
Das 1kHz Testsignal schaut mit 200-100ms/Dif fast genau so aus wie bei 
1ms/Dif. :-(
Bei einem Analogen Osci würde man bei 100ms/Dif nur einen großen Balken 
sehen...
Entsteht die falsche Anzeige durch das abtasten der ADC? Ist das 
DSO-bedingt?
Bei anderen DSO auch so?
Könnte man das Rechnerisch irgendwie besser auswerten?

l.G. Roberto ( W2024A)

[Bruno W. (brunowe)]

Hallo,

ich teste gerade mit der 0.75 und auch da ist ein Fehler in der 
Zeitbasis, so wie Roberto es beschrieben hat.
Beim Test mit dem 1kHz Testsignal ergibt sich bei mir folgendes Bild:
Mit den Timebases bis 20ms/Div ist alles i.O. - Die Anzahl der 
dargestellten Schwingungen stimmt mit Periodendauer des Signals überein.
* Bei 50ms/Div wird mir eine Periodendauer von 250ms suggeriert- eine
  Periode geht über 5 Div!
* Bei 100ms/Div eine Periodendauer von 50ms.
* Bei 200ms/Div wieder eine Periodendauer von 250ms.
Bei noch langsameren Timebases zieht sich der Fehler konsequent weiter 
durch.

Einmal abgesehen davon, dass eine Darstellung mit TB > 20ms/Div bei 
unserer Auflösung nicht möglich ist (weniger Pixel zur Darstellung als 
Schwingungen des Signals), so liegt wohl doch irgendwo noch ein 
Berechnungsfehler bei den langsamen TB vor.

Gruß, brunowe

[Blue F. (blueflash)]

@Roberto + Bruno

Danke für den Hinweis. Das muß ich mal ausprobieren. Ich gebe zu, dass 
die langsameren Zeitbasen nicht so oft zum Einsatz kommen und daher 
Fehler auch nicht so schnell auffallen.

Gruß Hayo

[Blue F. (blueflash)]

So, dafür hier etwas Lesestoff.

Ich weiß, dass viele von Euch mit dem Thema vertraut sind, aber es gibt 
wohl auch noch einige die sich damit noch nicht so beschäftigt haben 
oder bei denen es schon länger her ist. So oder so ist es aber wohl für 
alle ganz interessant die Theorie mal am eigenen W20xxA 
nachzuvollziehen.

Leider ist das Ganze doch etwas umfangreicher geworden, so dass ich 
erstmal nur eine deutsche Version fertiggestellt habe.

Sollte ich mich unverständlich ausgedrückt oder was falsches geschrieben 
haben - nur keine Hemmungen, immer raus damit.

Viel Spaß beim Lesen und Ausprobieren

Hayo

[Blue F. (blueflash)]

Oh,

hab schon einen Fehler entdeckt! Auf Seite 8 ist natürlich das Doppelte 
von 24,414 nicht 48,414 sondern 48,828. Ich hoffe Ihr könnt damit leben.

Hayo

[Kurt B. (kurt)]

Das klappt doch schon sehr gut! Die Cursor sind noch in Arbeit?

[Niklas O. (nevm)]

Hallo,

kleines Update mal von mir:  Stellt sich raus, dass meine
schnelle Idee vom Montag mit dem ersetzen der ISR fuer
den UART (Hardware::ISR_UART()) so nicht funktioniert.

Liegt daran wie die Original ISR in der Firmware benutzt
wird:  Zeichen holen, Zeichen in Wust von if-Abfragen
in MenuKey Wert umsetzen, dann Buttonhandler() mit
MenuKey aufrufen.

Hardware::Buttonhandler() macht dann wiederum nen
select/switch-case-Konstrukt ueber MenuKey und ruft
evtl. darin noch weitere Funktionen auf.

Falls der Groschen noch nicht gefallen ist:  Die ISR
ist zu diesem Zeitpunkt immer noch nicht verlassen!

..und sie wird natuerlich auch so lange sie nicht
fertig ist nicht nochmal aufgerufen.

Das ist, gelinde gesagt, nicht die uebliche Art,
wie man ISRs benutzt.  Da ich nicht wirklich Lust
hatte den bestehenden Code weiter als noetig zu
lesen, ist mir das auch erst aufgefallen, als ich
mich wunderte, warum meine ISR nie zum Zuge kam.

Eine Loesung ohne den Original-ISR umzustricken
sehe ich im Moment nicht.  Da es, wenn ich das
richtig sehe, in TomCat.cpp eine Main-Loop gibt,
waere es das einfachste, wenn im ISR nur eine
Variable geschrieben wird und dann ein Handler
die Eingabe interpretiert (wie das mit mehreren
zwischenzeitlich eingegangen Eingaben und
Prioritaet aussehen sollte habe ich noch nicht
ueberlegt).

Um das gewohnte alte Verhalten beizubehalten
koennte man alle Interrupts fuer die Laufzeit
der jeweiligen Funktion deaktivieren.

Bevor ich jedoch da einen chirurgischen Eingriff
beginne moechte ich noch Eure Meinung und Ideen
einholen.

@Hayo:
Hab' mal kurz durchgeblaetter, schoene Anleitung!

Gruss,
Niklas

[Blue F. (blueflash)]

Die nächsten Punkte auf der Roadmap sind:

- FFT Feinschliff - da warte ich mal auf Rückmeldungen
- Cursorfunktion an das neue Grid anpassen
- Cursor für die FFT nachrüsten
- Quick Measure komplett überarbeiten

Hayo

[Blue F. (blueflash)]

@Niklas

Ich gebe Dir Recht, die Implementierung der ISR ist recht 
gewöhnungsbedürftig. Da es so viele andere Baustellen gab hatte ich mich 
darauf beschränkt den Buttonhandler (es gab früher nur einen einzigen!) 
aufzuteilen in einen Haupt-Buttonhandler und jeweils einen für die 
Funktionstasten. Dadurch kann man sich immerhin schon mal besser 
orientieren. Technisch gesehen hat das natürlich nichts geändert.

D.h. auch hier besteht noch Optimierungsbedarf, allerdings schien mir 
das bislang nicht so dringlich wie die anderen Themen.

Hayo

[Stefan (Gast)]

Hallo Hayo,

Quick Measurement ist fast gefixt. Fehlt noch eine Kleinigkeit, dann 
müsste es soweit wieder klappen.

Stefan

[Blue F. (blueflash)]

Ach ja noch einer:

Das mit der ISR hatte der Programmierer auch beim Rollmode so gemacht - 
weswegen das wohl auch nicht funktioniert hat. Ich konnte es zuerst gar 
nicht glauben als das erste Mal gesehen hab dass die komplette Logik im 
ISR des Timers abgefackelt wurde. Bei meiner Implementierung stehen 3 
Zeilen im ISR - das war's.

Hayo

[Blue F. (blueflash)]

@Stefan

Cool! Ich hätte gedacht dass erst die Cursor geradegebogen werden müssen
bevor da ein sinnvolles Vorgehen möglich ist.

Hayo

[Stefan (Gast)]

Jo, die Cursor zicken gerade etwas. Die waagerechten Cursor sind OK. Nur 
die senkrechten zicken gerade. Haben einen minimalen Versatz.

[Niklas O. (nevm)]

Hallo,

als Ergaenzung noch, da das vllt. nicht deutlich
rueber gekommen ist:

ZModem geht aufgrund des Protokolls und der noch
fehlenden Moeglichkeit, (alle) vom Terminalprogramm
ueber RS232 reinkommenden Zeichen zu lesen, erstmal
ohne weiteres nicht.


Messdaten einfach rauswerfen geht natuerlich trotzdem,
analog wie dies beim Screenshot gemacht wird.

Diesbzgl. hatte ich mir schon ueberlegt, die Parameter,
also Kanal, Zeitbasis usw., in Plaintext gefolgt von
den Samples, je als Byte, zu uebertragen und wieder mit
einem Programm fertig interpoliert in CSV oder gnuplot
Script zu wandeln.

Um ein paar zu uebertragende Bytes zu sparen koennte
man vornehmlich Deltas zwischen zwei Samples uebertragen,
z.B. 4 Bit breit.  Inwieweit sich das ueberhaupt lohnt
muesste ich mal austesten -- in Anbetracht der maximal
16K*4 Samples die anfallen.

Meine Frage waere dann auch jetzt, was ihr Euch fuer
Ausgabeformate wuenschen wuerdet und ob das
Vorgehen insgesamt so in Ordnung ist.


Mein Plan sieht also dann so aus:
- Messdaten rausschreiben und Ausleseprogramm
- Screenshotprogramm: BMP-Dateien schreiben
  (evtl. auch PNG, falls ich eine einfache Moeglichkeit finde)
- Ausleseprogramme auch fuer Windows und fertig kompiliert
- Firmware anpassen damit ZModem geht

(in keiner festen Reihenfolge, vmtl. nun ZModem zuletzt)

Niklas

[Kurt B. (kurt)]

Das Ausleseprogramm für Windows bastele ich gerade. Ist nicht schön, 
funktioniert aber und wird heute hoffentlich noch fertig.

[Blue F. (blueflash)]

@Bruno + Roberto

Die langsamen Zeitbasen sind ok. Habe gerade noch mal geprüft. Was Ihr 
da gesehen habt ist Aliasing in seiner reinsten Form, d.h. 
Scheinfrequenzen pur (siehe meine Veröffentlichung von heute). Wenn Ihr 
in den Programming-Maps in der Timebase-Tabelle nachseht werdet Ihr 
fündig.

Die kleinste Zeitbasis mit der ein 1 KHz Signal noch dargestellt werden 
kann ist 20ms/div. Bei den langsameren Zeitbasen wird das Abtasttheorem 
verletzt (insofern hat Roberto schon Recht, dass es sich um eine 
DSO-spezifische Sache handelt). Und zwar müßt Ihr im Zeitbereich immer 
berücksichtigen das zu der angezeigten Abtastrate noch der 
Timebasefaktor kommt um das dass Signal reduziert wird.

Die tatsächliche Abtastrate ist dann also angezeigte Sa/s durch 
Timefaktor. Bei 50 ms/div liegt die Abtastrate aber nur noch bei 5KSa/s 
durch 5 = 1KSa/s also halb so viel wie eigentlich minimal nötig.

Bei den noch langsameren TB wird das natürlich noch extremer, so dass 
täuschend echte Signale mit einer völlig anderen TB angezeigt werden. 
Ihr habt ein wirklich schönes Beispiel dafür gefunden ;-)

Das Ganze gilt übrigens nicht für die FFT. Hier bleibt der 
Timebasefaktor unberücksichtigt, so dass nur die tatsächlich angezeigte 
TB maßgeblich ist.

Gruß Hayo

[Bruno W. (brunowe)]

Hallo Hayo,

hab deine o.a. Roadmap gelesen. Du vergisst nicht das Fixing des zeitl. 
Versatz zwischen den Kanälen?

gruß, brunowe

[Blue F. (blueflash)]

@Bruno,

nein, das habe ich auf dem Zettel. Allerdings sind nicht allzuviele 
Rückmeldungen gekommen verglichen mit den Downloadanzeigen wenn hier was 
veröffentlicht wird.

Die Korrektur ist eigentlich auch nicht sonderlich dramatisch, ich 
wollte sie nur gleich in die C-Routinen von Guido mit einfließen lassen. 
Da weiß ich aber nicht ab wann diese tatsächlich die Assemblerroutinen 
ersetzen werden.

Ich könnte das natürlich, wenn starker Bedarf besteht, auch vorher 
anders implementieren.


@Bernd

Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke 
nochmal für den Hinweis

Hayo

[Stefan (Gast)]

Also QuickMeasurment hat gerade in Grundzügen funktioniert. Auch die 
Cursor. Average, Pk-to-Pk und Frequenzbestimmung haben funktioniert. 
Damit müsste eigentlich auch der Rest gehen. Hat funktioniert, weil ich 
das ganze noch in eine Schleife für alle 4 Kanäle packe und dadurch 
einige Änderungen nötig sind. Weiß nicht, obs heute noch was wird. 
Schaut aber gut aus ;-)

[Bruno W. (brunowe)]

Hallo Hayo,

ja ok, ich hatte die blöden Timebase- Faktoren in meiner geistigen 
Rechnung nicht berücksichtigt! Daran sieht man, wie ungünstig die 
Sample-Raten in den einzelnen TB's gewählt ist. Der geringe Prozentsatz 
mit dem der zur Verfügung stehende Samplespeicher (16384 Samples) 
ausgenutzt wird, ist ein anderes Zeichen dafür.
Vor dieser TB- Anpassung standen wir im VHDL Design auch vor Kurzem ;-).
Tja, das Aliasing lässt sich leider nicht vermeiden, ein typisches ADC 
Problem.
Die Korrektur des zeitl. Versatz kann aus meiner Sicht noch warten, 
sollte halt nicht in Vergessenheit geraten. Schade das es keine To-Do- 
und Bug- list mit öffentlicher Möglichkeit von Ergänzungen gibt- sieht 
man einmal von der Wishlist unter Sourceforge ab.

Gruß, brunowe

[Kurt B. (kurt)]

Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.

Erklärung steht in der liesmich.txt.

Ich bräuchte eine Rückmeldung, ob die Farben korrekt wiedergegeben 
werden.
Wie gesagt, meine Ergänzungen sind etwas buggy und enthalten schwere 
Designfehler aber das Prog verursacht wenigstens keinen Bluescreen. ;-)

[Blue F. (blueflash)]

@Kurt

Prima, leider komme ich erst übermorgen zum Testen da ich bis dahin 
etwas beruflich eingespannt bin. Hab's mir aber schon mal runtergezogen.


@Bruno

Ja das hatte ich vergessen auf meiner ToDo Liste aufzuschreiben, die 
Timebasesteuerung wollte ich mal komplett umstellen. Ich sehe nämlich 
keinen vernünftigen Grund, warum die Samlerate nicht besser genutzt 
werden sollte. Keine Ahnung was sich der Programmierer dabei gedacht 
hat. Zuerst vermutete ich dass da irgendein tieferer Sinn hintersteckt, 
den ich nicht durchschaue, aber mittlerweile nach längerem Umgang mit 
dem Coding weiß ich dass es wohl eher nicht so ist.

Gruß Hayo

[Stefan E. (stefan_e)]

So Hayo,

habe dir unter SF meine aktuellen Änderungen für QuickMeasurment 
eingespielt. Viel Spass beim mergen. ;-) War doch sehr umfangreich. 
Dafür sind aber auch die 4 Kanäle in EINER Schleife zusammengefasst und 
nicht wie vorher jeder einzeln. Ich bin zufrieden ;-)

Bei mir geht derzeit auf beiden Kanälen (theoretisch auf allen 4, ich 
hab aber blos zwei, also fleißig Bericht erstatten) das Messen von 
Average, Duty Cycle, FallTime, Frequency, Maximum, Minumum, Peak-Peak, 
Rise-Time, +Width, -Width. Die Auswertung von einem Summen- oder 
Differenzsignal geht noch nicht.

Ich kenn mich mit dem Ändern der Menüsteuerung nicht aus. Aber wäre es 
möglich, die 3 Felder einzeln zu löschen?. Außerdem besteht prinzipiell 
jetzt die Möglichkeit die Genauigkeit einzustellen. (Auf kosten der 
Geschwindigkeit) Könnte man evtl. über das Menü ein und ausschalten.

Gruß,

Stefan

[Stefan E. (stefan_e)]

Und für alle andern auch noch die Ram-Datei

[Kurt B. (kurt)]

Nochmal @Niklas:
ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch 
ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze 
Pause einzulegen.

Zum Zielsystem:
Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die 
Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.

Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von 
einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte 
Ausgabe möglich?

Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den 
wichtigsten Parametern als txt File welches später mit einem PC Programm 
zu einem großen Bild zusammengesetzt werden kann.

PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet 
werden.

Tipps von einem Ahnungslosen:
BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte 
Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

[Bernd O. (bitshifter)]

Hayo W. schrieb:
> @Bernd
>
> Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke
> nochmal für den Hinweis
Super! Ich hatte gestern Abend noch etwas gespielt und gemerkt, dass der 
Fehler nicht immer auftritt und schon überlegt was zuvor anders war...

Beim Trigger bzw. seiner Darstellung habe ich noch ein paar Dinge 
bemerkt, die man verbessern könnte:

1) Wenn man im "Aquire"-Menü (*) zwischen Normal und Averaging wechselt 
wird der Averaging-Modus wird mit einem Durchmessersymbol dargestellt. 
Dieses Symbol verschiebt den Triggerpfeil um ca. 1/2 Symbolbreite nach 
unten (ca. 10 % eines Div). Da die numerische Anzeige rechts oben 
unverändert bleibt gehe ich davon aus, dass es nur ein 
Darstellungsproblem ist.

(*) Richtig wäre "Acquire" - aber den Druck des Bedienpanels wird man 
wohl nicht per SW ändern können ;-)

2) Die Pfeilspitze des Triggersymbols ist auch im Normal-Mode um ca. 
zwei Pixel zu tief. Bei beispielsweise 1 V/Div liegt der Trigger erst 
bei 1.04 V optisch auf der 1 V Linie.
(Ich weiß, ist pedantisch - aber so etwas sticht mir leider direkt ins 
Auge).

3) Die numerische Anzeige des Triggerlevels ist bei 2 V/Div manchmal 
falsch:

Ausgangssituation: 1 V/Div mit Triggerlevel 500 mV. Beim Umschalten auf 
2V/Div wird rechts oben ein Triggerlevel von "1.00 mV" angezeigt. 
Optisch per Pfeil dargestellt sind 1 V (also Volt statt Millivolt). Wenn 
man auf 5V/Div weiterschaltet wird der Level korrekt mit "2.50 V" 
angezeigt. Wenn man nun wieder auf 2 V/Div zurückschaltet, dann wird 
auch in diesem Bereich nun korrekterweise "1.0 V" angezeigt.
=> Es macht also für die Anzeige des Triggerlevels einen Unterschied, ob 
man von "oben" oder von "unten" in den 2V/Div Bereich kommt. Die 
restlichen Bereiche waren soweit ich gesehen habe O.K.

4) Wurde so weit ich weiß schon einmal angemerkt und könnte auch ein 
Feature und kein Bug sein ;-):
Intuitiv hätte ich erwartet, dass ein eingestellter Triggerlevel von 
beispielsweise 500 mV erhalten bleibt wenn ich den V/Div-Bereich 
wechsle. Im Normal-Mode ist es für mich gewöhnungsbedürftig, wenn man 
die Y-Auflösung ändert und erst mal "blind" ist bis man am Trigger 
gedreht (oder in den Auto-Modus gewechselt) hat.

Freue mich schon auf die nächste FW.

Gruß,
Bernd

[Guido (Gast)]

Hallo,

da ist ja eine Menge aufgelaufen. das macht Spaß!

@ niklas: Nach meiner Meinung reicht eine einfache binäre
Übertragung. Eventuell die Textübertragung konsequent als
Kommentar markieren (z.B. mit "#"), dann können zur besseren
Unterscheidung auch die Kanallisten durch kurze Kommentare
getrennt werden. Unsere Perl-Fans haben dann die Möglichkeit
alle denkbaren Filter zu implementieren.

@ Hayo: Zwei grundsätzliche Überlegungen.

1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
Nachteil erkennen, die Änderungen in Set_Switches sollten kein
Problem sein, nur die Grafik muss angepasst werden.

2.) Bei Timebase > 6 wird  nur jeder 4. Wert ausgewertet.
Wenn du eh an die Timebaseeinstellungen gehen möchtest,
solltet wir das gleich ändern. Dann werden unabhängig von
der Timebase immer 16k-Samples übertragen. Die Faktoren der
ProgrammingMaps werden dann vervierfacht, sonst ändert sich
nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
mit 16k-Samples ausgeführt werden kann, was nicht nur  die
zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
bringt,

Gruß, Guido

[Blue F. (blueflash)]

@Stefan

Super, ich werde mir das mal übermorgen ansehen. Grundsätzlich kann ich 
Dir das Menü beliebig einrichten, Du müßtest nur genau beschreiben wann 
was wo gesetzt oder gelöscht werden soll (welche Variablen und so).



@Bernd


Das nenne ich einen detailierten Fehlerbericht. Nicht übel. Etliche 
Punkte fallen derzeit allerdings unter die Kategorie "minor problems". 
Daher denke ich werden sie entweder mal so zwischendurch behoben (was 
bei mir des öfteren vorkommt), oder es wird etwas dauern da es immer 
noch einige größere Baustellen gibt. Auf jeden Fall danke für die 
Hinweise.

Gruß Hayo

[Niklas O. (nevm)]

Hallo Kurt,

> ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch
> ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze
> Pause einzulegen.

ZMODEM war ja nur dafuer gedacht um ein gaengiges Terminalprogramm
auf RS232 lauschen koennen zu lassen und automatisch Dateien vom
Oszi zu empfangen, ohne erstmal weitere Software zu installieren.
Mit XMODEM geht das leider nicht, weil da dummerweise im Protokoll
die Moeglichkeit fehlt auf Senderseite den Empfang direkt anzustoszen.

Mit dem XON/XOFF Software-Handshake geht es Dir primaer um die
Uebertragung an einen uC, oder?  Kann ich Dir einbauen, wie
beschrieben die UART ISR steht allerdings noch etwas im Weg.

> Zum Zielsystem:
> Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die
> Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.
>
> Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von
> einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte
> Ausgabe möglich?

Ja klar, das ist natuerlich moeglich.  Der Grund warum ich den Umweg
ueber die Planes mit RLE Kompression gegangen bin ist nur dass ich
dadurch auf ~15kB s/w und ~65kB Farbe komme (und mit minimalem
Programmcode).

Das DSO kann natuerlich auch gleich die Planes fertig ueberlagern
und eingefaerbt als PPM ausgeben, waeren auch nur geschaetzt nen
Dutzend Zeilen Code plus einige Konstanten mehr -- nur kaemen wir
da auf 640*480*3 = 900 kB. (Farbkomponenten kleiner als mit einem
Byte auszudruecken ist leider nicht spezifiziert bei PPM (setzt man
im Header < 255 muss man dennoch ein volles Byte ausschreiben pro 
Farbkomponente).)

Nehmen wir unkomprimiertes BMP mit 4 Bit Palette sind's noch ~150 kB.
Dazu kommt noch ein wenig Rechenzeit, Bufferung bei der Ausgabe fehlt
da auch noch...

Wenn Dir das nicht zu langsam ist ergaenze ich das gerne.  Kann
man ja so machen, dass das Ausgabeformat im Quick-Print Menue
und per RS232 fuer den Anwender/uC konfigurierbar ist.

> Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den
> wichtigsten Parametern als txt File welches später mit einem PC Programm
> zu einem großen Bild zusammengesetzt werden kann.

Mit txt File meinst Du also direkt Menschen-lesbar?  Auch kein
Problem, nur in welchem Format genau muesste man sich einigen.

> PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet
> werden.
>
> Tipps von einem Ahnungslosen:
> BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte
> Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

Ja, RLE geht optional.  Die Spec dazu hab' ich aber noch nicht
angeschaut.  Bei den Screenshots hatte ich schonmal verglichen und
Gimp erzeugte mir unter Verwendung einer Palette und Kompression
ein iirc. 48kB BMP File.  Da liege ich mit 65kB ziemlich gut dabei,
mit einem sehr simplen Algo wo sicher noch was rauzuholen waere.


Also, zusammenfassend:
 - fertiges PPM oder BMP (unkomprimiert erstmal) rausschreiben:
     kein Problem, nur wenige Zeilen zusaetzlicher Code plus
     gesteigerte Rechenlaufzeit
 - Software-Handshake mit Blockung:
     auch kein groszes Problem, beschriebene Problematik mit der
     jetzigen UART ISR steht nur bloed im Weg
 - Messdaten gleich fertig menschenlesbar raus:
     genauso, muessten wir uns nur auf ein Format einigen
     (z.B. CSV, welche Felder, Anordnung)


Mit Massenspeicher meinst Du sowas wie eine SD-Card, per SPI
angesprochen?  Das faende ich klasse.  Besonders wenn man dann
ein schoenes Gehaeuse dazu macht koennte das fast "nativ" zum
DSO gehoerend aussehen.

Gruss,
Niklas

[Kurt B. (kurt)]

Richtig, XON/XOFF für den µC. Brauchst du aber noch nicht einzubauen, 
wir brauchen erstmal ein richtiges Konzept.

Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen. 
Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es 
nicht werden.
Also müsste man im Oszi ein PNG oder JPG basteln.
Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Massenspeicher als SD-Karte oder mein Favorit der USB-Stick.
Ganz verrückte könnten die Daten per RFM12 Modul durch die Gegend 
funken. ;-)

Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt 
vom FPGA aus. Das lässt sich aber vorerst nicht nachrüsten, außerdem 
fehlen ja den 2-Kanalgeräten die 5? herausgeführten Pins am FPGA.

PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz 
drin.

[Roberto (Gast)]

Hallo Kurt
>Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.
Das Programm funktioniert bei mir.
(XP, W2024A, FW 0.80)
Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
Grösse der Dateien 901KB

Aber blöde Frage: Was kann ich jetzt mit den Files machen?
Kann es mit keinen meiner Programme öffnen ?
Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?

l.G. Roberto

[Niklas O. (nevm)]

Hallo Kurt,

> Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen.
> Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es
> nicht werden.

Theoretisch sollte es ja von der Schnittstelle her bei den 115200
Baud wesentlich schneller gehen (im Prinzip grob 10 Sekunden).
Wieviel Anteil da Rechenzeit hat und etwaiges Warten mangels
fehlender Bufferung habe ich nocht nicht genau geschaut.
Bufferung kaeme ohnehin bei ZMODEM wg. Blocking.

Rechenzeit scheint mir schon enorm zu sein.  Wobei ich vllt.
mal explizit sagen sollte, dass ich mich da nicht besonders
klever anstelle und jeden Pixel einzeln aus einer Speicherstelle
zurueck fuehre.  Das laesst sich mit einer Portion Bitmask
Voodoo sicher optimieren, uebersteigt jedoch derzeit meinen
Horizont (Hilfe wird dankend angenommen :)).

> Also müsste man im Oszi ein PNG oder JPG basteln.
> Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Ne die Seite kannte ich noch nicht, gerade kurz bissl rumgeklickt,
sieht nett aus.  Schaue ich spaeter mal genauer.

> Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt
> vom FPGA aus. [..]

Das waere natuerlich noch besser wenn ihr das hinbekommt.

> PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz
> drin.

Oh, noch besser :)

@Roberto:
> Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
> Grösse der Dateien 901KB

Ja das passt, bei S/W werden die 16 Planes direkt auf dem Oszi
kombiniert.  ~900KB passt auch, sind unkomprimierte 640x480
Pixel mit 24 Bit Farbtiefe.

> Aber blöde Frage: Was kann ich jetzt mit den Files machen?
> Kann es mit keinen meiner Programme öffnen ?

Ja, unter Windows ist PPM leider kein gaengiges Format, aber
fuer (ohnehin meist faule ;)) Programmierer ein extrem
einfach zu erstellendes Format.

Daher laengst meine Ansage fuer Windows-User auch BMP
zu generieren (was das naechst einfache Format waere ;)).

> Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?

Ja, natuerlich.  Steht auch schon auf meiner Agenda.

Kurt oeffnet die PPM mit Ifranview, iirc.  Gimp sollte auch gehen.
Wobei ich natuerlich jetzt niemanden dazu bringen will nur
deswegen zusaetzliche Software zu installieren.

BMP-Ausgabe wird wie gesagt sicher in Kuerze folgen.

Gruss,
Niklas

[Blue F. (blueflash)]

@Stefan

Nachdem ich jetzt eine halbe Stunde lang bei SFN rumgeklickt habe und in 
der Zeit nur zwei Sourcedateien geladen bekommen habe - kannst Du mir 
die Sourcen hier hochladen, ich hab keine Lust mehr mich damit weiter 
rumzuärgern. Das ist ja langsam und zäh wie Kaugummi mit dem Trac-Tool.

Gruß Hayo

[Stefan E. (stefan_e)]

Hallo Hayo,

kann ich machen. Allerdings erst heute Abend.

Gruß,
Stefan

[Michael W. (slackman)]

@Roberto & all,
ich werde mich um eine neue Win Applikation für das DSO kümmern (Anzeige 
und Steuerung des DSO), kann aber noch nicht sagen, unter welchem 
Framework. Lazarus vielleicht? Ist frei und auch für Linux/OSX 
verfügbar. Müsste mich aber erst einarbeiten.

Michel

[Niklas O. (nevm)]

Hallo,

so, ich hab' jetzt mal getestet wo da egtl. die Minute herkommt,
die so'n 65kB Dump braucht.

Erst einmal ist es kein Problem nur unter Verwendung von putchar()
da volle 10kB/s rauszuschoeffeln.  Das ist schonmal gut.

Nicht so gut ist aber, dass die grob restlichen 50 Sekunden
tatsaechlich voll und ganz in den Pixelschleifen verbracht
werden.  Dazu hab' ich nur die putchar() entfernt, RLE
wird weiter gemacht.  Auch bei B/W braucht das Oszi noch
fast 15 Sekunden nur dafuer.

NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...
Bislang vermutete ich verschenkte Zeit indem ich ungebuffert
rausschreibe, ist aber irrelevant...

Wenn man sich mein diff (aus den geposteten .tgz) nochmal
anschaut sieht man, dass da quasi "nix" passiert.  Natuerlich
ist wie in meinem letzten Posting gesagt die Pixelwandlung
nicht optimal, aber auch nicht so schlimm.

Damit dann gar PNG mit Deflate auf dem NiosII zu machen
koennen wir m.E. gleich mal komplett vergessen.

Sollten wir vllt. einfach die Speicherbereiche unveraendert
binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
sind, und alles auf dem Computer erledigen?
(den Code dafuer haben wir ja schon...)

Und auch Fragen an die Leute die schon laenger mit NiosII
und/oder der Firmware zutun haben:

- Wuerde es helfen das in Assembler zu schreiben?
- Ist da etwas was ich da mache auf NiosII besonders ineffizient?
- Andere Datentypen verwenden?

Gruss,
Niklas

[Michael W. (slackman)]

mal zum USB-BUS:
die UARTS des CY7C64713 können mit bis zu 230 KBaud kommunizieren. Gibt 
es das Board/die Firmware her? Aus irgendwelchen Dokus sehe ich, dass 
nur mit einem Viertel der möglichen Rate übertragen wird. Hier wäre noch 
Potential.

Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich 
möchte lieber den USB nutzen als die serielle Schnittstelle.

Vielleicht sollte man eine Möglichkeit bieten, den Firmwareupload via 
Auswahl in der Firmware (Menüpunkt) zu initiieren.

Wahrscheinlich ein wenig viel, oder ;-)
Neuer USB-Treiber, neue CY-Firmware, Anpassungen in der 
Scope-Firmware...

sorry

[Blue F. (blueflash)]

@Niklas

Das Schreiben in Assembler könnte evtl. was bringen, ist aber eigentlich 
kontraproduktiv, da wir uns bemühen etwas plattformunabhängiger zu 
werden und daher die Assemblerroutinen durch c-coding zu ersetzen

> NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...

So ist es. Bei dieser Variante wurde auch noch auf das 
Multiplikationsmodul verzichtet. D.h. bei der Optimierung auf 
Geschwindigkeit sollte man folgendes beachten:

- Floating Point Operationen -> ganz schlecht, möglichst umstricken
                                auf Integer

- Integer Multiplikationen -> möglichst vermeiden

- Integer Additionen -> sind ok

- Shift Operationen -> möglichst oft verwenden da erheblich schneller

- komplexe Bibliotheksfunktionen -> ganz schlecht, möglichst durch
                                    eigene optimierte Funktionen
                                    ersetzen.

- oder noch besser -> durch schnellen indizierten Tabellenzugriff
                      ersetzen

Gruß Hayo

[Falk W. (dl3daz)]

Nach längerer Zeit habe ich mal wieder eine FW....80 eingespielt und bin 
begeistert.

Niklas O. schrieb:
> Hallo,
...
> Sollten wir vllt. einfach die Speicherbereiche unveraendert
> binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
> sind, und alles auf dem Computer erledigen?
> (den Code dafuer haben wir ja schon...)

Ich hatte mir auch mal eine Erweiterung geschrieben, mit der ich die 
rohen ADC-Daten seriell ausgegeben habe (USB habe ich totgespielt).

Auf dem Display werden doch sowieso nur 512 Bytes angezeigt. Bei vier 
Kanälen sind das maximal 512*4=2048 Bytes.

Wenn man im Header die Einstellung überträgt (Menü, Timebase...) und 
dann 512 Bytes/Kanal, sollte das ordentlich flott werden. Die "hübsche" 
Darstellung kann dann der PC übernehmen.

Aber auch die vollen 16kB/Kanal machen maximal 64kB, also ca. 6s.

Wenn man den PC-Teil in Qt schreibt, kann der auf allen gängigen 
Betriebssystemen laufen.

Ich hatte das mal angefangen. Es müßten sämtliche Parameter per RS232 
einstellbar sein. Auf Kommando könnten die Daten einmal oder dauernd 
gesendet werden.

Wenn sich ein Qt-Spezialist fände, würde ich die HW-Schnittstelle PC- 
und Scope-seitig implementieren. Wenn nicht, würde ich eine Oberfläche 
basteln können. Schön wird das aber nicht ;-)

Falk
P.S.: Wie läßt sich USB wiederbeleben, wenn sie absolut nicht mehr 
ansprechbar ist? Ich hatte mit ein paar Cypress?-Tools herumgespielt...

[Niklas O. (nevm)]

Hallo,

@Hayo:
Tja, ich mache ja egtl. nix anderes als Integer Additionen, Shift
und paar Array-Zugriffe...  D.h., damit ist dann wohl Ende der
Fahnenstange, da von 50s auf humane 10s oder so zu kommen steht
wohl auszer Frage.

@Falk:
Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
angezeigten 512(*4) Werte reduzieren bei der Implementation
der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
dann beinahe in Realtime den Output anzeigen.

Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
einfach nachmalt. Dennoch ist es IMHO schoen, wenn man die Option
hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
Measurements.  Koennte man natuerlich auch nachmalen mit Programm,
aber warum alles doppelt.  Ich moechte auf die Screenshot-Funktion
zumindest nicht verzichten und sie hat mir lange gefehlt.

Niklas

[Niklas O. (nevm)]

Hallo Falk,

ich vergasz:
> [..] Es müßten sämtliche Parameter per RS232 einstellbar sein.
> [..] [HW-Schnittstelle PC- und Scope-seitig implementieren]

Ja alle Knoepfe sind wohl bereits auf RS232 gemappt.

Da ich ohnehin einen Eingriff an der Original UART ISR vornehmen
muss, sollten wir vllt. das (und die Routinen die da draenhaengen)
direkt mal aufraeumen und zusammen ein klares Interface
festschreiben.

Wenn jemand Material/Erfahrung zu Interfaces von anderen
professionelleren Scopes hat sollte er die dann einbringen.
Ich zumindest hab' da leider nichts vorzuweisen.

Niklas

[Blue F. (blueflash)]

Niklas O. schrieb:

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das sehe ich genauso. Insbesondere für dokumentarische Zwecke sehr 
praktisch wie man auch in meiner Anleitung sehen kann. Die Wartezeit von 
einer Minute kann ich dabei locker verschmerzen. Mit der Kamera war ich 
auch nicht schneller und hatte auch noch diverse Fehlversuche wegen 
Verwackelung und Fehlbelichtung.

Für die FFT-Doku habe ich die Screenshot-Funktion statt ins QP-Menü 
direkt auf den QP-Button gelegt und noch zusätzlich den Popuptimer für 
die Dauer des Screenshots blockiert.

Hintergrund: Mit der Implementierung in der Version 0.80 läßt sich kein 
geöffnetes Popupmenü blitzen und auf den Screenshots ist dann auch immer 
das QP-Menü zu sehen, was aber für Dokumentationszwecke oft nicht so 
günstig ist, da man ja auch die aktuellen Menü-Einstellungen 
dokumentieren möchte.

Ich habe mir schon einige Gedanken gemacht wie man das lösen kann, dass 
man trotzdem das QP-Menü zur Verfügung hat. Mal sehen...

Hat einer von Euch eine spontane Idee?

Hayo

[Falk W. (dl3daz)]

Niklas O. schrieb:
> Hallo,

> Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
> angezeigten 512(*4) Werte reduzieren bei der Implementation
> der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
> dann beinahe in Realtime den Output anzeigen.
>
> Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
> einfach nachmalt.

Mit den Rohdaten kann man aber noch viel mehr anstellen. Beispielsweise 
mathematische Funktionen, die man im Scope nicht machen kann.

> Dennoch ist es IMHO schoen, wenn man die Option
> hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
> Measurements.

Natürlich ist das prima, keine Frage. Nur hat man dann keine Daten mehr, 
sondern ein Bild.

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das geht mir nicht anders. Aber auch ein Dump der Daten ist praktisch 
und eigentlich mit "Dump to XLS" schon vorhanden. (Ich halte .xls für 
zwei/vier Spalten mit je 16.000 Zeilen für unsinnig. CSV reicht.)

Falk

[Guido (Gast)]

@ Hayo: QP-Button im Menu "scharfschalten", Einstellungen
nach Belieben und der nächste Druck auf QP macht die Hardcopy.
3. Druck auf QP: Menu erscheint wieder.

Sollte ohne großen Aufwand gehen.

Hast du mal meine 2 Fragen von gestern angedacht?

Gruß, Guido

[Roberto (Gast)]

Hallo
Habe jetzt einen Betrachter für  "ppm" gefunden.
http://www.fine-view.com/en/download.html
l.G. Roberto

[Blue F. (blueflash)]

@Guido

Ja, sorry hatte ich etwas verdrängt.

> 1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
> ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
> nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
> Nachteil erkennen, die Änderungen in Set_Switches sollten kein
> Problem sein, nur die Grafik muss angepasst werden.

Könnte man machen, allerdings könnte es schon etwas Aufwand geben, da 
die Skalierung in alle möglichen Routinen mit einfließt. Ich denke 
Stefan wird da bei QM auch mit zu tun haben. Vorteil wäre natürlich die 
bessere Ausnutzung der Wandlerauflösung und damit verbunden das 
geringere Rauschen in der Darstellung. Evtl. könnte es reichen die 
Skalierungsfaktoren anzupassen. Ich hab mir die Set_Switches() noch 
nicht so genau angesehen, ist die Umschaltung so ohne weiteres möglich?


> 2.) Bei Timebase > 6 wird  nur jeder 4. Wert ausgewertet.

Nein das ist nicht ganz richtig. Grundsätzlich ist die Situation zur 
Zeit so:

- es werden grundsätzlich immer 16k Werte gesampled

- die 1er und 5er Bereiche > 5µs nutzen jeden 5. Wert
- die 2er Bereiche > 5µs nutzen jeden 4. Wert
- der 5µs Bereich nutzt nur jeden 25. Wert

> Wenn du eh an die Timebaseeinstellungen gehen möchtest,
> solltet wir das gleich ändern. Dann werden unabhängig von
> der Timebase immer 16k-Samples übertragen. Die Faktoren der
> ProgrammingMaps werden dann vervierfacht, sonst ändert sich
> nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
> mit 16k-Samples ausgeführt werden kann, was nicht nur  die
> zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
> bringt,

Das habe ich nicht ganz verstanden. Wieso werden die Faktoren 
vervierfacht? Ich wollte die Faktoren eigentlich möglichst auf 1 oder 2 
bringen. Es stehen jedoch trotz allem für eine FFT immer die vollen 16k 
zur Verfügung, denn für die FFT ist nicht die eingestellte Timebase 
ausschlaggebend, sondern nur die indirekt damit verbundene tatsächliche 
Abtastrate. D.h. die Zeitbasen 2ns bis 1µs haben bei der FFT die 
gleichen Ergebnisse. Erst beim Wechsel auf 2µs verändert sich der 
Frequenzbereich durch die halbierte Abtastrate.

Für eine PC-Anwendung wäre es daher auch jetzt schon möglich die vollen 
16k zu nutzen, da die Werte ja vorhanden sind, nur bei der Grafikausgabe 
einfach übersprungen werden.

Gruß Hayo

[Blue F. (blueflash)]

@Niklas

Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab 
mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR 
auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Hayo

[elgodil (Gast)]

Thema Screenshot:

ev. Tastenkombination (ähnlich GERMS-Aufruf), dann könnte man so 
ziemlich jede Situation "knipsen"

[Guido (Gast)]

Hallo Hayo,

mit Set_Switches ist das kein Problem, ich muss mir nur wieder
klar machen, welches Bit für welchen Switch steht.

In den Bereichen mit Timebase > 6 werden 16k gesampled und im
FIFO abgelegt. In Readadc_all wird dann aber nur jeder 4. Wert
an den Anfang von DataArrayX geschrieben, in der
Assembler-Routine wird der Rest der Daten hinten angehängt, in
meiner C-Routine habe ich aus Geschwindigkeitsgründen darauf
verzichtet.

Besser wäre es unabhängig von der Timebase alle gesampleten
Daten hintereinander in DataarrayX zu schreiben, was für die
Grafik in den langsamen Bereichen die Faktoren vervierfacht.

Wenn man die (Hardware-)Timebase für alle Bereiche so
einstellen kann, dass immer korrekt gesampled wird, werden die
Faktoren natürlich 1. Das wäre optimal, ich habe aber nicht
verstanden warum das nicht so ist und vermute, dass da was in
der Hardware bockt (sonst hätten die das doch nicht gemacht).

Gruß, Guido

[Stefan (Gast)]

Da ja eh' nur RAW gesendet werden soll, es also keinerlei Entscheidung 
bzgl. des Formats zu treffen gibt, kann man doch "Quick Print", ohne das 
nachfolgende Menü nehmen. Quick-Print trifft's doch auf den Kopf...

[Blue F. (blueflash)]

@Guido

Das glaube ich nicht. Ich hab mir da schon so meine Gedanken gemacht 
(anbei der neue Entwurf des Timebasecontrollers) und werde mal eine 
Testversion bauen um das zu überprüfen. Allerdings muß man natürlich 
damit rechnen, das sich die Sampledauer entsprechend verlängert, was 
sich  in den langsamen Zeitbasen schon recht spürbar auswirken kann.

Gruß Hayo

[Blue F. (blueflash)]

@elgodil

Keine schlechte Idee, aber per ISR läßt sich das gleichzeitige Drücken 
von zweei Tasten nur schwer ermitteln. Der Germsmonitor-Auslöser dagegen 
ist fest verdratet (siehe NIOS Doku).


@Stefan

Ja sowas in der Art dachte ich mir auch. Allerdings wenn weitere Daten 
Übertragen werden sollen (Excel etc.), wäre ein Menü nicht schlecht.

Hayo

[Stefan (Gast)]

@Hayo
also kurz drücken und einen Quick-Print (Screenshot) bekommen - länger 
drücken und ein Menü für weitere Optionen erscheint. Quick-Print 
überschreibt somit keine angezeigten Settings, während die Anzeige der 
Softkey für das weiter führende Menü beim Excel-Export nicht relevant 
wäre.

[Martin H. (martinh)]

@Kurt

Bei meine test's mit deinem screen.exe habe ich festgestellt, das die 
Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt 
das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die 
farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index 
umstellen!). Anbei meine Version die mit \r arbeitet.

Martin

[Cra Z. (crazor)]

Michael W. schrieb:
> mal zum USB-BUS:

> Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich
> möchte lieber den USB nutzen als die serielle Schnittstelle.

Das sieht erstmal schlecht aus, ohne die Verbindungen im FPGA zu ändern. 
Der Germsmonitor wird vermutlich nur auf einer UART des Systems lauschen 
und nicht auf mehreren.

[Kurt B. (kurt)]

Danke Martin,
das werde ich mir später nochmal ansehen. Ich wollte das Prog eh noch 
etwas aufräumen.

[Cra Z. (crazor)]

Johannes Studt schrieb:
> Crazor schrieb:
>> Writing line 004277 of 023377: .X............0 sec / 134 sec left
>> Error: Timeout while reading response from DSO!
>> Response was: 'S219815B3D34<#33><#13>
>> '
>
> Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn
> der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt
> reagieren und dann ginge es weiter.
>
> /Hannes

Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein ! 
nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal 
in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht 
sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder 
nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon 
helfen!

[Niklas O. (nevm)]

Hallo,

anbei noch die v0.3 vom Screenshot Programm:
Jetzt auch fuer Windows und auch mit BMP-Ausgabe.

Kompiliertes EXE-File (unter MinGW), .BAT und README.txt sind
dabei.  Wenn sich jemand wundert warum sein Lieblingsprogramm
die BMP evtl. nicht oeffnen vermag: steht in der README.

Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
funktioniert alles richtig, habe nicht sonderlich lange testen
koennen.

@Hayo:
> Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab
> mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR
> auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Ja, mach das mal.

Niklas

[Roberto (Gast)]

Hallo Martin
> Bei meine test's mit deinem screen.exe habe ich festgestellt, das die
>Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt
>das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die
>farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index
>umstellen!). Anbei meine Version die mit \r arbeitet.

Meinst Du damit den roten Schatten, rechts der gelben Linie ?
Habe das screen.cpp durch deines ersetzt.
Ist aber noch immer der gleiche Schatten ?
Muss man da noch was ändern?
l.G. Roberto

[Cra Z. (crazor)]

Daniel H. schrieb:
> Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein !
> nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal
> in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht
> sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder
> nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon
> helfen!

Ok, habe nun Zeile 184 von
      while ($buffer !~ /\+/) {
nach
      while ($buffer !~ /[\+|\!]/) {
geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte 
ich dann .X.X.X.X. usw. in der Ausgabe, und nach dem 10. Versuch nen 
Abbruch. Dann hab ich mir gedacht baue ich in die Abbruchfehlermeldung 
auch die Ausgabe des Buffers mit ein, um zu sehen was der GERMSmonitor 
weiterhin antwortet, aber dann hat der Upload (leider ;) gerade mal 
funktioniert, sodass ich erst bei einem der nächsten Hayo-Releases 
weitertesten kann...

[Roberto (Gast)]

@Nicklas
Das Programm funktioniert bei mir! :-)
Auch kein Schatten mehr :-)
Leider kann ich kein Englisch.... (Doku)
Was ist der Befehl "-b".
Warum speichert er jetzt so viele Files extra?
Das PGM BW macht jetzt BMP :-) (-->ok)
Warum nur in S/W?
In der Doku habe ich was von "png" gelesen.
Gehen jetzt auch .png Bilder?

l.G. Roberto

[Johannes S. (demofreak)]

Daniel H. schrieb:
> Ok, habe nun Zeile 184 von
>       while ($buffer !~ /\+/) {
> nach
>       while ($buffer !~ /[\+|\!]/) {
> geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte

Ok, richtig wäre /[!+]/ (in Zeichenklassen hat das Plus wie auch das 
Ausrufezeichen keine Sonderbedeutung), aber es ist sicher prinzipiell 
keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich 
eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut 
übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und 
ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.

@Hayo: ich fände es ergonomisch, wenn der Druck auf QP einfach wie 
gehabt das Menü aufruft und ein längerer Druck die Übertragung 
stillschweigend auslöst. So würde ich das zumindestens bei meinen 
Applikationen machen.

/Hannes

[Martin H. (martinh)]

@Robert

Meiner Meinung has du das ganze nicht new compiliert!

Desshalb hier auch das screen.exe (mit Visual C++ 2008 Express 
erstellt).

Martin

[Stefan E. (stefan_e)]

@Hayo

Hier sind die Sourceen. Hab in hardware.cpp, tc_vars.cpp, tc_vars.h, 
display.cpp was geändert. Woanderst glaube ich nicht ;-)

@Stefan, der zweite

Können wir uns darauf einigen, dass ich ab jetzt mich immer als Stefan 
E. oute und du dir auch noch nen Buchstaben gönnst? Sonst bin ich am 
Ende noch selbst verwirrt, was ich geschrieben habe ;-)

[Falk W. (dl3daz)]

Niklas O. schrieb:
> Hallo,

> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
> dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
> funktioniert alles richtig, habe nicht sonderlich lange testen
> koennen.

Mir ist aufgefallen, daß fast 2/3 des Outputs Sequenzen "7e 7e 7e 0a" 
sind.

Ich werde das rle_coding etwas verändern und hoffe, daß ich die 
Datenmenge nochmal halbieren kann.

Den Code stelle ich dann hier zur Abstimmung ;-)

Falk

[Johannes S. (demofreak)]

Johannes Studt schrieb:
> keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich
> eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut
> übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und
> ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.

Dummes Hannes. :D
Na klar war das so vollkommen korrekt. Einfach die Zeile 183 wie oben 
schon beschrieben auf

                        while ($buffer !~ /[+!]/) {

ändern und schon wird bis zu 10mal versucht, die Zeile neu zu 
übertragen. Dabei wird jedesmal ein X gemalt, damit man weiß, dass da 
was krumm war.

/Hannes

[Stefan (Gast)]

Könnte man, bei all den Optimierungen, evtl. bei den Kanaleinstellungen 
einen Button aufmachen, der die Darstellung des jeweiligen Kanals auf 
50% Helligkeit setzt; ihn 50% transluzent zu machen ist ja wohl nicht 
drin :)
Oft hat man ein ein Signal vor dem Processing, und möchte es in bezug 
darauf auch nach dem Processing darstellen. Optimal ist es dann, wenn 
beide überlagernd liegen, aber da dominiert eben eine Farbe die andere 
immer sehr...

[Kurt B. (kurt)]

@Niklas,
du solltest wieder in die main() eine Endlosschleife packen damit man 
das Prog nicht für jeden Screenshot neu starten muss.

[Kurt B. (kurt)]

Wo kriege ich die ganzen fehlenden Includes her?

unistd.h
cdfes.h
features.h
...

[Niklas O. (nevm)]

Hallo,

> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
> dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
> funktioniert alles richtig, habe nicht sonderlich lange testen
> koennen.

leider doch ein Fehler:  Unter Windows wurde immer com1 verwendet,
auch wenn mit -c ein anderer COM-Port definiert wurde.  Anbei
die behobene aber ansonsten unmodifizierte Version.

@Roberto:
> Was ist der Befehl "-b".
Der bewirkt das Schreiben von BMP statt PPM Dateien.

> Warum speichert er jetzt so viele Files extra?

Das war schon immer so im Falle von PPM.  Da wird jede
Plane (Darstellungsebene, z.B. Kanal1-4, Cursor, ...)
auch einzeln gespeichert.  Ist ganz nuetzlich wenn man
bei der Entwicklung Darstellungsfehler lokalisieren will.

Bei Kurts Version war das wohl abgeschaltet und es wurde
immer nur eine Datei geschrieben.

> Warum nur in S/W?
Wenn Du im Quick Print Menue vom DSO die Taste ohne BW
drueckst sollte das farbig rauskommen.

> Gehen jetzt auch .png Bilder?
Nein, noch nicht.  In der README ist hinten beschrieben
wie man unter nicht-Windows da ein PNG raus machen koennte.

Deutsche Kurzbeschreibung werde ich in den naechsten Versionen
beifuegen.  Kurz gesagt wird mit dem Parameter -c der COM-Port
festgelegt, also etwa -c 4 fuer COM4.  Mit -f kann man einen
Dateinamen-Prefix festlegen, bei -f fft -b wuerde dann eine
Datei fft.bmp geschrieben.  -h zeigt Hilfe in Englisch an.

@Kurt:
> [Main Loop]
Werde ich per Schalter -l oder so hinzufuegen in den naechsten
Versionen, schreibt dann [prefix][nnnn].[suf], wobei nnnn
aufsteigend.

> Wo kriege ich die ganzen fehlenden Includes her?

Was benutzt Du denn als Compiler?  Ich habe das unter MinGW
kompiliert.  Bei de(r|n) (keine Ahnung davon) Windows libc
scheint es ja nichtmal snprintf() zu geben, jedenfalls habe
ich gesehen dass Du das mit strcat() usw. emulieren musstest.

Niklas

[Kurt B. (kurt)]

Hallo Niklas,
ich verwende das Visualstudio 6 bzw. 2008 Express.

Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er 
glaube ich nicht.

Die unistd darf bei mir nur unter Linux eingebunden werden.
Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)
Ersetzen von snprintf() durch sprintf_s().
Aus fopen wird fopen_s

Dann gibt es noch Probleme mit optarg und getopt()...

Die Frage ist ob die Änderungen auch mit Linux laufen. Sonst muss man 
mehr #ifdef einsetzen. Außerdem weiß ich nicht, was diese ganzen safe 
Funktionen sollen. Muss ein Feature von C++ sein.

Die Sache mit strcat() war nur eine Notlösung, weil ich vergessen hatte 
das es sprintf() gibt.

PS:
Mit MinGW geht es bei mir aber auch so. Ich musste erstmal googlen wie 
man damit kompiliert. ;-)

[Blue F. (blueflash)]

Das Wochenende ist gerettet!

Hier die neue 0.82 beta (hoffentlich werden wir den beta status los 
bevor wir die 100 knacken).

- für Niklas habe ich die UART ISR leergeräumt - hat jetzt nur noch 7 
Zeilen. Deiner Implementierung steht also nichts mehr im Wege.

- Stefans neue QM-Routinen sind auch mit dabei. Sieht nach den ersten 
Tests sehr vielversprechend aus. Dank des Redesigns ist das Flashfile 
wieder unter 1.3 MByte auf rekordverdächtige 1234 KByte geschrumpft!

- einige kleinere bugs sind gefixed.

- Der Screenshot liegt wie schon erwähnt direkt auf dem QP-Button, 
b/w-Screenshots sind daher zur Zeit nicht möglich.


Bei der QM-Funktion wird leider der untere Gridrand etwas zerbröselt, 
das wäre eigentlich was für unseren Plane-Spezialisten Guido. 
Interessanterweise tritt das bei der Cursorfunktion nicht auf.

Gruß Hayo

[Stefan E. (stefan_e)]

QM ist denke ich soweit ganz brauchbar. Der Rest, der noch nicht 
umgearbeitet ist (Delay, Phase, Math-Kanal,...) kommt auch noch 
irgendwann...

Gruß,
Stefan

[Blue F. (blueflash)]

@Niklas

Die neue 0.3 Screenshotversion arbeitet einwandfrei auch unter Windows. 
Das wird viele nicht-Linuxer freuen, da sie jetzt auch in den Genuss 
dieser praktischischen Funktion kommen.

Eine wirklich nützliche Erweiterung für unser W20xxA.

Hayo

[Stefan (Gast)]

Also bei mir laufen sowohl die BF.0.80, als auch die neue 0.82 nicht.
Die ganze Gruppe um 'Measure', 'Waveform' und 'File' geht einwandfrei; 
bei 'Trigger' reagiert kein einziger Button und die Channel-Buttons sind 
ebenfalls tot - 'Math' geht wiederum.
Es wird kein einziger Kanal angezeigt, bis auf die Menüs und die 
Cursor-Lines oder Quick-Measure -sofern aktiviert- ist der Bildschirm 
schwarz.
'Utility|Calibrate ADC/DAC' und 'Utility|Search Zero Lines' laufen 
ebenfalls durch - allein, ich hab' keine Signale...

Spiele ich die FW1.2.BF.0.75 beta zurück, geht sofort alles wieder.

Es ist ein E2024A. 'About' zeigt eine Hardware Version 8C7.0E

Was noch auffällt: unten links machen drei oder vier blaue Pixel 
permanent einen Mini-Night-Rider !?


Ist mir noch zu helfen ?

[Blue F. (blueflash)]

Ja es ist Dir zu helfen.

Da die Variablen der FFT-Funktion jetzt auch im Flash abgelegt werden, 
kann es vorkommen, dass das DSO. in einem Zwischenzustand der FFT 
startet wenn der Flashspeicher vorher nicht initialisiert war. Da Du 
Dich im FFT-Modus befindest, ist das ganze Triggermenü deaktiviert.

Abhilfe: den Mathbutton mehrfach drücken bis der normale Main-Modus 
wieder aktiv ist, dann das Edge-Menü drücken und Default-Setup. Jetzt 
noch die Timebase verstellen und bei nächsten mal ist alles gut.

Hayo

[Bruno W. (brunowe)]

Hallo Hayo,

wollte eigentlich schon gestern ein paar Kommentare zu der neuen FFT 
loswerden. Hab das Ganze eben mit der Version 0.82 überprüft, meine 
Anmerkungen treffen soweit auch darauf zu.

1.) Überraschend gutes Ergebnis (wenn man bedenkt, daß die HW und die 
Rechenleistung dafür eigentl. nicht ausgelegt ist)- Respekt!.

2.) Mit dem Cal. Signal ist mir aufgefallen, daß mit 50mV/Div der Pegel 
der Grundschwingung mit ca. 160mV angezeigt wird (Probe x1,5ms/Div, 
Poisson3.0). Beim Umschalten auf 25mV/Div wird er zu ca. 80mV angezeigt. 
Bei den anderen Fensterfunktionen ist das Verhältnis entsprechend.

3.) Da du die Beschriftung der log. Skala an der linken Achse angebracht 
hast, frage ich mich ob man das nicht auch für die lin. Skala übernehmen 
könnte.

4.) Lecroy korrigiert die fft Darstellung so, daß die Spektralllinien im 
Pegel dem Level im Zeitbereich entsprechen s.h. Dokument, Seite C-5 
oben.
http://www.lecroy.com/tm/library/manuals/download.asp?id=784

5.) Da du bei der log. Darstellung ja nicht etwa dBm oder dBV 
verwendest, sondern dB, würde ich eine auf die Grundschwingung (=0 dB) 
normierte Darstellung erwarten. Oder ist die Anzeige so zu verstehen, 
daß die Summe aller Spektralllinien 0dB entsprechen?

6.) Leider fehlt die Beschriftung der Freq.- Achse noch...

7.) Mir war gar nicht bewusst, welch großen Einfluss die Fensterfunktion 
auch auf den Pegel der Grundfrequenz hat, umso stärker wäre eine auf 0dB 
normierte Darstellung anzustreben.

8.) Eigentl. müssten doch alle Informationen zur Unterdrückung von 
Aliasing zur Verfügung stehen (TB, TB-Faktor, Freq. der 
Grundschwingung). Will damit sagen, könnte man nicht die Darstellung von 
Frequenzen die das Nyquist- Kriterium verletzen, direkt unterdrücken?

Gruß, brunowe

[Blue F. (blueflash)]

p.s.

was ist denn ein E2024A? E wie Extended Edition? ;-)

Hayo