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

Hallo Rainer,

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

Beim naechsten Release, bei diesem hatte ich das vergessen.

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

Ja.

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

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

Niklas

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

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

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

Hallo August,

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

(1) Zur "Quick Measure"-Datenuebertragung:

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

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

Das Ganze dann zusaetzlich zu einem Trace?  Optional?

(2) Zu LabView und kontinuierliche Messdaten:

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

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

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

Niklas

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

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


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

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

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

Gruß Hayo

Hallo Hayo,

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

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

Gruß Michael

@Niklas

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

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

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

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

Hayo

Es ist soweit,

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

Die Highlights sind:

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

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



@eProfi

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


Gruß Hayo

Hallo Hayo,

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

Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im 
Moment als "suggestion" unter 
http://sourceforge.net/apps/trac/welecw2000a/wiki/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

Hi,

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



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


@gyppe

- no donation, it is just for fun!

Hayo

Thanks for Your kind response Paolo

Hayo

Leider habe ich noch einige Bugs entdeckt.

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

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

Hayo

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

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

> What's the next step?

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

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

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

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

Kind regards
Hayo

Hallo Hayo,

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

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

Gruß
Rainer

Hi Rainer,

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

Zum "Left Edge":

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

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

Gruß Hayo

Etwas Anderes,

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

Hayo

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

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

Einstellung:

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


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

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

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

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

Ist das bei Euch auch so?

Gruß Hayo

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

Gruß Michael

Aha,

ich bekomme das nur auf Kanal 3 + 4 hin.

Gruß Hayo

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

Gruß Michael

Hallo,

ich melde mich mal kurz.

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

Die Ausgabe sieht dann so aus (echte Werte):

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

@Niklas

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

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


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

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


@Roberto

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

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

Gruß Hayo

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

By the way...

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

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

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

Hayo

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

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

Hayo

@Niklas

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


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

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

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


Hayo

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

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

Gruß Michael

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

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

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

Gruß Hayo

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

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

Gruß Michael

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

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

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

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

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

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


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

Gute Besserung!

Hayo

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

der Leon braucht keinen externen Takt mehr?

Eure Meinung ist gefragt.

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

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

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

Gruß Hayo

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

Oszi: W2022
Firmwareversion: 1.2.BF.2.7

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

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

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

Hallo Thomas,

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

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

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

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

Niklas

Hallo nochmal Thomas,

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

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

Niklas

Hayo W. schrieb:
> Gute Besserung!
Danke!

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

Mfg,
Kurt

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

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

Gruß Hayo

Thomas O. schrieb:

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

Hi Thomas,

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

Gruß Hayo

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. ;-)

@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

Alles klar, super.

Gute Nacht

Hayo

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

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?

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

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

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

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

> 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

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

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
i freue mich schon auf's naechste relaese

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

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 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

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

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, werde ich mir mal ansehen.

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

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

...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

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

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