Hallo Rainer, > Zum Datenformat habe ich noch folgende Anmerkungen: > 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in > den Header nehmen, damit unter /[Data]/ reine Zahlen stehen Beim naechsten Release, bei diesem hatte ich das vergessen. > 2) Bei channel_delays würde ich channel_delays_ns angeben, auch > damit hinten reine Zahlen stehen (Wer weiß wozu?) Ja. > 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das > Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben > verschoben" assoziiert. [..] Dann bin ich gespannt, wie das mit > fertigen Skalierungsfaktoren Der channel_vzero_levels und channel_scale_factors Kram faellt eh komplett weg sobald ich die Skalierungswerte A und B eingebaut habe, von daher keine Anpassung mehr daran. Niklas
@Niklas ich hatte vermutet, dass die channel_vzero_levels und channel_scale_factors schon die Anfangsstrukturen für die neuen Skalierungsfaktoren sind. Aber dann ist ja alles auf gutem Wege. @August Die Idee mit der Meßdatenübertragung an den PC finde ich sehr gut. Eine Sache die ich mir vorstellen kann, wäre ein Kommando, dass man vom PC an das DSO schickt und dann kommen die aktiven Quick Measure Werte zurück. Wäre das LabView-tauglich? Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer Fernsteuerung des gesamten W2000A vom PC aus aus?
Hallo August, > [..] Impedanz Messungen durchführen(über den gesamten Frequenzgang). > Ich möchte die Auswertung und Darstellung mit LabView machen. > Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. > Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? > Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine > Funktion hinzufügen die, die selektierten Messdaten von der Funktion > „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC > weitergibt. (1) Zur "Quick Measure"-Datenuebertragung: Ja, das ist eine gute Idee, schaue ich mir an. Welches Format waere da interessant? Aehnlich wie es bei den Tracedaten ablaeuft? Also z.B.: <code> [Measurements] frequency_str=<tab>2.5MHz frequency_num=<tab>2500000 [..] </code> Das Ganze dann zusaetzlich zu einem Trace? Optional? (2) Zu LabView und kontinuierliche Messdaten: Ich selbst habe leider keine Ahnung von LabView. Ich weiss nicht, ob sich hier jemand aus dem Forum vllt. schon einmal daran gemacht hat, einen LabView-Treiber zu implementieren, um das DSO darueber zu steuern. Bzgl. der kontinuierlichen Uebertragung der Daten ist zu sagen das dies zwar bei "Quick Measure" noch gut funktionieren wuerde, es aber unmoeglich wird bei den Traces, aufgrund (a) der begrenzten Speichertiefe des Oszis (16kSa/Kanal) (b) der Schnitstelle und nicht zuletzt (c) wegen des langsamen Softcores. Ich glaube auch nicht dass das bei USB grossartig besser wird. Ob es bei 4 Traces alle 6s noch sinnvoll ist diese "kontinuierlich" zu uebertragen weiss ich nicht. Niklas
> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer > Fernsteuerung des gesamten W2000A vom PC aus aus? Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es eine einfache Implementierung, die auf Tastatureingaben eines Terminals reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung hat auch schon jemand für sein Projekt benutzt (Kurt Du?). > Ich möchte die Auswertung und Darstellung mit LabView machen. > Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. > Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? Ist auch machbar und war auch mal für USB von WELEC implementiert - leider so schlecht dass man es rausnehmen mußte. Nur wie Niklas schon sagte wird die Wiederholrate extrem langsam wenn zu viele Daten übertragen werden. Eine Lösung wäre vielleicht wenn nur die 600 Werte des aktuellen Screens übertragen würden. Gruß Hayo
Hallo Hayo, >> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer >> Fernsteuerung des gesamten W2000A vom PC aus aus? Das funzte mal mit der originalen Soft von Wittig, allerdings nur mit der FW 1.4, hatte aber nur funktioniert, wenn sie dazu Lust hatte, dann trampelte die Software manchmal auf der Stelle und es regte sich nichts mehr! > Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung > hat auch schon jemand für sein Projekt benutzt (Kurt Du?). ...wo liegt die denn rum??? Gruß Michael
@Niklas Es gibt noch zwei Werte, die evtl. für die Parameterübergabe interessant wären: - die Pretriggerposition im Speicher (Memory Index 0....16383 / 0....4095) Format ist Integer. - der Pretriggerwert als float. Während dieser vorher nur lokal berechnet wurde habe ich Ihn jetzt global deklariert, so dass er jederzeit zur Verfügung steht. Ich habe die Variablen mal auskommentiert in die CSV-Routine eingetragen falls das von Interesse sein sollte. Hayo
Hallo Niklas Ich habe eher an eine einfache Übertragung wie bei Digital-Multimeter mit RS232 Schnittstelle gedacht. Die im „Quick Measure“ angezeigten Messwerte ( max 3) könnten zum Beispiel mit dem Voltcraft Protokoll übertragen werden. Ist zwar nur für einen Messwert, könnte man aber erweitern. [[http://blog.dest-unreach.be/2009/05/01/voltcraft-vc-940-protocol-reverse-engineered]] Ich werde mich in den nächsten Tagen umschauen welche Protokolle wir verwenden könnten. Der LabView Dateneingang kann an das jeweilige Protokoll angepasst werden. Gruß August
Angehängte Dateien:
-
Trigger_Submenu.jpeg
41 KB
Es ist soweit, wie versprochen die neue Version bei der sich einiges getan hat. Die Highlights sind: - Natürlich die neue Screenshot-Version von Niklas mit neuer CSV-Übertragung - neue double push Funktionalität bei Edge-Button, Pulswidth-Button und Main-Button ebenfalls von Niklas - invert Bug ist gefixt - neuer stabil arbeitender manueller Trigger - neues Trigger-Submenü mit diversen Einstellmöglichkeiten, zu finden im Mode/Coupling Menü. Da sollte für jeden Geschmack was zu finden sein. Weitere Details entnehmt bitte dem changelog und der Datei Special Functions.txt @eProfi Die Schrittweite der Pre Trigger Einstellung habe ich nicht auf die letzte Stelle des Zeitwertes bezogen, sondern auf die Zeitauflösung pro Pixel, da mir das sinniger erschien. Gruß Hayo
Hayo W. schrieb: > Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung > hat auch schon jemand für sein Projekt benutzt (Kurt Du?). Die Remotesteuerung wurde seinerzeit von Bruno im FFT-Screener (Matlab) verwendet. Leider wurde an dieser Baustelle nicht weitergearbeitet und ich komme derzeit nicht dazu mich damit zu beschäftigen, zumal ich eh nur auf Arbeit daran werkeln könnte, da der FFT-Screener nicht kompatibel zu Octave ist. branadic
Hallo Hayo, Hayo W. schrieb: >> ... Und wie sieht das eigentlich mit einer >> Fernsteuerung des gesamten W2000A vom PC aus aus? > > Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es > eine einfache Implementierung, die auf Tastatureingaben eines Terminals > reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von > Falk, die recht umfangreiche Möglichkeiten bietet. Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im Moment als "suggestion" unter http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI beschrieben ist? Dast ist ja noch arg rudimentär und Zukunftsmusik. Das von Falk außeinandergedröselte USB Protokoll bietet da ja schon einiges mehr. Gibt's da Quellcodebeispiele, wie man das unter Win vom PC aus nutzen kann? http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol "Set timebase" über Terminal habe ich gerade probiert (mit BT.2.13 FW). Da tut sich auch etwas, aber außer Debugausgaben kommt nichts weiter zurück. Dabei bin ich auf folgende offene Baustelle gestoßen: Die Umschaltung ist etwas "eigenwillig", d.h. die Kommandowirkung hängt von der vorher eingestellten Zeitbasis ab. Wenn man z.B. <stx>ET<0x18>... schickt, schaltet das DSO auf unterschiedliche Bereiche um, je nachdem wo es vorher stand. (z.B. 5us/div -> 5s/div, 20s/div -> 1s/div, 100ns/div -> 500ms/div). Außerdem kommt man nicht in die ganz langsamen Bereiche, weil Parameter über <0x1F> nicht angenommen werden. Aber ich vermute mal, dass die Baustelle z.Z eher brach liegt, oder? Schönen Sonntag Rainer Edit: Danke für die neue Wochenend-Edition
Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com), un utente mi ha chiesto se Hayo e voi altri accettate donazioni per supportare il progetto, magari tramite paypal o simili, non sono sicuro così chiedo qui. Hello, on the site (recently changed the address: www.cheap-hack.com), a user asked me if you Hayo and other, accepted donations to support the project, perhaps through paypal or similar, I'm not sure so I ask here. By, Gyppe.
gyppe schrieb: > Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com), > un utente mi ha chiesto se Hayo e voi altri accettate donazioni per > supportare il progetto, magari tramite paypal o simili, non sono sicuro > così chiedo qui. > > > Hello, on the site (recently changed the address: www.cheap-hack.com), a > user asked me if you Hayo and other, accepted donations to support the > project, perhaps through paypal or similar, I'm not sure so I ask here. > > Bie, Gyppe.
Hi, ich vergaß noch anzumerken, dass ich aufgrund der umfangreichen Änderungen gezwungen war die Flasheinstellungen zurückzusetzen. Also nicht vergessen das Gerät neu zu kalibrieren und die Hardwareeinstellungen neu zu machen. Please notice that I had to reset the flash. So calibration and hardware adjustment is recommended. @gyppe - no donation, it is just for fun! Hayo
Sapevo avresti risposto così, ma ho comunque chiesto per correttezza. Complimenti sei davvero una persona da ammirare, grazie! :)
This new firmware version was so good that no one have yet posted!!! I've try it to my welec and that's incredible...Thanks at all the staff!! Paolo
Leider habe ich noch einige Bugs entdeckt. Z.B. arbeitete der manuelle Trigger immer noch nicht so richtig unter allen Umständen. Jetzt sollte er es aber tun. Daher noch mal ein Update in dem nur einige Fixes sind aber sonst nix Neues. Hayo
Hallo zusammen! Ich hab seit ein paar Monaten eure Firmware(s) auf meinem Welec-Oszi und möchte mich bei allen Entwicklern hier, vor allem Hayo, mal herzlich dafür bedanken, dass ihr in eurer Freizeit unentgeltlich die Arbeit macht, die die Fa. Wittig leider nicht macht! Die originale Software mit der Wittig die Geräte immer noch ausliefert ist eigentlich eine Frechheit! Inzwischen nehme ich aber doch immer öfters mal das Welec anstatt meines 20 Jahre alten Hameg's, das ich eigentlich mit dem Wittig ablösen wollte... Vielen Dank! Gruß, Michael
New 2.15 version tested. On the welcome screen appear to be a "beta" version... Anyway all the functions that i've can tested are ok. Very good job with the filters!! Thanks again, Hayo and all!! What's the next step? Excuse me for the question, but i don't understand German language and google translate make a bad job: What are the benefits on ADC/DAC substitutions that is described on some previous messages? Ciao, Paolo
Paolo schrieb: > New 2.15 version tested. On the welcome screen appear to be a "beta" > version... don't worry, I just forgot to delete the "beta" > What's the next step? Several little improvements at math-functions and FFT. Hardwaresupport for the new input stage of branadic. > Excuse me for the question, but i don't understand German language and > google translate make a bad job: > What are the benefits on ADC/DAC substitutions that is described on some > previous messages? the 16 Bit DAC has a finer division at zerolevel adjustment. This is only relevant to the 2/0.2/0.02 and 1/0.1/0.01 ranges. It is not really necessary but nice to have. I got the LT2602 as free sample from Linear Technology. They are very small and You need to have some experience in soldering SMD parts if You want to replace them. Kind regards Hayo
>Several little improvements at math-functions and FFT. Hardwaresupport >for the new input stage of branadic. Great! :)
Angehängte Dateien:
-
Left_Edge.png
3,9 KB -
Left_Edge_1_12.png
3,9 KB
Hallo Hayo, die neue Auto-Pre-Trigger Funktion finde ich ausgesprochen praktisch. Beim Messen in der Einstellung "Left Edge" hat sich aber gezeigt, dass es vielleicht günstiger wäre, das "Left" nicht ganz wörtlich zu nehmen, sondern den Trigger auf den ersten Grid Raster zu legen (Left_Edge_1_12.png). Meistens interessiert doch ein bisschen, was vorne los ist ;-) Gruß Rainer
Hi Rainer, gleich vorweg - ich sehe mal zu dass ich das noch als extra Menüpunkt mit einbaue. Zum "Left Edge": Das ist ja den alten Analog-Oszis nachempfunden. Man stellt ja normalerweise die Zeitbasis so ein, dass nach dem Triggerdurchgang etwas mehr als eine Periode auf dem Schirm zu sehen ist. Dann hat man nämlich auch den am Anfang fehlenden Teil der nächsten steigenden Flanke locker mit auf dem Screen. Dazu kommt, dass viele Signale auch nicht so steil ansteigende Flanken haben, so dass auch vom Triggerlevel an die ganze Flanke zu sehen ist. Gruß Hayo
Etwas Anderes, ich mache mir gerade Gedanken über die Ansteuerung der Addon Platine. Hat schon jemand das Teil eingebaut und kann mir gegebenenfalls Testergebnisse liefern? Hayo
Angehängte Dateien:
-
Test01.jpeg
44 KB -
Test02.jpeg
38 KB -
Test03.jpeg
41 KB -
Test04.jpeg
47 KB -
Test05.jpeg
37 KB
So ich hab mal wieder was zum ausprobieren für Euch. Ich habe etwas rumgespielt nachdem ich für Rainer den neuen Menüeintrag eingebaut hatte. Dabei sind wieder die Spikes aufgetaucht und ich konnte feststellen dass die Spikes durch das Verstellen der Timebase verursacht werden. Einstellung: - Triggersource Kanal 4 - Combi oder Norm Trigger - Timebase 50ns - Signal auf Kanal 4 Alles ist gut. Dann Zeitbasis auf 50µs verstellt und wieder zurück auf 50ns siehe Bild Test01. Dann Zeitbasis auf 5µs verstellt und dann zurück auf 50ns - siehe Test02. Dann wieder verstellt und so weiter Test03...Test05. Wenn man das Gerät ausschaltet und wieder einschaltet ist alles wieder gut. Ist das bei Euch auch so? Gruß Hayo
Jo, hatte ich letzte Woche und gerade dann, wo ich es nicht brauchen konnte! Allerdings sporadisch, manchmal auf Kanal 1 dann mal auf Kanal 2 (W2022), wie es gerade Lust hat! Gemessenes Signal war 57 kHz Rechteck an einem LM2576 Adj. Dachte schon, jetzt ist er hinuber!! Die Grundlinie über das Display scheuchen, brachte auch keine Besserung. An der Warmlaufphase scheint es aber nicht zu liegen, da das DSO schon über eine Std. lief. Nach neuem hochfahren, war wieder alles hübsch... Gruß Michael
Aha, ich bekomme das nur auf Kanal 3 + 4 hin. Gruß Hayo
Sehe gerade, du hast 16V Sägezahn!?! Ich hatte bei der Restripplemessung dieselbe Einstellung wie du 2V/DIV, 50nS und Combitrigger "AC", ob das bei "DC" auch der Fall ist? Wenn du das provozieren kannst, dann prüf' das doch mal... Gruß Michael
Hallo, ich melde mich mal kurz. Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h gebraucht (Wegspeichern der in RenderText() berechneten Werte fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der Dimensionierung). Die Ausgabe sieht dann so aus (echte Werte):
1 | meas-000.txt |
2 | [measurements] |
3 | str=;dX = 5.4 us;1/dX = 185 kHz;dY 1 = 29 mV |
4 | desc=;dX = ;1/dX = ;dY 1 = |
5 | dimension=;u;k;m |
6 | unit=;s;Hz;V |
7 | value_bd=;5;185;29 |
8 | value_ad=;4;0;0 |
9 | value_float=;5.4;185.0;29.0 |
Konkrete Vorschlaege/Anregungen gerne willkommen. Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP", "Save to PPM", "Save to CSV" usw. einfach "Screenshot", "Trace" und "Measurements" machen, wobei dann das Format ueber ein Untermenue konfigurierbar wird. @August: Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram geben damit Du das Ganze schon nutzen kannst. Bezueglich meiner Spikes auf Kanal 3+4 beim Nulldurchgang auf dem DSO: Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal, wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was aendert. Negativ. Da das ganze Board ziemlich warm war hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt und bei offenen Geraet direkt gegen die Platine blasen lassen. Das verminderte die Anzahl Spikes jedoch nur gering. Nochmal komplett Front abnehmen, um auf die andere Seite der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit. Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn reproduzieren kann, kann ich mangels schnellem Signalgenerator nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt auch erst bei 50ns sehr haeufig auf. Niklas
Niklas O. schrieb: > Hallo, > > ich melde mich mal kurz. > > Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen > uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. > Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h > gebraucht (Wegspeichern der in RenderText() berechneten Werte > fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der > Dimensionierung). Währe es nicht einfacher den Float-Wert global zu deklarieren und dann per Multiplakation als Integer zu übertragen? > Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP", > "Save to PPM", "Save to CSV" usw. einfach "Screenshot", > "Trace" und "Measurements" machen, wobei dann das Format > ueber ein Untermenue konfigurierbar wird. Das wäre eine Möglichkeit, ich mach mir mal ein paar Gedanken dazu > @August: > Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram > geben damit Du das Ganze schon nutzen kannst. > > > Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal, > wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was > aendert. Negativ. Da das ganze Board ziemlich warm war > hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt > und bei offenen Geraet direkt gegen die Platine blasen > lassen. Das verminderte die Anzahl Spikes jedoch nur gering. > Nochmal komplett Front abnehmen, um auf die andere Seite > der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit. Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert hatte waren etwas nervig). Das ist wirklich angenehm und es wird wirklich ordentlich warme Luft aus dem Gehäuse gedrückt. Der Wackler könnte natürlich durchaus auch auf der anderen Platinenseite liegen. Ausprobieren lohnt sich allemal. Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor: von oben in den Spalt zwischen Knopf und Frontplatte linsen während man den Knopf dreht. Irgendwann kommt die abgeflachte Seite der Achse vorbei... Dann mit einem dünnen Schraubendreher dazwischengehen und mit der flachen Seite des Schraubendrehers den Rand an der Achse als Abstützpunkt beim Hebeln benutzen. Dadurch entlastet man den Rest des Drehgebers. > Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn > reproduzieren kann, kann ich mangels schnellem Signalgenerator > nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt > auch erst bei 50ns sehr haeufig auf. Es tritt nicht nur bei 50ns auf, aber bei 50ns und kleiner werden alle vier ADC dargestellt und dadurch auch alle Störungen, während bei den TB > 50ns immer nur 1 oder 2 ADC zur Anzeige kommen. Da "verschwinden" die Spikes teilweise scheinbar. Gruß Hayo
Hallo Hayo, >> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen >> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff. >> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h >> gebraucht (Wegspeichern der in RenderText() berechneten Werte >> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der >> Dimensionierung). > > Währe es nicht einfacher den Float-Wert global zu deklarieren und dann > per Multiplakation als Integer zu übertragen? Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen. Es sieht im Moment so aus:
1 | void FloatStr::RenderText(void) |
2 | Am Ende: |
3 | // copy values to protected variables for readout via Read_Int(B/A)Dot()
|
4 | Value_BDot = intbd; |
5 | Value_ADot = intad; |
> [..] > Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so > gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert > hatte waren etwas nervig). Das ist wirklich angenehm und es wird > wirklich ordentlich warme Luft aus dem Gehäuse gedrückt. Ja. Rainer hat mir oben auch schon einen leisen Luefter bei Reichelt vorgeschlagen den er bei sich verbaut hat. Das Problem mit dem 80er, den ich Sonntag benutzt habe: Der zieht 0,47A. (Abgesehen davon dass er hoellisch laut ist.) Der Original war iirc. weit unter 0,1A. Bei der naechsten Pollin- oder Reichelt Bestellung bestelle ich einen entsprechenden Luefter mit. > Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor: Beim letzten Mal, Anloeten der zwei Trigger-LEDs, Osrams in SMD, hab' ich da schon viel Freude mit gehabt... (sind btw. hell genug dass die ohne Modifikationen durch den Silkscreen durchscheinen.) Wo wir bei den Drehgebern sind: Bei Yokogawa hab' ich eine nette Vereinfachung bzgl. des Verschiebens der Traces gesehen: Wenn man die Drehencoder schnell dreht springen die Traces von Gridline zu Gridline, bei langsamen Drehen wie gewohnt Pixelweise. Vmtl. haben das die anderen hochwertigen Scopes aber auch. Ich hab' das ganze auch schon mal kurz angetestet, sieht dann im Code so aus:
1 | void UserIF::ON_Zero_Channel_1(void) |
2 | [..]
|
3 | if (Rotary_Direction == 0) //clockwise rotary direction |
4 | [..]
|
5 | else //Main mode TY |
6 | {
|
7 | if (rotbuf > 8) { // rotbuf -> Anzahl Schritte |
8 | int a, b, c; |
9 | // a positiv machen
|
10 | a = Virtual_ZeroLevelCH1 + 4096; |
11 | // naechstgelegene Gridlinie,
|
12 | // vllt. hier noch anders runden
|
13 | b = a/50; |
14 | // zur naechsten Gridlinie springen
|
15 | c = (b+1)*50; |
16 | // Zurueckskalieren und Wert setzen
|
17 | Virtual_ZeroLevelCH1 = c - 4096; |
18 | } else { |
Analog dasselbe fuer die andere Drehrichtung. Der ganze bestehende Code hierzu liesze sich btw. deutlich verkuerzen. ...Und funktioniert soweit. Ist etwas "wackelig", was aber an dem miserablen Response des Scopes liegt, woran wir aber wohl ohne das neue FPGA Design nichts aendern koennen. Ansonsten muss ich wohl eh nochmal an die Front dran, da beim W2024A fuers JTAG eine Loetbruecke fehlt und ich sonst nicht das neue Design ausprobieren kann. Niklas
Hallo Hayo zu den Spikes: (hatte ich schonmal geschrieben) Kannst Du die Frequenz von deinem Generator auch ändern? Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher Zeiteinstelleung am DSO l.G. Roberto
@Niklas > Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen. > Es sieht im Moment so aus:void FloatStr::RenderText(void) > Am Ende: > // copy values to protected variables for readout via Read_Int(B/A)Dot() > Value_BDot = intbd; Verstehe, Du benutzt die Instanzmethode readout() um Dir den Wert zu besorgen, das scheint mir ganz elegant zu sein. Wenn Du mit Deinen Änderungen soweit bist kann ich das ja mit einbauen. > Wenn man die Drehencoder schnell dreht springen die Traces > von Gridline zu Gridline, bei langsamen Drehen wie gewohnt > Pixelweise. Hört sich interessant an, werde ich mal übernehmen und testen. @Roberto > Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher > Zeiteinstelleung am DSO Das muß ich mal testen, hört sich ja merkwürdig an. Gruß Hayo
es gibt einen 80er Lüfter von Papst glaube der macht nur 9 dB, habe 2 davon in meiner PC Front die sind nur hörbar wenn man den Kopf an die Front des PCs steckt. Man muss allerdings auch sagen das der nicht ganz so viel Durchsatz hat wie andere 80er Lüfter.
By the way... > was aber > an dem miserablen Response des Scopes liegt, woran wir > aber wohl ohne das neue FPGA Design nichts aendern koennen. Ich habe mal die USTB-Timerwerte nachgerechnet und habe die akute Vermutung, dass unsere Büchse nicht wie bisher angenommen mit 33MHz läuft, sondern nur mit 25MHz. Das würde natürlich auch Einiges erklären... Hayo
Ich hatte auf dem Board einen 25MHz Quartz gesehen. Die Frage ist aber, ob dann das Timing mit den ADCs noch stimmt. Hayo
@Niklas
Ich habe Deine Idee mal aufgegriffen und etwas umgestrickt. Das sieht
dann so aus und funktioniert ganz gut:
else // main mode
{
if (rotbuf > 10)
{
int div, cmp;
div = Virtual_ZeroLevelCH1/50; // in which div we are?
if(Virtual_ZeroLevelCH1 > 0) // positive
{
cmp = div * 50;
if (cmp == Virtual_ZeroLevelCH1){div--;} // zero level was on grid
division before
}
else // negative
{ div--; } // next grid division
Virtual_ZeroLevelCH1 = (div)*50; // set zerolevel to next grid
division
}
Hayo
> also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder > taktet der FPGA intern? ...den Vorschlag hatte ich letztes Jahr schon mal gemacht! Im Datenblatt müsste ja stehen, was der Prozessor maximal so abhaben kann. Gruß Michael
Normal ist der für 33MHz ausgelegt (im NIOS I Design). Deshalb bin ich ja auch erstmal davon ausgegangen dass es so ist. Nur haben mich die Timerwerte bei den USTB etwas irritiert, da die iterativ ermittelten Werte nicht zu den vorher berechneten Werten passten. Die jetzt verwendeten Werte passen zu einer Taktfrequenz von 25MHz und einem Timer der mit halber Taktfrequenz läuft. Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen und dann mal gucken ob es funktioniert (alle Timerwerte müßte man natürlich anpassen). Evtl. könnte es Problem mit den ADCs geben. Irgend einen Grund muß es ja geben, dass die auf einen Teil der Performance verzichtet haben (man läßt sich ja auch nicht freiwillig ein Bein in Beton eingießen oder?). Gruß Hayo
Angehängte Dateien:
-
Altera_EPSC16_01.gif
40 KB -
Altera_EPSC16_02.gif
28 KB
nun ja, vielleicht wollten die "Welec-Designer", zur Sicherheit unter dem Limit bleiben, damit das Teil nicht abschmiert?!? Ein höherer Takt zieht mehr Leistung und somit auch mehr Wärmeentwicklung, also muß auch mehr Kühlung her, dürfte ja kein Problem sein Den Mega8-16PU, habe ich mal mit 33MHz takten lassen, der wurde nicht mal warm. Ich lege mal 2 Auszüge des Altera EPCS16 bei, schau mal rein. Da steht nur was von der Write Clock Frequency... Gruß Michael
oh, habe ich hier das falsche Datenblatt erwischt???
Hayo W. schrieb: > Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird garnichts mehr funktionieren! Eine weitere Frage ist, was die DCM(PLL) macht, wenn sie plötzlich übertaktet wird. Mfg, Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.
> Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird > garnichts mehr funktionieren! Das vermute ich auch, aber es wäre vielleicht einen Versuch wert. Ich denke kaputt gehen wird wohl nichts, aber es wird wohl nicht sauber laufen. > Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt. Gute Besserung! Hayo
vielleicht sollte man das neue FPGA-Design gleich auf die höhere Taktrate ausrichten 33 MHz sind immerhin ein Zuwachs über 30%
Im neuen Design arbeitet kein NIOS mehr, daher erübrigt sich die Frage der Taktung desselben...
der Leon braucht keinen externen Takt mehr?
Eure Meinung ist gefragt. Ich habe die Idee von Niklas mit den Rasterschritten beim Verstellen des Zerolevels mal für Kanal 1 und 3 eingebaut. Bei Kanal 2 + 4 ist noch alles beim Alten. Ich bin etwas unschlüssig ob das besser ist als das Alte oder nicht. Wie seht Ihr das? -> Die Triggermenüerweiterung für Rainer ist auch schon drin zum Probieren. Gruß Hayo
Hallo! Um das mit dem Takt noch mal abzuklären: Der CycloneII FPGA hat 4 PLLs. Jede PLL besitzt eigene Takteingänge und einen Taktausgang!. Damit muss man den Quarz zwangsweise an allen vier PLL-Takteingängen anhängen. Es sind neben den vier Takteingängen für die PLLs noch andere Takte vorhanden. Sollte das NOIS I Taktnetzwerk sauber mit der Signalerfassungsnetzwerk kommunizieren können und einen eigenen Takteingang haben (beim LEON3 mache ich das beabsichtigt nicht), dann könnte man die Taktgeschwindigkeit erhöhen. Für die vier zeitversetzten Taktsignale der ADCs ist das nicht empfehlenswert, da dadurch die gleichmäßige Abstastung noch mehr zerstört wird! MfG Alexander
Angehängte Dateien:
-
screenshot-0000.png
3,5 KB
habe gerade das Prellverhalten eines Jalousinenschalters getestet und da sind mir wieder einige Bugs aufgefallen. Und zwar erhalte ich im Single Trigger Modus auf Kanal 1 (Kanal 2 nicht getestet) bei einer eingestellten Horizontalauflösung von 1V/Div und einer Abtastrate von 1 mSek/Div keine Auslösung bei einer fallenden Flanke, das Signal ist 5V DC das wie gesagt über einen Taster geleitet wird. Bei 2mSek/Div löst der Trigger auch häufig nicht aus. Bei den andere Abtastraten geht es einwandfrei, bis auf den Umstand das am Ende der Aufzeichnung die ca. letze 5 Stellen im Display immer ein Spike 5V vorhanden ist. Ich vermute das die Zeichenroutine hier etwas verhaut und sich oder irgendwie ein Überlauf der Adressen stattfindet und wieder Daten aus dem vorderem Speicherbereich gezeichnet werden. Beim laden des gespeicherten Traces ist dieser Spike plötzlich weg. Gespeichert wird also der richtige Bereich, beim Betrachten direkt nach dem Auslösen hingegen passt der Speicherbereich nicht 100%tig Oszi: W2022 Firmwareversion: 1.2.BF.2.7
Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound erst damit zu aktivieren oder eine Screenshot.cfg um dort die Einstellung dauerhaft vorzunehmen? Beispiel 1: scrennshot.exe /s = startet die screenshot.exe Datei mit Soundausgabe Beispiel 2: scrennshot.cfg Datei wo Screenshot.exe erst nachschaut was gewünscht wird bevor etwas piepst oder nicht Sound=0 oder 1 Die Familie schläft gerade und nach jeder Dateiübertragung piepst der PC Lautsprecher und da hat man ja leider keinen Einfluss auf die Lautstärke, wenn ich nicht umbedingt einen Poti einbauen will.
Hallo Thomas, > Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound > erst damit zu aktivieren oder eine Screenshot.cfg um dort die > Einstellung dauerhaft vorzunehmen? Die BF-Version wurde wieder mit der OS vereint. Die neuen Versionen haben einen entsprechenden Schalter, dieser lautet "-a" (Alarm). Nur wenn "-a" gesetzt ist bimmelt es. Eine Konfigurationsdatei wird ohnehin in Zukunft kommen. Bis dahin kannst Du die Optionen weiter in die .bat eintragen. Die ist jetzt auch so gebaut dass man sie von anderen Verzeichnissen aufrufen kann und ihr zusaetzliche Parameter uebergeben kann. Aktuelle Screenshot-Programme sind wie gewohnt auch in den Firmware-Releases. Niklas
Hallo nochmal Thomas, > [Triggerverhalten] > Oszi: W2022 > Firmwareversion: 1.2.BF.2.7 Probier' mal die .15 oder .16 aus, am Trigger hat Hayo in der letzten Zeit geschraubt. Niklas
Hallo zusammen, ich habe gerade die neue Variante der Zerolevel Einstellung getestet und muss sagen: finde ich klasse. In der Regel setze zumindest ich die Kanäle ohnehin auf einen geraden Spannungswert, sprich ich verschiebe die Kanäle manuell kästchenweise, weil man sich dann mit dem Ablesen leichter tut. Das geht mit der neuen Variante wesentlich einfacher ohne dass man die Möglichkeit verliert, beliebige Spannungen zu setzen - ich bin also sehr für die Einführung auf allen Kanälen! Das einzige was dabei stört sind mal wieder die unsäglichen Bedienelemente, irgendwann werde ich mir da mal neue suchen müssen. Gruß Michael
Hayo W. schrieb: > Gute Besserung! Danke! http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum Unter Hardware/aktuellste Daten habe ich mal den aktuellen Schaltplan und ein Bild vom Layout hochgeladen. Layout und Schaltplan sind fast fertig und brauchen nur noch kleine Schönheitskorrekturen. Mfg, Kurt
Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Ich habe das aber jetzt trotzdem mal für alle Kanäle eingebaut mit dem Zusatz, dass ab einer bestimmten Menge Drehimpulse nicht nur ein Raster weiter gesprungen wird, sondern zwei. Dann kann man auch etwas schneller über den Screen hoppeln. Ansonsten mache ich gerade eine Komplettrenovierung bei der Autoscalefunktion und im Timebasecontroller. Gruß Hayo
Thomas O. schrieb: > Oszi: W2022 > Firmwareversion: 1.2.BF.2.7 Hi Thomas, danke für die Rückmeldung. Aber wie Niklas schon sagte bitte immer die aktuellste freigegebene Version bei Firmware und Screenshot verwenden. Gruß Hayo
Hayo W. schrieb: > Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Hallo Hayo, die großen Sprünge beim Offset sind bestimmt nicht verkehrt. Ich war da zunächst etwas unschlüssig, da man sowieso bei großen Wegen immer umgreifen mußte. Aber in der alten Version passierte es auch oft, dass sich beim schnellen Drehen mit der Position fast gar nichts tat (Unterabtastung der Geber?) und das ist jetzt in der 1.6 wesentlich besser. Gruß Rainer
Hayo, noch ein anderes Thema: Triggerlevel Läßt es sich ohne großen Aufwand hinbekommen, dass bei Umschaltung der Y-Verstärkung der Triggerlevel (in mV) konstant bleibt? Im Moment muß man bei Änderung vom Y-Gain immer den Triggerlevel ebenfalls nachstellen, wenn der Bezug von Signalhöhe zu Triggerlevel gleich bleiben soll. Ich finde das eher unpraktisch. Und hast du das vollständig disablete Kanal-Soft-Menü nach Abschaltung eines Kanals noch auf deiner ToDo Liste, wo du gerade beim Renovieren bist? Die neue Auto-Pre-Triggereinstellung "First Grid" ist sehr praktisch. Schönen Sonntag Rainer
Angehängte Dateien:
-
screen-0000.png
3,8 KB -
screen-0001.png
3,8 KB
ok habe die aktuelle 2.16 beta drauf und da gibt es die von mir beschriebenen Probleme nicht mehr. Mir ist aber etwas aufgefallen das schon mal gefixt wurde. Wenn man die Zeitbasis streckt sollte das Signal nach rechts gestreckt werden so das die erste Flanke an der gleichen Stelle bleibt. Ist das jetzt evtl. im Menü irgendwo einzuschalten, wurde das wieder absichtlich entfernt oder wurde es vergessen? Das mit Triggerpunkt finde ich genial so kann jeder das ganze so einstellen wie er es braucht. Triggerpunkt auf erstem DIV oder in der Mitte.... Genauso die Einstellung wie man die Singleshot Taste nutzen will, einfach spitze wenn man die Einstellungen so individualisieren kann. Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein zoomen möchte. Wäre es möglich die Dateiübertragung auf den Rechner irgendwie anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? Da beim Upload das Oszi nicht reagiert.
Thomas O. schrieb: > Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass > der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein > zoomen möchte. Muß ich mir mal ansehen, im Stop-Modus hatte ich das nicht getestet. > Wäre es möglich die Dateiübertragung auf den Rechner irgendwie > anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? > Da beim Upload das Oszi nicht reagiert. Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du möchtest die Anzeige dann auch auf dem Screenshot haben :-) Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird es dann nicht mit übertragen. Ich check das nochmal. Gruß Hayo
Hallo, >> (Thomas:) >> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie >> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? >> Da beim Upload das Oszi nicht reagiert. > >(Hayo:) > Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du > möchtest die Anzeige dann auch auf dem Screenshot haben :-) > > Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren > die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird > es dann nicht mit übertragen. Ich check das nochmal. Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten wir doch dafuer verwenden koennen? Falls dies nicht geht koennten wir, da wir Zeilenweise abarbeiten, nach ein paar Zeilen ganz oben eine entsprechende Mitteilung mit Fortschrittsbalken einblenden. Erstere Option waere offensichtlich viel eleganter. Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3] und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp) auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben, stellt sich aber heraus, dass die nirgendwo verwendet werden. Koennen also weg. Niklas
Thomas O. schrieb: > Wäre es möglich die Dateiübertragung auf den Rechner irgendwie > anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen? > Da beim Upload das Oszi nicht reagiert. IMO reicht es, wenn z.B. die LED über dem "Universal"-Regler blinkt. Ich halte es für übertrieben, dafür große Texte im Display einzublenden. Sooo lange dauert es nun auch nicht. Man könnte natürlich in der Zwischenzeit auf dem Screen in einer weiteren Zeichenebene TETRIS spielen. ;-)
Angehängte Dateien:
-
Menue_Disabled.png
2,6 KB
@Niklas Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden, warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird. Gruß Rainer
Niklas O. schrieb: > Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten > wir doch dafuer verwenden koennen? Ich dachte da an die Buffer_Planes. Die werden irgendwann vor der Screenausgabe mit den Hauptplanes verodert. >> Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3] > und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp) > auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben, > stellt sich aber heraus, dass die nirgendwo verwendet werden. > Koennen also weg. Ist erledigt Hayo
Kleiner Zwischenstand aus dem Hackerkämmerlein, ich bin gerade beim Autoscale. Dass das bislang so einigermaßen funktionierte ist eher Zufall. Das ist ein einziges Rumprobieren was der Kerl da veranstaltet hat. Nichts mit Hand und Fuß - also wie gehabt. Ich bin dran... Hayo
@Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder eine blinkende LED gemacht wird ist egal.
Hallo, Rainer: > Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden, > warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird. Ach, da brauch' ich nicht lange forschen. Da diese Ebene beim Schwarz-Weiss Screenshot zu sehen ist und die S/W-Routine auch die Memory Planes (3 Stueck) anschaut, entgegen der Farb-Routine, wird es eine dieser 3 Planes sein. Im Screenshot-Programm hab' ich wohl als Kommentar zu den Memory-Planes geschrieben "not yet determined". Das ist schon laenger her (Mitte 2009 iirc). Ist jedoch kein Problem zu beheben: eine Zeile in der Firmware und vier Zeilen im Screenshot-Programm. Thomas: > @Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu > sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder > eine blinkende LED gemacht wird ist egal. Okay, dann lassen wir eine LED blinken. Niklas P.S.: Bin momentan zeitlich ausgelastet. Ab April ist aber wieder Luft.
Hallo nochmal, bin gerade dabei, mir das Spektrum aus einem Signalgenerator in der FFT anzuschauen und dies zu dokumentieren. Ich habe die Cursor angezeigt um die Grundfrequenz und Amplitude zu vermessen. Jetzt ist der Sinus "leider" so sauber, dass die drei Kaestchen unten die restlichen Frequenzanteile komplett verdecken. Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info Feld anzuzeigen? Im normalen non-Math Modus ist das ja egal, dort schiebt man sich die Traces halt nen Stueck hoeher. Zusatz: Man kann natuerlich durch mehrfachen Druck der Cursortaste die drei Kaestchen ausblenden und sieht die Werte noch ganz unten, aber es gibt sicher auch Situationen wo man die Deltas herausstellen will. Niklas
Niklas O. schrieb: > Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT > entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info > Feld anzuzeigen? Wenn dann würde ich rechts bevorzugen. > Zusatz: Man kann natuerlich durch mehrfachen Druck der > Cursortaste die drei Kaestchen ausblenden und sieht die Werte > noch ganz unten, Das fand ich bislang ausreichend aber man könnte natürlich mal auf die obige Lösung umschwenken. Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase übertragen wird (gibt es nicht mehr), sondern der korrespondierende Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand anlegen? Gruß Hayo
Hallo Hayo, > Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der > Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase > übertragen wird (gibt es nicht mehr), sondern der korrespondierende > Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). > > Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand > anlegen? Das kann ich machen. Ich schaue mal zu das ich moeglichst bis Mittwochabend eine neue Version vom Screenshot-Programm und den entsprechenden Firmware-Diffs fertig bekomme mit den Features die ich in Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" beschrieben habe. Niklas
So nach mehreren Tagen rumgefrickel mit der Autoscale-Funktion sieht es jetzt ziemlich gut aus. Es werden jetzt alle Arten von Signalen sicher erkannt und je nach Anzahl der Kanäle richtig skaliert und auf dem Schirm einsortiert. Den richtigen Triggerlevel gibt es natürlich auch dazu. Wenn Niklas mit seinen Erweiterungen fertig ist, kann ich das zu einer richtig schönen neuen Version zusammenschnüren. Gruß Hayo
Angehängte Dateien:
-
Math_Scale.png
3,1 KB
Hi Hayo, gut hört's sich an. Hast du folgende Bugs bei der "Math"-Bedienung zufällig schon gesehen/abgestellt? - Wenn im Untermenü "Setting" der "Scale"-Regler aktiv ist, leuchtet die LED überm Universalregler nicht und außerdem ist "Offset" nicht aktivierbar. - Wenn die Berechnungsart "1*2" aktiv ist, taucht im Untermenü "Settings" auf dem "Scale"-Button und rechts davon noch Datenmüll auf. Ganz vielen Danke für deine unermütliche Arbeit an der Firmware. Gruß Rainer
Hallo Rainer, ich sehe mir das mal an. Gruß Hayo
@Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis aktivieren? In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach rechts gezeichnet wird, soll das so sein?
Hallo, ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut, wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt. Gruß
Thomas O. schrieb: > @Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis > aktivieren? Leider nein. Ich hatte das schon mal probiert, aber das Timing ist dann so sensibel dass jede Benutzeraktion am Gerät das Signal verfälscht und außerdem braucht ein ADC-Durchlauf gerade etwas länger, als die Abtastzeit in dieser Zeitbasis erfordert. > In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach > rechts gezeichnet wird, soll das so sein? Stört das? Man könnte es evtl. ändern wenn das ein Problem ist. Gruß Hayo
Gerd schrieb: > Hallo, > > ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal > verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im > Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut, > wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen > könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt. Hi Gerd, so was Ähnliches hatte auch Rainer schon gepostet. Den Fix gibt es mit dem nächsten Release. Gruß Hayo
Hallo Hayo, > Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der > Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase > übertragen wird (gibt es nicht mehr), sondern der korrespondierende > Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide). ich hab jetzt gesucht und gesucht, wo finde ich denn diesen "Programmers Guide"? Ich habe wohl Programming Maps gefunden auf der alten Google Seite, aber die laesst er mich nicht runterladen ("W2000A Programming Maps V3.03.zip The page you navigated to does not exist."). Niklas
anbei Diff gegen FW v2.15 und zu ersetzene Files des Screenshot-Programms. Niklas
Hi Niklas, sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle Version immer in das Doc-Verzeichnis des Downloads. Diese hier gehört zum letzten Release. In der Timebase Table findest Du die Spalten für die Indizes. Gruß Hayo
Hi Hayo, Falk, Guido, rowue, Niklas O., KB, Michael D., and guys all! I am back after a long time, I have to update me on the progress, so I will eagerly read the old messages. But I'd like to write some things. @ Hayo First, thanks You very, very much Hayo for the great job and free time You provided generously to us!!! I installed the new 1.2.BF.2.15 and later beta version release and they work well, so Hayo thank You very much for the really amazing great work done!!! As usual I am speechless, RESPECT to You and all other who contribuited!!! It is impressive, it seems to me to use a new DSO!!! If I did not see at it with my eyes I can not believe at it, really incredible!!! No words, RESPECT to You, branadic, Falk, Guido, rowue, Niklas O., KB, Michael D., Jürgen, eProfi, rawi and all other who contribuited!!! Sorry if I forgot someone, really sorry. As I already wrote I have to update me, and then about the old things I would like to remind you: @ Michael D. Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"] > Ich hätte da mal einen Vorschlag: > im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x > Messbereiche zur Verfügung! > Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern > und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja > voranden. I think this is really a great idea. Then there would be more, but first I want to document me about past developments in order to avoid repeating what has already been treated. I want to understand better the situation. Vielen Dank!!! Gruß Luc
Luc schrieb: Hi Luc, welcome back :-) > Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source > Firmware (Teil3)"] > >> Ich hätte da mal einen Vorschlag: >> im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x >> Messbereiche zur Verfügung! >> Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern >> und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja >> voranden. > > I think this is really a great idea. This issue is stored in the "development queue". But there are some more points of interest. So we must see which of them are solved first. In the new release coming out soon You will find multiple bug fixes and improvements. Niklas made several improvements for the screenshot function, and I completely redesigned the Autoscale function. Additionally I implemented a new zerolevel behavior inspired by Niklas. So You can look forward to the next release for You will like it! By the way, did You notice the new functions which came with the last releases? If not -> read the "Special Functions.txt". Regards Hayo
Hallo Hayo, > sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle > Version immer in das Doc-Verzeichnis des Downloads. Genau da wo ich nicht gesucht habe :) Anbei w2000a-screenshot.cpp mit nachgetragenen Werten. Dabei fiel mir noch auf das wir nicht konsequent mit den Begrifflichkeiten sind, ich gebe da bislang die Samplingrate als "timebase_str" und "timebase_num" aus. Habe ich jetzt noch nicht geaendert. Niklas
Hi Niklas, Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte, habe ich das erstmal nicht übernommen. Kannst Du mir da einen Tip geben wfür das gut ist? Gruß Hayo
Und noch ein kleines Problem:
Unter Windows bricht der Compiler ab mit fer Fehlermeldung
- 179 ....converting to int from double
Verdächtiger ist hier folgende Konstruktion:
FOREACH(OUTF( ( ( (data[j*p_numchact(para)+i] - 128) /* X - 256/2 */
* (p_chscalef(para, chlist[i]) / 1000.0) /* Factor */
- p_chvzero(para, chlist[i])) /* VirtualZero */
/ 50.0 ) /* 50px/div */
* -1 /* invert */
* p_chrange(para, chlist[i]).d /* Range */
/ rescalef)
, p_numchact(para));
Gruß Hayo
Hallo Hayo, > Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge > geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht > nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte, > habe ich das erstmal nicht übernommen. Da gibt es keinen Grund fuer, ich habe da glaube ich noch die beiden neuen protected Variablen initialisieren wollen und die Uebergabe zwischendurch erweitert und dann offensichtlich falsch wiederhergestellt. In der Eile gestern ist mir das im Diff dann nicht aufgefallen. > Unter Windows bricht der Compiler ab mit fer Fehlermeldung > - 179 ....converting to int from double > Verdächtiger ist hier folgende Konstruktion: > FOREACH(OUTF [..] Zeile 179 ist ganz woanders. Ich kann den Fehler gerade nicht nachvollziehen. GCC 4.5.2 unter MinGW hat nichts auszusetzen. Bitte kompiliere ohne -Werror usw.. Niklas
Alles klar, alles andere habe ich auch schon eingebaut. Es fehlen nur noch einige abschließende Tests. Ich habe übrigens die Autoscale-Funktion mittlerweile soweit, dass sie stabil von 1Hz - 140MHz arbeitet. Damit komme ich erstmal klar (und Ihr hoffentlich auch) ;-) Gruß Hayo
Hallo Hayo, für die Bedienoberfläche habe ich noch zwei Vorschläge, die den neuen Glanz noch steigern könnten: 1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung eigentlich konsequent, wenn man die Grid-Helligkeit auch durch mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist. 2. Im Eingangskanal Soft-Menü habe ich einen Vorschlag für einen zweiten Modus der "Dispatch" Funktion: a) Analogsignal-Modus (so wie bisher) und b) Digitalsignal-Modus, bei dem die Nulllinien alle eine halbe Kanalbreite tiefer landen. In Hardware::DispatchTraces könnte z.B. abhängig von der Anzahl der aktiven Kanäle (inkl. Math) ein Offset berechnet werden, um den alle Nulllinien nach unten verschoben werden. Aktivieren könnte man diesen Digitalsignal-Modus über Doppel-Push auf "Dispatch Channels". Wie ist die allgemeine Meinung dazu? Gruß Rainer
Hallo Rainer, das sind sehr interessante Vorschläge mit Praxisbezug. Ich prüfe mal was sich davon mit vertretbarem Aufwand umsetzen läßt. Danke für die Anregung Hayo
@Niklas Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. Hast Du da evtl. eine Idee? Gruß Hayo
Hi, > 1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung > eigentlich konsequent, wenn man die Grid-Helligkeit auch durch > mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der > Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg > grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für > den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist. Dem Stimme ich zu, das die "Gridabstufung" zu grob ist! Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist! Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine Sache! ...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!! Gruß Michael
Michael D. schrieb: > Dem Stimme ich zu, das die "Gridabstufung" zu grob ist! Da muß ich aber erst noch prüfen ob eine feinere Abstufung technisch machbar ist. -> ist in Arbeit > Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt > nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, > käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem > Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist! Ich glaube Rainer meinte das als Zusatzoption. Mal sehen... > Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine > Sache! > ...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!! Ja ich hab mich inzwischen auch schon dran gewöhnt, am rumzicken ändert das leider nichts. Der Grund ist auch immer noch nicht ganz klar. - sind es die Drehgeber? - ist es der lahme Prozessor? Wer weiß... Gruß Hayo
Michael D. schrieb: > Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt > nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden, @Michael, darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler sollte alternativ funktieren, damit man die Helligkeit auch direkt verringern kann. Die Frage war nur, ob man dabei ohne großen Aufwand für den Regler andere Stufen als für die Taste verwenden kann. Gruß Rainer
Tja das werd ich mal versuchen rauszufinden. Wenn es geht kriegt Ihr es auch... Gruß Hayo
@Rainer > darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler > sollte alternativ funktieren, damit man die Helligkeit auch direkt > verringern kann. Achso, als zusätzliche Alternative für's "Grobbe" ?!? Das wäre dann auch ok! @Hayo > Tja das werd ich mal versuchen rauszufinden. Wenn es geht kriegt Ihr es > auch... ...au ja Gruß Michael Edit: Hast du was am Quickmeasure was gedreht?
> Edit: Hast du was am Quickmeasure was gedreht?
Nein habe ich nicht. Aber ich habe für Euch was zum Drehen - nämlich am
Helligkeitsregler.
Es ist natürlich nicht die Helligkeit die man da regelt, sondern der
Farbton. Da unser W2000A nicht mit allen Display-Steuerleitungen
arbeitet stehen nur begrenzt viele Farben zur Verfügung.
Um es kurz zu machen - es gibt tatsächlich nur 3 Abstufungen pro Farbe.
Ich kann Euch aber anbieten verschiedene Farbtöne zur Verfügung zu
stellen wenn Euch das interessiert.
Welche Werte da zur Verfügung stehen könnt Ihr mit dieser Version selbst
ausprobieren. Die Farbwerte werden via Terminal ausgegeben.
Die Neuerungen sind natürlich auch schon an Bord. Ihr könnt ja schon mal
testen, vielleich findet Ihr noch Fehler die ich übersehen habe.
Viel Spaß
Hayo
@Hayo ich habe mal ein bisschen Grid-Farben gedreht... Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66% (0x2a) könnte ich mir als Abstufung die 0x1a vorstellen. Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die Sache eher unübersichtlich macht. Da habe ich nichts gefunden. Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die Belegung her? Gruß Rainer
Rainer W. schrieb: > ich habe mal ein bisschen Grid-Farben gedreht... schrill oder...? > Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66% > (0x2a) könnte ich mir als Abstufung die 0x1a vorstellen. ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor. Ich wollte mal ähnliche Farben nebeneinander in ein Array stopfen damit man bein hin und her schalten die Unterschiede besser sehen kann. > Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen > auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die > Sache eher unübersichtlich macht. Da habe ich nichts gefunden. Ging mir auch so > Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die > Belegung her? Ich hab da momentan nichts, aber unsere Hardware Spezis hatten dazu glaube ich was auf SFN veröffentlicht. Da muß ich bei Zeiten mal nach suchen. Aber - gute Nachrichten, mir ist es gelungen beim Screenshot ein Popup einzubauen ohne dass dieses mit übertragen wird. Gruß Hayo
Wer mehr Farben haben will: Beitrag "Re: Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen" Mit dem zum nächsten Grid springen: würde mir gefallen, wenn das eine Tastenfunktion wäre - oder die optionalen Encoder-Taster. Weiß jemand, ob die Abfrage der noch freien Pins des U9 74HCT166 möglich ist, um sie mit den Tastern zu verbinden?
Hayo W. schrieb: > ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor. 0x2A ist ein sauberer Grauton, während 0x1A das Gelb zu sein scheint, das auch oben für den Hintergrund der Bereichsanzeigen verwendet wird. Vielleicht wirkt es dadurch ein bisschen dezenter als das 66%-Grau. Unter den gegebenen Umständen sollte man dann da vielleicht im Moment nicht zu sehr drüber nachgrübeln. @eProfi gut zu wissen, aber alleine wegen der Gridfarbe an der Hardware rumzuschrauben ist mir doch etwas viel Zauber Gruß Rainer
Hi Hayo, hier mal eine kleine Rückmeldung! Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf den Combitrigger? Gruß Michael
Michael D. schrieb: > Hi Hayo, hier mal eine kleine Rückmeldung! > > Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. > Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. Ich bau das auch mit ein, dann hat man was für's Auge > Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das darstellen. > Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf > den Combitrigger? Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es Bedenken? Und in der Final-Version gibt es das Ganze auch noch mit Fortschrittsanzeige, so wie auch beim Screenshot. Gruß Hayo
Hayo W. schrieb: > Michael D. schrieb: >> Hi Hayo, hier mal eine kleine Rückmeldung! >> >> Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind. >> Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung. > Ich bau das auch mit ein, dann hat man was für's Auge > ...genau, tut ja nicht weh! >> Die Gridfarben werden im Screenshot nicht mit aufgezeichnet? > > Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte > den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das > darstellen. > nun ja, ist ja nicht soo wichtig! >> Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf >> den Combitrigger? > > Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es > Bedenken? > nö, ich find's gut! Der Combitrigger, ist so oder so genial und man ist dann auf der sicheren Seite > Und in der Final-Version gibt es das Ganze auch noch mit > Fortschrittsanzeige, so wie auch beim Screenshot. > Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon als "Flash" drinnen! ...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!? > Gruß Hayo Gruß Michael
> Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon > als "Flash" drinnen! Ich hoffe morgen oder Übermorgen. > ...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich > habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und > bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!? Das würde darauf hindeuten, dass es tatsächlich an den Encodern liegt (Billigschrott???) Gruß Hayo
Ok, damit das Warten nicht zu lang wird: - die Fortschrittsanzeigen für Screenshot und Autoscale sind drin - Double Push Funktionalität beim Autoscale Button - Es gibt einen neuen Button "Send Measure" im Quick Print Menü, dahinter steckt Niklas neue Measure Funktion. - die Farbpalette für das Grid läßt sich durch Druck auf den Grid-Intensitätsbutton ändern. In die Final will ich noch einige Goodies einbauen. Mal sehen wie lange ich brauche. testet schon mal, dann kann ich evtl. Fehler gleich mit wegbügeln. Gruß Hayo
moin Hayo, was iss eigentlich mit der 'vernachlaessigten' singel funktion geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten ein schoenes & erfolgreiches WE Charly
Charly B. schrieb: > moin Hayo, > > was iss eigentlich mit der 'vernachlaessigten' singel funktion > geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten Sollte stabil laufen. Im Mode/Coupling Menü gibt es die Möglichkeit im Submenü das Verhalten einzustellen. Probier mal aus und sag Bescheid wenn etwas nicht funktioniert. Gruß Hayo
Hayo W. schrieb: > - die Farbpalette für das Grid läßt sich durch Druck auf den > Grid-Intensitätsbutton ändern. Moin Hayo, verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann? Da hätte ich jetzt einen ganz ketzerischen Vorschlag: - 1 konfigurierbare Palette mit z.B. 4 Werten - Umschalten zwischen den Paletteneinträgen auf Tastendruck (für normale Bedienung) - Festlegung der Paletteneinträge über Drehgeber (zur Konfiguration) - Abspeichern der Palette in den Geräteeinstellungen. Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte. Schönen WE Gruß Rainer
Rainer W. schrieb: > verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten > vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann? Jupp, und hier die Werte: GridColorArray[10][4] = {{0x00, 0x15, 0x2A, 0x3F}, //white {0x00, 0x01, 0x02, 0x03}, //red {0x00, 0x04, 0x08, 0x0C}, //green {0x00, 0x05, 0x0A, 0x0F}, //yellow {0x00, 0x10, 0x20, 0x30}, //blue {0x00, 0x14, 0x18, 0x2C}, //light blue {0x00, 0x11, 0x12, 0x13}, //violet {0x00, 0x16, 0x17, 0x2B}, //pink {0x00, 0x06, 0x0B, 0x1B}, //orange {0x15, 0x1A, 0x2A, 0x3F}}; //test Das sind so ziemlich alle Werte die eine sinnvolle Kombination ergeben. > Da hätte ich jetzt einen ganz ketzerischen Vorschlag: > - 1 konfigurierbare Palette mit z.B. 4 Werten > - Umschalten zwischen den Paletteneinträgen auf Tastendruck > (für normale Bedienung) > - Festlegung der Paletteneinträge über Drehgeber > (zur Konfiguration) > - Abspeichern der Palette in den Geräteeinstellungen. :-) Jetzt willst Du es aber genau wissen... > Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte. Mein Vorschlag ist erstmal für alle die selber kompilieren können: tragt Euch in das Array oben Eure eigenen Werte ein und wenn Ihr eine gute Kombination gefunden habt übernehme ich die gerne in die offizielle Version. Gruß Hayo
Noch ein Hinweis an die unermüdlichen Tester: Beim Autoscale werden alle Suchschritte via Terminal ausgegeben, so dass man alles genau nachvollziehen kann. Gruß Hayo
Hallo Hayo, gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die Idee (stammte sie von Niklas?) finde ich übrigens sehr gut. Zu den Screenshots: Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder geht das per Paramter auf der PC Seite? Die Autoscale-Funktion hat bei ersten Tests gut funktioniert, natürlich muss man etwas Geduld haben aber das lässt sich beim Nios wohl nicht ändern. Allerdings würde es mir persönlich besser gefallen, wenn die Funktion die Zeitbasis so einstellen würde, dass eine Signalperiode auf dem Display zu sehen ist. Beim Test mit dem Rechteckgenerator des Oszis stellten sich 10ns ein, d.h. 12mal Zeitbasis umschalten bevor man eine Periode sieht. Das ist aber sicher Geschmackssache. Ansonsten habe ich einige neue Funtionen entdeckt, die ich gar nicht mitbekommen hatte, da hat sich in letzter Zeit doch wieder gewaltig was getan - klasse. Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf 10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den Default evtl. darauf setzen. GrußKürzlich haben wir übrigend in der Arbeit an unserem Oszi der 40 000 Euro Klasse feststellen müssen, dass der stinknormale Flankentrigger nicht der zuverlässigste ist...da macht unser 300 Euro Oszi gar keine schlechte Figur. Ein schönes Wochenende euch allen! Michael
Hi Hayo I have tested the latest firmware from yesterday. The new Autoscale works great, and the custom grid palette is an excellent idea. Unfortunately I'm not able to use the panning knob when in single shot: I acquire a waveform, I can zoom with the timebase knob, but I'm not able to move around with the smaller delay knob. With 2.15 this was working. Sorry if this issue was addressed before, anbd thank you for all your efforts. Be well, Andrea
Angehängte Dateien:
-
scrhCOM4_batch.gif
8,1 KB
ich noch mal, bei der Autoscale-Funktion, kann man das Signal hoch u. runter bewegen, aber nicht mehr nach links u. rechts, auch wenn ich auf Cursor oder Quickmeasure gehe... Gruß Michael
??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht? @Michael H. also noch mal: Schalter "-a" ist der bestätigungsbeep, Schalter "-b" die permanente BMP Ausgabe. "-c4" ist Comport und dem entsprechend anzupassen. noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!? Gruß Michael
Michael D. schrieb: > ??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht? komisch - scheint verschwunden zu sein > noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die > Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!? Ist noch beta, daher ist noch nicht alles wie es sein soll. Aber danke für den Hinweis, da muß ich noch ran. Gruß Hayo
moin moin Hayo, hatte heut morgen die 2.18 beta aufgespielt, leider dauert das Calibrate Offsets sehr lange (einige Minuten) und danach war keine X-Linie mehr sichtbar und auch keine Signale werden mehr angezeigt. :( hab die mal einen rs232 output vom start an ueber Calibr. Offsets mitgeschrieben, vielleicht hilfts ja oder hab i was falsch gemacht ? vlG Charly
hab jetzt die 2.16b drauf, scheint gut zu laufen, vlG Charly
Hi Charly, habe die 2.18 drauf und das Calibrieren dauert gerade mal 6 Sek.! Hast du mal Default Setup gedrückt? Aprorpos...ich dachte es liegt am Autoscale, dem scheint aber nicht so. Nach Default Setup, kann ich die Signale trotzdem nicht nach links oder rechts verschieben, hoch u. runter geht, was'n da los? Ist das nur bei mir so, oder kann das noch Jemand bestätigen? Gruß Michael
moin moin Michael, ja, ich habe auch default setup gedrueckt, sieht man auch im Log-File, i denke/hoffe Hayo kann sich da ein Bild machen was schief gelaufen ist. i warte halt auf das naechste release vlG Charly
Hi Hayo, - zur Quick Measure Datenübertragung habe ich gleich eine Fragen: Gibt es schon eine offizielle Protokollbeschreibung für die lachenden Männchen, die einem auf dem Terminal zwischen den Daten entgegenkommen oder ist das noch 'in progress'? - Die fehlende Wirkung des X-Position (Pan) Reglers auf den sichtbaren Signalausschnitt kann ich bestätigen. - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Der Fortschrittsbalken beim Screenshot ist super-chic! Schönen Abend und Gruß Rainer
ich habe mir mal die Mühe gemacht und bis hinunter zur 2.12 geflasht. Mit dem FTDI-Dongle dauert das zwar jedes mal 170Sek., aber was soll's... Ab der 2.13 tritt das Problem auf. Mit der 2.12 kann ich mit den Signalen von links nach rechts u. umgekehrt wandern! gruß Michael
Hallo, moin moin, danke für die zahlreichen Rückmeldungen. zur X-Verstellung: - da habe ich doch leider das Coding etwas überoptimiert und eine Zeile zuviel weggehauen bei der ich nicht mehr ganz sicher war wozu ich die gebraucht hatte - jetzt weiß ich es wieder :-) Als Workaround könnt Ihr im Pretriggermenü "Keep Value" einstellen, dann geht es wieder. @Charly Dein Problem konnte ich nicht nachstellen, bei mir funktioniert es super. Dein Log zeigt mir, dass die ADC bei Dir nicht losgelaufen sind - warum kann ich leider nicht sagen. Mich würde interessieren ob das bei Dir reproduzierbar ist. Ich stelle gleich noch mal eine korrigierte beta hier rein die Ihr testen könnt. Gruß Hayo
Moin Hayo, bei Einzeltrigger nach einer TB-Umschaltung sind noch Überreste (?) des alte Kanal 3/4-Problem vorhanden. Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Beim ersten Trigger nach einer Umschaltung der TB wird auf Kanal 3+4 nichts aufgezeichnet. Hattest du da nochmal drüber nachgedacht? Gruß Rainer
Ja da hatte ich schon etliches ausprobiert - leider ohne Erfolg. Das muß also erstmal schuldig bleiben. Wie bei anderen Bugs kann es aber durchaus sein, dass ich im Rahmen anderer Änderungen darüber stolpere. Hayo
@Hayo nach dem Flashen waren beide X-Lines da nur halt verschoben, dann Calibrate und weg waren sie, hab das geraet mehrfach aus/ein geschaltet und Calibrate versucht, leider ohne erfolg. :( Gibt es eigentlich eine neuere Soft zum Flashen unter W7/64 ?, i hab immer noch einen uralt Programmer v. Wellec und der brauch ewig vlG Charly
Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht. Habt Ihr Anderen da Überblick? Hayo
auch moin moin, uns fehlt hier eine Stunde...;) Das "Pre Trigger" Menu habe ich ja voll verpeilt! Da geht ja was. Ich nehme alles zurück, passt schon. Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2 Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen zu lassen, ist das möglich oder eher unpraktisch? Gruß Michael
Angehängte Dateien:
-
Active-Perl-Release_5.8.gif
5,7 KB
> Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du > nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es > eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht. > Habt Ihr Anderen da Überblick? Habe ich mir gerade mal verschafft! Es gibt eine neue Release Ver. von Active-Perl 5.8 Betriebssysteme sind unter Anderem auch 64bit angegeben, siehe Shot! bitteschön... Hier der Link: http://www.activestate.com/activeperl
gibts irgendwo eine Beschreibung wie was wann seriell gesendet wird f. das flashen ? event. kann man das ja selber proggen, oder gehts mitlerweile per USB und i hab das beste verpasst ? vlG Charly
Kleiner Tip für alle die den Überblick über die aktuellen Sonderfunktionen verloren haben: In der Datei "Special Functions" im Doc-Verzeichnis sind alle Funktionen beschrieben. Die Datei wird mit jedem Release upgedatet. Gruß Hayo
Michael D. schrieb: > Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2 > Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen > zu lassen, ist das möglich oder eher unpraktisch? Gute Idee Gruß Rainer
Angehängte Dateien:
Hi Charly, ich muß mich korrigieren, die letzte Release ist die 5.12, besser man nimmt diese! und nein, es funzt im Moment nur über den Serialport! Aktive-Perl installieren, ausführen und im Perl-Package-Manager das Win32-Serialport-0.22-Package installieren( muß aber auch separat heruntergeladen werden! Anbei mal ein Shot, wie das auszusehen hat Ich hatte mal irgenwo eine Anleitung gepostet, finde die aber im Moment nicht... Gruß Michael
Danke Michael, die 5.12 hab ich eben heruntergeladen, werde mal heute Abend testen mit dem neuen release von Hayo vlG Charly
So, das war jetzt etwas mühselig die ganzen kleinen Bugs zu finden.
Ich habe Eure Hinweise alle abgearbeitet und hoffe dass nicht mehr
allzuviel falsch läuft.
- Autoscale -> sucht jetzt schnellere Zeitbasen damit weniger
Perioden auf dem Schirm sind
-> DC-Offset Erkennung (Digitalsignal)
- Dispatch -> DC-Offset Erkennung (Digitalsignal)
- Grid -> Colorpaletten werden jetzt richtig eingestellt und gespeichert
(mein Favourit ist die hellblaue Palette, das erinnert mich
an mein Analog-Oszi)
-> zum Testen gibt es den Testswitch 2 (shift + Y) der sich via
Terminal umschalten läßt.
aus -> normale Intensitätsverstellung
an -> per Drehgeber können die Farben einzeln eingestellt
werden
- X-Verstellung (panning) geht wieder korrekt
Gruß Hayo
Danke! Jetzt gibt's an dem verregneten Sonntag Nachmittag wenigstens was zum spielen! :) Gruß, Michael
Hallo Hayo, super, dann kann man ja noch mal Grid-Farben drehen. Die "Intelligenz" der Dispatch gefällt mir auch sehr gut. Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine Chance. So wie es jetzt funktioniert, muß anscheinend immer ein neues Signal erfaßt werden, damit sich das Signal verschiebt. @Michael - Hier in Stuttgart scheint inzwischen wieder die Sonne :-) Schönen Sonntag Rainer
Hamburg - auch sonnig! Habe gerade meine Sommerreifen draufgezogen... > Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem > Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine > Chance. Wie ist das gemeint mit dem Einzelsignal? Habt Ihr noch was gefunden was klemmt? Gruß Hayo
Hayo W. schrieb: > Wie ist das gemeint mit dem Einzelsignal? Damit meint ich ein einmal erfaßtes Event, also kein periodisches Signal. Wenn das DSO auf Norm Trig steht und ein Event erfaßt hat, muß man erst auf STOP-Taste gehen, damit sich das Signal horizontal auf dem Schirm verschieben läßt. Wenn man nicht auf STOP geht, muß man erst ein neues Signal erfassen, damit des Panning eine Wirkung auf die Signalposition hat. Das mit dem STOP hatte ich nicht gepeilt. Ist ein bisschen umständlich, aber nicht so wild. Schönen Abend Rainer
Dafür gibt es eigentlich die Single-Funktion, die schaltet dann automatisch auf Stop und man kann dann das Signal hin und her schieben. Gruß Hayo
Das Drücken der Singe-Taste vor jeder Erfassung wollte ich ja gerade einsparen ;-)
Wie wärs mit nem Mind Interface? Da braucht man dann gar keinen Knopf mehr zu drücken... Gruß Hayo
Hayo W. schrieb: > Wie wärs mit nem Mind Interface? Hähä Hayo, mit der c't schon durch? Wir wollen eine Kinect-Steuerung. Grüße, Guido
Ich hänge mit der ct leider 6 Hefte hinterher - ich programmiere einfach zu viel, da kommt man nicht mehr zum Lesen. Aber ich habe mal eine Frage, bei mir sind die Spikes auf Kanal 3 + 4 teilweise so heftig, dass kein Autoscale auf diesen Kanälen funktioniert wenn diese die Triggersource sind. Ist das bei Euch auch so? Auf Kanal 1 + 2 ist alles ok. Gruß Hayo
Wetere Erkenntnisse: - Die Spikes treten nur bei warmgelaufenen Gerät auf -> also ein thermisches Problem (hatten wir ja früher schon vermutet). Ich werde da mal nachforschen wie man das wegkriegt, habe auch schon eine Idee. - Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf, die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht das nicht. Ich suche noch nach einer Lösung. Gruß Hayo
Hayo W. schrieb: > - Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer > als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf, > die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht > das nicht. Ich suche noch nach einer Lösung. Kann das eventuell mit dem Kanal 3/4 Erfassungsproblem nach TB Umschaltung zusammenhängen. Deine Autoscale Suchroutine wird doch auch an der TB drehen, ein Signal erfassen (wollen) und das dann auswerten. Nur so ein Gedanke ....
Das Problem ist die grundsätzliche Vorgehensweise. Für die Timebasermittlung wird in den 10mV Bereich geschaltet, damit die Flanken möglichst steil sind und man sie besser zählen kann. Das funktioniert auch ganz gut, nur auf Kanal 3 + 4 scheint dann ab 15 Vpp eine Übersteuerung einzusetzen und die ADC sind dann auf Vollanschlag aber nur nach unten. Gruß Hayo
Hayo, zur Entspannung habe ich noch eine "Oberflächenrauhigkeit" für dich: Wenn man "Display Persist" aktiviert hat und dann "Autoscale" startet, bleibt nach dem Ende vom Autoscale der alte Müll auf dem Bildschirm stehen. Da wäre noch ein feines Plätzchen für ein Clear Display nachdem Autoscale seine Arbeit beendet hat. Die Spikes auf 3 + 4 scheinen immer genauso so hoch wie das Signal zu sein, zumindest bei einem Rechteck. Daraus schließe ich eigentlich, dass es sich um ein sporadisches Adressierungsproblem handelt, so dass ab und zu korrekt gesamplete Daten an der falschen Stelle im Speicher landen. Wo auch immer das passiert ... Gruß Rainer
@Hayo, beim Autoscale in der 2.19 beta bin ich gerade noch auf Signale gestoßen, bei denen sich der Algorithmus verläuft: Signale: Probe Comp an 3, Gnd an 4 ergibt: 100 us/div, 500 mV/div, 10 mV/div (ok) Wenn ich die Signale vertausche, also Signale: Gnd an 3, Probe Comp an 4 endet das bei: 50 ns/div, 10 mV/div, 10 mV/div (Unfug) Eigentlich ist das Signal an Ch4 ja vernünftig. Da die Signalamplitude mit 1 Vpp eher friedlich ist, scheint da im Algorithmus noch was schief zu gehen und eher nicht dein 15V-Problem zu sein. Der gleiche Test mit Ch. 2 + 4 führt oft zum gleichen Ergebnis. Schönen Abend Gruß Rainer
Hallo Rainer, danke für Deinen ausführlichen Testbericht. Bin gerade vom Griechen zurück und arbeite schnell noch die Mails ab. Dein geschilderrtes Problem liegt mit ziemlicher Sicherheit an der reihenfplge der Abarbeitung. Der Autoscale der 2.19 arbeitet so: Spannungsbereich auf 10mV, dann den ersten aktiven Kanal (Reihenfolge 1,2,3,4) auf brauchbare Timebases prüfen. Wenn eine brauchbare Timebase gefunden wird, dann übernehmen. Sonst auf Default 50ns einstellen, weitere Kanäle werden nicht geprüft. Dann wird mit dieser Timebase für alle anderen aktiven Kanäle der richtige Spannungsbereich gesucht. In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet. Die Triggersource wird automatisch angepasst. Wenn kein Sigal gefunden wird dann wird Default eingestellt. Kanäle ohne Triggerbares Signal werden auch nicht mehr auf Spannungsbereich geprüft. Damit ist wahrscheinlich dann auch Dein Problem erledigt. Gruß Hayo
Hayo W. schrieb: > In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven > Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet. > Die Triggersource wird automatisch angepasst. Ich sehe, du bist schon wieder ein ganzes Stück weiter. Bei der Suche nach einer Triggersource kann man vielleicht davon ausgehen, dass der Benutzer schon den richtigen Triggerkanal gewählt hat. Wenn der Algorithmus auf diesem Kanal anfängt, hat er eine große Chance, dass er schon richtig liegt und die Suche gegenüber blindem Durchlaufen aller Kanäle verkürzt wird. Ich bin gespannt auf die 2.20 Gruß Rainer
Hallo, in der 19er springt der Trigger bei angehaltenem Signal schon viel weniger, wenn ich die Zeitbasis umstelle. Von 10ms auf 5ms wechselt er aber immernoch die Position im Signal. Sonst schon viel besser geworden.
Hallo Leute, es gibt jetzt eine Vorschau auf die Firmware: http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum Zur Zeit werden nur SD-Karten unterstützt, obwohl die USB-Geschichte natürlich schon funktioniert! Mfg, Kurt
Angehängte Dateien:
-
tastkoepfe_x1.png
5,1 KB -
tastkoepfe_x10.png
3,9 KB
Hallo, Michael H. schrieb: > gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber > den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die > Idee (stammte sie von Niklas?) finde ich übrigens sehr gut. Die Idee stammt von August. > Zu den Screenshots: > Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu > bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine > Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder > geht das per Paramter auf der PC Seite? Wie Michael D. schon schrieb: Per Parameter -b > Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf > 10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den > Default evtl. darauf setzen. Mhm, ich hab's jetzt nicht ueberprueft, aber sollte nicht die letzte Einstellung des Kanals beibehalten werden, d.h., einmal einstellen auf 10:1 Teiler und damit hat's sich? Ansonsten: Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt. Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz" Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO verglichen. Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD (inkl. Versand) Tastkopf. Die Traces sind etwas verschoben, da ich den Versatz nocht nicht wieder ueber die Delays im Utility-Menue kompensiert habe. Man sieht's aber auch "mit blossen Augen" ohne Cursor recht gut ;) Niklas
Rainer W. schrieb: > - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" > beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. > Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, > wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Mhm, hast Du die aktuelle Version die ich oben dem Hayo gepostet habe? Eine aeltere wird irgendwas in Richtung
1 | w2000a-screenshot: Internal Error: Unhandled dumptype in retrieve() (at 4): 4 |
sagen. > Der Fortschrittsbalken beim Screenshot ist super-chic! ACK, gut gemacht Hayo ;) Hayo W. schrieb: > Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht > richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden > Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. > > Hast Du da evtl. eine Idee? Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass das in den Memory-Planes gezeichnet wird, und diese werden beim Farb-Screenshot gar nicht ausgewertet/uebertragen. Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme aber erst am Wochenende dazu nachzusehen. Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2 nicht nachvollziehen konnte. Niklas
Niklas O. schrieb: > Rainer W. schrieb: >> - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send" >> beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch. Nein, ist auch schon behoben. >> Allerdings macht das Screenshot Programm unter Win direkt einen Abgang, >> wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?) Ich habe jetzt eine WIN32 .exe compiliert indem ich die Option -Werror rausgenommen habe. Läuft bei mir ohne Probleme. Ich gebe die beim nächsten Download mit. >> Der Fortschrittsbalken beim Screenshot ist super-chic! > > ACK, gut gemacht Hayo ;) Danke :-) > Hayo W. schrieb: >> Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht >> richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden >> Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden. >> >> Hast Du da evtl. eine Idee? > > Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass > das in den Memory-Planes gezeichnet wird, und diese werden beim > Farb-Screenshot gar nicht ausgewertet/uebertragen. Das kann ich ich vorab mal checken. > Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme > aber erst am Wochenende dazu nachzusehen. > > Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim > Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2 > nicht nachvollziehen konnte. Keine Ahnung, hab gerade kein Windows laufen, schau ich mal bei Gelegenheit nach Gruß Hayo
Also die Memory Planes werden überhaupt nicht benutzt, ich habe sie daher gelöscht. Der Einzige UI-Layer der einen Buffer benutzt ist der UI-Layer 2 (schwarz). Es liegt also an etwas Anderem. Gruß Hayo
Angehängte Dateien:
-
Testbild.jpeg
46 KB
Ok Fehler gefunden. Ich habe mal ein Testbild generiert und versendet. Man sieht das alle Planes korrekt übertragen werden. Nur im Screenshot-Programm wird die falsche Farbe zugeordnet. Die Buttons haben dann die gleiche Farbe wie die Schrift. Das ist wie ein Eisbär im Schnee. Also muß nur die Farbe in Grau geändert werden und alles ist gut. Ich werde das mal testweise machen. Gruß Hayo
moin Hayo,
> Ich habe mal ein Testbild generiert und versendet.
Wie hast'n das gemacht?
Gruß Michael
Das Testbild könnt Ihr Euch auch ansehen - das erscheint wenn man übers Terminal shift + C eingibt. Danach muß man das DSO aber resetten, da es dann stehenbleibt. Dieses Testbild habe ich dann einfach mal in einer Testversion in den Screenshot mit eingebaut. Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. Gruß Hayo
So es gibt auch eine neue Screenshot Version. Es doch nicht nur die Farbe, ich mußte auch die Layerreihenfolge ändern. Aber jetzt funktioniert es. Daher werden die neuen Versionen (FW + Screenshot) nicht mehr rückwärtskompatibel sein. Dank Niklas schicker Versionsabfrage aber ja kein Problem. Gruß Hayo
@Kurt ich lade gleich hier das neue Major Release hoch. Du solltest Deine Screenshotversion entsprechend anpassen mit der Layerreihenfolge. Ich habe da auf Firmwareseite aber bei Deinen Routinen noch nichts geändert. Ich würde dann die neue Reihenfolge und die Fortschrittsanzeige einbauen wenn Du das möchtest. Gruß Hayo
Ok hier ist es das neue Release. Was ist neu? - redesigned autoscale function with new TB search strategy setup in the autosacle menu. - new double push oprion for autoscale button for slow TB search - new screenshot version with corrected layers - new progress indicator for screenshot and autoscale - added Flat Top window for FFT - new zeroline adjustment - new grid colors which can be set by pushing grid intensity button in display menu For further details please read the changelog and the file Special Functions.txt Gruß Hayo
Noch ein kurzer Hinweis: Da die neuen Menüs Ihre Startwerte aus dem Flash beziehen kann es sein, dass beim ersten Aufruf falsche Werte eingetragen sind. Das erledigt sich nach dem ersten Aufruf der Menüs aber von selbst. Hayo
Hallo, ich habe mit der neuen 1.2.BF.3.0.zip das Problem das Calibrate offsets nicht geht. Identisches Problem wie bei charly hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Ansonzten saubere Arbeit! Gruß Torsten
Hallo Torsten, ich habe mal die neue Firmware auf mein zweites DSO gespielt und kann auch da die Probleme nicht nachvollziehen. Alles funktioniert bestens. Mein Vorschlag zur Vorgehensweise: - Gerät ausschalten und wieder anschalten - ins Utility Menü wechseln - Default Setup - dann das Calibration Set <Standard> explizit auswählen, auch wenn es schon auf dem Button angezeigt wird - Terminal starten damit man die Ausgaben sehen kann - Kalibrieren Die Terminalausgabe in eine Datei kopieren und hier posten. Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale Menu für TB Search ist völlig vergurkt und richtet sich auch nicht selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch aus? Gruß Hayo
Hallo Hayo, hab das mal so gemacht wie vorgeschalgen, im Anhang das Log dazu. Den Fehler im TB Search Menu sehe ich allerdings nicht. Gruß Torsten
Hallo Hayo, welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes? Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den Planes. Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert. Die Neuerungen beim DUMPCSV brauchst du noch nicht bei mir einbauen, die muss ich mir nochmal genauer ansehen. Auch beim Send Measure werde ich mal sehen müssen on ich das übernehmen kann. Mfg, Kurt
Hayo W. schrieb: > Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale > Menu für TB Search ist völlig vergurkt und richtet sich auch nicht > selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch > aus? Hi Hayo, danke für den inflationären Versionssprung. Bei meinem W2024A gibt es nach einem "Default Setup" weder mit "Calibrate Offset" noch mit dem Autoscale "TB Search" Menü irgendetwas zu meckern. Die Lösung mit TB Search auf Trig Source finde ich sehr gut. Bin gespannt, was sich noch alles so getan hat. Gruß Rainer
Hallo Jungs, danke für die Rückmeldung. Bin gerade vom Training und wie so oft vom Griechen zurück. @Torsten Danke für das Log. Ich habe eine Idee wo ich suchen muß. Wenn ich was finde liefere ich schnellstmöglich einen Fix. Stell mal vor dem Kalibrierungslauf den Trigger auf Auto! Wenn es dann funktioniert weiß ich was es ist. Gruß Hayo
Hallo, gerade die v3.0 ins Flash geladen. Sieht gut aus! Was womoeglich auch fuer die anderen relevant sein koennte (obgleich ich da nicht wirklich einen Erklaerung fuer habe): Nach manchen Firmwareupdates habe ich ploetzlich staerkeres Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein, wie es auch gerade wieder passiert ist. Das laesst sich bei mir dann beheben durch Laden eines Komplettdumps vom DSO im Auslieferungszustand von den Wittigs. Danach dann die neue Firmware, Rauschen ist weg. Das Screenshotprogram warnt wegen des unverhofft hohen Versionssprungs zwar, das kann aber getrost ignoriert werden. Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei Sourceforge dokumentieren. @Hayo: > [Testbild] > Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. Oeh, Pixelfehler? Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut das die Layer einzeln in Dateien abgelegt wurden, so dass man diese dann bei Darstellungsproblemen einzeln untersuchen kann. Das ist dann irgendwann weg gefallen. Macht es Sinn das als Spezialfunktion wieder einzubauen? Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, was viele unter Windows nur wegen der GERMSloader.pl bei sich installiert haben: Besteht Interesse an einem einfachen Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne grossen Aufwand realisieren. Es gab aber auch mal ein Tool fuer Windows mit GUI, was ist eigentlich daraus geworden? Niklas P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf aus China in Stellung 1:1 eine hoehere Bandbreite hat als die Welecs?
Ab sofort nehme ich die Vorbestellungen für den USB-Host an. Weitere Infos auf http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum#Sammelbestellung (Der Rest des Artikels wurde auch aktualisiert, insbesondere die Eagle Dateien!) Bei Fragen oder Anregungen meldet euch bitte hier im Forum oder per mail (SF Adresse). Mfg, Kurt
Hallo! Ich hätte enormes Interesse an der USB Erweiterung! (sorry dass ich so reinplatze, aber ich verfolge die Entwicklung immer mal wieder nebenbei, tausend Dank an alle Beteiligten!) Fragen: - Werden USB-Sticks > 2GB unterstützt (Habe das Problem regelmäßig an mittelalten Teks) - Welche Gehäusemodifikationen muss ich vornehmen? Habe gerade keine Vorstellung, wie die Platine in "echt" da reingehört. Aber ich habe jetzt den HW-Thread auch nur überflogen - steht das irgendwo? Sorry, wenn ich das übersehen habe, ich dachte nur ich melde mich gleich bevor die Dinger weg sind ;) Bzw. - Wenn ich schon "blöd" frag: Vllt. gibt es ja wieder mal "huckepacks" in der nächsten Zeit. Gäbe es vllt. jemanden mit mehr "Fingerspitzengefühl" und "Ästhetik" wie mir, der mir mein 2Kanal Gerät umrüsten würde? Selbstverständlich gegen anständiger Bezahlung. Hab leider keine anonyme E-Mail, aber wer evtl. Zeit für sowas hat kann hier ja eine Möglichkeit der Kontaktaufnahme Posten :) Beste Grüße, Pat
Hi pat, reinplatzen darfst du, ich habe ja ausdrücklich darum gebeten. ;-) pat schrieb: > Werden USB-Sticks > 2GB unterstützt Höchstwahrscheinlich ja, die VNC2 Firmware untestützt auch FAT32. Ich kann es aber noch nicht testen da ich meinen großen Stick irgendwo verbummelt habe. pat schrieb: > Welche Gehäusemodifikationen muss ich vornehmen? Wenn du ein externes 12V Netzteil verwendest, keine. Willst du den USB-Host vom Oszi aus versorgen musst du eine kleine DC-Buchse einbauen und irgendwo an die 12V Leitung löten. pat schrieb: > Habe gerade keine > Vorstellung, wie die Platine in "echt" da reingehört. In ein externes Gehäuse. Siehe o.g. Link (über deinem Post) auf den SF-Artikel. pat schrieb: > Vllt. gibt es ja wieder mal > "huckepacks" in der nächsten Zeit. Wird es definitiv geben. Als Teilesatz von mir, evtl. inkl. Platine. Das muss ich aber noch mit Bernhard klären. pat schrieb: > Hab leider keine anonyme E-Mail, Das ist schlecht. Ich brauche eine mail mit der Vorbestellung von dir, sonst verliere ich den Überblick. Mfg, Kurt
Hi Niklas, Niklas O. schrieb: > Nach manchen Firmwareupdates habe ich ploetzlich staerkeres > Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) > auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein, > wie es auch gerade wieder passiert ist. Das laesst sich bei > mir dann beheben durch Laden eines Komplettdumps vom DSO > im Auslieferungszustand von den Wittigs. Danach dann die > neue Firmware, Rauschen ist weg. Hattest du vor dem Rückspielen der Orig-FW die üblichen "Default Setup" und "Calibrate Offset" einmal durchlaufen lassen? > Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung > gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei > Sourceforge dokumentieren. Das wäre prima, eilt aber nicht. Die Quick Measure Ausgabe macht schon wieder Lust auf mehr. Zwei Dinge fallen mir da spontan ein: - Ausgabe mehrerer Messungen in eine Datei mit Time-Stamp, jeweils eine Messung pro Zeile - Automatische Ausgabe bei jedem Trigger -> eine Datei > P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf > aus China in Stellung 1:1 eine hoehere Bandbreite hat > als die Welecs? Von der 1:1 Messung war ich schwer beeindruckt und habe mich nur gewundert, das die W2022 im Moment in der eBucht ohne Tastköpfe für um die 200 über'n Tisch gehen.
Hi Kurt, auch ich melde hiermit Interesse an. Ich bin zur Zeit nur noch unschlüssig ob ich einen oder zwei haben möchte. Auch ich hatte geplant das Teil ins Gerät einzubauen. Gruß Hayo
Hallo Hayo, hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne Erfolg. Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf und dann die 3.0. Gruß Torsten
@Hayo, bitte schicke mir eine mail! Mfg, Kurt
Niklas O. schrieb: > Nach manchen Firmwareupdates habe ich ploetzlich staerkeres > Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4) Das liegt daran, dass ich bei manchen FW-Versionen das Flash zurücksetzen muß um neue Variable zu initialisieren. Das betrifft aber nur die Hardwareeinstellungen und die Offsets (ADC + DAC). Dadurch wird dann das Rauschen stärker. Da muß man nur einfach die Hardwareeinstellungen neu machen und einmal kalibrieren - fertig. > @Hayo: >> [Testbild] >> Man kann auch schön den Pixelfehler in der UI Plane 1 sehen. > > Oeh, Pixelfehler? Ja, die UI_Plane1 hat einen Pixelversatz von 32 Pixeln im Videospeicher, die am Ende (rechts) abgeschnitten werden und vorne (links) eingefügt werden. Das sieht man aber nur auf dem DSO, nicht im Screenshot, da im Screensh. die Pixel korrekt wiedergegeben werden. > Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut > das die Layer einzeln in Dateien abgelegt wurden, so dass man > diese dann bei Darstellungsproblemen einzeln untersuchen kann. > Das ist dann irgendwann weg gefallen. > > Macht es Sinn das als Spezialfunktion wieder einzubauen? Ja unbedingt. Das war ein Grund, warum ich solange an der BF-Version festgehalten habe. > Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, > was viele unter Windows nur wegen der GERMSloader.pl bei sich > installiert haben: Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Ach hier ein unbedingtes ja! Denn viele etwas unerfahrene User scheuen sich davor das Perl zu installieren. > P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf > aus China in Stellung 1:1 eine hoehere Bandbreite hat > als die Welecs? Ich dachte zuerst Du hättest Dich mit der Angabe der Kanäle vertan. Aber dann stimmte das also doch! Strange! Gruß Hayo
Torsten W. schrieb: > Hallo Hayo, > hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne > Erfolg. > Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf > und dann die 3.0. Warte noch mal. Ich habe gerade die zweite Compilation fertig. Da sollte der Fehler behoben sein, genau wie das Menüproblem im Autoscale-Menü, das aber nur bei 2-Kanalgeräten auftritt! Da habe ich wieder eine Altlast unseres WELEC-Programmierers gefunden die mir bislang nicht aufgefallen war. Gruß Hayo
Kurt Bohnen schrieb: > Hallo Hayo, > welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes? Da die Fortschrittsanzeige direkt in den Videospeicher geschrieben wird aber nicht mit übertragen werden soll, kopiere ich den Inhalt des Videospeichers vorher in die Bufferplanes und übertrage dann statt des Videospeichers die Bufferplanes. > Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige > einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den > Planes. Ich habe die Fortschrittsanzeige nur in die Screenshot-Routinen eingebaut, da die Datentransferroutinen so schnell sind, dass es hier überflüssig ist. > Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert. Hatte ich nur vergessen, da ich die B/W Funktion selbst nicht nutze - hab ich aber jetzt nachgerüstet. Gruß Hayo
Second compilation out now! I'm sorry for the bugs I didn't saw in the first comp. In der zweiten Kompilation sollten jetzt alle gemeldeten Fehler beseitigt sein. @Kurt Deine Screenshot-Routinen habe ich auch erweitert. Gruß Hayo
Hi, @Niklas > Das laesst sich bei > mir dann beheben durch Laden eines Komplettdumps vom DSO > im Auslieferungszustand von den Wittigs. Danach dann die > neue Firmware, Rauschen ist weg. Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm) modifiziert? > Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam, > was viele unter Windows nur wegen der GERMSloader.pl bei sich > installiert haben: Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne > grossen Aufwand realisieren. Ja, immer her damit! Mit dem Germsloader scheint es bei manchen Usern immer noch Probleme zu geben, da wäre das eine gute Alternative! Perl nimmt jede Menge Platz weg und es ist auch ein wenig umstandlich mit der Installation. Gruß Michael
Hallo Hayo, die C2 funktioniert nun auch bei mir bestens. Herzlichen Dank auch! Woran lag es das das gerätespezifisch war? Gruß Torsten
auch hallo Hayo, ...hast du jetzt was am Quickmeasure gedreht? Jetzt habe ich ohne Signal auf Kanal 1 -Pk-Pk 1,04V und auf Kanal 2 sogar Pk-Pk 1,14V ! Wenn man mal schnell was messen will, ist das schon ein bißchen viel, oder? Voher hatte ich so um die 160mV, schwankend...aber über 1Volt, finde ich heavy. Anbei mal ein Shot LG Michael
Angehängte Dateien:
-
Quickm_PeaktoPeak1.14V.png
4,3 KB
...hmm, der wollte nicht mit, jrtzt aber! Eingeschaltet ist der Smooth-Filter
Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig eingestellt und auch kalibriert? Gruß Hayo
Angehängte Dateien:
-
fw_v3.0_before.png
4,8 KB -
fw_v3.0_after.png
4,8 KB
Hallo, @Michael: > Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm) > modifiziert? Ich meinte mit "weg" natuerlich das zusaetzliche Rauschen. Die Eingangsstufen sind unmodifiziert. Auch kein Averaging oder Noise Filter eingeschaltet. @Hayo, Rainer: Default-Setup habe ich gemacht. Calibrate Offset benutze ich dauernd da der GND-Level staendig wegdriftet. Ich habe gerade mal gemacht was ich beschrieben habe, das Ergebnis seht ihr in den Screenshots. Der Unterschied ist minimal. Vllt. haengt es auch gar nicht damit zusammen. Ich hatte das vor laengerer Zeit aber schonmal heftiger. Ob ich davor wirklich Firmwareupdate gemacht habe weiss ich nicht mehr. Insgesamt hab' ich die Prozedur auch erst 2-3mal gemacht. Niklas
> Besteht Interesse an einem einfachen > Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne > grossen Aufwand realisieren. Wäre gut. Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann aber doch noch durch. Ein Aufspielen der 1.2.BF.3.0 Flash war überhaupt nicht machbar, so ab 7% war immer wieder Schicht. Mir z.Z. unverständlich, die Ram-Version konnte ich aber einwandfrei uploaden und sie funktionierte. Das Skope bootete jetzt aber nicht mehr in die alte Version, ein paar Zeilen waren ja bereits überschrieben. Nichts ging mehr. Nach etlichen weiteren vergeblichen Anläufen mit dem GERMSLoader die Flash-Variante doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser spielte, zum Glück, die TomCat.flash ein. Zu evtl. Fehlern in dieser Version kann ich nichts sagen, dazu fehlt mir im Moment noch die Erfahrung mit dem Gerät.
Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation bedauerlicherweise doch noch etliche Zinken drin waren. Gruß Hayo
Hayo W. schrieb: > Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation > bedauerlicherweise doch noch etliche Zinken drin waren. Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern. Niklas
Torsten W. schrieb: > Hallo Hayo, > die C2 funktioniert nun auch bei mir bestens. Herzlichen Dank auch! > Woran lag es das das gerätespezifisch war? Beim Autoscale Menü lag es daran, dass für die 2-Kanalgeräte bestimmte Menüeinträge bei der Initialisierung geändert werden (z.B. werden bei den Sourcen Kanal 3 + 4 gelöscht weil nicht vorhanden). Dabei hat der WELEC-Programmierer aberr nicht aufgepasst und mittels Bufferoverflow Werte in benachbarten Speicherbereichen überschrieben. Bei der Kalibrierung war es nicht geräteabhängig sondern eher zufallsbedingt. Ich hatte bei den Leseroutinen nur einige Kleinigkeiten "optimiert". Da bei mir der Fehler nicht auftrat hab ich natürlich auch nicht weiter gesucht. Durch Deinen Beitrag bin ich aber dann drauf gestoßen, dass ich da einen Fehler eingebaut hatte. Gruß und danke Hayo
Niklas O. schrieb: > Hayo W. schrieb: >> Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation >> bedauerlicherweise doch noch etliche Zinken drin waren. > > Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern. Nein ich meinte stone. Aber auch Dir sowie allen Anderen würde ich empfehlen die C2 zu verwenden und nicht mehr die erste Kompilation. In SFN habe ich die auch schon gelöscht, hier geht das leider nicht. Gruß Hayo
stone schrieb: > Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der > org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout > ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann > aber doch noch durch. > [..] > doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser > spielte, zum Glück, die TomCat.flash ein. Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler? Klingt fuer mich mehr nach Problem mit Verbindung als dass der GERMSLoader etwas falsch macht. Probier mal nen anderes und kuerzeres Kabel. Den WelecUpdater hab' ich als episch langsam in Erinnerung. Ich weiss nicht was der da veranstaltet, wenn er das aber saulangsam rueberschiebt erklaert das dann vielleicht dass es mit dem bei Dir funktionierte. Niklas
Angehängte Dateien:
-
accu_charge.jpg
52 KB
Aber mal was ganz Anderes. Ich habe um ein neues Akkuladegerät auf korrekte Funktion zu testen mal eine Ladekurve aufgezeichnet. Probant war ein 1,2V Mignon Akku. Man sieht schön die Entladekurve in den ersten drei Divs, dann die Ladekurve und zum Schluß die Erhaltungsladung nach dem Delta U Buckel. Die Spannung die da vom Cursor angezeigt wird stimmt natürlich nicht. Der untere Cursor liegt bei ca. 1V der obere bei ca. 1,6V. Ergebnis Ladegerät funktioniert - und das DSO auch ;-) Gruß Hayo
> Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler? > Klingt fuer mich mehr nach Problem mit Verbindung als dass der > GERMSLoader etwas falsch macht. Probier mal nen anderes und > kuerzeres Kabel. Ist ein normales RS232 Kabel von meinem AVR STK500 Board an einer RS232 Schnittstelle. Damit gab es bisher keine Probleme. Aber das es an dem Kabel liegt ist trotzdem nicht auszuschliessen. Ein Gegentest ist z.Z. nicht möglich da ich leider noch kein andres habe. Mich wundert dann aber warum es mit der .ram ohne Probleme funktioniert. Mit dem Welec-Updater habe ich grad die C2 raufgespielt. Stimmt, es ist damit langsam, hat aber funktioniert. Nur z.Info, die Versuche liefen mit: WinXP Pro SP3 ActivePerl 5.12.3 Build 1204 und Win32-SerialPort-0.22.
@Niklas ich habe mal bei mir das Rauschen analog zu Deinem Screenshot getestet. Nach dem Kalibrieren liegen die Werte im gleichen Rahmen (so um 6mV). Hat also wohl eher nichts mit dem Rückspielen des Flashs zu tun denke ich. Gruß Hayo
Thread beobachten
Seitenaufteilung abschalten
