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
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
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
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
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
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
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 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
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.
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
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
Rainer W. schrieb:> 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 ;-)
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.
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
Michael D. schrieb:> ...wieso hast du da ein schlechtes Gewissen???
Weil ich da mal dran war. Wenn ich mich recht entsinne habe ich den
Fehler nach Abschalten der Cursor noch behoben, beim Quickmeasure
und anderen Fällen nicht mehr. Ist arg lange her.
Grüße, Guido
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
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
Michael D. schrieb:> Wo willst Du die ID einblenden?
Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn.
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.
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
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
Hallo Hayo,
wie wäre die Einführung eines Math-Zero-Pfeils? Dann könnte man
schneller beurteilen ob die Ergebnisse stimmen.
Für die Mathematik werden doch sicherlich die spannungsbezogenen Werte
verrechnet und nicht die Binärwerte!?
Ohne das jetzt ausprobiert zu haben, aber lässt sich Math aus skalieren?
Falls ja wäre eine Anzeige in irgendeiner Ecke praktisch.
branadic
> 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
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
Hallo Hayo und alle an der Weiterentwicklung unseres Scopes
Interessierten.
Zuerst meine Gratulation für die neue USTB-Version. Hat bei mir schon
nützliche Dienste geleistet. Anbei ein Screenshot mit einem kleinen Bug,
der sich sicher leicht beheben lässt.
Ich bewundere auch die Geduld mit der Hayo alles anpackt und unser Gerät
inzwischen zu einem (zumindest in meiner Werkstatt) nicht mehr
wegzudenkenden Instrument gemacht hat. Dafür vielen Dank.
Manfred
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
Hallo Hayo,
erstmal Danke für Deine tolle Arbeit!
Ich hab hier noch 2 Dinge aus der 4.1HE:
Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen
Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen.
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 :-(
Gruß Jürgen
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
Hayo W. schrieb:>> 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???
Habe mir das eben nochmal genauer angesehen. Zunächst gleiche Reaktion.
Habe dann im Verzeichnis der screenshot.exe eine Datei
".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es
wieder :-)
Sorry - Hat mich auch gewundert, daß hier Screenshots gepostet
wurden....
Übrigens gefällt mir die alte Statusleiste viel besser!!! Die neue ist
doch zu verspielt und nicht so "technisch"!
Gruß Jürgen
> ".~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
Leider zu früh gefreut :-( Das war nicht die Ursache.
Es geht wieder nicht. Habe noch kein Schema entdecken können. Mal
funktioniert es und mal nicht.
Ich hätte jetzt zwei Verdächtige hier bei mir:
Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34
- Port.
Ich hab mal bei stehendem DSO-Bild mehrere Screenshots mit einem
Terminalprogramm aufgenommen. Etwa 1 von 10 Aufzeichnungen hat eine
andere Länge ??? Kann das sein?
Hajo, halte Dich aber damit erstmal nicht auf. Ich muss das DSO wohl mal
zu meinem PC tragen und dort testen.
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
Hayo W. schrieb:> Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas> aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?
Hallo Hayo,
auch kann mich für das neue Design nicht begeistern. Zu unübersichtlich
- es fehlt irgendwie eine klare Linie.
Gruß,
Bernd
Jürgen schrieb:> Ich hätte jetzt zwei Verdächtige hier bei mir:> Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34> - Port.
Es bleiben die zwei Verdächtigen. Nr.2 würde ich mit Vorurteil(?) als
Hauptverdächtigen bezeichnen..
Hab mit einem anderen Rechner getestet: Screenshot geht einwandfrei.
Ich bitte um Entschuldigung, weil man ja eigentlich hier erst posten
sollte, wenn man solche einfachen Dinge durch Test ausgeschlossen hat
... :-O
Freue mich schon auf die neue Version!
Gruß Jürgen
@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.
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.
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?
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.
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.
Gruß Jürgen
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
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
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
Hayo W. schrieb:> 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
Hallo Hayo, das wäre super!
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:
Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010, ist
realisiert
Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht
realisiert
bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi
12.09.2010, nicht realisiert
und als "nice to have":
auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu
können, von weitererGast 30.09.2010
Nur, damit es nicht vergessen wird :-)
VG Jürgen
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
Danke für die neue Version, Hayo!
Allerdings funktioniert die Pulsweitentriggerung noch nicht wie
gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware.
Z.B. funktioniert die Triggerung am besten nach einem "Center Channel
x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben
oder unten verschoben werden. Danach erfolgt keine Triggerung mehr.
Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach
die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und
"Pulse Width" und es funzt wieder.
Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung
des Triggerwertes.
Gruß Jürgen
Hayo, hab gerade Deinen Post gelesen.
Die Pulsweitentriggerung funktioniert sehr wohl. Es funktioniert ausser
"kleiner" normalerweise alles recht gut.
Also bitte nicht in SW nachrüsten sondern gangbar machen! :-)
Ich habe oben ja versucht anzudeuten, woran es hängt.
Die im Bild gezeigte Impulsform wird überwiegend stabil angezeigt.
Gruß Jürgen
Hayo W. schrieb:> Leider sind aber die Register überhaupt nicht dokumentiert. Da heißt es> zu experimentieren.
Nun, abgucken ist hier aber erlaubt. Habe mir vorhin die originale Welec
V1.4 nochmal "angetan" und vergleiche damit die Registerbelegungen.
Unterschied z.B. V1.4 ctrl_reg: 1807 BF4.2 : 1207
Die Funktion "<" geht dort auch nicht. Zumindest fängt diese Version
sogar den ganz kleinen Impuls aus meiner Beispielimpulsfolge stabil.
Das hängt aber sicher auch mit der Signalhöhe, Triggerpunkt usw.
zusammen, da der FPGA ja etwas zum Auswerten braucht.
In der V1.4 läßt sich aber .B. die Triggerung in beiden Richtungen durch
Verstellen von Triggerhöhe und/oder Pulsweite wieder starten.
Gruß Jürgen
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
Jürgen schrieb:> Allerdings funktioniert die Pulsweitentriggerung noch nicht wie> gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware.> Z.B. funktioniert die Triggerung am besten nach einem "Center Channel> x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben> oder unten verschoben werden. Danach erfolgt keine Triggerung mehr.> Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach> die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und> "Pulse Width" und es funzt wieder.> Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung> des Triggerwertes.
So, ich hoffe ich hab das Problem gefunden :-) Hab mal die Variablen bei
Edge und Pulse Width verglichen, wenn man nur den Kanal hoch und
hinunter schiebt.
Ich denke es fehlt das Update des trg_val_CHI_reg. Dieser Triggerwert
bestimmt die Stelle im Signal, wo die Pulsweite verglichen wird?!
Hajo, ich denke Du weisst eher wo da was zu ergänzen ist ?
Gruß Jürgen
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
Hallo Hayo,
hier die geänderte Funktion SetupTrigger() zur Übernahme. Feinschliff
(ext. Trigger usw.)und weitere Tests (Ch.2-4) dann später. War doch
einfacher als gedacht :-)
Jetzt kann man den Ch1 mit Pulse Width- Trigger über den Schirm jagen
und die Triggerung bleibt erhalten.
GN Jürgen
> 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 W. schrieb:> 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
Hajo, die Idee ist schon gut. Größer">" und Range"><" funktioniert ja
nun ganz gut. Ich hab bloß Bedenken, wie Du per SW das Timing bei "<"
einhalten willst? Im Prinzip kann man ja bei PulseWidth kleiner als
("<") durch Range ("><")ersetzen, weil lt. Welec Spezi im Handbuch der
Zeitbereich auch bei "<" nur von 16ns bis 100ms gehen darf. Ich hab
heute noch etwas experimentiert. Tatsächlich scheint die untere Grenze
auch bei Range eher bei 72ns zu beginnen. Man könnte also bei der
Einstellung von "<" einfach im Hintergrund "><" parametrieren... Oder
man läßt das "<" einfach weg ("temporär"grau machen):-)
Auf der anderen Seite ist meine Zusammenfassung der Kommentare
"registers_nios.pdf" aus den Sourcen noch mit sehr vielen Fragezeichen
versehen. Vielleicht muß nur ein Bit richtig gesetzt werden und alles
funktioniert?
Habe vorhin übrigens mit dem Mode(Auto/Normal/Combi)noch etwas gespielt.
Was spricht eigentlich dagegen dies generell in SetupTriggers()
freizugeben und nicht nur für Edge?
Beste Grüße
Jürgen