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

Kann das sein, das die Screenshot 0.97 vom 31.03.2011 nicht mehr so 
recht will?
Es ist egal ob ich Com1 oder Com4 angebe, mit den Parametern habe ich 
auch schon experimentiert.
Das Programm liest kurz aus und geht dann wieder zu!
Gebe ich z.B. Com4 an, obwohl das DSO an Com1 hängt, bleibt das 
Dos-Fenster offen und wartet wahrscheinlich auf eine Antwort vom Oszi.

Kann das Jemand bestätigen?

Gruß Michael

EDIT. Achso, habe die neue Beta druff!
...noch was: Ich wollte gerade die 3.0C6 zurückspielen und habe die 
Messstrippe abgezogen. Gemessen wurde ein 16MHz Rechteck mit 2V/Div 
1GSa/s 50nS, da blieben auf dem rechten Bildrand einige Messreste 
stehen.

Hallo Hajo,

gut dass das Wetter nicht zu sommerlich ist, und du zum Programmieren 
kommst.

Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen 
wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung

1

* Connecting to DSO and retrieving version information... done

2

  - found hardware version:  1C9.0.L

3

  - found model:  W2024A

4

Error: This version needs at least firmware version %d.%d, but you've got %d.%d.

5

6

Please update your DSO., exiting.

und das war's dann.

Gruß
Rainer

Hallo Rainer,
> Michaels Beobachtung kann ich bestätigen.
Da bin ich ja beruhigt.

Sach mal, hast du nix besseres zutun als am DSO rumzuspielen? :-)))

Ok, Spass beiseite...ich habe die C6 noch mal zurück gespielt und da 
funktioniert alles wie soll, schade, wollte heute Abend ein paar 
Messbilder mit den neuen Funtionen schiessen...

@Rainer,
Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten 
Seite?
EDIT: Ich habe das mit der C6 gleich mal gestest, da bleiben keine Reste 
im Schirm!

Gruß Michael

wo wir schon dabei sind...
Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt, 
d.h. schaltet man bei der C6 die Filter ein, von off bis Strong, geht 
der Pk-Pk Spannungswert hübsch mit runter, während bei der Beta der 
Peakwert oben bleibt, trotzdem die Spitzen des Signals weggebügelt sind.
Beispiel, siehe Shots von der C6. Von der Beta gehen ja leider keine...

Gruß Michael

Hallo Michael,

Michael D. schrieb:
> Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten
> Seite?

Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei 
5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch?

Die Quick Measurements auf Basis der gefilterten Werte halte ich auch 
für praktischer.

@Hayo,

USTB ist ja nicht wieder zu erkennen, fein, fein!

Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und 
"Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an.

Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und "USTB Disp." 
könnten eigentlich disabled sein, wenn man nicht im USTB Ablenkbereich 
ist. Oder bist du noch nicht bei solchen Oberfkächenfeinheiten?

Gruß
Rainer

Hi Leute,

hier ist ja auf einmal wieder richtig was los! Also Eins nach dem 
Anderen:

- die Screenshotfunktion hat sich nicht verändert. Die Versionserkennung 
läuft irgendwie ins Leere, muß ich mal prüfen. Danke für die Info. Wenn 
ich da weiter bin stelle ich eine korrigierte Version zur Verfügung.

> Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und
> "Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an.

Ja zu Anfang schon, aber sobald das Bufferende erreicht ist fängt der 
Rollmode wieder von vorn an (circular buffer) während der Shift mode 
alle Daten je nach eingestellter Richtung nach vorne oder hinten aus dem 
Buffer rausschiebt. Da das Schieben etwas mehr Rechenzeit braucht kann 
es bei TB = 1s und 4 aktiven Kanälen etwas hakelig werden. Also 
möglichst im Schiebebetrieb bei TB = 1s nur 2 Kanäle benutzen oder in 
den Rollmode umschalten.

> Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und
> "USTB Disp." könnten eigentlich disabled sein, wenn man nicht im USTB
> Ablenkbereich ist.

Die Menüs werden komplett umgebaut, die USTB-Popups verschwinden in 
einem eigenen USTB-Submenü.

> Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt,

hmmm, da hab ich eigentlich auch nichts geändert. Muß irgendein 
komischer Nebeneffekt sein. Werd ich mal prüfen, danke.

Hi,

> Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei
> 5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch?

das hatte ich auch bei niedrigeren Frequenzen, vielleicht hätte ich das 
DSO mal aus u. wieder einschalten sollen, evt. könnte das der Grund 
sein.
Ich habe jetzt wieder die C6 drauf.
Und da haben wir wieder das alte Problem mit den unterschiedlichen 
Signalquellen.
Und deswegen mein Vorschlag an dieser Stelle:

Ich habe hier einen schicken Rechteckgenerator mit einem Mega48 
zusammengebaut, der nicht viel grösser ist, als ein 2x16er LCD-Display.
Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am 
Pinout des Mega48/88, TTL-Pegel.
Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS.
Sehr kostengünstiger Aufbau und sehr genau, vorallem kein Signalgezappel 
auch bei nicht so Hf-Gerechter Umgebung.
Mein Vorschlag wäre, diesen Generator als allgemeines Messequipment für 
das Welec zu verwenden, dann wären wir nicht immer nur auf die 1kHz 
beschränkt und würden auf einer breiteren und einheitlichen Linie 
fahren.
Wäre das für euch interessant???
Wenn ja, dann könnte man dafür noch einen separaten Thread aufmachen, wo 
denn auch z.B. diverse Messergebnisse vom Welec, die mit diesem 
Generator gemacht wurden, eingestellt werden. ;-)


> Die Quick Measurements auf Basis der gefilterten Werte halte ich auch
> für praktischer.
Das meine ich aber auch, wenn ich meine Filter einsetze, dann möchte ich 
das auch angezeigt bekommen, also 5,25V und nicht 6,62V Peak to Peak wie 
auf den Shots weiter oben zu erkennen ist.


Gruß Michael

Das hört sich ganz gut an, aber da ich mit umfangreichem Equipment in 
der Richtung ausgestattet bin ist das für mich erst mal nicht so 
interessant.

Gruß Hayo

Ich noch mal,
Ich habe die Beta noch mal aufgesetzt.
Nach mehrmaligen 'Default Setup', sowie komplett ein u. ausschalten, 
sind die oben genannten Effekte plötzlich weg, sehr merkwürdig, aber um 
so besser!
Screenshot geht aber trotzdem nicht, da habe ich jetzt alles Mögliche 
getestet, ich bekomme keinen Shot.

Edit: Die 0.91 geht, allerdings nur beim Doppelpush und Ausgabe BMP.
Bei allen anderen Knöppen kommt ein 'internal Error'

Gruß Michael

Noch mal EDIT: Ich dachte eher daran, das wir dann alle auf der gleichen 
Ebene wären. Gleiches Oszi, gleiche Messfrequenzen, das war so der 
Gedanke.
Das du natürlich anders ausgestattet bist, war klar, hat aber nicht 
jeder zur Verfügung.

So, war heute hyperaktiv... ;-)

Die übelsten Bugs sind beseitigt. Die neue Menüstruktur ist schon 
eingebaut. Soweit ich getestet habe ist das stabil. Aber bestimmt ist 
mir da noch irgendwo was durchgerutscht, wer findet es zuerst?

Die neue Struktur könnt Ihr Euch im Programmersguide auf dem Blatt für's 
Menu ansehen. Alles was gelb ist, ist neu.

Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug 
Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine 
Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm 
aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen.

Jetzt ist der Debug Mode jedenfalls wieder an.

So jetzt gehts mit der besten aller Ehefrauen zum Griechen... (verdient)

Gruß Hayo

i hab das file mal zumindest als 1. runtergeladen ;)
Danke! Hayo & weiterhin viel spass beim proggen ....

und lasst es euch schmecken

vlG
Charly

Hallo Hayo,

bezüglich Unterschied zwischen USTB Roll vs. Shift bin ich mit Blindheit 
geschlagen.

Einziger Unterschied den ich gesehen habe:
Wenn ich das DSO auf Ch1 mit 1s/div bei 500mV/div das Probe Comp Signal 
(Noise Filter off, perm. Display) samplen lasse (ich weiß - wildes 
Aliasing) passiert nach  gefühlten 5-6 min folgendes:

Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch 
auf Reset (z.B. via Soft-Btn)

Roll Forward Mode: Springt wieder in den Anfangszustand mit 
rüberlaufendem T-Marker, um dann normal weiter zu samplen.

Tritt das bei anderen auch auf?


Michael D. schrieb:
> Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am
> Pinout des Mega48/88, TTL-Pegel.
> Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS.

@Michael

Am schönsten wäre für Testzwecke, <träum>wenn man hinter Probe Comp den 
Ausgang eines kleinen DDS Generators rausführen würde, der mit an der 
DSO Software dranhängt. </träum>
Zeig doch mal, wieviel HW-Aufwand du für deinen kleinen Generator 
betrieben hast? Wie kommst du auf den hohen Takt (Prozessor quälen)?
Ich verwende immer gern den miniDSS (KISS)
http://www.myplace.nu/avr/minidds/index.htm

Gruß
Rainer

Jörg H. schrieb:

> - die zur veränderten Empfindlichkeit passenden Skalierwerte in den
> Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe
> Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen.

Da werde ich erstmal Dummywerte eintragen. Genauere Werte müßtest Du 
dann nachliefern.

> - an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch
> nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir
> derzeit hart reincompiliert.

Das werde ich wie von mir schon vorgesehen über die Einstellung "Addon" 
im Hardwaremenü machen.

> - Die Software kann keinen echten "Mischbetrieb" der verschiedenen
> Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben
> diskussionswürdig, ob das überhaupt sein soll und kann. An diesem
> prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.

Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges 
verkomplizieren. Ich tendiere erstmal zu nein.

> Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins
> Flash kommen) und pro Kanal anzeigen,

wie Du schon sagtest gibt es diverse Stellen die ebenfalls betroffen 
wären.

> In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also
> ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen
> "ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe
> noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und
> 2er Bereiche, und einen für die 5er Bereiche.

Weil 1er und 2er den gleichen Scalierungsfaktor haben und der 5er einen 
anderen.

> (BTW, die Indizes sind
> ungünstig, wären besser vertauscht, damit der innere Zugriff schnell
> geht. Der letzte Index sollte die 0..255 Tabelle sein.

Muß ich mal checken und evtl. anpassen

> Ferner würde ich
> diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann
> alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die
> Zeichenschleife das nicht tun.)

Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin 
etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man 
könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der 
Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version 
reinkriege.

> Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht
> korrigiert:
>
> 1.) in Hardware::RestoreFromFlash()
> statt:
> Hardware::SetSwitches(2, -1);
> besser:
> Hardware::SetSwitches(2, Selected_Voltage_CH2);

Stimmt, habe ich im Zuge der neuen Startupsequenz mit korrigiert

> 2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf,
> das tut dem Chip wohl nicht gut.

Hier wird der Config-Backupsektor refreshed. Das muß daher bleiben. Dem 
Chip sollte das nichts machen. Bis der davon Schaden nimmt hast Du wohl 
schon den 100sten Netzschalter verschlissen. Während des Betriebes wird 
auch bei jeder neuen Einstellung ins Flash geschrieben. Das sollte das 
Flash locker mitmachen. Ich schreibe bei mir seit drei Jahren so oft ins 
Flash wie wohl kein normaler User sonst. Da funktioniert aber immer noch 
alles tadellos.

> Nur nebenbei, in meinen Projekten habe
> ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte
> Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem
> Timeout, verhindert versehentliches Dauer-Schreiben.

Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich 
tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der 
ganze Config-Sektor neu geschrieben werden da immer nur sektorweise 
gelöscht werden kann.

> 3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß
> aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die
> Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl
> ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am
> Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich
> drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach
> Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt.

Muß ich mal checken, ob ich das nachgestellt kriege.

Gruß Hayo

Rainer W. schrieb:

> Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch
> auf Reset (z.B. via Soft-Btn)

Stimmt, da ist noch was buggy. Hat aber schon mal funktioniert. Muß ich 
mal suchen.

> Roll Forward Mode: Springt wieder in den Anfangszustand mit
> rüberlaufendem T-Marker, um dann normal weiter zu samplen.

Soll ja auch so sein. Am Besten den Memorybrowser dauerhaft aktivierren, 
dann sieht man immer wo man sich gerade im Buffer befindet.

Gruß Hayo

Hayo W. schrieb:
> Am Besten den Memorybrowser dauerhaft aktivierren,

Guter Tip. Dann ist mir der Unterschied auch klar.
Der Hänger im Shift-Mode(bei 1s/div nach 5 min) passiert demnach, sobald 
das Bufferende erreicht ist.

Rainer

Ich hab da nochmal getestet.

Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte 
so groß ist, daß in der Zwischenzeit der nächste Interupt vom 
Acquisition-Timer kommt und damit die weitere Ausgabe unterbindet. 
Irgendwann gibt es dann wahrscheinlich einen Stacküberlauf.

Ich werde wohl den Signalbuffer im Shiftmode drastisch verkleinern 
müssen, zumindest in den Bereichen 1s  2s  5s.

Gruß Hayo

Hayo W. schrieb:
> Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte
> so groß ist

Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch 
schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig.

Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus, 
d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein 
Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-)

Gruß
Rainer

Rainer W. schrieb:
> Hayo W. schrieb:
>> Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte
>> so groß ist
>
> Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch
> schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig.

Nachgedacht schon, aber mir war das im ersten Anlauf etwas aufwändig. 
Eventuell muß ich mir da aber doch noch mal das Hirn verrenken, leider 
hab ich noch nie so eine Konstruktion machen müssen. Bei meinen 
Signalprozessoren gab es da immer eine Hardwareimplementierung für.

> Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus,
> d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein
> Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-)

Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du 
ein Sample? Oder einen ganzen Pufferdurchlauf?

Gruß Hayo

Hayo W. schrieb:
>> - Die Software kann keinen echten "Mischbetrieb" der verschiedenen
>> Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben
>> diskussionswürdig, ob das überhaupt sein soll und kann. An diesem
>> prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.
>
> Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges
> verkomplizieren. Ich tendiere erstmal zu nein.

In der Endversion bin ich auch der Meinung das nicht, aber momentan 
fände ich es schön, vergleichen zu können. Zugegeben kann man das auch 
nacheinander tun, mit zwei Softwaren. Da habe ich mich etwas in die Ecke 
gedacht.

>> Ferner würde ich
>> diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann
>> alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die
>> Zeichenschleife das nicht tun.)
>
> Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin
> etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man
> könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der
> Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version
> reinkriege.

Dann sollten wir mal an der Berechnung arbeiten, damit die 
Zeichenfunktion Gas geben kann. Vermutlich braucht sie deshalb so lange, 
weil sie in Fließkomma rechnet? Da könnte ich mir vorstellen bestenfalls 
die Endwerte in float auszurechnen und die Gerade dazwischen mit was 
Bresenham-artigem. Es sind ja nur 256 Werte, das sollte sehr schnell 
gehen. Könnte ich mich drum kümmern.

>> Nur nebenbei, in meinen Projekten habe
>> ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte
>> Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem
>> Timeout, verhindert versehentliches Dauer-Schreiben.
>
> Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich
> tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der
> ganze Config-Sektor neu geschrieben werden da immer nur sektorweise
> gelöscht werden kann.

Ach so, du vergleichst den Sektor vor dem Schreiben und brichst ab wenn 
gleich? Sehr gut, dann habe ich nichts gesagt.  :-)

Jörg

Hayo W. schrieb:
> Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du
> ein Sample? Oder einen ganzen Pufferdurchlauf?

Damit meine ich 16k (oder wie viel das z.Z. ist) messen, quasi das was 
z.Z. beim Shift Mode mit 1s/div bis zum Einfrieren passiert, so dass man 
Daten aufzeichnen kann, ohne sich darum zu sorgen, dass die ersten 
Samples wieder überschrieben oder rausgeschoben werden.

Gruß
Rainer

Hmm, ja das könnte man machen. Ich probier das mal...

Gruß Hayo

Hallo,

ich meld' mich auch mal wieder.

Rainer W. schrieb:
> Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen
> wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung
> * Connecting to DSO and retrieving version information... done
>   - found hardware version:  1C9.0.L
>   - found model:  W2024A
> Error: This version needs at least firmware version %d.%d, but you've got %d.%d.
> [..] [zu Firmwareversion 3.2 beta]

Hayo W. schrieb:
> Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug
> Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine
> Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm
> aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen.

Ich hab' mir das gerade mal angeschaut mit der 3.2 beta.  Das
Problem liegt in der letzten for-Schleife in dsoinfo().  Sonderzeichen,
darunter auch \n, schreibe ich als \0 in das info-Array.  Nun frage
ich ab, ob das gerade betrachtete Zeichen eben \0 ist und teste,
ob etwas verwertbares bzgl. Versionsangaben gefunden werden kann.  Da
mit Debugausgaben anfangs etwas "Muell" kommt, ist der Fall *p == '\0'
fuer den ersten vom DSO uebermittelten Nutzdaten-String, naemlich
"FW: 1.2.hayos.version", gegeben.  Ohne Debugausgaben wird der String
ignoriert und erst die darauf folgenden betrachtet.

Kurzfristiger Bugfix ist, vor der einlesenden while-Schleife statt:

1

i = 0;

2

while (i < ISIZE-1 && (c = rdchar(com)) != '+') {

zu setzen:

1

info[0] = '\0';

2

i = 1;

3

while (i < ISIZE-1 && (c = rdchar(com)) != '+') {

Im Anhnang der Quelltext von v0.97 (aus der FW 3.0 ZIP-Datei)
mit genau dieser Aenderung.  Leider habe ich gerade keine
Moeglichkeit das fuer Windows zu kompilieren, liefere ich
nach.

Niklas

Hi Niklas,

danke für die detailierte Analyse.

Gruß Hayo

Hallo Hayo,

mit der Beta friert ständig mein Schirm ein.
Wenn ich das Signal abziehe, bleibt es auch bestehen und, oder es 
bleiben Reste.
Bei den unteren Messbereichen so 250ms bis 50µS gehen die Messungen sehr 
schleppend und kommen ständig in's stocken. So richtig fix geht es erst 
wieder bei 1GSa also 500nS los, alles was darunter ist, ist eine 
Katastrophe.
USTB geht und dann wieder nicht. Bleibt einfach stehen und dann 
irgentwann mal weiter oder auch nicht...
Ich wollte dir das nur mal berichten, da ich ja weiß, das du kaum zum 
Messen kommst. Der Rainer hat dieselben Probleme.
Wenn du möchtest, kann ich dir mal ein paar Screenshots schicken, da 
stehen dann auch alle Werte drinnen. Das jetzt hier zu beschreiben, 
würde den Rahmen sprengen.
Einen schicken Abend noch,

Gruß Michael

Hi, bin erst jetzt wieder vom Griechen zurück, durch das viele 
Programmieren komme ich gar nicht mehr zum selber kochen...

Ich habe die USTB-Engine noch mal überarbeitet - die aktuelle Version 
ist jetzt 2.2.

Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine 
Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte.

Einfrieren sollte eigentlich nichts mehr. Einige andere Sachen habe ich 
auch noch optimiert.

Weitere Änderungen / Neuerungen stehen noch an.

Danke für die Rückmeldungen, wie immer sind weitere Reports von Euch 
stets willkommen!

Gruß Hayo

Hayo W. schrieb:
> Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine
> Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte.

Hallo Hayo,

die Puffergröße, die im Shift-Mode bewältigt werden kann, müßte doch 
sowohl von der Samplerate, als auch von der Anzahl der aktiven Kanäle 
abhängen - so ganz banal gedacht. Würde man beim 4 Kanaler dann nicht 
ungünstigstenfalls einen Faktor vier bei der Einkanalaufzeichnung 
verschenken, wenn man das rein an der Samplerate festmacht?
Oder hab' ich das zu einfach gedacht?

Gruß
Rainer

Im Prinzip hast Du recht, aber bei meinen Tests hat sich erwiesen, dass 
die Anzahl der Kanäle nicht ganz so ausschlaggebend war als dass sich 
der Aufwand gelohnt hätte die Anzahl der Kanähle zu berücksichtigen.

Soll heißen, dass selbst bei noch kleinerer Puffergröße (600 Byte = 
Screenbreite) im Dreikanalbetrieb die Sache ins Stocken kam (1s/Div und 
2s/Div), geschweige denn der Math-Modus ging. Der etwas größere Sprung 
von 2s/Div auf 5s/Div reicht dagegen um alles stabil bei 1200 Byte 
Puffergröße laufen zu lassen.

So wie es jetzt ist habe ich eigentlich schon das Maximum rausgeholt.

Am Memorybrowser könnt Ihr Übrigens immer gut die aktuelle Puffergröße 
erkennen.

Gruß Hayo

Hallo,

im Anhang das neue Kompilat des Screenshot-Programms v0.97
mit dem Fix fuer den Bug im Zusammenhang mit abgeschalteten
Debug-Modus in der Firmware (v3.2 beta).  Hayo kann dann in
zukuenftigen Versionen wieder den Debug-Modus abschalten.

English:
New compilation of the screenshot program v0.97 with a fix
regarding a bug that was found when the debug mode is turned
off in the firmware (as in v3.2 beta).  In v3.3 beta and
v3.4 beta Hayo temporarily turned debug back on for this
reason.  No other changes.

For more information and sourcecode see 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"

Niklas

Hallo Hayo,
die 3.4beta, läuft gut. Ich habe gleich noch mal den USTB-Modus getestet 
mit einem 0,23Hz Rechteck(Pulsweite 50:50) auf 1s, 2s und 10s.
Anbei 3 Shots.

Jetzt bleibt aber bei den Smooth und Strong-Filtern das Signal stehen 
(Test 2kHz). Es friert nur das Signal ein, nicht das komplette DSO.
Wenn ich die Filter tausche bzw. ausschalte, läuft's wieder!

Getestet habe ich noch die 3 anderen Filter StageI bis StageIII. Da 
läuft alles so wie es soll.

Ich hoffe, es nützt dir was.

Hallo Niklas,
Die Shots sind mit deiner neuen screenshot-fix gemacht, funzt wunderbar.
Tolle Arbeit und ein Lob von mir.

Gruß Michael

Ooouuhh,

das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die 
Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war.

Die eigentlichen Filterroutinen werden auch garnicht angesprungen. 
Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer, 
weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich 
jetzt beseitigt.

Danke für den Hinweis!

Gruß Hayo

Hayo W. schrieb:
> Ooouuhh,
aaaaahh...
>
> das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die
> Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war.

Das der da keinen Sinn macht, macht ja Sinn...
bei den Messungen weiter oben, war der auch garnicht eingeschaltet, 
fällt mir gerade ein!
Eben habe ich das noch mal provoziert, sobald eines der Filter aktiv 
ist, geht da nüscht mehr.
>
> Die eigentlichen Filterroutinen werden auch garnicht angesprungen.
> Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer,
> weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich
> jetzt beseitigt.

Fein!
Jetzt zickt nur noch der 'Smooth' und der 'Strong' Filter, im "nicht" 
USTB-Mode. Die Stages I-III sind ok!
>
> Danke für den Hinweis!
Bitte!
>
> Gruß Hayo

Gruß Michael

Und hier ist wieder das Sonntagabend-Event!

Wie von versprochen habe ich mir das Gehirn verrenkt weil die Lösung mit 
den kleinen Puffergrößen im Shift Mode etwas unbefriedigend war.

Herausgekommen ist eine Lösung mit sich gegeneinander verschiebenden 
Speicherbereichen statt einer Verschiebung der Daten selbst.

Dazu brauchte ich aber viel Speicher, so dass ich die Speicheraufteilung 
geändert habe. Das Ergebnis kann sich sehen lassen:

- 16KB in allen ultra slow TB für den Shift Mode
- 32KB sind möglich im Roll Mode!

Die Speichertiefe ist einstellbar im USTB-Menü (8KB/16KB/32KB). Von 
Rainer angeregt habe ich einen speziellen Single Mode für USTB 
implementiert.

Quick Print und Save/Recall unterstützen aber nur (8KB/16KB)

Gruß Hayo

Hallo Hayo,
ich habe deine 3.5Beta gleich mal getestet.
Das mit dem Smooth u. Strong Filter hat sich schon gebessert.
Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz 
Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's 
stocken.
Bei nur einer Flanke geht's ab wie Schmitt's Katze. Die StagesI bis III 
gehen nach wie vor wunderbar...what's the Different?

Ich wünsche dir noch einen schönen Sonntag

Gruß Michael

Ich noch mal,
habe gerade noch den USTB-Mode mit ---275Hz--- getestet und zwar mit 
1,2,5 und 10Sek.
Irgendwie stimmt da was nicht, 1s ist ein wenig voll?
Die 2s sind wieder schön gemalt, 5s füllt sich wieder und bei 10s ist 
das Signal wieder ok, oder habe ich das Messprinzip nicht verstanden?

Anbei die Shots mit den Einstellungen!

Gruß Michael

Hi,

sowas nennt sich Aliasing. Die Messfrequenz ist viel zu hoch für die 
Abtastrate. Ich teste da mit 0,05Hz. Heißt ja nicht umsonst Ultra Slow 
Time Base.

Das Andere muß ich noch mal prüfen. Ist auch noch beta Status. Bis zum 
stable Release muß ich noch ordentlich testen. Je mehr Ihr jetzt schon 
findet, desto schneller gehts!

Bis dann

Hayo

Hallo Hayo,

ganz große Klasse mit dem radikal geänderten Speicherkonzept in den USTB 
Modes. Der Single-Shot ist auch sehr fein.

Nach ein bisschen probieren sind mir noch folgende Kleinigkeiten 
aufgefallen:

- Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine 
Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das 
konzeptionelle Problem dabei. Vielleicht hat jemand die geniale Idee.
Eine Möglichkeit, die mir spontan einfällt, wäre im Browser ein 
hinterlegter Balken der den Speicherfüllstand anzeigt, aber es wäre 
natürlich schöner, wenn man dafür nicht wieder etwas neues erfinden 
müßte.

- Bei der Bedienung im Main/Delay Menü finde ich es persönlich 
unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü 
hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es 
nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu 
tauschen.

Und noch ein Punkt:
- Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang 
zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin 
ist.

Nochmal ein dickes Lob für deine tolle Arbeit.

Gruß
Rainer

Rainer W. schrieb:
> - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine
> Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das
> konzeptionelle Problem dabei.

Ja sowas ging mir auch schon durch den Kopf - allerdings noch ohne gute 
Idee

> - Bei der Bedienung im Main/Delay Menü finde ich es persönlich
> unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü
> hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es
> nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu
> tauschen.

Da hast Du natürlich recht, die Idee hatte ich auch schon, war aber noch 
zu "faul", werde ich aber noch machen.

> Und noch ein Punkt:
> - Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang
> zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin
> ist.

Da hatte ich auch schon überlegt, hatte aber gedacht, dass es dann nicht 
möglich ist nachträglich den Single Shot zu aktivieren ohne die 
bisherigen Ergebnisse zu verwerfen. Kann ich aber noch einbauen.

> Nochmal ein dickes Lob für deine tolle Arbeit.

Das schlechte Wetter in Norddeutschland machts möglich...

Gruß Hayo

Michael D. schrieb:
> Hallo Hayo,
> ich habe deine 3.5Beta gleich mal getestet.
> Das mit dem Smooth u. Strong Filter hat sich schon gebessert.
> Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz
> Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's
> stocken.

Ok hab's! In dem Bestreben das letzte Quentchen Performance rauszuholen 
hab ich leider mal wieder was kaputt-optimiert. Ist schon korrigiert und 
kommt mit der 3.6 beta.

Danke für den Report

Hayo

So, hier auch gleich die bereinigte Version.

- Filterproblem gefixt
- Browser Button und USTB-Button getauscht
- Bufferrefresh bei Single Shot

Als Nächstes werde ich mal Eure älteren Bug-Reports abarbeiten und dann 
die neue Hardwareansteuerung von Jörg einbauen. Dann steht dem neuen 
final Release nichts mehr im Wege.

Gruß Hayo

Rainer W. schrieb:

> - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine
> Anzeige, die über den Speicherfüllstand informiert.

Da fällt mir ein, dass der Memorybrowser da schon mal weiterhilft, denn 
da wird der aktuelle Samplezeitpunkt im Speicher durch das Triggersymbol 
angezeigt. Wenn das Triggersymbol ans Speicherende läuft wird der 
Singleshot ausgelöst. Das gilt allerdings nur für den Rollmode. Beim 
Shiftmode läuft ja das Ende des Signals gegen das Speicherende, und 
dafür gibt es momentan noch kein Zeichen. Wäre aber eine Überlegung 
wert.

Gruß Hayo

Hallo Hayo,

Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir...

Die Filter funzen todschick, ich benutze gerade den Smooth-Filter sehr 
oft und für's Grobbe dann mal schnell den Strong für die obere 
Müllbeseitigung, denn dafür sind diese sehr praktisch!!!

Ok, das mit dem USTB hätte ich mir denken können.
Sind denn die Messungen hier:
---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
dafür ok?
Man sieht sieht auf den Shots auch den Browser wie er sich füllt, das 
dauert schon seine Zeit bis der voll ist, einige Minuten.

Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf 
den Shots messe ich mit z.B. 0,23 Hz.

Gruß Michael

Michael D. schrieb:

> Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir...

Cool, dann bin ich jetzt 5 Sterne Programmierer... ;-)

> Ok, das mit dem USTB hätte ich mir denken können.
> Sind denn die Messungen hier:
> ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
> dafür ok?

Das kann man nie genau anhand des Bildes sagen. Im Prinzip muß das 
Signal bezogen auf die Abtastfrequenz bandbegrenzt sein (und zwar auf 
halbe Abtastfrquenz).

> Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf
> den Shots messe ich mit z.B. 0,23 Hz.

Dazu hat mal ein genialer Mensch namens Nyquist eine schlaue Idee 
gehabt. Nennt sich Abtasttheorem. Das besagt. das die Abtastfrequenz 
mindestens doppelt so hoch sein muß wie die höchste auftretende 
Signalfrequenz, damit das Signal korrekt wiederhergestellt werden kann. 
Wenn das nicht erfüllt ist entstehen sogenannte Scheinfrequenzen 
(Aliasfrequenzen) woher auch die Bezeichnung Aliasing stammt.

Die Abtastfrequenz wird ja in der Statusleiste angezeigt. Bei 1s/Div ist 
sie beispielsweise 50Sa/s -> nach der Theorie ist da also die 
Grenzfrequenz (oder auch Nyquistfrequenz) 25Hz. In der Praxis liegt sie 
jedoch weit darunter, mindestens bei 1/4 der Abtastfrequenz, da Du sonst 
auf dem Bildschirm nix Vernünftiges erkennen kannst.

Unser Oszi ist Beispielsweise mit einer Abtastfrquenz von max. 1MSa/s 
gesegnet, hat aber nur eine (theoretische) Bandbreite von 200MHz/100MHz 
was schon zeigt wie Theorie und Praxis zu bewerten sind.

Den Rest kannst Du Dir ja selbst zusammenreimen. Viel Spaß beim 
nachrechnen.

Im Prinzip kannst Du also den USTB-Bereich mit Frequenzen ab 5Hz abwärts 
sinnvoll testen - mit 0.23Hz bist Du also schon gut dabei!

Gruß Hayo

So, ich mal wieder,

hallo allerseits. Die letzten Tage habe ich den Fehlerreport von Rainer 
(11.7.2011) abgearbeitet. Zur Erinnerung, es ging um den (fehlenden) 
Refresh der Cursor-Daten. Dabei bin ich auf eine Menge Unrat gestoßen. 
Insofern freue ich mich über die neue Betaversion besonders. Ich habe 
die Assemblerroutinen für den Menüaufbau komplett überarbeitet und 
mengenweise performancehemmende Leichen entsorgt. Neben der erfreulichen 
Tatsache, das jetzt die Cursorwerte prompt und schnell angezeigt werden 
ist auch der gesamte Menüaufbau beschleunigt worden.

Die aktuelle Beta läuft nach meinen bisherigen Erkenntnissen so stabil, 
dass ich empfehlen würde sie erstmal dauerhaft zu flashen da sie 
gegenüber den 3.0 Cx Versionen doch deutliche Vorteile zu bieten hat.

Über Fehlerreports freue ich mich natürlich trotzdem.

Gruß Hayo

Ach ja noch als kleiner Nachschlag,

für alle die gerne selbst Performance-Messungen durchführen wollen habe 
ich einen dauerhaften Framecount eingebaut der gleichzeitig mit der 
Tastenkombination Shift+K über Terminal ausgegeben und resettet wird.

Gruß Hayo

Den ersten Fehler habe ich dann auch selbst entdeckt wie es aussieht.
Der Pretriggerwert wird bei TB-Wechsel nicht korrekt refreshed - erst 
beim Druck auf den Button..

Ist natürlich schon in Arbeit...

...Version 3.8 is coming soon...

Hayo

Damit die Anderen wissen, was der Hayo meint, habe ich mal 2 Shots 
gemacht.
Im 1. Shot ist das Terminal zu sehen mit all seinen Befehlen, mit denen 
man das Welec fernsteuern kann.
Ausser Shift+k ist noch nicht beschrieben, geht aber und ist auf dem 2. 
Shot zu sehen!

Gruß Michael

EDIT: Ach ja, unten auf der Statusleiste sind die Parameter für die 
RS232 zu sehen. (Stopbit 1, Handshake none)

Doch, der Framecounter ist schon beschrieben, man muß schon genau 
hinsehen ;-)

Einfaches Vorgehen bei der Messung:

- Uhr mit Sekundenzeiger bereithalten
- bei Nulldurchgang des Sekundenzeigers Shift + K drücken
- nach 60 Sekunden erneut Shift + K drücken

Als Ergebnis hat man die Frames pro Minute, die je nach Anzahl der 
Kanäle und zusätzlicher Funktionen variieren.

Hayo

Ok, Pretriggerproblem gefixt.

Kommt in Kürze...

Hayo

man, du hast ja Recht!
Das passiert mir jedes mal, das ich mich bei der Funktionsbeschreibung 
in der Spalte verhaue!
"not available" ist Shift+L

:-/

Jo Mann, so sieht's aus.

Und jetzt werd ich mich schön ins Bettchen kuscheln, bis dann

Hayo

Und die nächste  beta, die aber jetzt schon recht stabil ist. Was hat 
sich getan?

ich habe den zweiten Teil von Rainers Fehlerreport (11.7.2011, da war 
ich noch in Thailand) abgearbeitet.

Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert. 
Beim Prüfen der Berechnung bin ich auf eine völlig verwurstete Formel 
gestoßen die um Zehn Ecken mit zig Hilfsparametern die Position extrem 
rechenaufwändig und falsch berechnet.

Die neue Formel errechnet die Position mit drei Parametern viel 
schneller und richtig! Alle überflüssigen Parameter und Matrix-Arrays 
habe ich gelöscht, da diese nur hierfür benutzt wurden.

Das Ganze gilt ebenso für die QM-Delayed Cursor (z.B. bei Rise Time 
Berechnung im Delayed Mode).

Gruß Hayo

Für die nächste Beta überarbeite ich gerade die Zeichenroutine für das 
Pretrigger-Zeichen im Haupt und Delayedfenster, da es hier manchmal 
Darstellungs-/Löschfehler gibt.

Gruß Hayo

bei wieviel fps sind wir inzwischen?

Fast Vector:
- 2 Kanäle -> 475fpm
- 4 Kanäle -> 247fpm

Accurate:
- 2 Kanäle -> 419fpm
- 4 Kanäle -> 221fpm

Pixel:
- 2 Kanäle -> 511fpm
- 4 Kanäle -> 262fpm


Das ist in allen Bereichen zwischen 10 - 20fpm schneller als bei den 
3.0Cx
Für fps alles durch 60 teilen.


Ansonsten baue ich gerade die Hardwareunterstützung für die neue 
Eingangsstufe ein.

Gruß Hayo

Hallo,

schlechte Nachrichten bei mir.

Mein 4 Kanaler versagt den Dienst.  GUI funktioniert, aber
keine Anzeige der Eingangssignale.  Alle Traces werden
in der Mitte gezeichnet, Verschieben dieser ist auch
nicht moeglich.

Da mich es wunderte, warum auch die Relais nicht klicken beim
Wechsel der Ranges, hab' ich mir mal das Netzteil und das
Spannungsversorgungs-Board angeschaut.  Dabei fiel auf, dass
ein Bauteil, was fuer mich nach einer Induktivitaet/Spule
aussieht, abgeraucht ist.

Es handelt sich im folgenden Foto um das weisse Bauteil
direkt am linken Rand (bei den schwarzen Leitungen die
zum LCD-Inverter Board fuehren).  Bei mir war das Bauteil
schwarz (wohl auch vor dem Abrauchen schon ;)), duerfte
aber irrelevant sein.

http://sourceforge.net/apps/trac/welecw2000a/raw/attachment/wiki/Hardware/inverter.JPG

Vor dem Bauteil liegen 6.2V an.  Das ist (bzw. war) bei mir auch
Versorgungsspannung vom Original-Luefter (den hab' ich aber
bereits durch einen anderen getauscht, welcher direkt an den 12V
vom Netzteil angeschlossen ist).  Hinter dem defekten Bauteil liegen
im Betrieb nur ungefaehr 0.5V an.

Frage an Euch:  Um was fuer ein Bauteil handelt es sich mit welchen
Werten?  Wenn jemand das mal ausmessen koennte waere ich ihm sehr
dankbar.

Niklas

Hallo Niklas,
die Frage wäre einfacher zu beantworten wenn der link funktionieren 
würde. ;-)

Abgesehhen davon gehört das doch eher in den Hardware Thread.
Beitrag "Wittig(welec) DSO W20xxA Hardware"

MFG,
Kurt

Hallo Kurt,

hast Recht, gehoert in den anderen Thread.  Mea culpa.

Korrekter Link zum Foto:
http://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/Hardware/inverter.JPG

Niklas

Hallo Allerseits,

ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0 und 
prüfe die bisher gemeldeten Fehler. Aktuell prüfe ich das Verhalten des 
Single Shot, da hier einige Meldungen in der Vergangenheit waren.

Momentan kann ich aber keine Auffälligkeiten entdecken. Wenn Ihr noch 
Fehler entdeckt habt dann bitte melden. Bezüglich Trigger bitte immer 
auch mit den aktuellen Einstellungen des Triggermenüs.

Gruß Hayo

Moin Hayo,

Hayo W. schrieb:
> Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert.

Die synchronisierten Cursor im Delayed Fenster geben ein völlig neues 
Arbeitsgefühl und die Anzeige der Cursor Position sowieso. Klasse ;-)

Hayo W. schrieb:
> ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0

Da hätte ich noch die kleine Schönheitoperation mit dem völlig 
deaktivierten Kanal Menü, falls du da seit der 3.8 nicht schon dran 
warst:
Wenn man einen Kanal abschaltet, wird das Soft Menü völlig deaktiviert. 
Sinnvoller wäre vielleicht, es auf einen der aktiven Kanäle zu schalten, 
oder zumindest die "Dispatch Channel"-Taste freizugeben, damit man die 
verbleibenden Kanäle bequem neu anordnen kann.

Frohes Schaffen, wo Hamburg anscheinend von der Wochenendhitzewelle 
verschont bleibt ;-)

Gruß
Rainer

Hallo Hayo,

bei der Darstellung im Delayed Fenster gibt es noch einen Bug mit dem 
Datenzugriff. Wenn man bei aktivem und weit links liegendem Delayed 
Fenster die TB langsamer schaltet, wird u.U. auf ungültige Daten 
zugegriffen. Das sieht dann aus wie im beigefügten Screenshot.

Der Fehler läßt sich wie folgt provozieren:
Default Setup, Signal z.B. ProbeComp an Ch1 mit 200mV/div, TB 1 ms/div, 
Delayed aktivieren, TB_Delayed 200µs/div, Fenster ganz nach links, 
TB_Delayed 500µs/div.
-> et voilà ...

Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann 
anscheinend vor dem Anfang des Sample-Speichers. Bei TB-Umschaltung muß 
man evtl. einfach das Fenster so verschieben, damit das nicht passiert. 
Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende 
Kontrolle stattzufinden.

Gruß
Rainer

Alles klar, danke.

Werd ich mal genauer unter die Lupe nehmen. Allerdings muß ich heute 
noch unsere Viper spazieren fahren, da morgen schon wieder Regen 
angesagt ist.

Gruß Hayo

Rainer W. schrieb:
> Hallo Hayo,

> Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann
> anscheinend vor dem Anfang des Sample-Speichers.
Ja, ist korrekt.
> Bei TB-Umschaltung muß
> man evtl. einfach das Fenster so verschieben, damit das nicht passiert.
Es fehlt ein Limiter, der das Fenster wieder zurückschiebt wenn die 
Grenze außerhalb des Speichers liegt.

> Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende
> Kontrolle stattzufinden.
Nein, das sieht nur so aus weil da noch etwas mehr Speicher am Ende ist 
der dann dargestellt wird. Aber das ist so auch nicht korrekt. Muß auf 
jeden Fall korrigiert werden, bin schon dran...

Gruß Hayo

Hallo Hayo,
ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der 
3.6 geht noch alles.

Hast du eine Idee woran das liegen könnte?


Mfg,
Kurt

Hallo Kurt,

was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion? 
Ich habe da nichts dran geändert (zumindest bei 3.6/3.7 noch nicht), 
allerdings habe ich jetzt beim Dump die Pointer auf das Signal geändert 
weil ich das komplett umgestellt habe.

Ach ja, jetzt fällt es mir wieder ein. Ich habe den Debug-Mode im 
Comm-Interface abgeschaltet. Der hat bei externen Befehlen immer ein 
Echo zurückgegeben. Das Problem hatten wir ja auch mit unserem normalen 
Screenshot, der wollte zuerst auch nicht mehr, aber den hat Niklas ja 
entsprechend angepasst.

Kann es das sein?

Gruß Hayo

@Rainer

Problem ist gefixt,

Danke für den Hinweis. Die Menüsteuerung für das Channelmenü wollte ich 
eigentlich nicht ändern. Dein Einwand dass man erst zum nächsten Kanal 
umschalten muß ist zwar korrekt, aber der Sinn der Logik ist ja dass man 
durch mehrfaches Drücken den Kanal ein und ausschalten kann (toggeln) 
ohne das man zwischendurch in ein anderes Kanalmenü umgeleitet wird aus 
dem man dann wieder zurückspringen müßte.

Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so 
einfach umzusetzen, da das Menü immer komplett deaktiviert oder 
aktiviert wird.

Gruß Hayo

Hayo W. schrieb:
> was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion?

Genau kann ich das noch nicht sagen. Am Mikrocontroller sind die Debug 
Möglichkeiten leider sehr begrenzt.

Ich werde weitersuchen.

Hayo W. schrieb:
> Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so
> einfach umzusetzen, da das Menü immer komplett deaktiviert oder
> aktiviert wird.

Das ist ein schlagendes Argument ;-)
und spricht für die erste Lösung. Beim (Re-)Aktivieren eines Kanals wird 
ja auch jetzt schon, egal welches Menü angezeigt wird, automatisch auf 
das Channel-Menü für den neu aktivierten Kanal gewechselt, so dass das 
Zurückspringen jetzt schon funktioniert und das Ganze mit der 
Toogle-Philosophie prima zusammenpasst.

Gruß
Rainer

Der Gedanke dabei ist, dass der Fokus immer auf dem Kanal bleibt den man 
gerade bedient, solange bis man den nächsten Kanal bedient.

Gruß Hayo

Greetings to everyone, but especially to Hayo
I installed the new beta release from 04 to 08.
In going from FFT: Fn 500Mhz to: Fn12.50Mhz, the DSO crashes.
There is no way to unlock it.

Hi Conte,

thanks for Your report, I will check this and try to fix it soon.

Regards Hayo

moin moin Hayo,

im Singel Mode ist 'Stop' im display immer an.
Ist die TB recht langsam merkt man nicht ob getriggert wurde
da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es
machbar RUN/STOP beim triggern einzuschalten und nach dem
Bildaufbau die Single Taste zu loeschen ?, und nochmal die
Frage, ist es nicht machbar das man im Single Mode die TB
veraendern kann solange noch nicht getriggert wurde ?, immer
in den Run Mode zu schalten dafuer ist etwas umstaendlich (und
nutzt die Tasten ab ;) )


vlG
Charly

Ok, FFT-freezing bug is fixed! Had a little buffer overfow problem which 
is solved now.

Thank You for reporting

Hayo

Charly B. schrieb:
> moin moin Hayo,

Hi Charly

> im Singel Mode ist 'Stop' im display immer an.
Ja, der Displayaufbau ist so langsam, dass man das nicht genauso schnell 
darstellen kann wie mit den LED.

> Ist die TB recht langsam merkt man nicht ob getriggert wurde
> da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es
> machbar RUN/STOP beim triggern einzuschalten und nach dem
> Bildaufbau die Single Taste zu loeschen ?,
Den hab ich irgendwie nicht ganz verstanden. Ich habe mir das mal bei 
200ms/Div angesehen und fand eigendlich alles ganz normal. Die 
Umschaltung von Single nach Stop geschieht genau in dem Moment in dem 
das Triggerereignis auftritt. Kann man sehen wenn man die Zusatz-LED 
aktiv hat (oder ersatzweise die Channel-LED)

> und nochmal die
> Frage, ist es nicht machbar das man im Single Mode die TB
> veraendern kann solange noch nicht getriggert wurde ?, immer
> in den Run Mode zu schalten dafuer ist etwas umstaendlich (und
> nutzt die Tasten ab ;) )
Muß ich nochmal prüfen, ist aber nicht ganz einfach, da sich das unter 
Umständen mit den virtuellen TB im Stop-Modus beißt.

Gruß Hayo

Kurt Bohnen schrieb:
> Hallo Hayo,
> ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der
> 3.6 geht noch alles.

Hat sich komplett erledigt. Da die USB-Host Firmware etwas umfangreicher 
und anscheinend auch langsamer geworden ist gab es wohl Timingprobleme.

Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung 
liegt Kanal 2 um 2 Pixel zu hoch. Außerdem befindet sich am rechten Rand 
für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3.

Das angehängte Bild bitte ausreichend vergrößern.

Mfg,
Kurt

moin moin Hayo,

so kann man den 'Fehler' reprodzieren:
utility, Default Setup
TB auf 200ms, trigger so einstellen das er vom testsignal
triggert, jetzt auf Single, dann kurz mit dem TK das
Testsignal antippen und beobachten

vlG
Charly

Kurt Bohnen schrieb:
> Außerdem befindet sich am rechten Rand
> für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3.

Bei Kanal 3 und 4 setzt sich das dann fort. Das Gnd-Symbol ist immer zu 
sehen, aber darunter tauchen komische Dinge auf.

Debei ist mir aufgefallen, dass direkt unterhalb des schwarzen 
Zeichenfeldes, also direkt oberhalb der Soft-Menü Tasten oft Reste von 
den Feldern für die Quick Measurement Daten bzw. die berechneten 
Curserdaten zu sehen sind. Die Feldreste entstehen z.B. wenn man Quick 
Measurement aktiv hat und dann über Utility ein Default Setup auslöst.

Aber das ist wohl eher etwas für einen langen Winterabend ;-)

Gruß
Rainer

Nabend,
@Kurt
> Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung
> liegt Kanal 2 um 2 Pixel zu hoch.
Das kann ich bestätigen! Das ist war aber auch bei "fast" allen 
Vorgängerversionen auch so und ist nicht nur bei der GND-Kopplung so, 
zumindest ist das bei mir der Fall.
Ja ja, die Nulllinie war ja schon immer ein Problem...

@Guido,
> Ouh, das ist ein ganz alter Fehler, da habe ich noch ein schlechtes
> Gewissen. Irgendwie geht da das Zählen der Zeilen nicht glatt auf
> oder sowas.
...wieso hast du da ein schlechtes Gewissen???

Das passiert  aber auch manchmal bei anderen einstellungen, das da mal 
ein paar Reste auf dem Schirm bleiben.

LG Michael

Hi Leute,

danke für die Rückmeldungen. Leider bin ich gestern und heute bei 
Kundenterminen und komme daher zu nichts. Werde mal morgen alles unter 
die Lupe nehmen (im wahrsten Sinne).

Gruß Hayo

moin,
wenn ich meine Satzgebung da oben sehe, ohne Worte... ich sollte um die 
Uhrzeit nicht mehr schreiben...

Kein Grund das schlechte Gewissen zu bemühen, schließlich war das doch 
eine echte Hilfe, dass Du die Stellen zum Beheben der Pixelfehler schon 
mal gefunden hattest. Ich wäre da sicher so schnell nicht zu gekommen. 
Ich schau mal ob ich das für das neue Release beheben kann.

Gruß Hayo

So hab das mal geprüft, Guido - Kopf hoch, alles ist gut. Das Löschen 
funktioniert einwandfrei, Du bist also rehabilitiert. Nur wenn man 
direkt aus den Cursorfunktionen ein Defaultsetup auslöst, dann werden 
die Felder nicht ordnungsgemäß gelöscht, da es ja keine normale 
Beendigung der Funktion ist. Kann ich aber nachrüsten.

Gruß Hayo

Es is ja wie es is...              ;-)

So, Überreste sind beseitigt....für immer im Null Device!

Und an den Nulllinienmarkierungen bin ich auch grad dran. Ist mir erst 
jetzt aufgefallen dass da teilweise Nonsense steht. Zum Beispiel ist 
immer das Groundsymbol auf der linken Seite zu sehen was ja überhaupt 
keinen Sinn macht. Das muß anders werden...

Hayo

... und das wird es auch. Ich habe jetzt alle Bitmaps überarbeitet und 
die Formate korrigiert. Das sieht schon ganz gut aus. Meine Frau hält 
mich schon für etwas verschroben, da ich mit der Lupe versuche in den 
Oszi-Bildschirm reinzukriechen :-)

Gruß Hayo

Ha, der Hayo...
dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von 
5m Entfernung!!! Ich weiß, das war jetzt böse... :-)

Was is'n mit der Mess-ID.  "Welec", so wie "TEK", "Hp", "Rigol" ?
Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit 
was da gemessen worden ist! Kannst du das mit einbauen, oder ist das 
zuviel Akt? Dachte nur, wo du schon dabei bist... :-/

Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster 
wäre, hatten wir aber schon mal angesprochen, wollte nur mal in 
Erinnerung rufen.

Gruß Michael

Michael D. schrieb:
> Ha, der Hayo...
> dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von
> 5m Entfernung!!! Ich weiß, das war jetzt böse... :-)
Respekt, dann hast Du gute Augen. Zugegebenermaßen lassen meine seit 
zwei drei Jahren immer mehr nach. Deswegen ist mir das mit den falschen 
Anzeigen auch nicht weiter aufgefallen. Shit...


> Was is'n mit der Mess-ID.  "Welec", so wie "TEK", "Hp", "Rigol" ?
> Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit
> was da gemessen worden ist! Kannst du das mit einbauen, oder ist das
> zuviel Akt? Dachte nur, wo du schon dabei bist... :-/
Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden?


> Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster
> wäre, hatten wir aber schon mal angesprochen, wollte nur mal in
> Erinnerung rufen.
Ist nicht vergessen, gibt es aber noch nicht mit diesem Release, ich 
hoffe Ihr könnt das verschmerzen. Sonst wird die ja auch nie fertig. Ich 
wollte eigentlich wenn Ihr da nichts Grobes mehr habt heute das neue 
Release raushauen. Also wenn Ihr noch was habt dann hurtig, bald ist 
Anzeigenschluß...

Gru0 Hayo

Ist die Unterstützung der Eingangsplatinen schon drin?
Wenn ja ging das an mir vorbei, deshalb habe ich die Betaversionen 
bisher noch nicht angefasst.

Jörg

Hallo Hayo,

> Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden?

ähem, immer noch oben links, in der Ecke?!?

Ok, ich habe mal auf die Schnelle nach ein paar Beispielen geschaut...
guggst du!

Gruß Michael

Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der 
Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und 
siehe da - da stehen die Informationen von Kanal 1.


@Jörg

Ja die Hardwareunterstützung ist im Final Release drin.

Gruß Hayo

Als weiteres Gutie für das final Release habe ich noch am 
Rotary-Interface rumgeschraubt und die Geschwindigkeit bei TB-Wechsel 
und Spannungsbereichwechsel erhöht. Bislang war das doch arg zäh, 
besonders bei langsamen Zeitbasen. Das fühlt sich jetzt schon viel 
besser an.

Gruß Hayo

Hayo schrieb:
> Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der
> Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und
> siehe da - da stehen die Informationen von Kanal 1.
...hab' ich 'geguggt' und weiß ich ja! Vielleicht kann man den Krempel 
ein
Stück nach rechts rutschen?!?
War ja nur so eine Idee, weil fast alle DSO's das haben.
Wenn es zuviel Aufriss ist, dann lassen wir das...

> Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn.
Achso? Hm, wenn von DSO's Fotos geschossen werden, weiß man gleich mit 
was da gemessen worden ist! Finde ich schon informativ.

> Interessant wäre sowas für die Screenshotfunktion. Ob das dann besser am
> PC oder im Welec vor der Übertragung eingeblendet werden soll kann ich
> allerdings nicht beurteilen, da ich dazu die SW zu wenig kenne.
Da wäre Beides auch zu begrüssen, da ja Screenshots eh ein kleineres 
Dateiformat haben, als Fotos.
Ist ja jetzt nicht so Lebenswichtig!

Gruß Michael

Und hier ist sie, die diesjährige Holiday Edition.

Und wieder hat sich sehr viel getan. Dank Eurer Hilfe beim Testen und 
Analysieren konnte die Firmware wieder ein ganzes Stückchen verbessert 
werden. Die neuen Funktionen sind in der Special Functions.txt 
beschrieben.

Ansonsten einfach hier fragen.

Viel Spaß

Hayo

p.s. aufgrund der Komplexität kann sich der eine oder andere Fehler 
natürlich trotzdem noch eingeschlichen haben. Dann gebe ich natürlich 
kurzfristig eine neue Kompilation raus.

Hallo Hayo,

Ich habe deine Holiday Edition gerade mal geflasht und schon mal ein 
wenig getestet.
Shot 1:
Kanal 2 GND-Coupling, ist die Linie jetzt 2 Pixel zu hoch...die Lupe war 
staubig! :-)

Shot 2:
Im Quick Measure steht bei beiden Kanälen Peak to Peak auf 0 Volt beim 
GND-Coupling, das ist prima!

Shot 3:
Im Quick Measure steht auf Kanal 1 Peak to Peak 625mV u. Kanal 2 auf 1 
bis Teilweise 1,5 Volt, bei AC-Coupling! Ich glaube, das ist too much.
Die Spannungen bleiben, egal welchen Filter ich dazu schalte. Kann das 
noch Jemand bestätigen?
Was meinst du?

Gruß Michael

Ok, es sind die "bösen" einer u. zweier Skalen, die ja das extreme 
Grundrauschen mitbringen, dann kann das hinkommen. Die Filter werden in 
dem Fall also nicht berücksichtigt.
Wäre es möglich, das die Filter, die ja das Rauschen unterdrücken, bei 
der Messung mit einzubeziehen? Das soll heissen, wenn ein starker Filter 
ausgewählt ist, sollte das QM das wissen, ist das möglich?

Gruß Michael

Hayo W. schrieb:

> @Jörg
>
> Ja die Hardwareunterstützung ist im Final Release drin.

Ich war gerade im Begriff nachzufragen, was denn die "Final Release" 
ist, ob die "Holiday Edition" (Weihnachtsausgabe?) schon sowas ist.

Nun habe ich in den Code geguckt und meine Hinterlassenschaften 
gefunden. ;-)
Es sind eher zu viele (weil ich dir das so hastig abgekippt habe): Der 
Testcode in hardware_t.cpp kann und sollte raus, das sind die Definition 
und Aufrufe von porttest().
Ferner ist in ADDON_SetSwitches() noch etwas mit #if 0 auskommentierter 
Code, der kann auch entsorgt werden, sowie die auskommentierten 
printf().

Nun sollte ich wohl mal bald die Skalierungsfaktoren bestimmen?


Danke und Grüße
Jörg

@Michael

warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann 
hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei 
Gelegenheit mal nach.

Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da 
stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das 
nicht aufgefallen.


@Jörg

Die Addon-Unterstützung ist ja erstmal auch nur für Dich, da außer Dir 
noch keiner die Teile eingebaut hat. Wenn Du da den Feinschliff gemacht 
hast übernehme ich das einfach in die nächste Version.

By the way - wie findet Ihr die neuen Bitmaps? Achtet auf das schicke 
Average-Zeichen beim Triggerkanal. Und es wird jetzt auch rechts ein 
DC-Symbol eingeblendet.

Gru0 Hayo

hmm...
> warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann
> hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei
> Gelegenheit mal nach.
Ich hatte das wohl irgendwo da oben schon mal abgelassen, jetzt hatte 
ich auch nicht mehr daran gedacht, ausserdem will ich dir nicht ständig 
auf die "Nüsse" gehen...

> Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da
> stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das
> nicht aufgefallen.
Ich finde das QM sehr praktisch für das schnelle Ablesen.
Beim Analogen muß man ja erst mal die 'Kästen' abzählen! Und ja, 
manchmal mache ich mir's halt einfacher, dafür ist es ja da.

Na klar ist mir das neue DC u.AC-Symbol aufgefallen, ist jetzt schön 
lesbar!
Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch 
mal ein Bildchen...

Ok, hier noch ein paar Fehler:
1.Shot:
Im USTB-Modus, bleiben Reste auf dem Schirm, wohin ich auch schalte, die 
bleiben!

2.Shot:
Ich gehe auf 1GSa/s 50ns und die Reste bleiben!
Ausserdem bleiben die Symbole 'Roll Forward' und 'Step' stehen.

Dasselbe passiert auch umgekehrt, gehe ich in den USTB-Modus, bleibt 
oben der Combitrigger und noch andere Bröckchen stehen.

Gruß Michael

und jetzt in's Bett!

Hallo zusammen,
erstmal vielen Dank für den großen, dauerhaften Einsatz für die 
Firmware.

Beim Erforschen der neuen Version sind mir einige Dinge aufgefallen:

Die obigen Bilder sind mit GND-Kopplung auf 1 und dem Testsignal an 2 
entstanden.
Im USTB läßt sich die Kopplung nicht umstellen. Das Menü (GND, DC, AC) 
verschwindet sofort wieder.
Die ganze Bedienung im USTB ist exterm zäh. Das Übertragen eines 
Screenshots dauert ewig (192s gegenüber 15s normal).
Der Shift-Mode (USTB) verschiebt die Nullinie des GND-gekoppelten 
Signals nach unten (bei Reverse doppelt so weit wie bei Forward).
Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich 
erwarten würde...
Oder interpretiere ich was falsch?

Viele Grüße,
Rainer

Hallo nochmal,
die Dateinamen waren wohl ungeschickt gewählt, anbei das noch fehlende 
Bild.

Viele Grüße,
Rainer

Ok danke für die Rückmeldungen,

ich sehe es gibt noch was zu tun. Mal sehen ob ich dieses Wochenende 
noch eine bereinigte Version rausgeben kann.

Gruß Hayo

Michael D. schrieb:

> Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch
> mal ein Bildchen...

Ja, einfach Average einschalten, dann erscheint am Triggerkanal das 
Symbol.

Gruß Hayo

Rainer H. schrieb:

> Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich
> erwarten würde...
> Oder interpretiere ich was falsch?

Was würdest Du denn erwarten? Ich finde das sieht doch gut aus, wenn man 
davon absieht, das die Skalierung etwas ungünstig gewählt ist. die 
sollte möglichst auch bei 500mV liegen um vernünftige Ergebnisse zu 
kriegen.

Gruß Hayo

> Ja, einfach Average einschalten, dann erscheint am Triggerkanal das
> Symbol.

Ha! Ich hab's gefunden...
Was heißt  "Infinite(unendlich)" in Bezug auf den Average-Mode?

Gruß Michael

nimmt man diese Minusfunktion eher für differentielle Signale oder evtl. 
auch für Strommessungen also Spannung vor und nach Shunt? Lässt sich da 
vielleicht eine Invertierung einbauen.

Beispiel Spannung vor Shunt(0,1Ohm) 1V und danach 0,95V = 0,05V / 0,1 
Ohm = 0,5A
bei höherem Spannungsabfall (höherer Stromfluss) soll jetzt das Signal 
auf dem Oszi steigen anstatt ab zufallen oder funktioniert es evtl. 
einfach die Kanäle zu wechseln so das 0,95-1V gerechnet wird?

Hallo Hayo,
Du hast völlig Recht. Irgendwie hab ich die Einstellungen während des 
Tests unbewußt verändert. Also blinder Alarm. Sorry.

Allerdings ist mir beim Testen noch aufgefallen, dass im USTB mein 
GND-gekoppeltes Signal 1 ziemlich Amok läuft.

Viele Grüße,
Rainer

Ja die Groundkopplung ist noch nicht für USTB implementiert. Ich habe 
aber gerade die 4.1 in Arbeit in der alle genannten Punkte bereits 
behoben sind. Ich mache nur noch schnell etwas Feinschliff, dann gibts 
die neue Version gleich hier.

Gruß Hayo

Ok, freigegeben zum Flashen...

Gruß Hayo

Hab auch gleich noch ne Kleinigkeit gefunden. Wenn man "About 
Oszilloscope" drückt wird hinterher nicht alles korrekt wuieder 
hergestellt. Das ist aber auch schon ein alter Bug. Hat wohl noch keiner 
so richtig bemerkt.

Wird natürlich behoben...

Hayo

Ahhh,
das Quickmeasure weiß es jetzt auch, das da ein Filter an ist!
Grafikreste gibt es auch keine mehr.

Ich bin begeistert, nun gibt's den 7.Stern ******* für Hayo!!!

LG Michael

...und das ist noch nicht alles. In der 4.2 die gerade entsteht habe ich 
auch schon mit der Wiederherstellung nach dem Info Screen (Splash) 
aufgeräumt. Man startet daher jetzt endlich genauso wie man das Gerät 
ausgeschaltet hat bzw. wie es vor dem Info-Screen war.

Gruß Hayo

Hallo Hayo,

in der Kombination von USTB mit der Display Einstellung "Persist", wobei 
jetzt einmal dahin gestellt sei, ob das irgendwofür sinnvoll ist, 
merkwürdige Signale.
Mit festen +5V am Eingang sieht mit Persist-Mode "off" alles normal aus, 
bis auf den 0 -> 5V Sprung ganz am Anfang. Ungefähr in der Mitte des 
Bildschirms habe ich dann den Persist-Mode, bei immer noch konstanten 5V 
am Eingang, aktiviert und erhalte den "Lattenzaun" (Bild). Wenn man dann 
innerhalb der Aufzeichnung Persist kurz aus- und wieder einschaltet, 
wird der richtige konstante 5V Pegel angezeigt, bis man einmal kurz das 
Signal auf 0V runternimmt, dann wird wieder der Lattenzaun aufgebaut.

Hast du eine Idee, wo das herkommt?

Gruß Rainer

Jupp, hab ich. Am Gridende geht ja der Pegel von 5V wieder runter auf 
0V, da am Gridende ja der aktuelle Acquisitionzeitpunkt ist und vorher 
anscheinend nichts in den Puffer geschrieben wurde. Dieser Sprung von 5 
auf 0V wird dann durch die persistente Darstellung weiter durchgereicht. 
Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten 
Durchlauf mit 5V hattest wird das sicher nicht mehr auftreten, da ja 
dann schon der 5V Pegel im "Ringpuffer" steht und es keinen Sprung mehr 
gibt.

Gruß Hayo


p.s. ich beiß mir hier gerade die Zähne an der FFT aus. Alles andere 
kehrt super wieder in den Ursprungszustand zurück nach einem Restart - 
nur die FFT nicht, die klemmt danach. Soon Mist...


Hayo

Hayo W. schrieb:
> Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten
> Durchlauf mit 5V hattest ...

Das stimmt. Dann ist das wohl so ...

Dafür hat sich bei mir gerade die Triggerlinie in den oberen 
Bildschirmbereich mit den Meßbereichsanzeigen verirrt.

1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt, 
knabbert das "T" ganz links ein bisschen an der "1" in der obersten 
Zeile

2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu 
negativen Werten schiebt, wandert die gestrichelte Line und das "T" 
incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des 
gleichfarbigen Kanals verschwindet auch ganz. Das sieht so aus, als ob 
das Clipping für den Triggerlevel die Invertierung nicht berücksichtigt. 
Nach unten wird die Triggerverschiebung nämlich sauber begrenzt.

In dem Inset sieht man das schön vergrößert ;-)

Den FFT-Restore wirst du schon knacken.

Gruß Rainer

Manfred,h schrieb:
> Anbei ein Screenshot mit einem kleinen Bug,
> der sich sicher leicht beheben lässt.

Bei mir wird die Periodendauer richtig angezeigt. Wie erzeugst du den 
Fehler?

Gruß Rainer

Hallo Manfred,

es freut mich zu hören, dass Dir die Firmware gute Dienste leistet. 
Danke für den Hinweis, ist natürlich auch schon behoben. Da hatte ich 
die Rundungsroutine ungeschickterweise erst nach der Einheitenermittlung 
aufgerufen, das ist aber jetzt korrigiert.

Gruß Hayo

Moin, moin,

ok werd ich mir auch mal ansehen.

Hayo

Jürgen schrieb:

> Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen
> Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen.
Ist in der neuen Version behoben -> danke

> Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die
> screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi
> selbst :-(
Das kann ich mir leider nicht erklären. Bei mir läuft der Screenshot 
einwandfrei auf zwei verschiedenen Rechnern und auf Windows und Linux. 
Was läuft da bei Dir schief???

Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas 
aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?

Gruß Hayo

> ".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es
> wieder :-)
ach, wo kommt die denn her? Wurde die irgendwie generiert?

Hallo Hayo,

ich habe mir den Screenshot mal 5 Minuten lang angeschaut und mußm dem 
Jürgen zustimmen! Als Designer, würde ich das aber nicht komplett 
zerschlagen. Wie sieht's denn aus, wenn man da 3 Blöcke daraus macht?
Z.B. ein Block für die Kanäle mit Spannung, der nächste Block 1GS/x 20ns 
und den dritten Block mit dem Rest? Dann wäre da nicht so viel 'Unruhe' 
in der Grafik!

Gruß Michael

Ich sehe schon, das spaltet evtl. die Gemeinde. Ich kann mal einen 
Testschalter einbauen, damit man zwischen den Darstellungen auswählen 
bzw. testen kann.

Gruß Hayo

Moin Hayo,

Hayo W. schrieb:
> Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas
> aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?

ich finde die alte Version einfach klarer.

@Michael
Dein Kompromiß wäre eine ernste Überlegeung wert.

Noch mal ein dickes Lob speziell für das jetzt endlich richtig 
benutzbare Delay-Fenster.

Gruß Rainer

p.s. Michael, meintest du etwa so?
Ich bin weiterhin für die alte.

@Jürgen

Kein Problem, lieber einige Rückmeldungen mehr als weniger. Nur so 
kommen wir weiter.

Ich sehe schon, die Tendenz geht gegen die neue Statusleiste. Ich gebe 
zu ich bin auch etwas unentschlossen und schwanke zwischen nettem Design 
und besserem Kontrast.

Ich warte nochmal ab, aber es sieht so aus als würde das neue Design 
wieder sterben....:-(

Hat ne Menge Arbeit gemacht. Aber man muß halt experimentieren.

Hayo

Rainer W. schrieb:

> Dafür hat sich bei mir gerade die Triggerlinie in den oberen
> Bildschirmbereich mit den Meßbereichsanzeigen verirrt.
Ist erledigt.

> 1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt,
> knabbert das "T" ganz links ein bisschen an der "1" in der obersten
> Zeile
Ist erledigt.

> 2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu
> negativen Werten schiebt, wandert die gestrichelte Line und das "T"
> incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des
> gleichfarbigen Kanals verschwindet auch ganz.
Ist erledigt.
>
> Den FFT-Restore wirst du schon knacken.
Ist erledigt


Hier die Vorabversion der 4.2 die schon alle Fixes beinhaltet aber noch 
mit der neuen Statusleiste daherkommt. Vermutlich die einzige Version 
mit dieser Statusleiste.

Gruß Hayo

mir gefällt auch die alte Version der Statusleiste besser. Ich würde 
diese gerne mal mit dem Hintergrund zur Schrift invertiert sehen, sieht 
bestimmt auch nicht schlecht aus. Vielleicht den Schalter dafür 
einbauen.

Um das Gute aus beiden Welten (schickes Design und hoher Textkontrast) 
zu verbinden, habe ich hier mal grob eine Version skizziert, die den 
bisherigen helleren Farbton als Texthintergrund beibehält und eine 
dunklere Farbe als Basishintergrund verwendet. Ob Einzelfelder oder 
Gruppenfelder sei jetzt mal dahingestellt. Die Menüzeile (und 
Meß-/Cursorparameter) könnten dazu passend eingefärbt werden, wobei man 
mal gucken muß, ob mit der verfügbaren Farbpalette guter 
Hintergrundkontrast zum Zeichenfeld und Farben für den 3D-Effekt unter 
einen Hut zu bringen sind.

Gruß Rainer

ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W 
bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen 
das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht 
auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso 
weniger Helle Balken man auf dem LCD hat.

moin  Rainer,
deine Version gefälllt mir ganz gut, vielleicht noch ein ganz helles 
Grau im Hintergrund, mal schauen, wie das kommt...

(hast du meine letzte PN nicht bekommen?)


moin Thomas,
deine Version kommt auch ganz gut! Evtl. noch einen Dunkelgrauen 
Hintergrund, sodas man sieht, wo der Messbereich vom Schirm aufhört?
Wenn das machbar wäre sich die Farbgebung, je nach Lichtverhältnissen 
anpassen zu können, wäre das ein Highlight. Natürlich nur dann, wenn die 
Perfomance nicht darunter leidet!

Gruß Michael

ich finde die Abtrennung zum Messbereiches ist doch durch das 
Raster(Rahmen) gegeben. Anderst würde es das ganze optisch drücken 
wodurch es kleiner aussieht.

...könnte sein. Müsste man mal visuell ausprobieren!

hier nochmal die direkte Gegenüberstellung. Die Spannungsbereiche müssen 
ja nicht weiß gemacht werden, habs nur mal ausprobiert.

Thomas O. schrieb:
> ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W
> bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen
> das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht
> auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso
> weniger Helle Balken man auf dem LCD hat.

Also nachts ohne Licht nutze ich das Oszi recht selten :-) Aber 
ansonsten stimme ich dir voll zu: so ists am besten ablesbar und es 
sieht nicht so vollgequetscht aus. Ich finde es ohne eingefärbtem 
Hintergrund am besten.

@Hayo

hattest du was gemacht an der 'Triggeranzeige' im
Single Mode in der 4.1 ? (geht immer noch nicht) ;(

vlG
Charly

hallo thomas,

der linke Shot sieht gut und aufgeräumt auf.
Wo du schon dabei bist, nimm mal verschieden Grautöne und setze die mal 
als komplette Leiste (ohne die Kästen), hinter die weisse Schrift...mal 
schauen, wie das kommt!

Gruß Michael

welche Kästchen meinst du die der Menüpunkte?

so habe mal die Menüpunkte auch S/W gemacht gefällt mir ganz gut oder 
meinst du die Kästchen ganz entfernen.

> welche Kästchen meinst du die der Menüpunkte?
Nö.
Ich meinte die obere Leiste, ohne die Kästchen mit einem mittleren oder 
dunklen Grau, aber durchgehend von links nach rechts...vielleicht sollte 
man einige Grautöne mal testen?!?

Ich finde den linken Shot auch nicht schlecht! Und überhaupt finde ich 
die Schwarz-Weiß-Kombination schon ansprechend, ist nicht so verspielt.
Was mir gut gefällt, ist die '1 Pixel' breite Kontur., die ist schön 
dezent und nicht so aufdringlich.
Ich bin schon ganz gespannt!!! Wie machst das denn mit den Shots, 
spielst du da im Code?

Gruß Michael

EDIT: Mit der Scwarz-Weiß Kombination, könnte man im Display-Menu 
zwischen positiv u. negativ, je nach Sichtverhältnissen hin u. 
herschalten?!? Da wäre dann für fast jeden was dabei, oder?

noch mal EDIT: Die Kästchen im unteren Bereich, würde ich auf jeden Fall 
lassen...

Hallo allerseits,

bin gerade erst nach Hause gekommen. Hier ist ja ganz schön was los.

@Michael

Die Bilder sind Kopien von meinem Shot. Achte mal auf die Signale. Die 
Bilder sind einfach mit einem Bildbearbeitungsprogramm manipuliert 
worden. Ist aber eine gute Idee um mal ein Gefühl für die Farben zu 
kriegen.

@Charly

Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter 
Bugfix residiert sondern unter Change Request. Habe ich aber auf dem 
Zettel stehen.
(Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?)

@all

Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich 
irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß 
Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar 
nicht :-).

Wenn man die Statusleiste in schwarz/weiß realisiert böte sich 
zusätzlich die Option die weißen Zeichen in den Gridlayer zu schreiben, 
was die Möglichkeit bietet die Helligkeit zu verstellen und auch die 
Farbpalette im Display-Menü einzustellen - so wie bei der FFT wenn das 
s/w Layout aktiv ist.

Gruß Hayo

>Wie machst das denn mit den Shots, spielst du da im Code?
Wie Hayo schon sagte, mit dem Bildbearbeitungsprogramm, ich nehme mit 
mit der Pinzette eine Farbe und Fülle dann einen Buchstaben oder einen 
Bereich mit der selektierten Farbe, etwas unprofessionell, aber 
Paint.net was ich gerne benutze, hat keine Funktionen wie Farbe 
ersetzen.

Mir gefällt auch dieser verspielte Hintergrund nicht einfach Schwarz 
wäre schonmal ein Vorteil, die Schriftfarben sind nebensächlich. Es 
erinnert mich immer ein meinen Sat-Receiver mit klicki-bunti Oberfläche.

all

> Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich
> irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß
> Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar
> nicht :-).
pfff, is' klar! bin auch schon fuffzich und kein
Schwarz-Weiß-Denker :-)))

Ok, das letze Layout von Thomas finde ich schön übersichtlich.
Mein Vorschlag:
Die obere Anzeige mit Hintergrundbalken, Schrift ohne Kästchen und die 
untere Reihe mit Kästchen.
Schriftfarbe für unten u. oben in einem Auswahlmenu veränderbar.
Hinntergrundfarbe für oben u. unten ebenfalls veränderbar,dann bräuchte 
man quasi nur 2 Scrollmenus im Displaymenu, geht das?
Dann wäre für Jeden was dabei und das Welec wäre in der Klasse schon mal 
'einmalig'!
Was meinst du, oder ist das zuviel Aufriss?

Gruß Michael

> Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?

Ich habe das Teil gerade mal an.
Stimmt, da geht erst mal nix! Erst wenn man den entsprechenden Button 
gedrückt hat, dann lassen sich die Zeiten verstellen...
Ich hab's jetzt noch mal getestet, immer mal die Knöppe drücken, dann 
tut sich was, dauert halt ein wenig bis die Zeiten umspringen...

Ist schon nicht so ganz ohne...

Die gelben Buttons habe ich inzwischen schon wieder rausgenommen nachdem 
die allgemeine Stimmung eindeutig dagegen war.

Wie wärs mit einer Testmöglichkeit für den monochromen Status. Die 
Umschaltung geht mit Shift + D via Terminal. Default ist allerdings die 
normale Darstellung.

Gruß Hayo

@Jürgen

sehe ich mir nachher an, muß mal wieder zum Griechen gehen...

Gruß Hayo

das will ich jetzt auch mal ausprobieren. Kann mir jemand kurz sagen wie 
ich dem Welec den Befehl schicke.

na klar!
Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da 
steht alles, ausser Shift+D da steht noch: not available!

Auf dem Screenshot steht alles drauf, guggst du hier:

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

Gruß Michael

Michael D. schrieb:
> na klar!
> Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da
> steht alles, ausser Shift+D da steht noch: not available!

Wie jetzt? Da steht  * Monochrome switch     : Shift + D *

-> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael? 
Steht der Gang zum Augenarzt an?? ;-)

Bitte berücksichtigt, dass in der monochromen Darstellung noch nicht 
alles 100%ig funktioniert, da ist noch das Stopzeichen das stehen bleibt 
und die Kanalnummern hinterlassen Spuren...

Soll halt zum Testen sein. Wenns gefällt kann ich das immer noch 
verbessern.

@Thomas

Du brauchst ein Terminalprogramm. Unter Linux benutze ich immer Minicom. 
Unter Windows ist Teraterm mein Favorit. Gibt es frei zum Download hier:

http://sourceforge.jp/projects/ttssh2/releases/

Gruß Hayo

> Wie jetzt? Da steht  * Monochrome switch     : Shift + D *
ja, steht 'jetzt' da, aber nicht auf dem Link von  meinem Shot...

> -> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael?
nö, noch der Erste...dumdidum

> Steht der Gang zum Augenarzt an?? ;-)
unter Anderem...  :-(

Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine 
Vorverdauung!!!

Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit 
der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor 
lassen?
(Ich denke mal, das das nur mal auf die Schnelle war für's Testen?)

Gruß Michael

Michael D. schrieb:

> Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine
> Vorverdauung!!!
Ist zu Fuß nur 10 Minuten entfernt...

> Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit
> der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor
> lassen?
Geht auch, müßte mal sehen welcher Layer sich da anbietet.

> (Ich denke mal, das das nur mal auf die Schnelle war für's Testen?)
Korrekt, das ist nur um mal zu checken ob das ne Option ist. Der normale 
Status bleibt auf jeden Fall, alles Andere würde ich optional machen 
über irgendein Menü oder Schalter.

Gruß Hayo

Jürgen schrieb:
> Hallo allerseits,
>
> also ich hab da eben ganz andere Probleme :-(
>
> Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?
> Hajo, da scheint etwas durcheinander geraten.

Leider habe ich da einen ganz üblen Bug in die Rundungsroutine 
eingebaut...

Danke für den Hinweis, Abhilfe kommt so schnell wie möglich.

Gruß Hayo

Moin Hayo,

gestern bin ich mal auf FFT gestossen, man hat da keine 
Darstellungsoptionen mehr, ist das noch Baustelle?

Gruß Michael

Wie meinst Du das? Eigentlich sollte alles funktioniern wie bisher - was 
es bei mir auch tut. Was geht denn bei Dir nicht?

Gruß Hayo

für die Spektrum Darstellung, gab es doch mal mehrere Anzeige-Modi (ich 
glaube so 5 Stck.)die man mit dem Drehgeber auswählen konnte, wo ist das 
denn hin?
Momentan ist da Win: Rectangle als feste Darstellung angegeben.

Gruß Michael

Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen 
zweiten Druck auf den FFT-Button.

Ist nicht optimal - weiß ich. Deshalb werde ich auch automatisch ins 
FFT-Menü verzweigen wenn die FFT gewählt wird.

Gruß Hayo

Für alle die nicht so genau wissen wie das mit dem Terminal funktioniert 
hier eine Beschreibung, die ab jetzt auch bei den Releases mit dabei 
ist.

Hayo

So hier die 4.2 mit dem verbesserten Monochrome Status.

Es wird jetzt der cremefarbene Layer benutzt statt des Gridlayers. Der 
weiße Layer geht leider nicht da dieser einen Darstellungsfehler hat der 
Probleme auf der linken Seite verursacht.

Ich finde ja eigentlich den Gridlayer besser...

Gruß Hayo

Jürgen schrieb:

> Hallo Hayo, das wäre super!
Schon geschehen - s.o.

> Ich hab mal im Teil 3 unseres Firmware Threads gesucht, was da noch so
> alles zur Triggerung anlag und in der 4.2pre schon realisiert ist:
Ja hab ich auch schon, aber das ist schon etwas unübersichtlich.

> Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010,  ist
> realisiert
Korrekt, das ist schon drin

> Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht
> realisiert
Oh, den hatte ich allerdings nicht mehr auf der Pfanne -> nehme ich auf

> bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi
> 12.09.2010, nicht realisiert
Den auch nicht -> kann ich einbauen

> und als "nice to have":
> auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu
> können, von weitererGast 30.09.2010
Den hatte ich noch auf der Pfanne, bin aber noch am überlegen wie man 
das am sinnvollsten einbaut.

> Nur, damit es nicht vergessen wird :-)
Alles klar, danke.

Gruß Hayo

> @Charly
>
> Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter
> Bugfix residiert sondern unter Change Request. Habe ich aber auf dem
> Zettel stehen.
> (Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?)

ja das waehre mir am alllerwichtigsten, aber i dachte mir schon das
da noch nix ist, aber die anzeige das ein Triggerevent da war
im Single mode sollte zeitnah sein, im moment ist es so das
es angezeigt wird wenn der Schirm geschrieben wird,

so kann man den 'Fehler' reprodzieren:
utility, Default Setup
TB auf 200ms, trigger so einstellen das er vom testsignal
triggert, jetzt auf Single, dann kurz mit dem TK das
Testsignal antippen und beobachten, erst nach ueber 2 Sekunden
wechselt run/stop auf Rot und die "LED4" Flackert,
meiner meinung nach sollte run/stop direkt beim Triggern auf
Rot und wenn alles aufgezeichnet ist Single von rot auf gruen
Da ich viel im Single Mode arbeite hab i im moment keinen
anhaltspunkt zu sehen ob schon getriggert wurde oder ob das
Oszi noch wartet.

So, i hoffe i habe mich nicht zu kompliziert ausgedrueckt

vlG
Charly

Ok, danke Charly,

ich sehe mir das noch mal genau an.


Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer 
und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es 
aussehen könnte.

Hayo

Da die Pulsweitentriggerung hier einige Male aufkam habe ich die mal 
getestet (hab ich sonst nie benutzt) und festgestellt dass die bis auf 
die "Größer" Funktion überhaupt nicht funktioniert. Da ich nicht weiß 
wie weit oder ob überhaupt diese Funktionen hardwareseitig implementiert 
sind kann ich höchstens mal versuchen das softwaremäßig nachzurüsten -> 
schade eigentlich.

Hayo

Leider sind aber die Register überhaupt nicht dokumentiert. Da heißt es 
zu experimentieren.

Gruß Hayo

Hi Hayo,

> Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen
> zweiten Druck auf den FFT-Button.

Ganz zufällig, habe ich mir da einen Wolf... :-(
...und genau, das habe ich gesucht! Nicht zu fassen, wäre ich nie drauf 
gekommen. Wo ist das dokumentiert?

Die obere Leiste in Monochrome kommmt gut, gefällt mir! Die setzt sich 
noch schön vom Grit ab.

Gruß Michael

Das ist dokumentiert in Special Functions.txt - wie meistens. War aber 
etwas ungünstig vom Handling gebe ich zu. Ab jetzt verzweight er direkt 
ins Menü wenn FFT aufgerufen wird. Der zusätzliche Druck führt aber 
immer noch ins Menü.

@Jürgen

Die Doku kannte ich noch nicht, da werde ich mal sehen ob ich da was 
machen kann, danke.

Gruß Hayo

Hayo W. schrieb:
> Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer
> und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es
> aussehen könnte.

Die Darstellung der Statuszeile mit dunklem Hintergrund scheint mir auch 
sehr gelungen. Allerdings halte ich es für nicht so praktisch, den Text 
in den Gridlayer zu packen, da das Grid doch oft dezent in den 
Hintergrund gedreht wird, man aber die Angaben zum Meßbereich eigentlich 
doch immer in voller Schönheit sehen möchte.

Gruß
Rainer

Michael D. schrieb im Beitrag #2329221:
> Man kann ebenfalls ein beliebiges "NULL-MODEM" Kabel verwenden, sollte
> nur nicht zu lang sein, könnte Übertragungsfehler geben!

Das mit dem "Null-Modem" Kabel halte ich für ein Gerücht. Für die 
Verbindung vom PC zum DSO ist das IMHO ein ganz normales serielles 1:1 
Kabel bzw. USB-Seriell Adapter mit Stecker DE-9 male auf DSO-Seite ohne 
irgendwelche Adernvertauschungen.

... und das funktioniert bestens. ;-)

Gruß
Rainer

Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse 
während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.

Gruß Hayo

> Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse
> während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.

Ihr habt natürlich Recht! Das war Blödsinn. Ich habe beim Mod die 
Löschung beantragt.

Hallo Hayo,
drückt man im Utility Menü auf Default Settings, werden in der Kopfzeile 
die Kanalnummern in einem runden Hintergrund gezeichnet. Hier ist das 
Menüupdate wahrscheinlich noch nicht durchgelaufen... ;-)

Nach längerer Abwesenheit tut sich wieder ziemlich viel hier. Das Scope 
entwickelt sich wirklich klasse weiter. War schon kurz davor, es zum 
Höker zu geben...

<All>
Gibt es eigentlich schon ein Handbuch für das Scope? Sicher, hier 
tüfteln viele Cracks aber nach den Meldungen sind doch auch Einige dabei 
(wie ich), die nur so hobbymäßig rumlöten. Und da fehlt's so manches Mal 
an Infos, was das Teil alles kann und wie man's effektiv einsetzt...

Michel

Hayo W. schrieb:
> Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse
> während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.
>
> Gruß Hayo

Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem 
zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar 
nichts in Sachen Kommunikation PC <-> Scope.

Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit 
dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit 
dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das 
Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort 
aus zu initiieren?

(Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das 
Henne - Ei Problem, oder?)

Michel

also wie tuts das Serielle Kabel mit welchen ich die Firmware aufspiele 
oder nicht. Habs noch nicht durchgemessen ob Nullmodem oder normal.

Zum Terminal habe ich es zeitlich noch nicht geschafft, werde das am WE 
mal nachholen aber die obere Statusleiste sieht schon um einiges besser 
aus.

Ich wollte mein Scopy auch schon dahin tuhen wo es herkam. Aber da hat 
sich die letzte Zeit wirklich was getan, man kann garnicht so oft 
"Danke" sagen wie man will.

Ja es tut sich wirklich wieder was. Ich möchte auch nochmal (hab ich ja 
schon öfters) darauf hinweisen, dass zeitweilige Pausen hier nicht zu 
bedeuten haben dass das Projekt nicht mehr läuft.

Bei mir ist es z.B. so dass ich abhängig von meinen beruflichen 
Projekten manchmal keine Zeit habe , besonders wenn es Auslandsprojekte 
sind. Da kann es dann einfach mal mehrere Wochen Funkstille geben. Das 
Ganze hier ist aber ein langfristiges Projekt und geht auf jeden Fall 
weiter. Sobald ich wieder Luft habe bin ich dann auf jeden Fall wieder 
dran.

Also gebt Eure Büchse nicht gleich weg wenn es hier mal ruhig ist.


@Jürgen

Klasse, werd ich mir mal ansehen und einbauen. Vielleicht können wir den 
PW-Trigger ja doch noch wieder brauchbar machen.

Ich habe mir auch schon überlegt nur die Funktionen per Software 
nachzurüsten die per Hardwareansteuerung nicht realisierbar sind, so 
dass wir aber die volle Funktionalität haben.

Gruß Hayo

Michael W. schrieb:

> Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem
> zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar
> nichts in Sachen Kommunikation PC <-> Scope.
Das ist aber sehr speziell und anscheinend ein Einzelfall. Du kannst ja 
mal genau dokumentieren was da bei Dir im Einsatz ist (Kabel, Interface) 
damit andere da nicht dran verzweifeln wenn sie die gleichen Prbleme 
haben.

> Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit
> dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit
> dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das
> Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort
> aus zu initiieren?
Der USB-Anschluß ist momentan für (fast) nichts zu gebrauchen. Ich habe 
noch ein neues USB-Interface in Planung (bzw. auch schon teilweise 
implementiert). Es gab auch mal jemanden der sich das übernehmen wollte, 
da habe ich aber nichts mehr von gehört.

Zur Zeit kann man die mitgelieferte WELEC PC-Software in begrenztem 
Umfang
benutzen, aber leider ist auch die etwas buggy und es gehen nicht alle 
Funktionen.

> (Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das
> Henne - Ei Problem, oder?)
Die Frage ist durchaus berechtigt. Aber zur Zeit ist die RS232 einfach 
die Schnittstelle der Wahl beim WELEC.

Gruß Hayo

@Hayo

hab grad festgestellt die Freq. messung
zeigt immer 0.00 an ;(
Periodenmessung geht
(letztes release)

vlG
Charly

Ok, check ich

Danke, Hayo