Wittig(welec) DSO W20xxA Open Source Firmware

@Hayo

Danke fuer die HE, bei mir treten die spikes in AUTO mode nun nicht mehr 
auf, dafuer habe ich nun manchmal spikes im Normal mode! Die sind leider 
viel schwieriger zu erkennen weil sie nicht immer an der selben stelle 
im Speicher sind!

N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu 
funkzionieren:

Bis zu 50ns/div ist sie OK (die Darstellung hat einen kleinen Versatz),
aber wen ich weiter zoome (was meiner Meinung nach nicht moeglich sein 
sollte) wird nur eine Linie dargestellt (vermutlich ein falscher Bereich 
der Daten). und ich kann nicht mehr nach 50ns/div zurueck gehen.

Martin

Danke schon mal für die ersten Testberichte.

@Michael H.

> Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als
> früher ist, kann das sein?

Jein, das kommt auf die eingestellte Zeitbasis an, da je nach 
ungenutzten Samplewerten mit unterschiedlicher Filtertiefe gearbeitet 
wird. Den Bereich <= 100nS habe ich auf schnelle Shift-Operation 
umgestellt statt wie vorher normale Division, weiß aber nicht ob das 
schon in der letzten Version drin war oder ob das jetzt neu ist.

> Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme:
> Das Oszi verstellt beim Laden nicht mehr den Trigger, steht aber
> immer auf "Stop"

Ja natürlich! Da ist wohl die Funktionsweise des Recall  unklar. Also 
das gespeicherte Signal wird mit allen zugehörigen Einstellungen aus dem 
Flash geladen. Damit dann im nächsten Durchlauf das geladene Signal 
nicht gleich wieder vom aktuellen Signal überschrieben wird, geht das 
Gerät in den Stop-Modus. Durch das Drücken der Stoptaste wird dann der 
Stop-Modus und damit auch der Recall beendet -> die alten Einstellungen 
werden aus dem Flash wieder hergestellt und der normale Betrieb wieder 
gestartet.

> und als ich versuchsweise eine Einstellung mit drei Signalen
> gespeichert und geladen habe und anschließend das ganze mit
> nur einem Signal, wurden die Nulllinienmarkierungen aller
> vier Kanäle mit eingeblendet, Ergebnis war: 2x Kanal 1,
> die anderen drei jeweils einmal.

Diese Testkonstellation hate ich noch nicht. Danke für den Tip, werde 
ich mal checken.


@Sven

Programmierkenntnisse sind nicht nötig. Mit den Tests helft Ihr mir 
erheblich weiter. Da ich nicht die Zeit habe alle Konstellationen zu 
testen bin ich auf diese Hilfe angewiesen.


@Martin H.

> Danke fuer die HE, bei mir treten die spikes in AUTO mode nun
> nicht mehr auf, dafuer habe ich nun manchmal spikes im Normal mode!
> Die sind leider viel schwieriger zu erkennen weil sie nicht immer
> an der selben stelle im Speicher sind!

Ok werde ich mal checken. Ich habe alle Tests bislang im AUTO-Modus 
gemacht.

> N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu
> funkzionieren:

Da habe ich in dieser Version nichts dran geändert. Das müßte also ein 
Fall für die offizielle "OS"-Version (Ticket) sein.

Gruß und danke

Hayo

Hallo Hayo,

Ich habe gerade deine Firmware aufgespielt. Im FFT Menü gibt es einen 
Fehler beim Anzeigen des Menüs "Mode". Siehe Screenshot.

Ein weiterer kleiner Bug (war schon in vorigen Versionen). Wenn man 
"Autoscale" drückt und danach "Undo Autoscale), werden im oberen Menü 
die Spannungsberecihe aller Kanäle angezeigt obwohl nur einer aktiviert 
ist. (siehe Screenshot im zweiten Posting).

Der DAC Abgleich funktioniert bei mir nicht korrekt oder ich mach etwas 
falsch. Ich stelle alle Kanäle auf 5V/div und starte "Search Zero Lines" 
und danach "Calibrate DAC".

Danach stelle ich alle Kanäle auf 2V/div und mach das gleiche.

Stelle ich nun wieder zurück auf 5V/div habe ich auf Kanal 3 und 4 einen 
Offset von -0.5div ud auf Kanal einen Offset von +0.25div. Auf Kanal 2 
ca einen Offset von +2 Pixel.

Mache ich etwas falsch?

lg Robert

Screenshot 2

@Robert S.

Zum Kalibrieren hat Guido schon alles gesagt. Ansonsten danke für den 
Fehlerreport, da hab ich ja wieder was zu tun, bevor das in die 
"OS"-Version einfließen kann.

Gruß Hayo

Danke für die Hilfe!!

Ich hab noch zwei Fehler beim Delayed Mode gefunden.

#1: Ist der Delayed Mode aktive und man schaltet das Gerät aus und 
wieder an, muss man am Timebase Rad einmal drehen, damit ein Signal 
angezeigt wird.

#2: Im Delays Mode wird das Softmenü der Gritintensität nicht 
aktualisiert wenn man im Display Menü am zugehörigen Drehencoder dreht 
(die Gridintensität ändert sich schon). Wenn man den Delayed Mode 
beendet wird wieder die Gridintensität vor aktivieren des Delayed Modes 
angezeigt. Sollte man im Delayed Mode einen Screenshot machen, wird die 
Grid-Plane mit der Intensität aus dem Main Mode angezeigt, nicht mit der 
geänderten.

lg Robert

Auch ein Fall für ein Ticket, da dieses Problem auch die "OS"-Version 
betrifft. Die 0.92HE-Änderungen findet Ihr im Changelog.

Hayo

Hallo


Ich hab mein Oszi erst sehr kurz und benutze aufgrund der Spikes noch 
immer die firmware 90.

Nun hab ich eine Frage wieso ist das "Rauschen" bei 1V größer als bei 
500mV sollte es da nicht größer werden je kleiner die V Basis ist... 
also der Ausschlag? Weil bei mir ist es genau umgekehrt. Im Anhang sind 
2 Bilder das bei 1V hat deutliche hügel das bei 500mV nicht mehr so 
sehr. (Ich weiß handy Kamera aber gibts ne MAC oder Linux software zum 
Screenshot auslesen?)


http://img255.imageshack.us/i/67664861.jpg/


http://img171.imageshack.us/i/500mv.jpg/

lg Mike

Hallo Mike,

es gibt auch eine Linuxversion, die ist auch bei der HE dabei.

Die Messbereiche sind grundsätzlich in drei Hauptbereiche eingeteilt, 
die sich durch den Skalierungsfaktor unterscheiden. Alle 5er Bereiche 
haben einen günstigenren Faktor als die 2er oder 1er. Daher haben aller 
5er Bereiche ein geringeres Rauschen als die 2er und 1er Bereiche.

Gruß Hayo

Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon 
"fertig" oder schraubt ihr dort noch herum?

Danke für die schnelle Antwort.

lg Mike

Mike K. schrieb:
> Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon
> "fertig" oder schraubt ihr dort noch herum?

"fertig"? - Was für ein Wort ;)

Wie Du aus dem Text von brunowe weiter oben entnehmen kannst,
hat das DSO vier Verstärker, aus denen sich die Verstärkungsstufen
(1; 1,25)*(1;2;4) -> (1;1,25;2;2.5;4;5) einstellen lassen.

Das Rauschen der ersten beiden Verstärker bleibt etwa gleich
(7nV/sqrt(Hz)+ 20nV/sqrt(Hz) -> 27nV/sqrt(Hz) (ohne Rauschstrom))
und wird mit den nächsten Stufen entsprechend verstärkt.
Jeder der beiden nächsten Verstärker steuert nochmal 20nV/sqrt(Hz)
zu.

Entsprechend verhält sich das Signal/Rauschverhältniss reziprok
zur Amplitude des Eingangssignals.

An der hardwareseitigen Behebung dieses Problems arbeiten derzeit
Leute. Eine Umstellung der Verstärkungsfaktoren (1,25; 2; 4 -> 1;2,5;5)
erfodert weitere Messungen (es gibt hier verschiedene Ergebnisse zur 
Durchlasskurve des Gerätes zwischen beiden Serien (W201X, W202X))
und hätte derzeit nur evtl. Vorteile für die Firmware (Geschwindigkeit, 
Speicherbedarf ;)

Die dekadischen Stufen (1V, 100mV, ...) werden über ein 
Widerstandsnetzwerk abgebildet.
>
> Danke für die schnelle Antwort.
>
> lg Mike

Grüße,

   rowue

Danke für die Erklärung  Rolf Würdemann.

Jetzt wart ich nur mehr auf 0.92, aber zurzeit glüht der svn nur so vor 
updates.

lg Mike

Ich habe vor ewigkeiten ja schonmal davon geredet, dass "bald" eine 
Version des FPGA-Redesigns zur verfügung stünde, mit dem man schonmal 
"spielen" kann. Neben Studiums-Endspurt-Stress kamen diverse Probleme 
mit dem Design hinzu, und große Teile wurden seitdem überarbeitet oder 
neu implementiert. Außerdem habe ich nun tatkräftige Unterstützung bei 
der Entwicklung!

Nach langer Zeit gibt's also mal wieder was zu zeigen: 
http://www.youtube.com/watch?v=vwSE2alpnYQ

Viel Spaß damit

Daniel

Michael H. schrieb:

> Leider ist bei der HE das alte Problem mit dem zerstückelten
> Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass
> ich keinen ansehnlichen Shot erstellen konnte.

Den Effekt hatte ich mal unter Linux. Bei mir funktioniert allerdings 
jetzt alles. Sonst unter Windows das BMP-Format verwenden.

Hayo

Hallo Sven,
für das schnelle Update benötigst Du Pearl! Unter Windows sollte es so 
gehen (Zitat von viel weiter oben):
-----
Ich verwende ActivePerl 5.8.8 (habe ich von
http://www.oldapps.com/Perl.php geladen).

Zusaetzlich benoetigst du das Modul Win32:SerialPort

Am einfachsten ist die Installierung via Perl Package Manager (PPM):

1. Neues Repository eintragen via Edit -> Preferences
   und den Reiter Repositories
   Name: Bribes
   Location: http://www.bribes.org/perl/ppm
   (ein ausfuerliches help findest du unter
    http://www.bribes.org/perl/ppmdir.html)

2. Jezt kannst du das Modul Win32-SerialPort installieren:
   Zeile mit Win32-SerialPort suchen und an klicken
   Action -> Install Win32-Serialport 0.19

Das sollte alles sein.
-----
Ich hatte Anfangs auch Probleme mit Pearl und habe später gemerkt, dass 
ein Nullmodemkabel das Problem dann behoben hat! Man ist versucht, den 
Reichelt-Adapter direkt mit dem Scope zu verbinden (passt ja!), 
allerdings sind dann RX und TX vertauscht. Also: Nullmodem-Kabel!

Den Rest findest Du im Updatepaket beschrieben.

Michel

@Sven

Beim downloaden mit Perl der Original Firmware brauchst du zirka 1Std 
fürs spätere uploaden der hier erhältlichen firmware per perlskript 
brauchst du 5min

lg Mike

Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine
> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der
> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?
>

Es existieren Samplerates von 50 und 100 MSa/s, diese sind aber auch
in der Zeitbasis schwer auszuselektieren.

> Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts
> angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger
> Rumdreherei erscheint das Signal dann auf einmal wieder.
> Ich werde auch nochmal versuchen, das nachzustellen.

Ich konnte mittlerweile das Signal durch Drehung der 
Verstärkereinstellung
wieder "sichtbar" machen.
>
> Gruß
> Michael


Grüße,

    rowue

PS: Sachdienliche Hinweise zu den Tickets können gerne an die
entsprechenden Tickets angehängt werden ;)
PPS: Die neue FW sieht gut aus, hat aber leider einige neue Bugs.
QM mit Zeitbasen <50ns funktioniert leider immer noch nicht
(Skalierungsproblem?)

Hallo Leute,

ich war zwischenzeitlich etwas beruflich eingespannt, so dass ich leider 
nicht zu meiner Lieblingsbeschäftigung gekommen bin. Eure Beiträge und 
Fehlermeldungen habe ich dennoch verfolgt und werde eine korrigierte 
Fassung der HE in Kürze hier posten damit wir das dann mal endlich in 
die OS Version reinpatchen können.

Ich war aber trotz alledem nicht untätig. In der Zwischenzeit habe ich 
mich mit anständigem Mess-Equipment eingedeckt, um mal zuverlässige 
Aussagen zum Einsatzbereich (Bandbreite und Signalintegrität) der W201x 
und W202x Geräte machen zu können (HP3325A Präzisionssignalgenerator, 
Tektronix 2465A 350MHz Oszilloskop). Wollen doch mal sehen was die W20xx 
so hergeben mit den neuesten Firmwareänderungen.

@Rolf

Kein Skalierungsproblem. Wie schon weiter oben gesagt liegt es mit 
ziemlicher Sicherheit daran, dass die interpolierten Daten in anderen 
Speicherbereichen liegen. Ob ich dazu auch noch komme weiß ich 
allerdings nicht.

Gruß Hayo

Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine
> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der
> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?


Nein, der Grund ist entweder ein Fehler im FPGA-Design oder nur die 
vergurkte Firmwareprogrammierung. Ob Ersteres zutrifft ergründe ich 
noch. Wenn es nur die Firmware ist werde ich das auf jeden Fall 
nachrüsten, beim FPGA-Design kann ich nicht viel machen, außer die 
Sampletiefe und die Samplerate etwas geschickter zu verteilen als 
momentan. Da bleibt dann nur der Umstieg auf eins der neuen FPGA-Designs 
(siehe Hardware-Thread).

Gruß Hayo

rowue schrieb:
> Hi Hajo,
>
> bei mir steht auch noch ein HP8116A und ein Grundig FG100,
> ersterer könnte interessant sein, wenn wir mal in höhere
> Bereiche gehen wollen ;)

Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel 
Ausgang) ?

> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
> umzuschalten - dann hätten wir in allen Bereichen die
> gleiche Aussteuertiefe (habe schon etwas dran gespielt,
> muss da aber noch mal ran;)

Wie hast Du die Umschaltung gemacht (Softwareseitig oder 
Hardwareseitig)?


Werde gleich mal die ersten Ergebnisse meiner Vergleichstests 
veröffentlichen, allerdings wie es sich gehört im Hardwarethread.

Gruß Hayo

Hayo W. schrieb:
> rowue schrieb:
>> Hi Hajo,
>>
>> bei mir steht auch noch ein HP8116A und ein Grundig FG100,
>> ersterer könnte interessant sein, wenn wir mal in höhere
>> Bereiche gehen wollen ;)
>
> Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel
> Ausgang) ?

Müsste ich mal prüfen - tendentiell eher nicht, wobei
ich allerdings in der FFT auch bei 50MHz die Oberwellen bis
200MHz klar erkennen kann (inkl. des von Andre beschriebenen
"überziehens")

>
>> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
>> umzuschalten - dann hätten wir in allen Bereichen die
>> gleiche Aussteuertiefe (habe schon etwas dran gespielt,
>> muss da aber noch mal ran;)
>
> Wie hast Du die Umschaltung gemacht (Softwareseitig oder
> Hardwareseitig)?

Über die Bit-Register - also Hardwareseitig - ich habe
als Skalierungsfaktoren (auf die 400 px) mittels Messung
2,55;2,56;2,55 herausbekommen (wobei der theor. Wert bei
2,4606 liegt) und will als nächstes Nachschauen, wie ich
den "ZeroScaleFactor" bestimme, auch, wenn mir die Werte
bekannt vorkommen ;)

Neben dem evtl. Vorteil, nur zwei Werte (delayed, normal)
für die Darstellung auf dem Bildschirm zu haben, hätte
das noch in der Auswertung den Vorteil nicht ständig die
veränderten Verstärkungen der einzelnen Stufen einbeziehen
zu müssen. Dafür hätten wir halt nur um die 156 Bit zur
Verfügung :(
>
>
> Werde gleich mal die ersten Ergebnisse meiner Vergleichstests
> veröffentlichen, allerdings wie es sich gehört im Hardwarethread.
>

o.k. ;) - Oder im SF-Forum ;)

> Gruß Hayo

Grüße,

   rowue

(Sorry für "Hajo" ;)

Hmm,

ist doch etwas später geworden beim Griechen, daher gibt es die 
Fotoserie zu meinen Messungen erst morgen (also nachher).

Sorry Hayo

Guido schrieb:
> Hallo Hayo und Rolf,
>
> die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet.
> Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:
>
>

1

> 

2

> case 0 : dat_buf = 0x0005; break;

3

> [...]

4

> 

5

>

>
> @ Rolf: Hast du das auch so?

Genau so ;)

Ich habe dann mit dem HP in den 50, 20, 10 mV/DIV Stufen jeweils die 
Gleich-Spannungen in 1DIV Schritten von -4 DIV bis 4 DIV(*) eingestellt, 
mit dem Multimeter kontrolliert (0,3% Messgenauigkeit, in der weiteren 
Fehlerfortpflanzung vernachlässigt) und die (Roh-)Daten 
(bandbreitenbegrenzt) ausgelesen.

Von diesen Rohdaten habe ich jeweils die ersten 2048 Sätze genommen und 
die Mittelwerte gebildet. Mit diesen Mittelwerten (inkl. Fehler) habe 
ich dann eine lineare Regression (Fit mit Polynom ersten Grades) im 
Bezug auf Bits/DIV durchgeführt. Es ergaben sich folgende Zusammenhänge:

1

10 mV/DIV: 19,4926 pm 0,1738  Bits/DIV  (rel. Fehler: 0,8916%)

2

20 mV/DIV: 19,5195 pm 0,1507  Bits/DIV  (rel. Fehler: 0,7720%) 

3

50 mV/DIV: 19,6316 pm 0,1337  Bits/DIV  (rel. Fehler: 0,681%)

Als Skalierungsfaktoren für die Software hätte ich somit (**)

1

10mV/DIV: 2,5651 pm 0,0229

2

20mV/DIV: 2,5615 pm 0,0198

3

50mV/DIV: 2,5469 pm 0,0173

Mit folgenden Auflösungen [mV/Bit]:

1

10 mV/DIV: 0,513  pm 0,0046

2

20 mV/DIV: 1,0246 pm 0,0079

3

50 mV/DIV: 2,5469 pm 0,0173

Wenn gewünscht, kann ich die Änderungen an tc_hardware.cpp mal in's svn 
spühlen, dann können hier weitere Messungen zur Auflösung, etc 
vorgenommen werden - ich gehe da schon von - leichten - Unterschieden 
auf Grund der Bauteilstreuung aus.

Die angegebenen Fehler beziehen sich auf die Fehler der Anpassung (wie 
gut passt eine Kurve mit dieser Steigung auf die Messpunkte). Für die 
Fehler der berechneten Mittelwerte habe ich mal den mittleren relativen 
Fehler berechnet:

1

10 mV/DIV: 1,3653%

2

20 mV/DIV: 1,0736%

3

50 mV/DIV: 0,8531%

(ja, ich habe gepfuscht und die Standardabweichung des Fehlers nicht 
angegeben ;)

>
> Gruß, Guido

Grüße,

    rowue

(*)  Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
(**) Ich habe die Daten gerade noch mal ausgewertet, deshalb der
     Unterschied zum vorherigen Posting.

Hi,

muß Euch leider noch mal auf morgen vertrösten mit meiner Bilderserie.


Gruß Hayo

Rolf Würdemann schrieb:
> Guido schrieb:
>> [...]
>
> (*)  Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
Soll natürlich 50mV/DIV heissen ;)

> [...]

@Rolf

Ich habe mal die Messungen in den Hardwarethread gestellt. Leider stehen 
mir nur bis 10 MHz die präzisen Rechtecksignale zur Verfügung. Darüber 
habe ich nur ein nicht ganz so sauberes Hilfssignal, dass ich auf der 
Rückseite des Funktionsgenerators abgreifen kann. Zudem habe ich da auch 
nur einen nicht einstellbaren recht kleinen Signalpegel. Da wäre eine 
Meßreihe mit Deinem 50 MHz Pulsgenerator sicher ganz interessant, zumal 
man da dann auch die verschiedenen Spannungsbereiche miteinander 
vergleichen könnte.

Gruß Hayo

@mike0815

Ok, danke das ist ein praktischer Hinweis zum Kalibrieren.

Gruß Hayo

Hayo W. schrieb:
> @Rolf
>
> [Pulsgenerator]

Hi Hayo,

sorry erstmal für die späte Antwort - ich hatte die letzten
Tage etwas sehr mit den 1;2.5;5 Faktoren und ihrer Abbildung
im Source gespielt ;)

Ich sehe mal zu, dass ich mir am WE noch das 2022A von
'nem Kollegen ausleihen kann, um dann mit beiden Geräten
entsprechende Aufnahmen zu machen. Allerdings könnte
es noch interessant sein, dies mit Deinem Tek zu vergleichen
(da ja die Bandbreite, etc. des HP nicht bekannt ist).

Alternativ könnte ich mit einigen Annahmen die "theoretischen"
Ausgangssignale des HP simulieren und dagegen stellen.

>
> Gruß Hayo

Grüße,

   rowue

mike0815 schrieb:
> moin erstmal,

Mohltiet ;)

> [Problem mit der DAC-Kalibrierung]

@mike0815:

Welche Version nutzt Du? Die 0.92HE oder die 0.91OS?

@Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
Deiner letzten?

Ich weiss, dass Falk was an der ADC-Kalibrierung geändert
hat (r176, r178, die vor Deinem Urlaub war r172). Ich habe
bei meinen Spielereien (Faktoren) das Problem symmetrisch
zur Null-Linie (leicht, proportional zum Abstand).
>
> Gruß, Michael

Grüße,


   rowue

Rolf Würdemann schrieb:

> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
> Deiner letzten?

Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er 
denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das 
Handling verändert?

Gruß Hayo

Hayo W. schrieb:
> Rolf Würdemann schrieb:
>
>> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
>> Deiner letzten?
>
> Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er
> denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das
> Handling verändert?

Generell? Oder bezogen auf die ADC-Kalibrierung?

Letzteres:
http://sourceforge.net/apps/trac/welecw2000a/changeset/176/fpga/nios/oss/trunk/src/hardware_t.cpp


Wenn Du eine Übersicht haben möchtest:

http://sourceforge.net/apps/trac/welecw2000a/log/fpga/nios/oss/trunk
>
> Gruß Hayo


Grüße,

    rowue

mike0815 schrieb:

> Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config
> geschrieben und dann abgespeichert, nein, doch???

Jupp, wird sie.

> Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die
> Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann
> wieder Ok.
> ...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe
> Problem???

Hmm, das muß ich mal überprüfen. Die 0.93HE steht in den Startlöchern. 
Da hat sich einiges getan. Unter anderem habe ich die Startupsequenz 
komplett geändert um den Reload aus dem Flash für jede Ausgangssituation 
zu gewährleisten und nebenbei das gemeldete Problem mit dem Restart nach 
Delayed-Betrieb zu beseitigen.

Vielleicht läßt sich das dann gleich mit erledigen.

Gruß Hayo

Nur mal so ne dumme frage aber woher bekommt man eigentlich das Bin für 
die Holiday edition?

lg Mike

Da es sich nicht um offizielle Releases handelt, sondern um 
Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter 
oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im 
Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten 
Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so 
dass es über eine einfache Korrektur doch schon hinausgeht.

Hayo

mike0815 schrieb:

> ach, das wird wieder eine HE??

Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist 
werde ich das HE mal mit anhängen um den Bezug herzustellen und um 
klarzustellen, dass es keine offizielle Version aus dem SFN ist.

> Jedenfalls, macht es hier einen riesen Spass!

Das geht uns allen auch so, daher verbraten wir hier ja auch soviel Zeit 
anstatt soziale Kontakte zu pflegen ;-)

> Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen
> betrifft, da es mein Erstes ist...nach 35 Jahren...'lach'

Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses 
Projekt!

> Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und
> der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne
> Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche
> Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da
> noch was versaue!!!

Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die 
reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei 
Gelegenheit auch mal ausprobieren.

> Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese
> für übersichtlicher halte als die SVN.

Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein 
paar Dokus oder Softwarebundles ablegen.

> Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen
> und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch
> übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine
> oder andere Anfänger, so wie ich es bin, einen besseren Durchblick
> erhalten!!!

Leider wurde die Seite für den Upload gesperrt und wird vermutlich auch 
nicht wieder geöffnet um den Fokus auf die SFN-Seite zu setzen.

Gruß Hayo

Guido schrieb:
> @ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im
> Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach
> ausschalten.

Hi Guido, kleine Korrektur meinerseits, seit einigen Versionen (frag 
mich jetzt nicht nach der genauen) werden die Einstellungen direkt 
gespeichert. Das erkennst Du an folgendem Coding:

  //Save new values to flash
  config_changed = true;

Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal 
ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen 
Konfigurationsdaten ins Flash geschrieben.

Gruß Hayo

Hallo,


> > Die 0.93HE steht in den Startlöchern. <
>ach, das wird wieder eine HE?? Ist ja wurscht...

Also mir ist das ganz und gar nicht wurscht!
Ab dem 05.10 werde ich wieder an der GUI weiter entwickeln (Mein 
Co-Programmierer ist derzeit anderweitig beschäftigt).
Leider ist in den HE Versionen der Datentransfer nicht im vollen Umfang 
verwirklicht (Befehlssatz gem. SF), demzufolge kann ich diese nicht zur 
Entwicklung heranziehen! Die in den Grundzügen bereits vorhandene GUI 
baut ergo auf die OS 0.91 auf.... schade, da mit dieser Version bei mir 
massive Probl. bei höheren Freq. auf Ch1 auftreten.


Gruß, brunowe

Hayo W. schrieb:
> Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal
> ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen
> Konfigurationsdaten ins Flash geschrieben.

Erfolgt das Setzen in Interrupt-Handlern? Dann erfolgt das 
Rücksetzen&Flashen hoffentlich unter Ausschluss von weiteren Interrupt? 
;)

@Bruno

Wenn die 0.93HE hier getestet wurde und keine größeren Fehler mehr 
auftreten, können die Änderungen in die OS-Version einfließen. Bislang 
war das Ganze noch nicht ausgereift genug um es einfach da rein zu 
mergen. Es handelt sich doch zum Teil um recht umfangreiche Änderungen, 
daher möchte ich vorher sichergehen das da dann nicht neue Fehler mit in 
die OS-Version eingebaut werden (so wie sie ja in der 0.92HE vorhanden 
waren). Die wären ja ansonsten jetzt schon mit drin.

Andererseits muß ich erst prüfen ob ich alle Änderungen der OS-Version 
auch in meiner eigenen Version haben möchte. Mir fehlt da momentan der 
Überblick ob das alles stabil läuft und ungeprüft will ich das nicht 
einfach so übernehmen.

Gruß Hayo

Ich nochmal zum "DAC-Abgleich"

...habe festgestellt(W2022A-092HE), das wenn ich die DAC-Kalibrierung 
durchgeführt habe und dann den NOIS Filter einschalte, ich nochmals 
einen Abgleich durchführen muß (DAC-Taste drücken), diesmal nur 1x in 
den 5er-Bereichen, in allen anderen Bereichen, muß ich mindestenst 1-4x 
die DAC-Taste drücken, dann erst ist alles hübsch!

Dann hätte ich noch eine Frage zum Coupling-Mode, was für eine Bewandnis 
hat es mit dem PROBE-Softkey? Welche Funktion hat er? Kann ich intern 
1:1 - 1000:1 schalten oder was hat er für eine Funktion?

Gruß Michael

Michael H. schrieb:
> Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch
> wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden.
> Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist
> angezeigt.
>
> Gruß
> Michael

...logisch! Ist denn der 'MIST', der da angezeigt wird, so erheblich 
bzw. die Werte falsch? Wenn ich am Tastkopf 10:1 eingestellt habe, dann 
habe ich z.B. 680mV als 6,8V umgerechnet...
...nun ja, das ist dann natürlich eine angenhme Sache, d.h. wenn ich den 
Tastkopp auf 10:1 stelle muß ichh den PROBE-Knopp auch auf 10:1 
schalten?

Habe das eben mal gestestest: Tastknopp 10:1 und Probeknopp ebenfalls 
auf 10:1 und wieder zurück auf 1:1...
Es gibt vom Messverhalten keinen Unterschied beim verstellen des 
PROBE-Knopp's!
...und stimmt, bei Tastkoppschalter 1:10 kommt Müll raus, ist da jetzt 
der Eingang hinüber, oder was?


Gruß Michael

Ansonsten bleibt noch zu erinnern: Man kann an 2 Orten den Vorteiler 
einstellen: Im Kanal- und im Trigger-Menü...

...jetzt hab' ich mein Fett weg...

...ein Tek, ja genau, vielleicht mach ich noch ne' Sammlung auf.

Hallo Jürgen,

mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben 
gebracht hat...
melde dich bei SF an, und merge die Versionen!!!
Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas 
scheut...


Gruß, brunowe

Hi,

der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich 
eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die 
Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne 
bei.

Ich selbst entwickle zur Zeit immer noch auf der Basis meiner eigenen FW 
da mir die Änderungen an der OS-Version nicht verifiziert bzw. validiert 
genug sind. Mir fehlt da momentan der Überblick wer da alles an welchen 
Baustellen herumflickt und ob das alles richtig gestestet wird. Daher 
ist es mir (zumindest momentan) lieber, die Änderungen die ich in meiner 
FW ausgiebig getestet habe nachträglich in die OS-Version einfließen zu 
lassen, bzw. sinnige Änderungen aus der OS-Version zu übernehmen.

By the way: gibt es einen konkreten Status zur Remoteschnittstelle und 
zur Screenshotfunktion? Läuft das stabil?

Gruß Hayo

Hallo Hayo,

der Status der implementierten Befehle ist hier dokumentiert:
http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI

Das USB Protokoll ist hier beschrieben:
http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol

Der Datentransfer via RS232 läuft absolut stabil. Leider lassen die 
derzeit möglichen 115kBd keine tolle refresh- rate bei meiner GUI zu.
Die RS232 ist da eindeutig der limitierende Faktor was z.B. die live 
Darstellung einer FFT betrifft (ca. 2-3 Bilder/s). Im neuen VHDL Design 
kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden, 
aber da sollen sich die VHDL Profis ruhig noch etwas spielen.

Gruß, brunowe

Bruno We schrieb:
> Im neuen VHDL Design
> kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden,

Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die 
mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige 
was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1.

Hayo W. schrieb:
> Hi,
>
> der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich
> eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die
> Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne
> bei.

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

Hallo,

> Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die
> mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige
> was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1....

Ok... soweit logisch. Dachte allerdings das der FPGA die Daten dann auch 
in der dementsprechenden Geschwindigkeit "weiter schieben" muss?! Oder 
ist die Geschwindigkeit via FW anpassbar, also nicht via HW fix 
vorgegeben?

Gruß, brunowe

Hi ...

Nach dem ich einige Tage Don Quichotte gespielt habe, nun einige
Kommentare zum Thema svn/sfn von mir:

Begriffsunterscheidung:

  svn: Abkürzung für Subversion - System zur Versionsverwaltung
       (Source-Code, Messdaten, Texte) - ich verwende dieses z.B.
       für Messdaten ebenso wie für Texte (u.a. meine damalige DA)
       als auch für Sourcen.

       svn bietet hier die nette Möglichkeit, Änderungen zu
       dokumentieren und ggf. wieder Rückgängig zu machen.

  trac: System zur Verwaltung von Projekt-Daten - spielt wunderbar
        mit svn, enthält u.a. ein Wiki ein Ticketsystem und bietet
        die Möglichkeit, Änderungen im Source und Tickets zu
        verlinken (damit mensch nachher sehen kann, wofür die
        Änderung gemacht wurde (Bugfixes))

  sfn: Plattform für Open-Source Projekte, u.a. mit verteilter
       Distribution und Angebot, svn, und trac zu verwenden.

Wenn jemand nun auf die Seite:

   http://sourceforge.net/apps/trac/welecw2000a/

geht, landet man im Trac-Wiki des SFN-Projektes und kann sich
z.B. die Sourcen (mit Änderungen) im svn oder offene/geschlossene
Tickets ansehen.


Oben auf der Seite steht:

"Visit project welecw2000a", ebenso wie "Welec W2000A". Beide
Links führen auf die Seite:

   http://sourceforge.net/projects/welecw2000a/

Dort befindet sich eine Sektion "Files". In dieser Sektion
findet man die Releases - also die herausgegebenen Versionen.

Während im svn (derzeit) nur die Sourcen drin sind, sind hier
auch die compilierten Versionen (soweit verfügbar) drin, welche
sich dann einfach in das DSO hochladen lassen.

Die Sourcen einiger Releases (es sollten eigentlich alle sein ;)
findet man im svn unter:

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/tags

Das Verzeichnis

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/trunk

enthält den derzeitigen Entwicklungstand (der OS Version).

Über das Verzeichnis

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/branches

können z.B. Abzweigungen im Source-Tree (tiefgreifende Änderungen,
Version 2.0, etc) verwaltet werden (um diese dann später wieder
in den trunk einzupflegen)

Wird auf Basis des svn(-Tree) gearbeitet, so lassen sich 
Versionskonflikte zumeist sehr einfach lösen. Hier könnten wir aber das 
Problem haben,
dass der Dateiaufbau der BF und der der OS sich unterscheiden. Falk 
hatte damals die Änderungen von Hayo eingepflegt, das war aber eben mal 
drei Stunden Arbeit (und händisches einpflegen ist eher fehleranfällig).

Die Arbeit mit svn scheint erstmal sehr viel Overhead zu haben,
hat sie aber nicht - ist der Client der Wahl (gerne auch cli) gefunden, 
so ist die Lernkurve sehr steil (Nach dem Motto: einen Tag für den 
Client der Wahl, 'nen viertel Tag für das svn) und die Vorzüge einer 
Versionsverwaltung sind in einem Projekt (egal ob Text, Source oder
Messdaten) nicht zu unterschätzen (wer einmal Rohdaten weggeworfen hat 
und sie nachher wieder brauchte wird dies bestätigen können).

Wenn ich mir die Tickets im Trac ansehe
(http://sourceforge.net/apps/trac/welecw2000a/report/1)

sieht man, dass sowohl in der BF als auch in der OS Fehler offen sind.
Wir können nun daraus zwei Baustellen machen. Oder gemeinsam an 
einer
arbeiten.


Grüße,

    rowue

PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer 
Abweichung von 1,8% ...

branadic schrieb:
>> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer
>> Abweichung von 1,8% ...
>
> Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite
> aufmerksam machen:
>
> http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement

merci ;)
>
> Gruß, branadic


Beste Grüße,

   rowue

Hallo Leute!

Hat jemand von Euch mit dem Vinculum Board weitergearbeitet?

Der USB Stick hat leider sehr unterschiedliche Zugriffszeiten sodass 
wahrscheinlich ein FIFO und ein Handshake in die Kommunikation mit dem 
Oszi eingebaut werden muss.

Es wäre schön, wenn jemand der das bisherige Protokoll versteht es mal 
im Klartext notieren könnte. Damit meine ich die den Teil der den 
Screenshot einleitet, die Lauflängendekodierung und die Bilderstellung.

Dann könnte man das Protokoll in Richtung Handshake optimieren und auf 
den Mikocntroller portieren.

Mfg,
Kurt

Hi,
hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers 
müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst 
gibts Ärger von der Chefin.

Auch wenn sich oberflächlich außer der Fehlerkorrektur scheinbar nicht 
so viel getan hat, sind die Änderungen unter der Haube recht 
umfangreich.

Das DSO startet jetzt nach dem Ausschalten immer mit der letzten 
(gespeicherten) Einstellung vor dem Ausschalten. Neu ist hierbei unter 
Anderem die Unterstützung für den Math-Betrieb (auch FFT) und den 
USTB-Betrieb.

Um etwas kompatibler zur OS-Version zu sein habe ich Falks aktuelle 
Version der Remoteschnittstelle mit eingebaut. Ich habe es allerdings 
nicht mehr geschafft die Screenshot-Version umzurüsten, daher bitte 
wieder die beigelegte Version verwenden.

Da es letztens hier angefragt wurde lege ich die Sourcen diesmal bei.

Achtung - dies ist keine Entwicklerversion für das SFN! Nach 
erfolgreichen Tests können die Änderungen je nach Zustimmung in die 
SFN-Version übernommen werden. Ob ich das mache oder jemand anderes 
können wir ja noch klären.

Gruß Hayo

Hallo zusammen,

ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster 
Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder 
andere Sache beisteuern können.

@Hayo

Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine 
Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk 
mitbekommst.

Stefan E. schrieb:
> Hallo zusammen,
>
> ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster
> Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder
> andere Sache beisteuern können.

Super!

> Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine
> Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk
> mitbekommst.

Da muß ich zu meiner Schande gestehen, dass ich noch keine Zeit gefunden 
habe mich mit SVN und drumherum auseinanderzusetzen. Wenn ich 
zwischendurch Zeit hatte hab ich nur an der FW rumgeschraubt. Muß ich 
also noch ran. Dann werde ich Deinen Vorschlag mal aufgreifen.

Ansonsten noch an alle viel Spaß beim Testen,

Gruß Hayo

Hayo W. schrieb:
> Hi,
> hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers
> müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst
> gibts Ärger von der Chefin.

Das wollen wir ja nicht! ;)

>
> [1.2.BF.094.HE]

Ich habe die Version in's Ticket-System eingetragen,
dann können evtl. Fehler dort gleich eingetragen werden ;)

URL: http://sourceforge.net/apps/trac/welecw2000a/report


>
> Achtung - dies ist keine Entwicklerversion für das SFN! Nach
> erfolgreichen Tests können die Änderungen je nach Zustimmung in die
> SFN-Version übernommen werden. Ob ich das mache oder jemand anderes
> können wir ja noch klären.

Vorschlag: lass uns beide das doch gemeinsam machen ;)
>
> Gruß Hayo


Grüße,

    rowue

Ok,

wie hattest Du Dir das vorgestellt?

Gruß Hayo

Hayo W. schrieb:
> Ok,
>
> wie hattest Du Dir das vorgestellt?

Wir treffen uns Samstag (früher Nachmittag), erstellen
erstmal einen unified diff Deiner aktuellen Sourcen zum
Stand 0.88 (war glaube ich der, den Hayo zum einpatchen
vervendet hat) und patchen mit Hilfe dieses Diffs die
Sachen in das svn.

Treffen könne wir uns (von meiner Seite aus) bei Dir,
bei mir oder bei mir in der Firma. Zu Dir müsste ich
mit Bus/Bahn und (ggf.) Fahrrad.

Bei mir stände uns ein grosser Schreibtisch und eine seperate
Werkbank zur Verfügung. Da ich gerade zwei Geräte (W2014A,
W2022A) zur Verfügung habe, könnten wir die Patches auch
gleich auf beiden Geräte testen. Wenn Du das Tek mitbringst,
könnten wir uns ebenso die Ausgaben des HP auf den drei Geräten
ansehen.

Bei mir in der Firma hätten wir in der Werkstat viel Platz
und Internet bis zum Abwinken, müssten aber evtl. unsere
Geräte (falls wir was testen möchten) rantragen (ISP).

>
> Gruß Hayo

Grüße,

    rowue

Hi allerseits,

hier die aktualisierte 0.95HE - Bruno war aufgefallen dass die 
Remoteschnittstelle nicht funktioniert, daher habe ich nochmal gesucht 
und festgestellt, dass ich vergessen hatte die UART-ISR mit 
nachzuziehen. Das sollte jetzt also funktionieren. Falls es noch 
Probleme gibt immer raus damit.

@Rolf

Hört sich echt gut an, leider bin ich jetzt am WE komplett ausgebucht, 
da ich Besuch aus dem Ruhrpott bekomme. Grundsätzlich können wir das 
aber gerne machen. Welche der Örtlichkeiten wir dann wählen können wir 
dann ja kurzfristig abstimmen.

Gruß Hayo

Hayo W. schrieb:
> Hi allerseits,
>
> [0.95HE]

Habe das Ticket-System angepasst (und die 0.94HE dort gelöscht)
Es wäre nett, wenn Fehlermeldungen (überwiegend) dort landen ;)
>
> @Rolf
>
> [Besuch aus dem Pütt]

O.K. - wollen wir dann das nächste Wochenende (10./11.10.,
preferiert: Samstag, den 10.10) in's Auge fassen? ;)

>
> Gruß Hayo


Grüße,

   rowue

@Jürgen

Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu 
sein, denn das Problem müßte eigentlich auch bei den älteren Versionen 
auftreten. Ich weiß auch schon so ungefähr woran es liegt.

Danke für den Hinweis

Hayo

Ok,

Bug erkannt - Gefahr gebannt. Ist erledigt. Nebenbei habe ich noch die 
Start/Stop-Logik beim Singleshot optimiert.

Gruß Hayo

Hayo W. schrieb:
> @Jürgen
>
> Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu
> sein, denn das Problem müßte eigentlich auch bei den älteren Versionen
> auftreten.

Schau mal in's Ticket-System ;)

http://sourceforge.net/apps/trac/welecw2000a/report/1

> Ich weiß auch schon so ungefähr woran es liegt.
>
> Danke für den Hinweis
>
> Hayo
Grüße,


   rowue

Du meinst Ticket 39??

Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung 
eher in eine andere Richtung wies. Werde ich dann resolven wenn die 
Korrektur raus ist.

Hayo

So,

da nach über 50 Downloads jetzt keine weiteren Rückmeldungen vorliegen 
scheint es zumindest keine gravierenden Schnitzer zu geben. Die 
Remoteschnittstelle scheint daher wohl auch zu funktionieren.

Daher hier nochmals eine fehlerkorrigierte HE. Das wegdriftende Signal 
im Stopmodus bei eingeschaltetem Noise-Filter ist gefixed. Bei der 
Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so 
dass diese jetzt vernünftig funktioniert. Nebenbei habe ich noch weiter 
das Coding aufgeräumt und tote Variablen und Coding gelöscht. Beim 
ersten Start könnte es leichte Nebeneffekte geben, da sich das 
Flashlayout mal wieder etwas geändert hat.

Ein einfaches Default-Setup sollte das aber beheben.

Gruß Hayo

Hayo W. schrieb:
> Du meinst Ticket 39??
>

Jupp ;)

> Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung
> eher in eine andere Richtung wies. Werde ich dann resolven wenn die
> Korrektur raus ist.

Die Beschreibung war nicht allzu gut - sorry ...
ich hatte das Phänomen, dass am linken Rand (des Signals)
dieses bei Betätigen der Stop-Taste an den oberen Bildschirm-Rand
zog.
>
> Hayo


Grüße,

   rowue

PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt

Die Single/Run Logik kapiere ich noch nicht so recht - hilfst du mir auf 
die Sprünge?

Michael

Ah da stimmte noch was nicht mit meiner Masse, jetzt macht das ganze 
Sinn und scheint auch gut zu funktionieren.

Michael

Zum Singlemodus ist noch anzumerken, dass der Triggermode zwangsweise in 
den Normalmodus geschaltet wird, damit auch wirklich nur dann ein neues 
Ereignis ausgelöst wird wenn die Triggerschwelle überschritten wird.

Sollte da aber nichts kommen (zu hoher Triggerlevel oder so) wartet das 
DSO natürlich bis zum Sankt Nimmerleinstag.

Der Singlemodus steht jetzt nur noch dann zur Verfügung wenn der 
Single-Druckknopf grün hinterleuchtet ist - dazu muß man die 
Run/Stop-Taste drücken. Im aktivierten Zustand ist der Druckknopf orange 
hinterleuchtet. Nach erfolgtem Triggerereignis ist er wieder grün und 
signalisiert damit Bereitschaft. Das Ganze wird durch erneutes Drücken 
der Run/Stop-Taste beendet.

Gruß Hayo

Rolf Würdemann schrieb:
> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt

Sind aber noch genug für alle da...      ;-)

Gruß Hayo

Hayo W. schrieb:
> Rolf Würdemann schrieb:
>> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt
>
> Sind aber noch genug für alle da...      ;-)

Wink verstanden ;)
Ich hoffe mal, dass ich Fr/Sa mit der Geschichte an der
ich gerade bin durch bin, dann kann ich mir das eine oder
andere "greifen" ;)
>
> Gruß Hayo

Grüße,

   rowue

Hallo,

ist es Absicht, dass wenn ich Quickmeasure aus und dann wieder 
einschalte die Kanalwahl der einzelnen Messfunktionen überschrieben 
wird? Denke ja hoffentlich mal nicht. Hab das mal rausgenommen. Jetzt 
bleibt die Kanalwahl der einzelnen Messfunktionen beim Aus- und 
Einschalten von Quickmeasurement erhalten.

Ich werde die Änderungen in den aktuellen trunk der OSS ablegen. Ich 
hoffe odch, dass irgendwann hier auch mal deine Änderungen erscheinen. 
Es ist schon ein Aufwand in zwei Verisonen immer nachzuschauen, ob 
jemand anderes das Problem vielleicht schon gefixt hat.

@Hayo

Ich habe mich mal daran veruscht, die HE0.96 und die OSS.91 
zusammenzuführen, damit wir wieder an einem Strang ziehen. Hat auch fast 
alles geklappt. Kannst du mal schauen, ob noch alles drinnen ist, was du 
die letzte Zeit gemacht hast. Außerdem habe ich bei der RS232-Verbindung 
irgendwas vermischt. Jedenfalls geht die Screenshot-Funktion derzeit 
nicht. In tc_vars.cpp Zeile 2570 & 2450 habe ich den Überblick verloren, 
was den nun eigentlich ins Menü für den Screenshot rein muss. Bin da 
gerade nicht so auf dem laufenden. Vielleicht kannst du die 
Screenshot-Funktion wieder richten. Blicke da gerade nicht durch ;-)

Hallo Stefan, hallo Hayo,

schön das du am mergen bist Stefan! Ich hoffe du nimmst die Remote 
Control Funktionen aus der OS.91 da die in der HE 0.96 definitiv noch 
einige Probleme haben! Wollte ein Ticket aufmachen, da aber die 0.96 
nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler 
auch in der 0.95 auftaucht, hab ich nicht getestet).
Ich Hatte auch keine Lust das Ganze ausführlich zu testen, da mich das 
bei meiner GUI Programmierung nur behindert.

Der "Dump data  STX  ASCII 03" liefert definitiv falsche Daten,
Die continious dump Befehle zeigen gar keine Wirkung...

Hier hab ich mal einen Screenshot der neuen GUI veröffentlicht, damit 
man auch sieht wo das Ganze hinführen wird...

http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34

Gruß, brunowe

Hallo brunowe,

ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit 
deiner GUI testen?

Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die 
Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und 
grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es 
heute Abend in SF.

Stefan E. schrieb:
> Hallo brunowe,
>
> ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit
> deiner GUI testen?
>
> Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die
> Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und
> grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es
> heute Abend in SF.

Committe meinetwegen einfach, wenn es Probleme mit der PC-Kommunikation 
gibt, kümmere ich mich darum.

Falk
http://sourceforge.net/apps/phpbb/welecw2000a/

Hi,

besten Dank schonmal an Stefan für das Mergen der Versionen, ich weiß 
nicht wann Rolf und ich sonst dazu gekommen wären.

Zur Remote-Schnittstelle: Da mir die Testmöglichkeiten fehlen habe ich 
die OS-Sourcen nach offensichtlichen Änderungen durchsucht und diese 
dann bei mir eingebaut. Kann gut sein, dass noch eine Kleinigkeit fehlt, 
die mir nicht aufgefallen ist, hier sollte aber die OS-Version die 
Vorgabe liefern.

Zum Screenshot: Ich hatte das Druckmenü bei mir so geändert, dass die 
einzelnen Funktionen vom DSO aus anwählbar sind und daher die 
Screenshotfunktionen mit einem Parameter versehen.

Um mit der aktuellen PC-Software kompatibel zu sein, müssen die 
Screenshotfunktionen der OS-Version verwendet werden - auch die RLE 
Encoderfunction!

Um das Ganze zu mergen gibt es zwei Varianten:
Entweder  muß die Menüstruktur der OS-Version verwendet werden, dann 
werden keine Parameter gebraucht, oder die Screenshotfunktionen und die 
PC-Software werden um diese Parameter erweitert, dann kann meine 
Menüstruktur verwendet werden (Definition in tc_vars 2450/2570/2607).

Die flash_t kann vermutlich komplett von mir übernommen werden, da dort 
wahrscheinlich keiner etwas geändert hat.

In hardware_t gibt es die neuen Funktionen Reset_To_Default() und 
Restore_From_Flash() die bei der neuen Startupsequenz genauso zum 
Einsatz kommen wie bei der Recall-Funktion und der 
Autoscale-Undo-Funktion.

-> handle_ADC() hat sich unter Anderem geändert!

In userif_t hat sich ebenfalls einiges getan, unter anderem die neue 
Run/Stop/Single-Logik im Button handler.

commif_t kann größtenteils von der OS-Version übernommen werden, hier 
habe ich nur im USB-Transfer einige tote Variablen entfernt (CH1_DAC_1 
usw.)

In display_t haben sich die Draw-Routinen etwas geändert.

In signal_t hat sich die Noise Suppression etwas geändert (if-Bedingung 
- siehe Ticket 39)

Ich werde aber noch mal über Deine gemergten Files drüberschauen und mal 
sehen ob mir da was auffällt.

Gruß Hayo

Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den 
ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da 
einfach was schiefgelaufen?

Gruß Hayo

Hayo W. schrieb:
> Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den
> ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da
> einfach was schiefgelaufen?

Da sind nur ziemlich lange relative Pfade drin.

Ich habs mal für Winzip vorverdaut ;-)

Falk

@Falk

Danke.

@Stefan

Ich habe mal userif_t.cpp geprüft - es gibt noch 5 Stellen die geändert 
werden müssen und je nach wunsch evtl. die Quick Print Menüfunktionen. 
Ich prüfe noch die anderen und stelle die überarbeiteten Files dann hier 
ein.

Gruß

Hayo

Hayo W. schrieb:
>
> Bei der
> Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so
> dass diese jetzt vernünftig funktioniert.

Mir gefiel das vorher besser!
Mit der 0.96HE ist es nicht mehr möglich das Signal im stop mode zu 
analisieren (strecken, verschieben usw.) überdies wenn ich in den delay 
modus wechsle sind die Signale weg!


grüss Martin

@Martin

Ich habe im Stop-Modus das Drehgeberinterface blockiert, da sich die 
Nullpunktlage verschieben ließ, ohne dass das Signal folgte. Wenn das 
vom Handling gefälliger ist mit der Möglichkeit was zu verstellen, kann 
ich das auch wieder rausnehmen oder etwas feiner einschränken.

Gruß Hayo

Martin H. schrieb:

> wenn ich in den delaymodus wechsle sind die Signale weg!

Das war mir noch nicht aufgefallen, ist in Arbeit...

Hayo

Hayo W. schrieb:
> Martin H. schrieb:
>
>> wenn ich in den delaymodus wechsle sind die Signale weg!
>
> Das war mir noch nicht aufgefallen, ist in Arbeit...

Können wir vielleicht endlich mal versuchen, eine Version zu 
pflegen?

Wer einen Bug findet, meldet den hier: 
http://sourceforge.net/apps/trac/welecw2000a/report
Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen 
werden committed und ggfs. wird eine Release daraus gemacht, das man 
dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen 
kann.

Sonst wird das Durcheinander noch größer.

Falk

@Falk

Wenn ich noch was ändere, baue ich das in die gemergte Version mit ein, 
evtl. ändere ich aber auch erst nach dem Mergen direkt in der OS 
Version.

Keine Sorge, ich mach jetzt deswegen keine neue Version auf.

Gruß Hayo

@Stefan

Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an 
der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer 
dabei.

@all

Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen 
Status?

Gruß Hayo

Hayo W. schrieb:
> @Stefan
>
> Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an
> der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer
> dabei.
>
> @all
>
> Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen
> Status?

Ich habe eben Stefans Files commited (revision 245).

Falk

Bruno We schrieb:
> Hallo Stefan, hallo Hayo,
>
> [....] Wollte ein Ticket aufmachen, da aber die 0.96
> nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler
> auch in der 0.95 auftaucht, hab ich nicht getestet).[...]

Habe die 0.96HE im Ticket-System nachgetragen
>
> Gruß, brunowe


Grüße,

   rowue

>@Stefan

>Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an
>der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer
>dabei.

Das war ich. Hab mich wohl nicht eingetragen. Vorher wurden beim Ein-und 
Ausschalten von QM die ausgewählten Kanäle der Messfunktionen geändert. 
Das hab ich abgestellt.

>Können wir vielleicht endlich mal versuchen, eine Version zu
>pflegen?

>Wer einen Bug findet, meldet den hier:
>http://sourceforge.net/apps/trac/welecw2000a/report
>Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen
>werden committed und ggfs. wird eine Release daraus gemacht, das man
>dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen
>kann.

>Sonst wird das Durcheinander noch größer

Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann 
ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in 
welcher Version behoben war.

@Hayo
Wenn du noch die letzten Änderungen schickst, aktualisiere ich das in 
SF, bis du dich damit mal selber befasst. Lieber viele kleine Schritte, 
als so ein großer. Danach würde ich die 0.92_OSS rausbringen, auf der 
wir alle weiterentwickeln.

>Da sind nur ziemlich lange relative Pfade drin.

>Ich habs mal für Winzip vorverdaut ;-)

Hab das unter OpenSuse gezippt. Das da dann überhaupt die Pfade mit 
drinnen sind ist mir neu.
Das WinZip ein Mist ist dachte ich mir ja schon immer ... ;-)

@ Hayo

Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte 
bis dahin nicht verstanden, dass das überhaupt möglich ist...
Wenn ich mal auf Energiereserven in mir stoße, fange ich vielleicht mit 
einem kleinen Handbuch zur Firmware an, sicher haben andere auch 
Probleme, alle Möglichkeiten zu entdecken.
Achja: bei mir funktioniert der delayed modus mit der 0.96 tadellos.

Ich fände es auch gut, wenn man im Stop Mode die Möglichkeit zum 
Scrollen oder Zoomen (wo möglich) wieder bekommen könnte.

Gruß
Michael

Falk Willberg schrieb:

> Ich habe eben Stefans Files commited (revision 245).

Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen 
sind noch nicht geprüft.

Ist das so gewollt?

Gruß Hayo

Stefan E. schrieb:

> Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann
> ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in
> welcher Version behoben war.

Damit testen kann, wer testen will, hier noch eine TomCat.ram aus den 
SVN-Sourcen: http://falk-willberg.de/tmp/TomCat.ram.gz

Falk

>Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte
>bis dahin nicht verstanden, dass das überhaupt möglich ist..

Wir haben uns doch nicht irgendeinen billigen Oskar gekauft, bei dem QM 
nur auf einem Kanal gleichzeitig möglich ist. ;-)

Ich denke, dass du dich auf #33 beziehst. Da hab ich versucht das zu 
erklären. ;-)

Roberto schrieb:
> Hallo werte W20xxA Besitzer und Interessierte!
>
> Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal
> einen zweiten Teil davon aufgemacht!
> Bitte hier weiterschreiben:
> Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

Ohne mich!

Falk

Oh, da habe ich doch glatt dem falschen die Lorbeeren zugeschustert, so 
war das nicht gedacht.
Stimmt, du warst ja der QM-Fachmann! Dann also danke nochmal an dich für 
die Erklärung und die gute Arbeit an den Messfunktionen.
Ein gutes Beispiel für die Nützlichkeit habe ich hier gerade laufen: ein 
I2C Farbsensor, dessen Werte ich mit nem Controller als dreikanalige PWM 
ausgebe (RGB). Da kann man sehr schön sehen und messen, was für 
Farbanteile man da gerade hat. Jaja, die Welec-Kiste hat zwar noch ihre 
Macken, aber irgendwie ist sie mir doch schon ans Herz gewachsen :)
Wie aufwändig ist es denn, die Messerei für die schnellen timebases zu 
fixen?

Deinen Vorstoß zur Zusammenführung der Versionen finde ich auch klasse, 
es bahnte sich ja schon der eine oder andere Streit an deswegen.

Gruß
Michael

Hayo W. schrieb:
> Falk Willberg schrieb:
>
>> Ich habe eben Stefans Files commited (revision 245).
>
> Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen
> sind noch nicht geprüft.

Dann pflege die Fixes doch ein.

> Ist das so gewollt?

Ich wollte endlich wieder eine Basis haben, auf der ich sinnvoll 
weitermachen kann. Es gibt da ein paar Erweiterungen, auf die jemand 
wartet.

Falk

@Hayo

Es wäre schön wenn das Strecken und Verschieben des Signals im 
Stop-Modus wieder ginge ...

Manuel schrieb:
> hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur
> ganz kurz auf geht und dann gleich wieder weg ist?
>
> ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen
> laptop und da gehts nur kurz auf und ist nach ner  halben sekunde wieder
> weg...

Das screenshot-Programm ist ein Kommandozeilen-Tool. Im Terminal (oder 
wie heißt das unter Win?) siehst Du auch die Fehlermeldung.

Wahrscheinlich ist das Problem, daß am Laptop keine COM1 vorhanden ist, 
auf die das Tool ohne Parameter zugreift.

Alternativ installiere Linux, damit gehen auch andere Sachen besser.

Vielleicht könnte sich mal ein Windows-User des Screenshot-Tools 
annehmen? Da sollte sich doch bei >95% Marktanteil jemand finden...

Falk
P.S.: Solche Fragen sind bei 
http://sourceforge.net/apps/phpbb/welecw2000a/ besser aufgehoben.

...das ist die Dos-Eingabeaufforderung "CMD.exe" meistens unter 
C:\Windows\system32 zu finden oder unter dem Reiter "Zubehör"

Gruß Michael

Jürgen schrieb:
> @alle
>
> Roberto hat doch nun schon den neuen Thread aufgemacht.
>
> Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
>
> Schreibt doch bitte alle dort weiter, damit dieser Thread nicht noch
> länger wird!

Nein, http://sourceforge.net/apps/phpbb/welecw2000a/ ist besser 
geeignet.

Falk

...also was dann jetz? Mir geht das jetzt auf'n S..., wann sind wir uns 
denn hier einich???
Ich versuche so gut wie möglich hier den Überblick zu behalten was aber 
bald unmöglich sein wird, da der Thread hier wirklich schon 100km lang 
ist!

Ich fände es jetzt nicht schlecht, wenn es, wie FALK es schon 
vorgeschlagen hat, im SF weiter ginge, da ja schon 3 Thread's 
(ENTWICKLER, HARDWARE, SOFTWARE) aufgemacht worden sind!!!

Ich selbst bin dort als KASTOR7 registriert(mike0815 war schon 
vergeben)!
Bei Fragen oder Beiträgen von hier, kann ja verlinkt werden...
...das wäre jetzt mein Vorschlag, was hält denn der Rest davon???

Gruß Michael

Hallo Michael,

allein schon weil wir auf SF (innerhalb unseres Projekts) Admin Rechte 
haben, bin ich stark dafür!

P.S.:
Ich hab mal hier:
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34
ein aktuelles Foto von der GUI eingestellt. Derzeit bin ich dabei einige 
Programme der Profis zu analysieren, um mal zu sehen wie die das ein 
oder andere Problem in der Programmierung und Darstellung gelöst haben.
Da ich derzeit schon ca. 3000 Zeilen Programmcode geschrieben habe 
wird's langsam Zeit für eine ordentliche Programmstruktur...

Gruß, brunowe

Meine Meinung dazu könnt Ihr hier

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

lesen und kommentieren. Danke!

Hallo zu allen!
entschuldigt sich für meinen bösesten Deutschen, aber ich habe ein 
Problem mit dem W2012A und ich brauche eure Hilfe..

Ich versuchte die Fortbildung der Firmware mit der Software von Welec zu 
machen (W2000-Update)und während es für Fehler entlud, schloß ich das 
Fenster. es scheint jetzt, daß ich keine firware mehr installiert  habe 
und wenn ich wieder das Programm den upload losgehen lasse, fängt es 
nicht an..
wie ich kann wiedergutmachen?

Hallo an alle! Ich kaufte den Umfang von welec und ausgeliefert haben, 
den Artikel regelmäßig bezahlt denn es ist eine Schande, nicht um E-Mail 
zu reagieren.
Ich dachte, dass die Deutschen richtigen Leute waren. Enttäuschung 
total!
Ich möchte eine Antwort von Ingenieur.

Hello everyone! I purchased the scope from welec and have shipped the 
item regularly paid for it is a shame not respond to email.
I thought that the Germans were right people. Disappointment total!

Ciao a tutti !  Ho acquistato l'oscilloscopio dalla welec e non hanno 
spedito l'oggetto regolarmente pagato è una vergogna non risponde ad 
email .
Credevo che i tedeschi erano persone corrette .Delusione totale!