Hallo,

ich möchte mich an der Weiterentwicklung (erst GUI, später ggf. FPGA)
beteiligen und hab schon erste Kontakte mit Alex gepflegt. Es gibt
inzwischen viele nützliche Infos zum DSO, aber bei der Suche nach diesen
Infos ist mir aufgefallen, daß sie weit verstreut liegen und daß die
Entwickler sich auf den verschiedensten Plattformen tummeln:

- der vorliegende Firmware-Thread

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

der inzwischen aufgesplittet wurde und den trotzdem kaum jemand benutzt
:-)

- das Hardware-Forum Beitrag "Wittig(welec) DSO W20xxA Hardware"

- Sourceforge http://sourceforge.net/apps/phpbb/welecw2000a/ mit
diversen Kategorien

- Skype

- Welec- und #Welec-IRC-Chat auf conference.jabber.ccc.de

- ...

Das Engagement der Entwickler ist super, aber wäre es nicht sinnvoller,
die Kräfte zu bündeln und uns auf eine einzige Plattform zu einigen?

Ich favorisiere welecw2000a auf Sourceforge, weil das sehr übersichtlich
ist und man auch recht schnell an die gewünschten Infos kommt. Es ist
schade, daß es bisher so wenig genutzt wird.

Gruß Ingo

Die Frage ist doch, sind alle unregistrierten Gäste bereit, sich bei
Sourceforge anzumelden?
Nicht dass wir SF in deutsch und englisch diskutieren und hier noch mit
ein paar zurückgebliebenen* Gästen.



* Nein, nicht geistig zurückgeblieben.

Beim Versuch ein neues Thema bei Sourceforge zu erstellen bekomme ich
einen Umleitungsfehler.
Verwendet wird Firefox unter WinXP SP3. Beim Internet Explorer
funktioniert es hingegen.

Hallo Kurt,

mir ist nicht ganz klar was du mit neues Thema genau meinst.
Hast du das gelesen:
http://sourceforge.net/apps/phpbb/welecw2000a/view...

(können wir bei Bedarf natürlich ändern... ist aber derzeit halt so
eingestellt)

Ich hab auch einmal ein paar Gedanken zu der PC GUI zusammengefasst:
(und hoffe auf Response)

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

P.S. derzeit sind schon 55 Leute bei unserem Projekt in SF registriert.
Die notwendige Registrierung kann also eigentlich keine Begründung für
die geringe Anzahl der Posts dort sein.

Gruß, brunowe

Hallo Bruno,
mit neues Thema meine ich ein neues Topic erstellen. Das geht unter
Firefox genausowenig wie auf ein Topic Antworten.

Dieses Topic wurde mit dem IE erstellt.
https://sourceforge.net/apps/phpbb/welecw2000a/vie...

Hallo Kurt,

also ich hab meinen o.a. Topic mit Firefox (3.5.3) erstellt und hatte
keine Probleme. Mag evtl. nur ein kurzfristiges Problem mit dem SF
Server gewesen sein?

Bruno We schrieb:
> Hallo Kurt,
>
> also ich hab meinen o.a. Topic mit Firefox (3.5.3) erstellt und hatte
> keine Probleme. Mag evtl. nur ein kurzfristiges Problem mit dem SF
> Server gewesen sein?

Ich habe den IE8 mit WinXP da funktionert das sehr wohl, ein neues Topic
zu eröffnen(wenn man registriert ist)z.B.
https://sourceforge.net/apps/phpbb/welecw2000a/vie...

Hallo Alexander,
ich bin für alles offen und für jeden Fortschritt den dieses Projekt
macht, dankbar!
Es wird doch von allen Seiten nach Unterstützung geschriehen, daher
verstehe ich nicht, das eine solche Arbeit, wie du sie leistest da
untergehen kann (17000 Zeilen, du meine Güte), über ein solches
Engagement sollte man schon eine Anerkennung verdiehnt haben, die du
auch hiermit von mir erhälst: HUT AB!

...so, ich gehe jetzt mal mit meinen Buben gassi!

Gruß Michael

Jürgen schrieb:
> Stefan E. schrieb:
>
>>@Hayo
>
>>Es wäre schön wenn das Strecken und Verschieben des Signals im
>>Stop-Modus wieder ginge ...
>
> Ebenso!
>
> Gruß Jürgen

Hab ich bei mir (BF.0.97) schon nach Euren Wünschen geändert, ebenso wie
ich den Bug im Autoscale inzwischen gefixed habe. Muß mich aber noch mit
dem SVN anfreunden um es in die OS-Version einpflegen zu können. Gebe zu
dass ich das irgendwie vor mir herschiebe, da ich mit allen möglichen
Ideen rund um die Firmware beschäftigt bin.

Aktuelles Projekt bei mir ist gerade der Timebase-Controller. Meine
bisherigen Tests mit verschiedenen Registerwerten lassen vermuten, dass
das FPGA-Design anscheinend tatsächlich so vergurkt ist, dass die
Timebases 100MSa/s und 50MSa/s nicht vorgesehen sind.

Zur Zeit bereite ich gerade eine komplett neu designte Timebasesteuerung
vor, bei der zwar auch die beiden Timebases fehlen, aber bei der die
Aufteilung etwas sinniger und homogener ist.

Gruß Hayo

alex008_ schrieb:

> Beispielsweise habe ich schon ca. 17000 Codezeilen für das Projekt
> geschrieben, ohne dass dies den meisten die die myC Threads lesen,
> bewusst ist oder von mir viel gehört haben.
>
> Jeden Version von Hayo und Slogs Pläne sind bestens bekannt, jedoch
> gehen die beachtlichen Leistungen aller anderen unter. Das liegt leider
> in der Natur der Sache, dass Neuentwicklungen anfangs für sehr lange
> Zeit für Anwender nichts vorzuweisen haben. Diese Eigenschaft verzerrt
> zusätzlich das Bild, welches die Masse von den einzelnen Entwicklern
> bekommen.
> Dieses führt dazu, dass viele den bekannteren Entwicklern mehr
> vertrauen, als den unbekannteren, welches in einigen Fällen sehr
> nachteilig wirkt.

Hi Alex,

wie Du schon sagtest ist es halt so dass das primäre Interesse erstmal
den direkt nutzbaren Ergebnissen gilt. Ist ja auch verständlich. Deine
Entwicklung (und auch die der anderen FPGA-Entwickler) sind aber
durchaus nicht unbemerkt geblieben an der Softwarefront. Die
Bestrebungen auf der Firmwareseite gehen ja nicht nur in Richtung
Fehlerfreiheit und neuer Funktionen, sondern auch in Richtung
Portierbarkeit auf andere FPGA-Designs. Ich für meinen Teil warte schon
seit einiger Zeit gespannt darauf, dass eines der neuen Designs einen
Status erreicht, der eine Portierung möglich macht. Wenn ich das richtig
mitbekommen habe ist Deine Arbeit zur Zeit die einzige die noch konkret
vorangetrieben wird.

Wie ist denn Deine Einschätzung wie lange es ungefähr dauern wird bis
eine Portierung auf Dein neues Design möglich sein wird?


> Um einen Portalwechsel oder eine interne Abwerbung für einen
> Entwicklungszweig zu erreichen, muss man sehr leicht verständliche
> und sehr gute Gründe vorweisen können.

Also meine Gründe hier weiterhin zu posten sind folgende:

- SFN ist teilweise extrem langsam mit den Antwortzeiten bzw. Ladezeiten
der Seiten, teilweise ist es auch mal überhaupt nicht zu erreichen

- ich hatte mehrfach das Problem, dass ich mit drei unterschiedlichen
Browsern arbeiten musste um auf den unterschiedlichen Seiten alle
Funktionen zur Verfügung zu haben

- in diesem Forum kommen die meisten Anfragen zur Firmware, daher gebe
ich hier natürlich auch die meisten Kommentare ab


Trotz alledem finde ich die SFN-Projektseite wirklich gut und versuche
auch diese Plattform mit zu nutzen. Es ist ja eigentlich auch kein
echtes Problem auf beiden Plattformen präsent zu sein.

Gruß Hayo

Nabend ....

ich habe mal die Verstärkungsfaktoren von

1.25, 2, 4 auf 1, 2.5, 5 angepasst (hatte Guido auch
schon mal) und die Darstellung entsprechend geändert.
Der Patch kann in

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

eingesehen werden, ebenso wie weitere Messungen zu dem Thema.
Als Diskussionsthread habe ich bei SFN

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

aufgemacht. Falls der eine oder andere mit dem Image alternative
Messungen macht, würde ich mich über einen Anhang an's Ticket
freuen.

Grüße,

   rowue

Hallo Rolf,
hast das imgage 2x im Anhang, sind beide unterschiedlich oder...war das
ein Versehen???

Gruß Michael

Hayo W. schrieb:
> Jürgen schrieb:
>> Stefan E. schrieb:
>>
>>>@Hayo
>>
>>>Es wäre schön wenn das Strecken und Verschieben des Signals im
>>>Stop-Modus wieder ginge ...
>>
>> Ebenso!
>>
>> Gruß Jürgen
>
> [...]
>
> Aktuelles Projekt bei mir ist gerade der Timebase-Controller. Meine
> bisherigen Tests mit verschiedenen Registerwerten lassen vermuten, dass
> das FPGA-Design anscheinend tatsächlich so vergurkt ist, dass die
> Timebases 100MSa/s und 50MSa/s nicht vorgesehen sind.

Also: André hat da mal einige Dinge ausgerechnet:

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

ich bin über "Stopp", Timebase verstellen (von 25MSa/s aufsteigend)
mal in den Bereich 50 und 100 gekommen - also scheint da was
möglich angedacht zu sein ;)

>
> Zur Zeit bereite ich gerade eine komplett neu designte Timebasesteuerung
> vor, bei der zwar auch die beiden Timebases fehlen, aber bei der die
> Aufteilung etwas sinniger und homogener ist.

Wäre schon mal einiges ;)
>
> Gruß Hayo

Grüße,

   rowue

PS: aber gerade weil Du so gute Ideen hast, solltest Du Dich mit dem
svn anfreunden ;) - Es beißt nicht und geht schnell ;)

Michael D. schrieb:
> Hallo Rolf,
> hast das imgage 2x im Anhang, sind beide unterschiedlich oder...war das
> ein Versehen???

Tja, einmal mit Virus, einmal ohne ;)

Scherz beiseite:

   war ein Versehen ....

btw: Das ram-Image fusst auf dem aktuellen svn-Stand

>
> Gruß Michael

Grüße,

   rowue

Ingo M. schrieb:
> Hallo,
>
> [...]
>
> - Skype
>
> - Welec- und #Welec-IRC-Chat auf conference.jabber.ccc.de

Es gibt einmal

   #welec (IRC) auf irc.freenode.net

und einmal

   welec@conference.jabber.ccc.de

   als Groupchat innerhalb Jabber (xmpp) auf conference.jabber.ccc.de
   (aka jabber.ccc.de)

   bevor sich über letzteres jmd. wundert, jabber.ccc.de ist ein
   sog. "freier" Server, auf den sich jeder eintragen kann und
   wo auch so ziemlich jeder einen Groupchat/Chatroom aufmachen
   kann ;)


>
> - ...
>
> [...]
>
> Gruß Ingo

Grüße,

   rowue

...man, müsste längst im Bett sein...

ich bekomme das gezappel vom Rechtecksignal nicht weg, erst wenn ich
Kanal 2 anschliese, habe ich bei beiden ein ruhiges Signal, ziehe ich K2
wieder ab, bleibt K1 ruhig stehen!
Ziehe ich K1 ab, zappelt K2 wieder, ein Tauschen der Tastköppe bringt
nichts.
Ich hab das Image mit dem Virus erwischt...(auch Scherz)

Gruß Michael

...vergesst es, hatte da was übersehen!!!

Gruß Michael

Hallo !

Ich würde mich gern von meinem W2024A trennen. Ich hab's jetzt ~ 6
Monate, Firmware-Updates sind eingespielt, das Abschirmblech aus dem
Hardware-Thread liegt bei. Das Scope ist in makellosem Zustand, der
Bildschirm fehlerfrei - Nichtraucher - 1A Zustand.
Natürlich einschließlich aller 4 Tastköpfe !

Bekomme ich ein realistisches Angebot ?


Gruß, Stefan

Rolf Würdemann schrieb:

> Also: André hat da mal einige Dinge ausgerechnet:
>
> http://sourceforge.net/apps/trac/welecw2000a/wiki/Timebases
>
> ich bin über "Stopp", Timebase verstellen (von 25MSa/s aufsteigend)
> mal in den Bereich 50 und 100 gekommen - also scheint da was
> möglich angedacht zu sein ;)

Die Gedanken von André habe ich mir in ähnlicher Form auch schon
gemacht, hier handelt es sich aber um wünschenswerte Aufteilungen. Im
Gegensatz dazu stehen aber die tatsächlich möglichen Aufteilungen des
bestehenden FPGA-Designs. Ich habe schon diverse Registerwerte getestet,
diese führen aber zu verzerrten Signalen. D.h. wie schon geschrieben
habe ich bislang noch keine Registereinstellung gefunden die tatsächlich
die TB 100/50 MSa/s hergeben. Wenn Du zufällig mal auf diese TB gestoßen
bist, versuche das doch mal nachzustellen und teile mir mal die
Registewerte mit (kann man sich im Terminal mit >,< anzeigen lassen)


> PS: aber gerade weil Du so gute Ideen hast, solltest Du Dich mit dem
> svn anfreunden ;) - Es beißt nicht und geht schnell ;)

Klar, ist wahrscheinlich kein großes Ding, aber wenn ich von der Arbeit
nach Hause komme und nicht gerade für Trivialaufgaben wie Gartenarbeit
etc. herangezogen werde, schwirren mir meist schon irgendwelche Ideen im
Kopf rum. Da setzt man sich natürlich lieber hin und probiert das aus
anstatt sich mit SVN auseinanderzusetzen.

Ok ich gebe zu ich bin schwach und undiszipliniert ;-)

Aber da es sich um ein Hobby handelt und es kein Geld dafür gibt nehme
ich mir diese Freiheit einfach mal raus. Immerhin hab ich SVN schon
installiert, das ist doch schon mal ein Schritt in die richtige
Richtung!


Gruß Hayo

Bevor noch weitere fragen, und da ich das Ganze auch transparent halten
möchte:
Ich mag das Scope wirklich sehr. Bildschirm ist prima, Software hier und
da etwas hakelig, aber im Großen und Ganzen viel Gegenwert für's Geld.
Ich möchte es jedoch nicht mehr verwenden, da der Trigger einfach immer
noch nicht zuverlässig arbeitet und andere Baustellen anscheinend eine
höhere Priorität haben - versteht mich bitte nicht falsch; ich habe
keinen Anspruch, dass etwas für mich priorisiert wird; aber wozu braucht
denn ein Scope eine Screenshot-Funktion, Auto-Meassure, Store-Restore
u.s.w., wenn die eigentliche (!) Funktion, das Darstellen von
Signalverläufen, nicht einwandfrei funktioniert !?
Ich habe z.B. einen Ausschnitt einer digitalen Kommunikation; jetzt
interessiert mich der Bereich, der gerade so nicht mehr angezeigt wird;
weil der Bildschirmbereich nun einmal endlich ist. Drehe ich die
Timebase einen runter, ist alles FLAT, kein Trigger, nichts. Timebase
noch einen runter und das Signal wird wieder angezeigt - links an den
Rand gequetscht, denn so weit wollte ich mit der Timebase ja eigentlich
nicht runter gehen :(
Regelmäßig bleibt das Signal auch einfach stehen (Normal-Modus, Ticket
vorhanden) - obwohl definitiv ein triggerfähiges Signal anliegt. Man
muss dann wieder auf Auto und zurück zu Normal wechseln, um den Trigger
erneut zu motivieren. Das ist Mist und da ich nicht erkennen kann, dass
das zeitnah gefixed wird, habe ich mich zum Verkauf entschieden. Wenn
man mit den Einschränkungen leben kann, wird man nirgends mehr für sein
Geld bekommen - ich denke, da sind wir uns alle einig.

Stefan

Noch ein kleiner Nachschlag zu den Ausführungen von André.

Letzendlich gilt es einen Kompromiss zu finden zwischen einem möglichst
großen Scrollbereich und der Anzahl der verfügbaren Delayed-Zeitbasen,
die ohne Interpolation darstellbar sind.

Das eine Extrem ist der Faktor 1 wie bei der Zeitbasis 50nS/Div, hier
stehen nur interpolierte Delayed-Zeitbasen zur Verfügung, aber dafür ein
maximaler Scrollbereich.

Das Gegenextrem ist der Faktor 25 wie bei der Zeitbasis 5µS/Div, hier
steht ein minimaler Scrollbereich der Möglichkeit gegenüber 4 nicht
interpolierte Delayed-Zeitbasen zu nutzen.

Der optimale Kompromiss liegt meines Erachtens bei Faktor 4 und 5
(Zeitbasen 10µS - 500mS). Hier hat man einen recht anständigen
Scrollbereich und trotzdem zwei nicht interpolierte Delayed-Zeitbasen.

Meine Bestrebungen gehen daher auch in die Richtung möglichst homogen
bei den meisten Zeitbasen den Faktor 4 und 5 zu verwenden und nur
ausnahmsweise davon abzuweichen.

Gruß Hayo

Default User schrieb:

> Das ist Mist und da ich nicht erkennen kann, dass
> das zeitnah gefixed wird, habe ich mich zum Verkauf entschieden. Wenn
> man mit den Einschränkungen leben kann, wird man nirgends mehr für sein
> Geld bekommen - ich denke, da sind wir uns alle einig.
>
> Stefan

Hallo Stefan,

in der Tat weiß auch ich nie genau wann ich welchen Fehler fixen werde.
Oft ist es so, dass ich im Rahmen einer Idee die ich umsetze auf Fehler
in anderen Bereichen stoße, die ich dann fixe. So auch jetzt bei meinen
vorbereitenden Änderungen zum neuen Timebasecontroller. Hier habe ich
mehr als die Hälfte der Zeit bis jetzt aufgewendet um Bugs zu fixen (im
Rotary Interface, beim Zeichnen der Zero-Zeichen etc.). Eines ist aber
definitiv sicher: Die FW wird sukzessive besser und für so kleines Geld
gibt es nirgends solche Technik mit mittlerweile so breitem Open Source
Support.

Was ich mich dabei frage ist, was Du denn als Alternative vorgesehen
hast. Wenn ich mir so die ganze Low-Budget Konkurenz aus Asien ansehe,
wäre das für mich auf keinen Fall eine Alternative. Da käme bei mir dann
nur ein (recht teures) Marken-DSO in Frage. Dieses Budget steht aber
Vielen im Hobbybereich nicht zur Verfügung.


> da der Trigger einfach immer
> noch nicht zuverlässig arbeitet und andere Baustellen anscheinend eine
> höhere Priorität haben - versteht mich bitte nicht falsch; ich habe
> keinen Anspruch, dass etwas für mich priorisiert wird; aber wozu braucht
> denn ein Scope eine Screenshot-Funktion, Auto-Meassure, Store-Restore
> u.s.w., wenn die eigentliche (!) Funktion, das Darstellen von
> Signalverläufen, nicht einwandfrei funktioniert !?

Also die Baustellen an denen die unterschiedlichen Entwickler arbeiten
haben keine direkte Priorisierung, sondern richten sich eher nach den
Neigungen und Interessen der jeweiligen Entwickler. Die
Screenshot-Funktion erlaubt zum Beispiel den Testern die einfache
Dokumentation von Fehlern - sehr Hilfreich! Ebenso einfach ist dadurch
das Erstelllen von Anleitungen.

Bei mir gehen die Prioritäten vom Grundsätzlichen zum Detail. Das heißt,
wenn das Coding im Großen und Ganzen verwurstet ist, dann bringe ich da
erstmal Ordnung rein, bevor ich mich auf Details stürze. Und die
Darstellung von Signalverläufen hängt hier von diversen Einflüssen
verschiedener Programmabläufe ab.

Wenn es also Probleme gibt die einem auffallen, bzw. die einen massiv
stören, sollte man sie erstmal melden (Ticket und evtl.
Forumsdiskussion). Je nach Schwere des Problems ist dann die
Wahrscheinlichkeit recht groß,
dass es in absehbarer Zeit eine Lösung gibt. Zumindest habe ich bei
meinen Entwicklungen immer ein waches Auge bezüglich bereits bekannter
Probleme.

Gruß Hayo

Hallo Hayo,

vielen Dank für Deine aufmunternden Worte. Ich habe nicht wirklich eine
Alternative im Auge; d.h. die neuen 4-Ch von Rigol für €900 sind mir
schon aufgefallen, ab das ist eben auch schon mal eine Hausnummer.
Ich habe noch ein zweites Scope von OWON; nichts worüber man ins
Schwärmen gerät, aber es triggert zuverlässig und stellt -im Rahmen
seiner Möglichkeiten- soweit alles dar.
Ich kann auch durchaus nachvollziehen, dass man bei einer verfrickelten
Firmware schnell vom Hundertstel ins Tausendstel kommt, auch dass sich
bei jedem Beteiligten Vorlieben ausprägen ist absolut nachvollziehbar;
aber auch wenn ich dieses und jenes prima finden würde und manche Dinge
(Screenshot) sehr hilfreich sind - nützt doch das alles nichts, wenn die
Grundfunktionalität nicht einwandfrei abgebildet ist !  Im Grunde
genommen, möchte man doch erst einmal MESSEN und braucht dafür einen
funktionierenden, verlässlichen Trigger - ohne Anzeige des Signals, kein
Auto-Measure und auch keinen Screenshot oder was sonst noch alles...
Wie gesagt, Vorlieben sind nachvollziehbar - das geht mir nicht anders
;) Aber wenn ein Auto immer wieder nach Belieben stehen bleibt und
manche Strecken überhaupt nicht fahren will, freut man sich doch nicht
darüber, dass man jetzt den Intervall der Scheibenwischer einstellen
kann, oder ?

Ich mag den Gedanken eines Open-Source-Scopes sehr - nur stehe ich mit
dem unzuverlässigen Trigger einfach zu oft im Regen... Wenn das Signal
dann einfach wieder völlig unmotiviert stehen bleibt (Ticket) während
man gerade aufwändig eine bestimmte Situation herbeigeführt hat oder
versucht, den Tastkopf an einer kniffligen Stelle ruhig zu halten kann
man schon mal ausflippen :-\
Wenn zusätzlich bestimmte Details ums Verrecken nicht darstellbar sind,
weil der Trigger in der erforderlichen Timebase einfach nicht läuft,
nach ja, ich spar' mir besser die Worte :(

Letztendlich - was meinst Du denn, wird das mit dem Trigger noch etwas
(?) ist das eine Firmware-Angelegenheit oder hängt da zu viel vom
FPGA-Design ab ?

Gruß, Stefan

@Stefan

> Ich habe noch ein zweites Scope von OWON;

Interessant! Da würde mich ja der direkte Vergleich interessieren. Ist
da die Firmware einigermaßen ausgereift oder wird man da auch von
etlichen Bugs geplagt, gibt es FW-Updates? Wäre es eine ernstzunehmende
Alternative?


> Im Grunde genommen, möchte man doch erst einmal MESSEN und
> braucht dafür einen funktionierenden, verlässlichen Trigger

Ja da hast Du natürlich recht. Aber das was für den Anwender die
Grundfunktionen sind, sind für den Entwickler oft komplexe
Detailfunktionen bei denen es (aus Entwicklersicht) eher Sinn macht an
anderer Stelle anzufangen um sich dann zum Detail vorzuarbeiten.

Was den Trigger angeht finde ich eigentlich das sich die Benutzbarkeit
doch schon extrem verbessert hat. Hast Du den mal mit der original FW
ausprobiert? Dagegen ist das doch schon echt gut. Die Probleme die Du da
schilderst sind mir noch nicht so aufgefallen, was aber auch daran
liegt, dass ich als Entwickler nicht immer so praxisbezogen teste wie
die eigentlichen Anwender. D.h. meistens habe ich am 50 Ohm Abschluß ein
Signal aus dem Signalgenerator (oft Rechteck) das sich ganz gut triggern
läßt.

> Letztendlich - was meinst Du denn, wird das mit dem Trigger noch etwas
> (?) ist das eine Firmware-Angelegenheit oder hängt da zu viel vom
> FPGA-Design ab ?

Das ist allerdings keine leichte Frage. Die Triggerung setzt sich ja aus
einem Hardwareanteil und einem Softwareanteil zusammen. Da ich mich nur
zwischendurch mal mit der Triggerung beschäftigt habe kann ich das nicht
mit Sicherheit beantworten. Meine Einschätzung ist aber, dass hier auf
Softwareseite sicherlich Optimierungspotenzial vorhanden ist.


Gruß Hayo

@Guido

Stimmt den NORM-Modus verwende ich eigentlich auch nie. Vielleicht ist
mir deshalb nichts aufgefallen.

Gruß Hayo

Jetzt macht mich nicht unruhig (!) der Auto-Modus des Owon funktioniert
genau so, wie er soll: kann der Trigger einrasten, macht er's - wenn
nicht, läuft das Signal durch, ganz so, als wäre kein Trigger aktiviert.
Beim Wittig triggert er im Auto-Modus nie; darum nutze ich ihn auch
nicht.

Ein triggerfähiges Signal (nahezu perfekte Flanken) liegt an und blitzt
von Zeit zu Zeit auch mal auf ?!?

Das OWON hat einen -etwas blassen- VGA Bildschirm mit eindrucksvoller
Größe. Es ist in den unteren Spannungsbereichen nicht sonderlich
rauscharm - befindet sich aber damit beim Welec in guter Gesellschaft.
Die Darstellung in den oberen Spannungsbereichen ist dagegen
einwandfrei. Die Firmware ist völlig ohne Auffälligkeiten; wenn auch
stellenweise etwas lieblos implementiert. Möchtest Du durch den Speicher
scrollen, oder sonst irgend etwas an den Drehreglern einstellen, geht
das nur 1:1. Also keine Erhöhung der Schrittweite bei schnellem Drehen
oder so.
Im Grunde genommen ein echter 68er VW Käfer. Fair im Preis; aber eben
Basisausstattung ohne Spielereien. Was gehen soll, geht - darüber hinaus
keine Extras.
Die Tasten funktionieren im Prinzip, sind aber so schwergängig, dass sie
das -zugegeben sehr leichte- Scope wegschieben. Also immer die Finger
oben auf das Gehäuse und mit dem Daumen die Tasten drücken. Mache ich
beim Welec aber mittlerweile auch so :)

Erzählt doch mal, warum der Auto-Modus bei Euch einrastet !?

Stefan

Das mit dem Trigger ist wirklich ein Problem - das erwähnte Ticket
stammt von mir.
Im Auto Modus triggert er zuverlässig, aber nur wenn eine ausreichende
Zahl Signalperioden dargestellt werden (ich glaube ab 5 oder so klappt
es). Wenn man das ganze größer braucht, um Details zu untersuchen, hilft
nur der Normal-Trigger. Und der spinnt, wie ich schonmal ausführlich
erklärt habe. Zwischendurch bleibt alles einfach stehen, obwohl nach wie
vor triggerfähige Flanken anliegen. Aber das habe ich wie gesagt ja
schon im Forum und im Ticket beschrieben.

Gruß,
Michael

Habe mal versucht das nachzustellen. Bei mir triggert er ohne Probleme
sobald eine Flanke vorhanden ist, selbst wenn der Rest der Periode nicht
mehr auf dem Bildschirm zu sehen ist. Das Ganze auch mit verschiedenen
Signalformen (Rechteck, Sinus, Dreieck, Rampe links, Rampe rechts). Und
zwar auch genau am Pretriggerpunkt. Mehr kann man eigentlich nicht
verlangen.

Welche Firmware, bei welcher Timebase, welche Spannungseinstellung,
welche Signalform?

Anbei die aktuelle 0.97 beta, würde mich interessieren ob es da auch
auftritt.

Gruß Hayo

So habe nochmal etwas rumexperimentiert, bei 500 MSa/S konnte ich auch
eine leichte Triggerschwäche bei abnehmender Anzahl Flanken auf dem
Screen feststellen. Anscheinend triggert das Gerät bei 1 GSa/S am
zuverlässigsten.

Allerdings war diese leichte Schwäche nicht so gravierend wie von Stefan
beschrieben.

Gruß Hayo

Ich habe mir deine neue Version mal geholt - jippie der Cursor geht
wieder im Stopmode und Zoomen auch!
Der Trigger spinnt aber nach wie vor.
Test erfolgte mit I2C Bus, wie im Ticket beschrieben.
Zunächst bei 50us timebase => alles ok.
Umgeschaltet auf 20us => keine Reaktion mehr, auf Zweitoszi bei gleicher
timebase alles bestens.
Umgeschaltet auf 10us => geht wieder.
Wieder auf 20us => geht erst, bleibt dann wieder stecken.

Keine Ahnung, ob das lediglich bei dieser timebase geschieht, es nervt
aber tierisch.
Abhilfe bei Steckenbleiben: Run/Stop zweimal drücken oder an timebase
drehen. Wahrscheinlich nur eine Kleinigkeit?

Gruß
Michael

Das "Herumhüpfen", wie Guido es nennt, ist durchaus nicht normal. Bei
meinem Zweitgerät, das nur eine Billiggurke ist, gibt es nichts
dergleichen.
Eins der dadurch verursachten Probleme ist, dass der Average Mode meiner
Ansicht nach nur Müll liefert...wie könnte es auch anders sein, bei dem
Gehüpfe?
Beim andren Oszi führt das Averaging zu einem Lehrbuch-Signal....

Gruß,
Michael

Beim Zoomen läuft hier gerade auch einiges schief: wenn ich im stopmode
von 20us auf 5us drehe, zoome ich heraus statt herein!

Gruß
Michael

Also, ich hab' jetzt die 097 drauf und -hätte mich jetzt auch gewundert-
im AutoModus kein Trigger bei wirklich erstklassigen Signalen. Es werden
völlig unmotiviert Signale eingeblittet - von Triggern kann in keiner
Timebase die Rede sein.
Im EdgeMenü ist alles einwandfrei eingestellt und funktioniert ja nach
Umstellung auf den NormalModus einwandfrei. Trigger bei 250k perfekt -
FLAT bei Reduktion auf 100k - erneuter Trigger bei 50k - jedoch
Darstellung Mist !

Also alles wie gehabt :(

Ist vielleicht ganz interessant:
Von TB250k auf 100k - kein Trigger.
Weiter auf TB50k - triggert.
Wieder hoch auf 100k - nichts.
 Jetzt Stop | Run gedrückt und TRIGGERT.
Weiter auf 250k - wieder einwandfrei.
Runter auf 100k - absolut tot.
 Jetzt Stop | Run gedrückt und TRIGGERT.

hmm...

Uff bin ich froh, dass ich da Rückenwind bekomme - mein Ticket und meine
Postings dazu fanden leider keine Resonanz aber je mehr Leute das
Problem melden, desto wahrscheinlicher ist es doch, dass ein
barmherziger Entwickler sich der Sache annimmt...

Was haltet ihr denn davon, elektor auf das Projekt OpenSource Oszi
hinzuweisen? Eine Kurzmeldung würde bestimmt die Aufmerksamkeit einer
Menge Leute darauf lenken und vielleicht auch Zuwachs im Entwicklerteam
bringen. Wenn ich das richtig mitbekommen habe, könnte ja gerade die
VHDL Front noch Verstärkung vertragen.


Gruß
Michael

Macht mal bitte jemand bei mir ein Update bzgl. des AutoModus; den Ihr
ja wohl größtenteils benutzt. Warum funktioniert der Trigger bei mir nur
im NormalModus ?

Ich nehme an dass Du Default Setup schon mal gedrückt hast oder? Im
Automodus triggert das Gerät definitiv überhaupt nicht? Auch nicht in
der 50 nS Timebase?

Wenn dem so ist muß ja irgendein Defekt vorliegen. Als einzige Maßnahme
fällt mir momentan nur ein Flash-Restore ein. Wenn Du selbst ein Backup
gemacht hast kannst Du das ja einspielen, ansonsten würde ich mir mal
die angezeigte Hardwarerevision notieren, dann kannst Du auch ein Backup
von jemandem hier bekommen (z.B. von mir).

Gruß Hayo

Ein Default-Setup habe ich jetzt noch einmal durchgeführt. Bleibt alles
wie gehabt - Tigger im NormalMode, frei laufend im AutoMode. Wobei der
NormalMode -ebenfalls wie gehabt- eher launisch ist; gern mal stehen
bleibt und in mancher TB einfach stehen bleibt.
Nachdem Normal funktioniert und Auto nicht, halte einen Hardwaredefekt
für ausgeschlossen.

Gruß, Stefan

Also bei mir geht's im Wesentlichen meist ebenfalls um digitale -in
diesem Fall serielle- Daten. Da verliert man schon den Glauben, wenn man
liest, was Guido so schreibt :(
Was soll ich da schreiben (?) Serielle Daten 14-28 kBps, ~5VDC, TB
zwischen 50k und 250k.

Was mir beim Trigger auffält, ist, dass man den Triggerlevel bei einem
Rechteck relativ weit oben an der Flanke ansetzen muss, wenn man sich
nahe an der unteren Rechteckspannung bewegt, streikt er gern. Bei 5v/div
(da 3 Kanälge gleichzeitig dargestellt werden) muss ich bis auf ca. 45%
der Amplitude hoch, bevor sich der Trigger regt (20us/div).

Bei 2V/div sieht es besser aus, aber >15% muss der Trigger immer noch
stehen.

Meine Triggerprobleme habe ich übrigens immer mit Kanal 4 gehabt, vor
allem bei 20us will er sich oft nur schwer überreden lassen. Dabei habe
ich eine interessante Beobachtung gemacht: nach einem Triggerereignis,
dass die Kiste gekonnt ignoriert hat (konkret löse ich per Hand eine I2C
Übertragung aus), drücke ich Stop und wie durch ein Wunder zeigt er auf
einmal doch das Signal. Scheinbar nur mit der Darstellung, das triggern
im Hintergrund scheint zu funktionieren.

Gruß

Michael

Oh da wollte ich eigentlich ein Verb spendieren.... es hapert mit der
Darstellung, sollte das heißen.
Und "dass" sollte natürlich "das" heißen.

Irgendwie stimmt da noch was nicht mit der Umschaltung der Zeitbasen.
Bei Umschaltung von 10us auf 5us war es gerade wieder so, dass sich der
Zeitausschnitt vergrößert hat (Darstellung wie 20us), erst nach Schalten
auf 2us und wieder zurück nach 5us stimmte das Ganze.

So bin gerade wieder eingestiegen,

- wie Guido eben anmerkt ist der Trigger für periodische Signale
gedacht. Ein serieller Datenstrom ist aber mitnichten periodisch! D.h.
hier kann man eigentlich nur per Single-Shot Momentaufnahmen machen,
sonst sieht es nämlich so aus als würde der Trigger durchlaufen, da ja
bei jedem Triggerevent das dargestellte Signal anders aussieht. Und
schon haben wir die Erklärung.

Probier mal ein periodisches Signal (Siganlgenerator, Quarzoszillator
etc.) dann sollte es doch wohl klappen.

Gruß Hayo

Also, es kommt ein Impulspaket, dann lange nichts mehr, dann ein
Impulspaket. Der NormalModus triggert doch auch !?

Es gibt noch eine weitere Möglichkeit zu triggern, wenn sich der
Datenstrom ab einer bestimmten Zeit wiederholt. Dafür ist nämlich die
Holdoffeinstellung vorgesehen. Damit kann man die Zeit einstellen, die
der Trigger nicht einrastet bevor er wieder erneut triggert.

Eventuell kommst Du damit weiter. Allerdings muß ich sagen das ich die
Funktionalität des Holdoff noch nicht geprüft habe. Ich habe bisher nur
im Coding gesehen, das für Holdoff Register gesetzt werden.

Gruß Hayo

Manchmal habe ich den Eindruck, dass meine posts unsichtbar sind...

@ Michael H.

Also ich sehe deine Posts...

Ich habe jetzt nochmal Vergleichstests mit Kanal 1 durchgeführt - hier
scheint alles so zu laufen wie es soll.
Kanal 4 zeigt dagegen die genannten Schwierigkeiten.
Wenn ich Kanal 1 und 4 beide an SDA des I2C Busses hänge und auf Kanal 1
triggere, erscheinen die beiden Signale meistens gleichzeitig (wie es
sein soltle), manchmal vergeht aber fast eine Sekunde, bis Kanal 4 auch
aktualisiert wurde! Dies ist nach Zeitbasiswechsel der Fall und tritt
dann ein- bis zweimal auf, danach passt wieder alles.

Gruß
Michael, der glücklicherweise wohl doch nicht unsichtbar ist

Jürgen schrieb:
> Mahlzeit zusammen!
>
> Warum nutzten wir nicht einfach das Handbuch?
>
> http://www.welec.de/data4download/W2000A/W2000AOMen6C8.pdf
>
> Dort ist alles ( Run/Stop/Single/Autotrigger/Normaltrigger usw.
> S.2-2,S.4-14) sehr gut und genau beschrieben und sollte am Ende auch
> genau so funktionieren!

Die Funktionen sind zwar nett erklärt, entsprechen aber nicht ganz der
tatsächlichen Funktionalität. Es gibt mitnichten einen Pretriggerbuffer
oder eine Postriggerbuffer, die separat befüllt werden. Auch an anderen
Stellen handelt es sich eher um idealisierte Annahmen.

Gruß Hayo

>Ich habe jetzt nochmal Vergleichstests mit Kanal 1 durchgeführt - hier
>scheint alles so zu laufen wie es soll.
>Kanal 4 zeigt dagegen die genannten Schwierigkeiten.

Das ist doch schon mal ein Hinweis.

Vielleicht wäre es sehr hilfreich, mal für alle Register die die
Bedeutung der einzelnen Bits zu ermitteln.

Ich finde das derzeit sehr unübersichtlich. Zusätzlich wird zum löschen
der Bits die invertierte Darstellung verwendet.

@Jürgen

Es gibt keinen expliziten Pretriggerbuffer, sondern nur einen Buffer für
den gesamten Signalverlauf (16384 Byte). Der Pretrigger bestimmt nur
zusammen mit dem Memory-Window und dem Zoomfaktor welcher Ausschnitt im
Screen dargestellt wird.

By the way -> bei meinen Vorbereitungen zum neuen Timebase Controller
stelle ich gerade die Tabellen für Zoomfaktoren und Signallängen um.
Dabei bin ich auf diverse falsch berechnete Werte bei den interpolierten
Zeitbasen gestoßen.

Beispielsweise berechnet der Kollege von WELEC 600/2.5 = 300 und
600/1.25 = 150. Da wundern einen natürlich einige Werte und Effekte
nicht.

Dabei sind diese Fehler durch die verschwurbelte Tabellenzugriffslogik
um drei Ecken nicht auf den ersten Blick erkennbar. Die Umstellung auf
neue Tabellen schafft hier deutlich mehr Transparenz.

Gruß Hayo

Hallo,

ich hoffe jemand kann mir hier helfen. Ich habe nach einem misslungenen
Firmware-Update riesen Probleme mit meinem Welec W2012A. Ich kann das
Oszi zwar flashen, aber es bootet die Firmware einfach nicht. Der
Bildschirm bleibt schwarz. Ich habe nur noch Zugriff auf den Bootloader.

Gruß
Marius

EDIT: Die Firmware ins RAM laden geht irgendwie. Aber die Seriennummer
ist weg. Ich habe vor dem Einspielen der Firmware einen kompletten Dump
meiner Original-Firmware gemacht. Aber das Einspielen schlägt auch fehl,
irgendwann bricht es einfach ab.

Marius Wensing schrieb:
> Hallo,
>
> ich hoffe jemand kann mir hier helfen. Ich habe nach einem misslungenen
> Firmware-Update riesen Probleme mit meinem Welec W2012A.

Zunächst mal - don't panic!

Bei einem mißlungenen Update kann schon mal das restliche Flash einen
Ditsch abkriegen. Dann muß man das neu einspielen, ist aber kein Ding.
Wir kriegen das hier schon per online Hilfe wieder hin. Bei mir war das
damals das Gleiche.

Zunächst müssen wir erstmal wissen wie Du Dein Update gemacht hast:

- Betriebssystem (Linux / Win (Version))
- WelecUpdater / Perlskript
- Hardwarerevision (Nummer auf dem Startscreen wenn Du die notiert hast)

Eventuell ist Dein Backup nicht in Ordnung, dann kannst Du hier eines
bekommen.

Gruß Hayo

Hi all,

ich habe nach dem letzten Flashen das Problem, dass keine Signale mehr
angezeigt werden, auch die Testsignale gehen nicht! Ich kann komplett
durch alle Screens schalten nur eben mit dem Messen ist's nix.

Hatte die 0.97 eingespielt, danach die 0.96 - nichts half.

pleaze!!

Michel

@Jürgen

Sach ich doch! Idealisierte Darstellung ;-)

Hayo

@Michael

Default setup hast Du gemacht?

Hayo

@ Hayo,

bin ich mir jetzt nicht sicher... Wo finde ich den Punkt denn? Unter den
Utilities? Kann mich nicht erinnern...

Michel

Hallo Michel,
du gehst in den EDGE-Modus, dann muß über der rechten SOFTKEY-TASTE
"DEFAULT SETUP" stehen! Die betätigst du, dann müsste alles wieder
hübsch sein!

Gruß Michael

Hallo Hayo,
die Nullinien-Kalibrierung zickt immer noch rum, wenn ich das Scope
wieder einschalte, ist sie völlich daneben (nur bei 1V+2V/DIV)

Noch ne Frage: Macht es einen Unterschied beim Kalibrieren, wenn der
NOIS-FILTER eingeschaltet ist???

Gruß Michael

@Michael W.

Du findest Default Setup einmal im Save/Recall Menu und einmal im Edge
Menü.


@Michael D.

Die Kalibrierung war auch erstmal als Abhilfe gedacht. Eine
Überarbeitung steht noch an und soll dann eine etwas sicherere genauere
Kalibrierung bringen und dann auch für alle Bereiche mit einem Schlag.
Kommt aber erst nach der Umstellung des TB-Controllers. Ebenfalls noch
unfertig sind die FFT-Funktionen, wobei ich mal sehen muß in welcher
Reihenfolge ich das angehe.

Der Noise-Filter hat keinerlei Auswirkungen, da die Kalibrierfunktionen
komplett eigene Lese und Verarbeitungsroutinen nutzen.

Hayo

Hallo Hayo,
mal wieder was dazu gelernt...

es wäre schön, wenn die Kalibrierung an 1. Stelle wäre, dann müsste man
nicht ständig nachhoppeln, da ich mich beim (z.B.PWM-Messung) manchmal
frage, warum die Spannungen plötzlich nicht mehr stimmen----alles
abziehen, kalibrieren, wieder alles anschliessen, ist dann schon etwas
lästig(ich will ja nicht pöpeln)...

Gruß Michael

@Michael D.

Übrigens habe ich bei mir keine Probleme mit den Nullpunkten, hab eben
nochmal geprüft, alle Spannungsbereiche kalibriert, dann ausgeschaltet
dann wieder ein, alles ok.

Hayo

oh man, hab's jetzt selbst noch mal probiert und ist bei mir genauso,
typisch Vorführeffekt, wer weiß, was da manchmal vor sich geht...

Gruß Michael

auf welche Weise hast du denn geflasht? Mit dem Germsloader (inkl.
Skript)
oder mit dem Welec_Updater?
RS232 auf 115kBaut gestellt? Die Flash_Adressen richtich eingegeben? Wie
lange dauert der Flashvorgang?
...wir kriegen das!!!

Gruß Michael

Hallo,

ich bins nochmal... Ich habe gestern Abend noch etwas weitergehender
versucht die Firmware wiederherzustellen. Anscheinend ist mir das auch
weitestgehend gelungen. Meine Seriennummer ist wieder da und auch das
Oszi startet mit der Holiday Edition. Ob alles wieder so wie vorher ist,
kann ich aber noch nicht sagen. Prinzipiell sieht es aber mal nicht
schlecht aus.

Wenn ich noch Hilfe brauche melde ich mich hier wieder.

Allerdings habe ich derzeit in einigen Zeitbasen große Zeichenfehler.
Das war aber vor dem FW-Update auch schon so. Ich habe mal ein Foto
angehängt, wo das deutlich wird. In einigen Zeitbasen treten Peaks auf,
die da definitiv nicht sind. Verschiebe ich das Signal in Y-Richtung,
gibt es Stellen, wo die Peaks verschwinden, und dann wieder welche, wo
die Peaks da sind.

Vielleicht kann mir jemand sagen, ob das normal so ist.

MfG
Marius

Hallo Marius,

das mit den Peaks kann ich bestätigen!
Beim verschieben tritt es tatsächlich nur jeden 3. oder 4. Raster der
Y-Achse und nur an bestimmten Stellen des Bildschirms auf!
fast Dasselbe gilt beim verschieben ohne Signal nur minimaler, mal ist
die Nullinie ohne Rauschen, geht man einen Raster weiter, rauscht es
wieder u.s.w....hm, an was liegt das denn?

Gruß Michael

Die Peaks treten bei meinem W2022A überhaupt nicht auf und bei meinem
W2014A nur auf Kanal 4. Da verhalten sie sich dann aber wie von Euch
beschrieben. Das kann man aber eigentlich nicht als normal bezeichenn,
ich war auch schon mal am Überlegen ob das ein Rückgabegrund ist.
Allerdings wurde das bei mir besser als ich den Lüfter modifiziert habe
(siehe Hardwarethread).

Gruß Hayo

Ich verstehe nur nicht, warum das nur in bestimmten Zeitbasen auftritt.
Ich habe das Problem extrem bei 1 GS/s und 500 MS/s, aber dort auch
nicht in allen Zeitbasen wie oben im Bild zu sehen ist.

Das verschieben der Signale in Y-Richtung geschieht doch sicherlich rein
in Software. Sonst müssten die Peaks doch auftauchen egal wo sich das
Signal auf dem Bildschirm befindet.

MfG
Marius

na toll, Hayo hatte ein thermisches Problem und beim Guido muß es sich
erst aufwärmen ---großes Fragezeichen---
Ich werde das mal testen bei offenem Gerät, das wenn der Fall wieder
eintritt, schau ich mal ob es mit Kühlung was bringt, wenn nicht, könnte
es wirklich ein Softwareproblem, wie Marius beschrieben hat, sein!

Gruß Michael

Hayo, kannst Du mal kurz sagen, an welcher Stelle das alte Signal
gelöscht wird?

Falk

Falk Willberg schrieb:
> Hayo, kannst Du mal kurz sagen, an welcher Stelle das alte Signal
> gelöscht wird?

Hi Falk, ich bin mir nicht sicher was Du meinst. Der Signalbuffer wird
bei jedem Acquisitionsdurchlauf im ADC-Handler neu beschrieben. Die
Grafikausgabe wird nicht gelöscht sondern die Grafiklayer werden in
TransferPlanes() einmal pro Schleifendurchlauf neu ausgegeben.

Gruß Hayo

Zu den Peaks:

Dass diese in unterschiedlichen Zeitbasen unterschiedlich stark
ausgeprägt sind hängt mit dem Zoomfaktor zusammen, der ja dafür sorgt
dass nur jeweils der 2te, 4te, 5te, 10te, 20te oder 25te Wert
dargestellt wird. Bei Faktor 2 bedeutet das, dass nur die Werte von 2
ADCs dargestellt werden, bei Faktor 4 ist es nur ein ADC. Bei den
anderen wechseln die ADCs. Wenn jetzt die Spikes von einem ADC
verursacht werden, dann hat man bei Faktor 1 (50nS) alle Spikes im Bild.
bei Faktor 2 und 4 hängt es jetzt davon ab von wo gestartet wird, im
günstigsten Fall verschwinden die Spikes ganz. Bei den nicht durch 4
teilbaren Zeitbasen treten die Spikes dann mit reduzierter Häufigkeit
auf.

Hier hilft am ehesten der Download als CSV, da hier unabhängig vom
Zoomfaktor das ganze Signal zur Verfügung steht

Soweit zur Theorie.

Ob die Spikes durch den Trigger verursacht werden kann ich ich nicht
sagen, möglich wären auch Timingprobleme beim Auslesen des ADC, ein
FPGA-Designproblem also. Ich habe auch noch von keinem unserer
FPGA-Designer von diesem Peakproblem gehört. Es handelt sich
offensichtlich um ein Problem des WELEC-Designs.

Dass die Firmware hier verantwortlich ist würde ich eher nicht vermuten,
da sonst die Auswirkungen bei allen gleich sein müssten.

Gruß Hayo

Hallo zusammen.

Ich habe mal die "Zeitfresser" dingfest gemacht:

Hardware::Handle_ADC(): 127ms
Display::DrawSignals(): 72ms
Hardware::TransferPlanes(): 26ms

Basis ist Rev. 260, 200mV/10mV 100µs Trigger: Auto.

HTH,
Falk

So nun muss ich mich hier auch mahl melden war seither stiller mit Leser
(und mit nutzer).

Und deswegen vorab danke! an alle fleißigen Entwickler an der Hardware,
Software und FPGA Front die das Gerät So langsam brauchbar machen.

Macht Bitte weiter so.

nun zu meinem Problehm
Ich hab vor einigen tagen die Software Version
„FW1.2.BF.0.82+beta“ und direkt danach „FW1.2.BF.0.84beta" in mein
W2024A geflasht das klappte auch wunderbar und die Software lief
Abgesehen von den bekanten Fehlern perfekt.

Nun hab ich das Scope zum ersten mahl nach einigen tagen wieder
eingeschaltet und es lief nicht mehr hoch.

 Auch das einspielen meines original Backups (kompletter Speicher
Bereich von 0x00040000 bis 0x007FFFFF) brachte keine Verbesserung
(gelegentlich werden nun beim Einschalten Fragmente der Startbildschirms
angezeigt).

hat jemand einen Tipp was man da machen kann.

Und Woran das liegt wäre denke ich auch interessant (ich hatte ca. 5
Monate die original Firmware 104 auf dem Gerät die Lief (wen man das bei
so vielen Bugs) so nennen darf immer perfekt

ach ja zum einspielen und sichern der Software hab ich den WelecUpdater
(V0.4BA22)verwändet
führ Hilfe wäre ich sehr dankbar

MFG
Stefan


 und wenn´s hilft ich habe Spikes auch nur im Warmen zustand auf Kanal
Drei

Also danke Guido für den Tipp mit dem Terminal Leider Schweigt das Scope
gerade.

Ich hab es Seither auch nicht mehr hingebracht das der Startbildschirm
kommt

jetzt weis ich auch nicht weiter. könnte mir mahl jemand einen komplett
Backup eines W2024A zur Verfügung stellen (für den fahl das mit meinem
was nicht stimmt
oder
hat sonst noch jemand eine  Die

ach und noch was ich weis nicht ob das schon jemand aufgefallen ist aber
es gibt eine Verbindung auf der Netzteilplatine zwischen dem 230 Netz
und Der Hauptplatine (natürlich über Spannungsteiler) sollte es da
eventuell Eine Trigger Möglichkeit aufs Netz Geben ?
ich hab das bis jetzt in keinem Triggermenu gefunden

Hallo Welec Gemeinde,

Da mein PC GUI inzwischen schon einen recht brauchbaren Stand erreicht
hat, möchte ich es ab sofort zum Test anbieten.
Wer Interesse daran hat ( und mit den Rahmenbedingungen s.h.
http://sourceforge.net/apps/phpbb/welecw2000a/view...
einverstanden ist, kann auf Anfrage von mir einen Download link
erhalten.
Noch ist nicht ansatzweise alles verwirklicht was ich mir vorgenommen
habe, denke aber das ich über die kalten Wintermonate noch einiges
fertig bekomme.
Besonders da der Programmumfang inzwischen so umfangreich ist, das die
"Testerei" mehr Zeit in Anspruch nimmt, als das Programmieren, hoffe ich
auf diese Weise auf umfangreiche Rückmeldungen und
Verbesserungsvorschläge.
Der Leistungsumfang ändert sich täglich, deshalb macht es auch nicht
viel Sinn hier eine komplette Leistungsbeschreibung zu posten. Das
Programm sollte mit den FW Versionen 0.91 OS und, nachdem Hayo den
Remote Befehlssatz übernommen hat, auch mit der 0.97 HE arbeiten.

Gruß, brunowe

alex008_ schrieb:
> Hallo,
>
> ich entwickle das LEON3 HW-Design.

...

> Bis das ganze aber Benutzertauglich ist, vergeht mindestens noch ein
> Jahr!

Na, nicht so pessimistisch....

> Ich freue mich natürlich über jede Hilfe (SW+HW)!

Da die NIOS-Geschichte offensichtlich eine Ein-Mann-Show bleiben wird
und ich da auch kein Potential für entscheidende Verbesserungen mehr
sehe, werde ich meinen Einsatz an dieser Stelle reduzieren oder
einstellen und mehr an der LEON3 FW arbeiten.

Was ich bisher gesehen hab, gefällt mir ganz gut.

ZPU liegt ja momentan auf Eis, wenn ich das richtig verstanden habe.

Sorgen macht mir, daß auch hier ein Punkt ist, der von einer einzigen
Person abhängt. Ich jedenfalls habe keine Ahnung von VHDL.

Falk

Das mit dem Leon (und neuer Software) finde ich gut. (Nach dem Wenigen,
was ich Neuling bisher weiß... :-)

Ich wäre dabei, das bestehende Nios-Design und die Herstellersoftware
halte ich auch für eine Sackgasse (nix für ungut).

Ich selbst kann praktisch kein VHDL, bin Firmwareentwickler in einer
ASIC-Firma, die Hardware machen andere. Bin's aber gewohnt, mit solchen
zu arbeiten.  ;-)

Jörg

Hallo brunowe,

mein Kompliment für die gelungene PC-GUI! Das sieht schon sehr
ansprechend aus.

Ich möchte mich der Bitte von Mike B. nach den Sourcefiles der PC-GUI
anschließen. Da ich vorwiegend mit Linux arbeite, würde ich gerne
probieren, ob ich die PC-GUI mit Scilab laufen lassen kann. Dies würde
mir auch die Gelegenheit geben, die Funktionalität der PC-GUI zu
studieren, um ggf. Teile davon für die DSO-GUI zu verwenden. Der
Firmware-Download/Upload funktioniert in Linux übrigens tadellos.

Gruß Ingo (ingom)

Michael schrieb:
> Ist das Oszi eigentlich Fernsteuerbar? Ich kenne das von den großen
> Osziherstellern. Die Befehle über IEEE sind fast immer die gleichen.
> Seriell kann man ja die gleichen Befehle benutzen.
>
> Mfg Michael

...ein Namensvetter,
du sprichst das DSO mit der Seriellen Schhnittstelle über ein
Telnet-Prog. an!
Die Befehle sind z.B. im FW.096HE unter dem Ordner "DOKU" interpretiert!
Ansonsten die Schnittst. mit 115 KB einstellen(sonst funzt das net)
Telnet mit Schnittltelle COM ebenfalls 115 KB einrichten, dann "H"(help)
eintippen, der Rest dürfte ja bekannt sein!
...hab' ich was vergessen?

Gruß Michael

Michael schrieb:
> Ist das Oszi eigentlich Fernsteuerbar?

Teilweise schon:
http://sourceforge.net/apps/trac/welecw2000a/wiki/...

> Ich kenne das von den großen
> Osziherstellern. Die Befehle über IEEE sind fast immer die gleichen.
> Seriell kann man ja die gleichen Befehle benutzen.

Wenn es dafür einen Standard gibt, kann der eingebaut werden.

Evtl ist

Falk
P.S.: Hier das Ergebnis eines ersten Versuchs, NIOS mal richtig flott zu
machen: http://www.consult42.com/NIOS-Schnell-2.avi
Mal sehen, wie schnell das noch ist, wenn ein anständiger Trigger,
Offsets, Skalierung etc. eingebaut sind.

Hey,
das schaut ja ganz schön flink aus. Was für eine Zeiteinstellung war
das?

Stefan E. schrieb:
> Hey,
> das schaut ja ganz schön flink aus. Was für eine Zeiteinstellung war
> das?

500mS/s Ja, schnell ist das (ca. 50fps), aber dafür fehlt noch einiges
an Konvertierungen etc.

Falk

Falk Willberg schrieb:

> P.S.: Hier das Ergebnis eines ersten Versuchs, NIOS mal richtig flott zu
> machen: http://www.consult42.com/NIOS-Schnell-2.avi

Und hier zum Ausprobieren:
http://consult42.com/W20XXA-prereleases/TomCat-22102009.ram

Bitte keine Fehlerberichte. Das ist nicht mehr als eine Studie.

Falk

Und hier die Variante mit Vektoren als Video:
http://consult42.com/signal2.mpg

Könnte sein, daß das etwas wird...

Falk

Ich hab's mal ins Ram geladen, also ich muß schon sagen, das geht ja ab
wie Schmitt's Katze!!!
Hast du einen Turbolader in die FW eingebaut? (lach)

Gruß Michael

Michael D. schrieb:
> Ich hab's mal ins Ram geladen, also ich muß schon sagen, das geht ja ab
> wie Schmitt's Katze!!!
> Hast du einen Turbolader in die FW eingebaut? (lach)

Nein, eigentlich habe ich eine ganze Menge Zeug übersprungen.

In Kurzform: Ich nehme die Werte aus dem ADC-Puffer, skaliere die über
eine Tabelle und schreibe direkt in den Framebuffer.

Falk

Falk Willberg schrieb:

>
> Nein, eigentlich habe ich eine ganze Menge Zeug übersprungen.
>
> In Kurzform: Ich nehme die Werte aus dem ADC-Puffer, skaliere die über
> eine Tabelle und schreibe direkt in den Framebuffer.
>
> Falk

...das war als erstes meine Vermutung, das da einiges übersprungen wird,
wollte es nur nicht ansprechen, dachte das ich mich mit dieser Aussage
blamiere!!!
Es ist schon verblüffend, das die Geschwindigkeit garnicht abnimmt, wenn
man noch den 2. Kanal mit einschaltet! Hatte ich mal kurz getestet...
Wenn man das noch nach Bedarf switchen könnte, wäre das ne feine Sache!

Gruß Michael

Michael D. schrieb:

...

> Es ist schon verblüffend, das die Geschwindigkeit garnicht abnimmt, wenn
> man noch den 2. Kanal mit einschaltet! Hatte ich mal kurz getestet...
> Wenn man das noch nach Bedarf switchen könnte, wäre das ne feine Sache!

Das geht: Auf der RS232 'S' tippen (test switch 1).

Falk Willberg schrieb:
> Das geht: Auf der RS232 'S' tippen (test switch 1).

wie sieht's aus, könnte man es in die nächste FW mit einbauen?

Gruß Michael

Michael D. schrieb:
> Falk Willberg schrieb:
>> Das geht: Auf der RS232 'S' tippen (test switch 1).
>
> wie sieht's aus, könnte man es in die nächste FW mit einbauen?

Wenn es brauchbar ist, könnte eine FW 1.2-OS-0.92 released werden.

Hayos FW-releases sind ja inzwischen inkompatibel geworden, wenn ich
nicht irre.

Falk

au mann, ich denke, das ihr das gemeinsam gestaltet, nein?
Jetzt habe ich irgenwie den Faden verloren!
Bei der Entwicklung kann ich leider nicht mitwirken, denn was da noch zu
lernen wäre, würde warscheinlich mein restliches Leben nicht mehr
ausreichen...ich bräuchte sowieso mindestens 3 davon!!!
Wie auch immer, hier im Forum haben sich Viele festgebissen, im SF will
keiner so recht teilnehmen.
Es sind sehr viele Baustellen wo man jetzt so langsam den Überblick
verliert!
Mühselig muß man sich alles zusammen suchen und findet dann doch
nüscht... Also wie soll man hier ünterstützen durch Test's u. Berichten,
wenn alles so weit verstreut ist???
Z.B. sollten alle Files, ob Software, Gui's, Nios oder FW's über einen
Link von hier erreichbar sein, denke ich.
SourceForge wird die File-Seite überhaupt nicht gepflegt! Die letzte FW
ist die 091, wir sind jetzt schon bei 097!!!
Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine
Resonanz bekäme, oder?

Michael D. schrieb:
> au mann, ich denke, das ihr das gemeinsam gestaltet,

Das wäre besser.

...

> SourceForge wird die File-Seite überhaupt nicht gepflegt!

Releases gab es da länger nicht, siehe unten. Da ist aber trotzdem viel
los: http://sourceforge.net/projects/welecw2000a/develop

Fast jede kleine Änderung ist da kommentiert. Die Entwicklung findet
praktisch öffentlich statt.

> Die letzte FW
> ist die 091, wir sind jetzt schon bei 097!!!

Da schiebe ich den schwarzen Peter ganz weit von mir. Wenn nix
eingepflegt wird, kommt auch nix raus.

> Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine
> Resonanz bekäme, oder?

Ja, das ist schade. Ich kann da aber nichts mehr dran ändern.

Falk

Hallo Leute,

zu Sourceforge:
Vieleicht haben einige Leute Angst dass ihr Post dort übersehen wird,
weil kaum einer in ein fast leeres Forum reinschaut?

Mann kann jedoch auch ein ganzes Forum abonnieren. Wählt man z.B. "Board
index ‹ Entwicklung (deutsch) ‹ Firmware" erscheint unten auf der Seite
ein Feld "Subscribe forum". Damit kann man die mail Benachrichtigung für
neue Themen aktivieren. Das gleiche gillt natürlich auch für einen
einzelnen Thread


zur Firmware:
Ich habe mich nochmal neu in die Teile für screenshot und CSV Export
eingearbeitet. Die sind ja wirklich übersichtlich geworden!

Vor einiger Zeit war mal ein einfaches Handshake Protokoll angedacht.
Das Oszi müsste auf Eingaben über RS232 warten können. Wurde das
mittlerweile realisiert?

Außerdem frage ich mich, warum die Reihenfolge der Daten für den CSV
Export geändert wurde. Besser fände ich: Ersten Wert Ch1-Ch4, zweiter
Wert Ch1-Ch4...
Und nicht Werte 0 bis 16383 von Ch1, dann von Ch2, Ch3 und Ch4.
Auf die Reihenfolge der Werte in der CSV Datei hätte das natürlich keine
Auswirkung!


Mfg,
Kurt

Hallo branadic,
Danke erstmal für das Blech, ist heute gekommen!

Du hast Recht, ich habe das eben noch mal geprüft "OS u. BF! Also "OS"
ist von Falk und "BF" von Hayo?
Mit den 2 Entwicklungsbäumen habe ich kein Problem und so schlecht finde
ich das jetzt auch nicht, wenn man irgentwann vielleicht doch auf eine
gemeinsamen Ebene trifft ?!?
Wie es zum Spalten gekommen ist, habe ich ja auch mit bekommen, war ja
schon fast "Zoff in Beverly Hills"...dachte nur, das ihr euch
zwischenzeitlich wieder vertragen hattet...hm!
Ich selbst bin mit "kastor7" (mike0815 war schon vergeben) im "SF"
angemeldet und stöbere auch regelmässig auf den Seiten.
Vieles wird über Skype diskutiert?
Gibt es da die Möglichkeit zum chatten oder was? Vielleicht schreibst du
mir eine PN in der du mir beschreibst, wie ich dazu stoßen kann?!?

Michael D. schrieb:
> au mann, ich denke, das ihr das gemeinsam gestaltet, nein?

Jein ....

> Jetzt habe ich irgenwie den Faden verloren!
> [Entwicklung, Link]
> Z.B. sollten alle Files, ob Software, Gui's, Nios oder FW's über einen
> Link von hier erreichbar sein, denke ich.

Sowas ist bloss mit einem Wiki auf SF.net wesentlich leichter
zu pflegen als hier - in diesem Sinne gibt es einen Link:

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

> SourceForge wird die File-Seite überhaupt nicht gepflegt! Die letzte FW
> ist die 091, wir sind jetzt schon bei 097!!!

Tja, die muss dann jmd. hochladen - wobei es halt zwei Versionen
gibt: einmal BF - aka Hayo und einmal OS (OpenSource), an welcher
mehr Leute mitarbeiten.

Da wir letztens die Änderungen von mir bzgl. der Verstärkerstufen
eingepflegt haben und (u.a.) Falk jetzt dabei ist, damit die
Signalverarbeitung und -darstellung von unten hoch neu aufzuziehen,
werden die beiden Versionen jetzt stärker divergieren.

> Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine
> Resonanz bekäme, oder?

Sagen wir es so: ich empfinde es jetzt erstmal als Schade, dass einige
Räder zweimal erfunden werden und Arbeit doppelt gemacht wird - aber wir
werden sehen ...

Grüße,

    rowue

Hallo,

hier ist ja wieder was los! (Und ich kann es mir nicht verkneifen auch
meinen Senf dazu zu geben)
...
>  Außerdem wird es ausgerechnet von den Leuten protegiert, die hauptsächlich
> auf nichtöffentliche Kommunikationswege setzen und die Ergebnisse
> ihrer "fruchtbaren Diskussionen" weder hier noch auf SFN
> veröffentlichen.
Was meinst du damit Guido?
SKYPE?  Skype ist in dem Sinne öffentlich, das wir schon mehrmals hier
aufgerufen haben sich aktiv an den Live- diskussionen dort zu
beteiligen! Jeder der nicht nachvollziehen kann das es bei der
Entwicklung, bei Tests oder aktuellen Fragen einfach unakzeptabel ist,
bis evtl 1-2 Tage später eine Email eintrifft. Hier nochmals mein Skype-
Nutzername: brunowe1
 Meldet euch einfach bei mir (oder einem Anderem dort aktiven (Falk,
Crazor, branadic....) WIR schließen niemanden aus.
Aber da ich hier im Forum nicht einmal eine alte Nachricht bearbeiten
kann, die notwendige Übersicht in keinster Weise gegeben ist, uns kein
eigener Webspace zur Verfügung steht... Also ich möchte auf SF nicht
mehr verzichten.

Ich habe heute übrigens heute meine Quelldateien für den FFTscreener
veröffentlicht- auf SF natürlich (sind schließlich über 100 einzelne
Dateien).
http://welecw2000a.svn.sourceforge.net/viewvc/wele...

Muss jetzt demnächst nur noch eine Beschreibung fertig machen und hoch
laden. Diese Dateien sind in dieser uncompilierten Form (nur) unter
Matlab lauffähig. Wer die Matlab Runtime benötigt, der kann sich bei mir
melden, damit ist dann auch die kompilierte (exe) Version unter Windows
lauffähig.

Macht der Hayo eigentl. derzeit überhaupt noch weiter?
Schon länger nichts mehr gelesen von ihm. Den Ansatz der
Grafikbeschleunigung von Falk und Jörg finde ich sehr gut! Mein
FFTscreener stützt sich übrigens (in der derzeit aktuellen Version 0.01)
auf die FW von Falk, läuft aber auch noch mit der BF0.97. Bei neueren
Versionen wird das wahrscheinl. nicht mehr gegen sein, da Hayo die
seriellen Remotebefehle nicht, oder bestenfalls verzögert einpflegt.

Gruß, brunowe

Odic schrieb:

...

> Das einzige, was ich nicht verstehe, ist: warum trefft ihr keine bewußte
> Entscheidung und kommuniziert die klar und deutlich?

Diese Entscheidung ist vor Monaten gefallen, nur hält sich einer nicht
daran. Das kann man alles, wenn man richtig viel zeit hat, hier
nachlesen: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware"

> Ich denke, jeder hat genug Sinn für Realität um zu wissen, dass ihr die
> beiden Versionen entweder JETZT zusammenführt oder NIE.

Einmal habe ich Hayos Änderungen mit dem SVN zusammengeführt, ein
weiteres Mal jemand anderes.

Ich mach das nicht noch mal.

Falk

Guido schrieb:
...
> Für mich ist dieses hier wichtiger, weil mich auch andere Themen
> interessieren und ich daher meist täglich hier vorbeschaue. Im SFN
> ist nicht soviel los, dass es sich täglich lohnen würde.

Es gibt für alles Mögliche eine eMail-Benachrichtigung.

> Außerdem
> wird es ausgerechnet von den Leuten protegiert, die hauptsächlich
> auf nichtöffentliche Kommunikationswege setzen und die Ergebnisse
> ihrer "fruchtbaren Diskussionen" weder hier noch auf SFN
> veröffentlichen.

Vor wenigen Tagen meldete sich ein "Neuer" im öffentlichen IRC-Kanal
#welec bei irc.freenode.net. Der diskutiert jetzt im Skype-Chat mit und
hat schon wertvolles zur FW beigetragen.

Mit Rowue bespreche ich mich regelmäßig im öffentlichen Jabber-Kanal
"welec" bei jabber.ccc.de.

Im übrigen will *ich* auch einen Kommunikationskanal haben, in dem
sich die Experten austauschen.
...

> Was gegen das SVN auf SFN spricht ist die Disziplinlosigkeit der
> Nutzer. Da wurden z.T. in 30 minütigem Abstand neue Versionen
> eingepflegt, die zum Teil noch nicht einmal durch den Compiler
> gelaufen sind.

Erzähl mal, welche Du meinst.

> Eine Menge Änderungen (ca. 273) wurden durchgeführt,
> die wohl alle völlig ungetestet sind.

Soso, das ist eine mutige Behauptung. Meine commits sind natürlich
getestet. Natürlich nicht in jeder Hinsicht und meistens nur von mir,
aber für "reife" Versionen gibt es die Releases.

Und 273 Änderungen bedeutet auch, daß keiner sich im stillen Kämmerlein
etwas zusammenhäkelt, sondern daß jede Änderung transparent ist.
...

> Es ist doch eigentlich nicht so schwer: Die Trunk-Version ist die
> stabile Grundlage, in der nur gemeldete Fehler behoben werden. Wenn
> jemand etwas Grundsätzliches ändert oder etwas testen möchte, macht
> er einen Branch. Um Tester für seinen Branch muss sich dann natürlich
> jeder selbst kümmern.

Dann mach' doch! Jede Hilfe ist willkommen.

Hast Du eine Vorstellung davon, wie groß die Menge der Entwickler der
NIOS-FW ist?

Falk, der jetzt die SVN-Version weiter brauchbar macht und alle daran
teilhaben läßt, indem er soeben Revision 277 eingecheckt hat.

Jürgen schrieb:
> Hallo,

...

> Anfügen muß ich, daß Hayo zu Beginn eine klare Festlegung zu Änderungen
> in den Sourcen festgelegt hatte:

Wann hat Hayo das "festgelegt"?

> 1. Änderungen werden von den Entwicklern gekennzeichnet ( eventuell auch
> mit Beginn und Ende )

Das macht Subverion automatisch beim Einchecken.

> 2. Kommentare sind einzufügen

http://welecw2000a.svn.sourceforge.net/viewvc/wele...

Und bitte, zeige mir doch mal die Kommentare von Hayo in den Sourcen.

BTW: Revision 245 ist mit "Merged FW1.2.BF.0.96HE with SVN" kommentiert:
http://welecw2000a.svn.sourceforge.net/viewvc/wele...

Und was Absprachen angeht, lies doch einfach mal
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" und folgende.

Falk
P.S.: Ich hatte hier übrigens schon mehrfach gefragt, ob sich jemand des
Win/DOS-Teils des Screenshot-Programms annehmen könnte. Rate mal,
wieviele Meldungen es gab.

Nachtrag:
Leute, beruhigt Euch mal wieder.

Die Situation ist doch die:
Hayo zieht es vor, seine unbestritten wertvollen Verbesserungen an der
FW alleine zu machen. Dagegen ist nichts einzuwenden.

Einige andere, u.a. ich selbst, ziehen es vor, das im Team zu machen und
alle daran teilhaben zu lassen.

Das ist nicht die optimale Lösung, aber wer etwas daran verbessern will,
muß sich leider auf seinen Hintern setzen und etwas beitragen.

Ich tue das und kann mit der Situation gut leben.

Falk

Hallo an alle,

jetzt finde ich endlich auch mal die Zeit mich hier zu Wort melden.
Dafür jetzt ein längerer Post.

Ich verfolge die Bemühungen um das Wellec Scope schon seit Anfang an und
habe versucht mich durch mitlesen - hier und auch im Sourceforge - immer
wieder auf dem neusten Stand zu halten bzw. zu bringen. Das hat zwar
nicht immer geklappt, aber doch meistens. Jetzt habe ich gerade mal
etwas Zeit und werde versuchen auch mal was beizutragen.

Beitragen könnte ich prinzipiell beim sowohl der Firmware (C), als auch
beim FPGA-Redesign (VHDL). Allerdings weiß ich nicht wie sinnvoll esist
mich da einzuarbeiten und dann doch nicht die Zeit zu finden kostruktiv
mitzuarbeiten. Dort wo es hilft und mir möglich ist werde ich es aber
gerne versuchen. Doch fürs erste habe ich überlegt, an einer anderen
Baustelle zu beginnen.

Korrigiert mich, wenn ich falsch liege. Aber ich denke was vielen -
vorallem Neueinsteigern und Leuten die nur selten mitlesen - hier fehlt
ist der Überblick. Ein kurzer Leitfaden zum Einstieg. FPGA, Firmware,
Versionen, Binaries, .... Was ist was und wo und wie muss ich vorgehen.

Wenn ich im Moment die Projektseite
https://sourceforge.net/projects/welecw2000a/ öffne, dann sehe ich
erstmal außer dem fetten Button zum Download der
w2000a-screenshot-0.91.tgz und der Kurzbeschreibung "Firmware
development/ improvement for the digital storage oscilloscope "Welec
2000a- series" garnichts. Sourceforge ist da leider sehr
unübersichtlich. Klein darunter findet man dann den eigentlich wichtigen
Link zur "Website" https://sourceforge.net/apps/trac/welecw2000a/.
Hilfreich wäre es an der Stelle wenn in der Kurzbeschreibung auf den
Link zur eigentlichen Website (und vielleicht auch zum PHPBB-Forum)
hingewiesen würde. Als jemand der Sourceforge kennt findet man den Link
zwar selbst, aber aus leidvoller Erfahrung mit Nutzern die sich auf
Sourceforge nicht auskennen weiß ich, dass SF nicht wirklich intuitiv
und übersichtlich ist.

Wenn mann es dann auf die Projektseite im Trac Wiki
https://sourceforge.net/apps/trac/welecw2000a/ geschafft hat sieht es ja
schon garnicht mal so schlecht aus. Allerdings fehlt auch hier noch eine
aussagekräftige Einleitung bzw. ein Überblick für alle die die nicht die
ganzen Forendiskussionen im Kopf haben. Und hier würde ich jetzt gerne
versuchen anzusetzen und einen Kurzeinstieg zu schreiben die folgenden
Themen und Fragen beantwortet.

0.0 Was brauche ich um die Firmware nutzen zu können?
-> Windows oder Linux PC, Welec2000 oder Welec2000A Oszilloskop.
-> Hinweis: Erster Schritt sollte Firmware backup sein!
0. Wo liegen die Informationen (Foren, Wiki) wo kann ich bei mich bei
Fehlern und Problemen melden
1. Ich habe nur ein W2000 ohne A. Kann ich das auch nutzen?
->Hinweis auf Umbauanleitung für W2000 zu W2000A.
2. Wie mache ich ein Firmware Backup?
2.1 Unter Windows
2.2 Unter Linux
3. Wie kann ich eine neue Firmware aufspielen (für original Welec FPGA
Design)
3.1 Welche unterschiedlichen Firmware gibt es, wie komme ich dran, wo
sind  die stabilen Versionen, was sind die Unterschiede zwischen den
einzelnen Firmware?
-> Firmware im SVN
(https://sourceforge.net/apps/trac/welecw2000a/browser) unter fpga/nios.
-> "NIOS" ist der original Core für den Altera FPGA des Oszilloskops auf
dem die originale Welec Firmware und auch die darauf basierende Open
Source Weiterentwicklung läuft. Der NIOS-Core ist nicht frei verfügbar.
-> Die Entwicklung finde in fpga/nios/oss/trunk statt.
-> Stabile/offizielle? Versionen liegen in /fpga/nios/oss/tags, welche
Version ist was, sind die aktuell?
-> In fpga/nios/welec liegen die Original Sourcen (alle?, gibts auch
Binaries?)
3.2 Firmware aufspielen Windows
3.3 Firmware aufspielen Linux
3.4 Fehler Melden (Trac Ticketsystem) und Foren
4. Gibt es weitere Tools/Software für die Arbeit mit dem Oszilloskop?
-> Screenshots, FFTscreener, LabView Treiber ... (hier bin ich nicht auf
dem aktuellen Stand)
5. Andere FPGA Designs für das Oszilloskop
-> jeweils im entsprechenden Unterordner des FPGA Verzeichnisses
-> alles noch in Entwicklung, noch keine voll funktionsfähige Version?!
5.1 leon3 -> fpga/leon3 ?
5.2 t51   -> fpag/t51 ?
5.3 zpu   -> fpga/zpu ?

Teilweise sind in der Gliederung schon Informationen eingetragen.
Korrigiert mich bitte, wenn etwas falsch oder unvollständig sein sollte.
Ich werde versuchen obiges auszuformulieren und dann auf der Hautpseite
des Trac-Wiki zu Verfügung zu stellen bzw. zu verlinken, wenn gewünscht.
Für Unterstützung, Tips oder Mithilfe von anderen hier bin ich gerne
offen.

Auf Sourceforge bin ich als holgerm registriert.

Ich hätte diesen Beitrag auch ins SF PHPBB Forum geschrieben, aber ich
war mir nicht sicher wo er da am besten hinpasst, deshalb hier.

Ich hoffe mit meinen Äußerungen und Anmerkungen keinem irgendwie auf die
Füße getreten zu sein. Alles was ich hier äußere ist als konstruktive
Kritik geacht und auf keinen Fall ein Angriff auf irgendjemanden.

Danke fürs Lesen des doch sehr langen Posts.

Gruß Holger

Holger M. schrieb:

...

> Korrigiert mich, wenn ich falsch liege. Aber ich denke was vielen -
> vorallem Neueinsteigern und Leuten die nur selten mitlesen - hier fehlt
> ist der Überblick. Ein kurzer Leitfaden zum Einstieg. FPGA, Firmware,
> Versionen, Binaries, .... Was ist was und wo und wie muss ich vorgehen.

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

Ja, da muß man sich mal durchgraben. Und ich bin so vermessen, daß ich
das auch erwarte, wenn sich jemand ernsthaft für das Projekt
interessiert. Das ist alles kein Vergleich mit den originalen FW-Sourcen
;-)

Sicher gibt es übersichtlichere Möglichkeiten, aber Besseres haben wir
nicht und besser als die hiesigen unstrukturierten Monster-Threads ist
das auf jeden Fall.
...

> Ich hoffe mit meinen Äußerungen und Anmerkungen keinem irgendwie auf die
> Füße getreten zu sein.

Mir nicht. Ich habe mal gelernt, daß Kritik dem Kritisierten hilft, sich
zu verbessern.

Falk #welec - irc.freenode.net
P.S.: Hier zwei Downloadzahlen:
Video zum angucken: 208 (http://consult42.com/W20XXA-prereleases/)
TomCat.ram zum selbertesten: 17 (http://consult42.com/signal2.mpg)

Hallo Falk,
die Links sind vertauscht, das wird aber Jeder merken, denke ich...

...der Holger spricht mir aus der Seele!!!
Ich bin wirklich kein fauler Mensch, suche u. lese, was das Zeug hält!
Nur hier etwas Konstruktives beitragen zu können, ist wirklich eine
Katastrophe!
Deshalb kommen dann auch die einen oder anderen dämlichen Fragen von
mir(oder nicht nur von mir), gerade weil alles so verstreut liegt!
Z.B. hatte ich garnicht darauf geachtet, das die eine FW "OS" von Falk
und die ander FW "BF" NUR von Hayo ist!!! Wie ist das mit den
Ver.Nummern? sind die jetzt fortlaufend oder bleibt Falk bei der 092er
oder hat Hayo auch eine 092er???
Ich kann nicht programieren und kein FPGA-Design entwickeln, kann aber
z.B. flashen über den Welec-Upd. und dem Germsmonitor(obwohl das
einrichten garnicht so einfach ist und das auch für Andere, wie die
Vergangenheit es zeigte)und eben testen...
Ich benutze das DSO hauptsächlich für analoge Messungen, wenn ich dann
Spannungen ablese mit einer Differenz von 0,5-1V weil die
Nulllinienkalibrierung sich ständig verirrt da könnte ich Kinder
kriegen...
In keiner Version ist dies in den Griff zu bekommen! Denn stimmt diese
nicht, stimmt keine Messung!

Gruß  Michael

Michael D. schrieb:
> Hallo Falk,

...

> Deshalb kommen dann auch die einen oder anderen dämlichen Fragen von
> mir(oder nicht nur von mir), gerade weil alles so verstreut liegt!

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

Da liegt alles sauber geordnet.

> Z.B. hatte ich garnicht darauf geachtet, das die eine FW "OS" von Falk
> und die ander FW "BF" NUR von Hayo ist!!!

Weder ist die eine FW nur von Hayo noch die andere nur von mir.

> Wie ist das mit den
> Ver.Nummern? sind die jetzt fortlaufend oder bleibt Falk bei der 092er
> oder hat Hayo auch eine 092er???

Das ist das Problem.

Falk

Falk Willberg schrieb:
> Michael D. schrieb:
>> Hallo Falk,
>
> ...
>
>> Deshalb kommen dann auch die einen oder anderen dämlichen Fragen von
>> mir(oder nicht nur von mir), gerade weil alles so verstreut liegt!
>
> http://sourceforge.net/apps/phpbb/welecw2000a/view...
>
> Da liegt alles sauber geordnet.
>
...keine Frage, ich meine die FW-Versionen: Ein Teil liegt hier, das
andere in Google-Groups und der Rest im SFN
Könnte man nicht ALLE FW-Versionen (ob beta oder release) die bisher
erschienen sind mit Beschreibung auf eine Seite setzen?

>> Z.B. hatte ich garnicht darauf geachtet, das die eine FW "OS" von Falk
>> und die ander FW "BF" NUR von Hayo ist!!!
>
> Weder ist die eine FW nur von Hayo noch die andere nur von mir.
>
sondern???

>> Wie ist das mit den
>> Ver.Nummern? sind die jetzt fortlaufend oder bleibt Falk bei der 092er
>> oder hat Hayo auch eine 092er???
>
> Das ist das Problem.
>
> Falk
eben, wie geht das jetzt weiter?

Gruß Michael

Jürgen schrieb:
> Hallo Falk,
>
>>Jürgen schrieb:
>>> [...]
>
> Muß mich wohl doch mal intensiver mit TortoiseSVN unter WinXP
> beschäftigen :-(
> Sehe aber bisher nur die Möglichkeit das SF - Repository zu nutzen.
> Änderungen im lokalen Repository z.B. für einen Test sind aber bei
> zwischenzeitlichen Änderungen in SF dann wohl weg? Oder kann man auch
> "abwärts" mergen?

Solange die Änderungen nicht an gleich Stelle stattfinden
sind Differenzen zwischen dem SVN-Repository und der lokalen
Kopie i.A. kein Problem. Dies gilt teilweise auch innerhalb
einer Datei. Erst wenn sich die Änderungen zu sehr überlagern
(und svn die nicht mehr zusammenführen kann) wird ein "Conflict"
aufgelöst, wobei die verschiedenen Versionen noch auf der
Platte liegen und im Source die entsprechenden Stellen gekennzeichnet
sind.

Trotzdem lohnt es sich vor dem Arbeiten ein "svn up" zu machen ;)
>
> Gruß
> Jürgen
>
> Sorry, der Post ist viel zu lang!

Grüße,

   rowue, der 324 Messungen ausgewertet hat, um verlässliche Daten zu
haben.

(soviel zum Thema "nicht testen" ;)

So, die Herren mögen weiterzanken, nachdem sie sich das Bild angesehen
haben. Das ist bei offenen Eingängen, ohne BW-Linit, ohne jegliche
Filterung in SW entstanden.

Ich hatte nur die je zwei 0-Ohm-Widerstände durch 23,5 Ohm (lag in der
Bastelkiste, richtiger wären 24,9) ersetzt.

Falk

Sieht gut aus, Falk. Die Widerstände werde ich auf jeden Fall auch bald
umbestücken.
Ihr solltet euch aber nicht an den 24.9 Ohm aus dem Datenblatt
aufhängen, das ist lediglich ein Beispiel. In anderen Datenblättern gibt
es üblicherweise eine Grafik dazu wie "recommended serial resistance
versus capacitive load". Wenn die Größe der Lastkapazität bekannt ist
sucht man sich damit eben den passenden Serienwiderstand.
Wer einen Blick in die Application Notes zur AD813x Serie wirft, wird
dort auch verschiedene Widerstandswerte je nach Anwendung vorfinden,
beispielsweise 2x 49.9 Ohm beim Treiben eines ADCs von Analog Devices.

Gruß
Michael

Nochmal die Frage direkt an Falk:

gibt es in der Firmware eine Möglichkeit auf RS232 Eingaben zu warten?
Zwecks Handshake.

Mfg,
Kurt

Kurt Bohnen schrieb:
> Nochmal die Frage direkt an Falk:
>
> gibt es in der Firmware eine Möglichkeit auf RS232 Eingaben zu warten?
> Zwecks Handshake.

Das kann man natürlich machen. Was schwebt Dir denn vor?

Falk

Die Daten für Screenshot und CSV Export Blockweise übertragen. Für erste
Tests 128 Byte, später bis zu 3kByte.

Vor dem Senden eines Blocks soll das Oszi auf ein Clear-to-send vom
Zielsystem (PC oder USB Host) warten.

Kurt Bohnen schrieb:
> Die Daten für Screenshot und CSV Export Blockweise übertragen. Für erste
> Tests 128 Byte, später bis zu 3kByte.
>
> Vor dem Senden eines Blocks soll das Oszi auf ein Clear-to-send vom
> Zielsystem (PC oder USB Host) warten.

Kann man machen. Ich muß mal sehen, wann ich dazu komme. Oder hätte
jemand anderes Lust dazu?

Falk

Offtopic:
Verkauft noch jemand einen 2 oder 4 Kanaler?
Melde interesse an!
torsten-otten ät gmx.de

Gruß
Torsten

Odic schrieb:
> Hallo zusammen,

> @Falk:
> Danke für den Hinweis. Ich kenne den Thread und lese auch seit ettlichen
> Monaten mit. Ich möchte auch überhaupt nicht ausschließen, dass ich die
> von mir angefragte Entscheidung lediglich überlesen habe. Kannst du -
> oder jemand anderes - mir bitte einfach in einem Satz das damalige
> Ergebnis wiedergeben?

Nach meinem Verständnis hatten sich alle anwesenden Entwickler darauf
geeinigt, den Code künftig im SVN zu pflegen.

> Ich möchte ungern Stunden darauf verwenden, den
> ganzen Thread noch einmal durchzugehen. ;-)

Ich auch nicht. Weil µc.net für diese Art der Diskussion ungeeignet ist,
wie Du ja auch merkst, benutzen wir inzwischen andere Kanäle.

...

> - An die Autoren der OS-Version: Mich würde eure bisherige Erfahrung mit
> dem offenen System bzw. nähere Infos zu getroffenen Konventionen
> interessieren.

Warum? Willst Du Dich beteiligen? Dann können wir und über alles
verständigen.

> Wie funktioniert die Abstimmung zwischen den aktiven
> Entwicklern bzgl. bearbeiteter Code-Teile/Funktionalitäten?

Ich schreibe die URLs, IRC- und Jabber-Daten jetzt nicht nochmal hin.

> Hayo hatte ja zudem irgendwann
> mal Bedenken geäußert, dass eine fehlende Koordination zu unerwünschten
> bzw. unübersehbaren Änderungen in der SW führt. Ich denke niemand, der
> bereits einmal mit einer größeren Gruppe an einem Projekt gearbeitet
> hat, kann das Problem von der Hand weisen. Aber wie begegnet ihr ihm?

Welche größere Gruppe meinst Du? Die aktiven NIOS-Entwickler?

Falk

So, ich noch mal.

Ich hatte implizit vorausgesetzt, dass ich das ganze in Englisch auf das
Wiki schreiben würde. Das komplette Wiki ist ja schließlich auch auf
englischer Sprache und Doku zu Softwareprojekten schreibe ich persönlich
in 90% der Fälle auch in Englisch.

Ich wollte auch nicht das Wiki neu erfinden, sondern Informationen zur
Klärung an einigen Stellen beitragen. Ich habe nämlich, wie zuvor
geschrieben, eine ganze Weile gebraucht, bis ich rausgefunden habe wo
welche Sourcen liegen und noch immer keinen rechten Überblick wo welche
Binaries zu finden sind, bzw. auf welchem Repository-Stand diese
aufbauen. Falk hat zwar oben mal den Link
(http://consult42.com/W20XXA-prereleases/) zu irgendwelchen Versionen
gepostet, aber der Zusammenhang zwischen Quellen in SF und den Sourcen
ist zumindest mir auch noch nicht klar. Ich hatte z.B. gehofft Binaries
in den entsprechenden Tags des Repository zu finden.

Bevor ich anfange an einem Projekt zu arbeiten, versuche ich zuerst
dessen Strukturen zu verstehen, sonst wird das nix mit der Arbeit oder
ist sehr mühselig. Das ist aber bei der aktuellen Dokumentation eher
mühselig finde ich. Anderen hier scheint es ähnlich zu gehen. Einige
scheinen sich in SF nicht wirklich auszukennen bzw. zurecht zu finden,
sonst wären ja schon alle dorthin gewechselt, statt hier endlos lange
Threads durchzuscrollen.

Deshalb hatte ich vorgeschlagen all denen die sich nicht - wie ich jetzt
- in mühevoller Kleinarbeit alles immer wieder zusammen suchen wollen
etwas zu helfen, indem die Doku etwas klarer wird. Ich dachte mir halt
es wäre für das Projekt von Vorteil. Wenn es mehr Leute in kürzerer Zeit
einen Einstieg in die Materie finden können, dann gibt es vielleicht
auch mehr potentielle Helfer. Und sei's nur das jemand mit nem Welec
Oszi mal ein Backup zieht, die OS-FW mal ausprobiert und Bugreports
meldet. Wenn es dafür ne "Schritt für Schritt" Anleitung gibt dann ist
das doch um so einfacher.

Wobei das mit der Einstiegshürde "Ja, da muß man sich mal durchgraben"
von Falk natürlich auch ein Argument ist ... das mir die Arbeit ersparen
würde den Text für's Wiki zu schreiben.

So long
Holger

Gibt es irgendwo eine aktuelle,vollständige! Anleitung zum compilieren
der Firmware unter Windows?

Welche Programme brauche ich, in welcher Reihenfolge werden sie
installiert...

Hallo zusammen,

ich habe gerade die Posts der letzten Tage gelesen. Dazu möchte ich
anmerken, dass ich versucht habe vor vielleicht drei Wochen die
Versionen zu mergen. Das Ergebnis war, soweit ich das getestet habe,
ganz OK. Allerdings habe ich dabei auch Hayos neue Run/Stop-Logik
übernommen. Deshalb war die Version, zumindest für mich persönlich,
unbrauchbar, da man keine Signale zoomen konnte. Auf Sourcen mit den
Änderungen warte ich bis heute. Deshalb habe ich vorgestern selbst Hand
angelegt. Ich kann nur hoffen, dass irgendwann wieder alle an einen
Strang ziehen.

@Falk: Deine Änderungen sind interessant. Ich hoffe nur, dass diese auch
noch so schnell laufen, wenn z.B. die Verbindungslinien gezeichnet
werden...
Kannst du deine Änderungen vielleicht in einen Branch umziehen? Dann
können wir vom Trunk eine OS.092 veröffentlichen.

Guido schrieb:
> Hallo,
> Ins momentane SVN (sorry)
> ferkelt einfach jeder seine wichtigen Änderungen ("added -> in
> Comments") ins offizielle Trunk. Dadurch wird dieses früher oder
> später automatisch unbrauchbar.

Sag mal, (sorry) hast Du noch alle Tassen im Schrank?
Ich darf Dir mal kurz sagen, was ich da so 'reingeferkelt habe:

Ich habe Niklas' Screendump ist so verbessert, daß ein Screenshot in
Farbe in 15s fertig ist.
Ich habe eine Fernsteuerung (für RS232) eingebaut, die es u.a. erlaubt,
das RAM auszulesen, Variablen zu setzen etc. Damit habe ich bspw. das
Bit gefunden, das das Scope für >50MHz unbrauchbar gemacht hatte.
Und momentan bin ich dabei, die Darstellungsgeschwindigkeit etwa um den
Faktor 5-10 zu verbessern.

> Aber klar, das sind Anfangsprobleme,
> die aber bitte nicht einfach ignoriert werden sollten.

Das Anfangsproblem ist, daß wir die Wohnung eines Messies renovieren
müssen. Wir sind jetzt noch in der Phase, daß wir mit Radladern Müll
'rausschaffen. Da bringt es noch nicht viel, sich über coding Style oder
die Farbe der Wasserhähne Gedanken zu machen.

Falk

Alter Schwede was ist das hier für ein rumgezicke!

Ich denke ich muß mal einige klare Worte sagen. Also erstmal trotz des
gezickes sind die Fortschritte in allen Bereichen nicht übel. Bei mir
war in letzter Zeit viel los (Trauerfall ind er Familie, Beruf) so dass
mir nur wenig Zeit blieb für unser Projekt.

Zu den Versionen:

Ich entwickle keine zweite Linie! Die einzige offizielle Version ist die
OS-Version. Der Grund warum ich ab und an eine BF.0.XX rausgetan habe
ist, dass ich eine Rückmeldung zu einigen Änderungen brauchte die ich
neu eingebaut hatte.

Zu diesem Zweck werde ich auch in Zukunft weitere Test oder
Demoversionen rausgeben. (@Stefan - Du hattest leider meine Version
unvollständig gemerged, daher einige Ungereimtheiten bei Start/Stop).

Ich benutze eine eigene Entwicklungsbasis um etwas die Übersicht über
die Änderungen zu behalten und nicht alles ungetestet übernehmen zu
müssen. Grundsätzlich übernehme ich aber die Änderungen aus der
OS-Version und baue meine Änderungen nach ausgiebigen Tests und
Rückmeldungen in die OS-Version ein. Mittlerweile habe ich mich mit SVN
etwas angefreundet und hoffe ich zerschieße nichts bei meinen ersten
Versuchen etwas zu committen.

Zu den Kommentaren im Coding:

Grundsätzlich kann man sagen, je mehr und ausführlicher kommentiert wird
was man macht, umso besser ist der Code wartbar. Eine Kennzeichnung mit
dem Entwicklerkürzel vereinfacht eventuelle Nachfragen.

Sicherlich sind mir auch schon Programmteile durchgerutscht die nicht so
gut kommentiert oder gekennzeichnet waren. Das sollte aber eher die
Ausnahme bleiben. Grundsätzlich ist das als Empfehlung (an den gesunden
Menschenverstand)zu sehen um allen das Leben etwas leichter zu machen.

Gruß Hayo

Stefan E. schrieb:
> Hallo zusammen,
>
> ich habe gerade die Posts der letzten Tage gelesen. Dazu möchte ich
> anmerken, dass ich versucht habe vor vielleicht drei Wochen die
> Versionen zu mergen.
...
> Deshalb habe ich vorgestern selbst Hand
> angelegt.

Zur Information derjenigen, die SVN noch weniger kennen, als ich:
Ich bekam eine Mail, daß Stefan eine Änderung committed hatte.
In der gleichen Datei hatte ich reichlich "herumgeferkelt".

Wie löst man das? Mit SVN so:
svn update; svn commit

Und schwupps, waren beide Änderungen berücksichtigt.

> @Falk: Deine Änderungen sind interessant. Ich hoffe nur, dass diese auch
> noch so schnell laufen, wenn z.B. die Verbindungslinien gezeichnet
> werden...

Tut es: http://consult42.com/signal3.mpg

> Kannst du deine Änderungen vielleicht in einen Branch umziehen?

Ok, ich lerne dann mal SVN Lektion III ;)

> Dann können wir vom Trunk eine OS.092 veröffentlichen.

Gute Idee! So machen wir das.

Falk

@Hayo

Ja war mir klar, dass ich da was falsch gebaut habe. Das ganze war sehr
umfangreich. Allerdings hat das bei deiner Ausgabe bei mir auch nicht
funktioniert. Deshalb bin ich davon ausgegangen, dass auch in deinen
Sourcen irgendwo ein Fehler steckt. Nachdem ich von dir einige Zeit
nichts mehr gehört hatte, musste ich einfach selber eine Lösung finden
um überhaupt mal wieder weitermachen zu können. ;-)

Und wegen SVN: DU kannst NICHTS zerschießen! Alles kann rückgängig
gemacht werden. Ich habe am Anfang auch Mist gebaut und Kopien erstellt,
die ich nicht mehr löschen konnte. Probiere es einfach. Ansonsten
einfach in Skype anklopfen. Dort bekommst du eine sicherlich kompetente
Hilfe bei den ersten Schritten.

Mir persönlich ist es egal, wieviele commits an einem Tag gemacht
werden. Hauptsache es werden in regelmäßigen Abständen welche gemacht.

Das mit den Entwicklerkürzeln in Kommentaren versuche ich zu übernehmen.
Leider vergesse ich es noch oft.

@Falk
Yeah!

@all

Ich werde mal versuchen (in einem branch natürlich ;-)) einen neuen
Trigger zu implementieren, der die Vorteile von Auto- und Normal-Trigger
vereint. Hoffentlich klappts :-)

C:\welec\firmware>make
# 2009.10.25.13:04:13 --- (Note: to make for Nios 16, try "make clean all M=16")

# 2009.10.25.13:04:13 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc -I .
./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 -DBUILDBY
=" - 20091025" -D_Debug_ src/TomCat.cpp -o obj/TomCat.cpp.o
/bin/sh: nios-elf-gcc: command not found
make: *** [obj/TomCat.cpp.o] Error 127

Die Programme wurden installiert nach dieser Anleitung:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Das Makefile wurde auch angepasst. Wo ist der Fehler?

Kurt Bohnen schrieb:

...
> /bin/sh: nios-elf-gcc: command not found
> make: *** [obj/TomCat.cpp.o] Error 127
> 

...

> Das Makefile wurde auch angepasst. Wo ist der Fehler?

Kein Pfad nach nios-elf-gcc.

Falk

Und wo wird der Pfad eingetragen. Makefile oder Systemvariablen?

Müssen die Systemvariablen (oder sind es Benutzervariablen?) einen
bestimmten Namen haben? Wert ist klar.

Problem gelöst:
Die Pfade müssen in der Systemvariablen "Path" eingetragen werden. Die
einzelnen Einträge sind mit einem Semikolon zu trennen.

@Falk,
danke für den Hinweis!


Mfg,
Kurt

Guido schrieb:
> Hallo Falk,

Hi Guido,

>
> mit den Ferkeleien meine ich ausdrücklich nicht deine
> Änderungen und Erweiterungen im Screenshot usw. Die
> wurden in dieser Version eingeführt und werden dort
> gepflegt, das ist selbstverständlich.

ACK ...

>
> Das mit den neuen Zeichenroutinen ist zum Glück schon
> geklärt (ander finden vllt. die passenderen Worte als
> ich).
>
> Auch die Vertikaleinstellungen hätten in einem Branch
> geändert werden sollen, solche Sachen führen schnell
> dazu, das Inkompatibilitäten resultieren.

Jein - ich hatte die Änderungen hier sehr ausführlich
getestet und dann noch mal als Patch (mit Werzen)
veröffentlicht bevor ich sie (ein bis zwei Wochen später
und nach Rücksprache mit Falk) committet habe.

Der Sinn eines Branches besteht ja auch darin, seine
Änderungen unabhängig vom trunk durchzuführen (um
sich auf diese Aufgabe konzentrieren zu können) und
das Endergebniss nachher einzupflegen.

Die Aufteilung in "branches", "tags" und "trunk" und
ihre entsprechende Verwendung in eine Empfehlung und
kein Gesetz und selbst "Gesetze" dürch nicht ignoriert
aber gebrochen werden.

Es gibt auch Gruppen, welche ganz ohne "branch" arbeiten,
auch wenn es sicher sinnvoll gewesen wäre, die
Vertikal-Ablenkung und aus ihr resultierende Änderungen
in einem branch abzuhandeln.

Zur Inkompatibilität: diese stellt sich mit dem mergen
des branches in den trunk ein - und dieser Schritt wird
immer gegangen werden müssen, wenn ein Feature eingepflegt
wird.


>
> SVN kann nicht zaubern, und bei fast 300 diffs ist es
> faktisch unmöglich einen definierten Zustand
> wiederherzustellen.

Kommt auf die Aussagekraft der commit-messages an ;)
Generell könnte ich auch jetzt noch den Code entfernen -
allerdings fussen z.B. auch Falks Tabellen jetzt darauf,
dass es einen Aussteuerbereich des ADC's und nicht mehr
zwei gibt.
>
> Hayo sollte seine HE auch als Branch anlegen und aus
> mehreren Branches ein neues Trunk erstellen, das kann
> SVN nun wirklich (bis auf die Konflikte, die dann von
> Hand geköst werden müssen).

Sicher?
>
> Gruß, Guido

Grüße,

   rowue

Rolf Würdemann schrieb:
> Guido schrieb:

>> Auch die Vertikaleinstellungen hätten in einem Branch
>> geändert werden sollen, solche Sachen führen schnell
>> dazu, das Inkompatibilitäten resultieren.
>
> Jein - ich hatte die Änderungen hier sehr ausführlich
> getestet und dann noch mal als Patch (mit Werzen)
> veröffentlicht bevor ich sie (ein bis zwei Wochen später
> und nach Rücksprache mit Falk) committet habe.

Genau. Nach etlichen Tests war klar, daß diese neuen Faktoren nur
Vorteile haben würden.

Und, Guido, an welcher Stelle hat Dich diese Änderung bei der
FW-Entwicklung gestört?

Falk

Es ist ja außerordentlich mühselig, wegen jeder kleinen Änderung an
Variablen wie bspw. "adc_change12_reg" eine neue FW einzuspielen.

Deswegen gibt es (seit längerem) die Möglichkeit, einige Variablen per
RS232 zu ändern. Dokumentiert ist das in
http://sourceforge.net/apps/trac/welecw2000a/wiki/...
Die Funktion kann man mit "hterm" benutzen oder über das kleine tool
"misc-tools/setvars/setvar.pl".

Wenn jemand eine Variable ändern will, die noch nicht in der Liste
steht, bitte Nachricht an mich, ich kann das dann kurzfristig einbauen.
(Kann aber auch jeder selbst: set_vars() in src/userif_t.cpp)

Bitte pflegt Änderungen oder gefundene Bedeutungen in
http://sourceforge.net/apps/trac/welecw2000a/wiki/... ein.

Falk

Guido schrieb:
> Hallo Falk und Rolf,

Hi Guido,

>
> mit der Vertikaleinstellung ist halt das Problem, dass
> hayos Version nicht kompatibel ist, mich stört es nicht,
> ich habe ja schon vor langer Zeit damit experimentiert.

Jein - die Änderung der Vertikaleinstellung ist vom Grundsatz
her kompatibel mit Hayos Version. Es werden (bis auf die
Hinzunahme einer weiteren Schiebeoperation in der Anzeige) nur
Registerwerte und Faktoren geändert. Den meisten Algorithmen
ist es egal, ob da nur mit 2.04; 3.25 oder 2.575 gearbeitet wird.
Problematischer sieht es mit den Optimierungen aus, welche
nun als Konsequenz aus der Änderung folgen. Hier werden
Algorithmen geändert und ausgetauscht ...
>
> Ich will keine Prinzipien reiten, mir geht es um das
> Praktische. Wenn 6 Entwickler an einem Trunk Änderungen
> (nicht Bugfixes o.ä.) vornehmen und nach 4 Wochen stellt
> jemand fest, dass etwas nicht mehr funktioniert, dann wird
> es schwer den Fehler zu finden. Haben wir dagegen 6 Branches,
> sagen in dem Fall 5 Entwickler "bei mir geht es noch".

Naja, Du musst ja auch bedenken, dass hier mehr als ein
Entwickler zur gleichen Zeit am gleichen Punkt arbeiten.
Sie Dir als Beispiel nur Jörg und Falk an, welche gerade
die Auslese- und Darstellungsroutinen "überarbeiten".

Der Vorteil beim Branch ist hier m.E., dass diese Arbeit
nicht von Änderungen am trunk beeinflusst wird (warum sehen
meine Werte auf einmal anders aus) und sich z.B. auch
"conflicts" eher vermeiden lassen.

Man arbeitet in der Zeit halt enkoppelt vom trunk (und ich
muss gestehen, dass ich am Anfang kurz überlegt habe, 'nen
branch dafür aufzumachen ;)

Der Preis dafür ist, dass wir auch beim Mergen des branches
Fehler einführen können (was ja schon passiert ist, als
Hayos Änderungen eingepflegt wurden).

Zur Inkompatibilität mit Hayos Version (dem ich an dieser
Stelle mein Beileid aussprechen möchte), so stellt sich
dann eher die Frage, ob und wie Hayo diese Änderung übernehmen
möchte. Die Angebote bzgl. svn stehen noch immer.
>
> Grüße, Guido

Grüße,

   rowue

Hier mal eine Herausforderung an die eher künstlerisch Begabten:

Wie wäre es, wenn mal jemand ein neues Logo für den Startbildschirm
entwerfen würde?

Ideal wäre Vektorgrafik, die dann auch gerne animiert sein darf. Es gibt
640x480 Pixel und die Farben, die man auf dem Display sehen kann. Ideal
wäre eine Beschränkung auf Gelb, Grün, Rot und Blau.

Um dieses Thema hier herauszuhalten, habe ich mal einen neuen Fred
aufgemacht: Beitrag "Wittig(welec) DSO W20xxA - Neues Logo"

Viel Spaß,
Falk

Odic,

ich finde, das haut schon hin. Skype-Chat zur Abstimmung und svn bei
Sourceforge zur Codepflege. Noch sind wir nicht so viele, als daß das
ein Problem wäre. Auch mit dir und Hayo nicht, wink...
Im Moment haben wir mit kleinen Feature-Branches angefangen, die dann
rasch wieder auf den Trunk gemerged werden sollen.

Was wir noch brauchen könnten wäre ein besseres Forum, das ist bei
Sourceforge so langsam daß ich es nicht benutzen mag. Monster-Threads
hier eigentlich auch nicht.

Jörg

Kurz zur Info...

in der OS.0.92 hat sich ein kleiner Fehler eingeschlichen, der
die Besitzer der W20X4 betrifft und heute Abend behoben
wurde. (https://sourceforge.net/apps/trac/welecw2000a/ticket/43)

Ein entsprechender Tag auf eine Version 0.92a wurde schon gesetzt,
die entsprechende Version wird bald zum Download (Falk?) zur Verfügung
stehen.

Grüße,

   rowue

Rolf Würdemann schrieb:
> Kurz zur Info...
>
> in der OS.0.92 hat sich ein kleiner Fehler eingeschlichen, der
> die Besitzer der W20X4 betrifft und heute Abend behoben
> wurde. (https://sourceforge.net/apps/trac/welecw2000a/ticket/43)
>
> Ein entsprechender Tag auf eine Version 0.92a wurde schon gesetzt,
> die entsprechende Version wird bald zum Download (Falk?) zur Verfügung
> stehen.

Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht...

Darum noch eine Kopie hierhin.

Falk

Falk Willberg schrieb:
> Rolf Würdemann schrieb:
>> Kurz zur Info...
>>
>> [OS 0.92a]
>
> Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht...
>
> Darum noch eine Kopie hierhin.

Liegt immer noch nicht da, nachher noch mal schauen ....

Aber:

Ich bin heute morgen mal durch die Tickets gegangen und habe
erledigte Tickets abgeschlossen. Viel ist da nicht mehr.
Diverse von den Bugs hat btw. Hayo erlegt.

Darum meine Bitte an *alle*: Jeder möge sich die aktuelle Version
der von ihm präferierten Firmware ansehen und schauen, ob er/sie
noch unbekannte Bugs findet. Wenn ja: bitte in's Ticket-System
damit.

>
> Falk

Grüße,

     rowue

Frage zum Screenshot Programm:

Ist der Umweg über fun_hdr(), fun_data() und fun_ftr() auf die
Funktionen csv_hdr(), csv_data() und csv_ftr() wirklich nötig oder von
Vorteil?
Oder kann man csv_ftr() mit in receive_trace() einbauen.

Ich werde mal den CSV Export so umbauen das ihr seht was ich mit
blockweiser Übertragung meine.

Mfg,
Kurt

Hier mal ein Bild von ca. 1h Persist mit dem Probe-Generator.

Was auffällt ist, daß die Impulse nur an bestimmten Stellen auftreten
und den gleichen Wert haben.

Vielleicht hat ja noch jemand eine Idee...

Falk

Ich habe mich gerade wie gewünscht auf Käfer-Suche begeben.
QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei
der Murks diesmal vermutlich einfach daran liegt, dass die neuen
Skalierungsfaktoren hier nicht berücksichtigt werden?
Lohnt sich ein Ticket oder wisst ihr auch so, was Sache ist? Kurz gesagt
stimmen da die Werte überhaupt nicht mehr, wirklich abenteuerlichst was
da rauskommt.

Michael

@ Falk: ehrlich gesagt kann ich dein Bild nicht ganz nachvollziehen, was
hast du da genau getrieben?

Michael H. schrieb:
> @ Falk: ehrlich gesagt kann ich dein Bild nicht ganz nachvollziehen, was
> hast du da genau getrieben?

Eine Stunde lang im Persist-Mode das Rechteck des Generators anzeigen
lassen. Die Nadelimpulse snd die berüchtigten "Glitches".

Falk

Rolf Würdemann schrieb:
> Falk Willberg schrieb:
>> Rolf Würdemann schrieb:
>>> Kurz zur Info...
>>>
>>> [OS 0.92a]
>>
>> Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht...
>>
>> Darum noch eine Kopie hierhin.
>
> Liegt immer noch nicht da, nachher noch mal schauen ....
>
> [...]

die OS 0.92a ist jetzt auf SFN verfügbar.

Alle Nutzer, die sich die OS 0.92 (ohne a) geflasht haben:
bitte updaten.

Grüße,

   rowue

...ist die von hier nochmal modiefiziert???

Gruß Michael

...scheint doch dieselbe zu sein!
Der Screenshot geht nicht???

Gruß Michael

Ja

>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei
>der Murks diesmal vermutlich einfach daran liegt, dass die neuen
>Skalierungsfaktoren hier nicht berücksichtigt werden?

Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf
Zeitbasen kleiner 50ns.

Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade
andere Sachen mehr stören. Außerdem hängt das natürlich auch von der
neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt.

Stefan E. schrieb:
>>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei
>>der Murks diesmal vermutlich einfach daran liegt, dass die neuen
>>Skalierungsfaktoren hier nicht berücksichtigt werden?
>
> Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf
> Zeitbasen kleiner 50ns.

Da passieren auch schlimme Dinge ;)

> Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade
> andere Sachen mehr stören. Außerdem hängt das natürlich auch von der
> neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt.

Was hälst Du davon, wenn wir eine zweite Skalierungstabelle generieren,
die immer die richtige Abbildung (u_char)ADC-Wert->(long)Spannung in mV
enthält?

Die entsprechenden Flags, die eine Generierung solcher Tabellen auslöst,
setzen wir sowieso.

Du kannst Dich ja melden, wenn Du nochmal das QM angehst.

Falk

Hallo,

hab mal einen dritten Trigger nach meinen Vorstellungen eingebaut.
Er verwendet normalerweise den Normal-Modus. Kommt für 500ms kein
Trigger-Ereignis schaltet er auf Auto um. Wird der Triggerwert
irgendwann überfahren, dann geht es wieder in den Normal-Modus.

Das ganze heißt derzeit Standard-Trigger. Wer einen besseren Namen hat,
kann sich melden ;-)

Das ganze klappt derzeit nur, wenn die Timebase nicht zu lange
eingestellt ist. Da muss noch eine Fallabfrage rein ;-)

Bei mir klappt das ganze ganz gut.

Stefan E. schrieb:
> Hallo,
>
> hab mal einen dritten Trigger nach meinen Vorstellungen eingebaut.
> Er verwendet normalerweise den Normal-Modus. Kommt für 500ms kein
> Trigger-Ereignis schaltet er auf Auto um. Wird der Triggerwert
> irgendwann überfahren, dann geht es wieder in den Normal-Modus.

Sehr angenehm! So werde ich den wahrscheinlich immer einstellen...

> Bei mir klappt das ganze ganz gut.

Ich mußte nach Einspielen der TomCat.ram den Trigger-Modus einmal von
"Standard" auf "Standard" (Kein Tippfehler) umschalten.

Falk

Ja, der Fehler ist bekannt. Nur steige ich beim Menü nicht ganz durch
g

Stefan E. schrieb:
>>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei
>>der Murks diesmal vermutlich einfach daran liegt, dass die neuen
>>Skalierungsfaktoren hier nicht berücksichtigt werden?
>
> Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf
> Zeitbasen kleiner 50ns.
>
> Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade
> andere Sachen mehr stören. Außerdem hängt das natürlich auch von der
> neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt.

Also ich habe QM mit der umgesetzten Skalierung geprüft - sah soweit
gut aus

Grüße,

   rowue

Michael H. schrieb:
> Ich habe mich gerade wie gewünscht auf Käfer-Suche begeben.
> QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei
> der Murks diesmal vermutlich einfach daran liegt, dass die neuen
> Skalierungsfaktoren hier nicht berücksichtigt werden?
> Lohnt sich ein Ticket oder wisst ihr auch so, was Sache ist? Kurz gesagt
> stimmen da die Werte überhaupt nicht mehr, wirklich abenteuerlichst was
> da rauskommt.

In Zeitbasen < 50ns? - Das ist ein anderes Problem. Bei grösseren
Zeitbasen habe ich das getestet und die Werte haben den Erwartungen
entsprochen.
>
> Michael


Grüße,

  rowue

Hallo Stefan,

ich habe deine Mod-Version mal ins Ram geladen und war so begeistert,
das ich die 092er danach geflasht habe!!!
Ich kann jetzt das erste Mal triggern ohne gezappel (nur ein wenig am
Triggerlevel drehen) bis zum erbrechen! Jetzt macht das ganze mehr
Spass!!!

An dieser Stelle, ein Lob von meiner Seite für diese tolle Arbeit, ich
bin begeistert.

Ich habe mal den Screenshot getestet, die 041er Ver. reagiert garnicht!
Habe es dann mal mit der 091er Ver. versucht, hat erst die Bytes
raufgezählt ist dann aber abgestürtzt (Screenshot hat ein Prob.
festgest.)

Nach mehrmaligen Versuchen, konnte ich dann 3 x Bitmap-Shots (2x Farbe,
1x Monochrom) machen die sich sehen lassen konnten, wie man sieht!
Vielleicht könnte ja Jemand ein bißchen daran schrauben?

Gruß Michael

Hey Michael,
Danke für das Lob. Ein paar Probleme sind mir noch aufgefallen. Aber die
versuche ich auch noch auszubessern. Das ganze ist noch im
Experimentierstadium ;-)

Wegen dem Screenshot weiß ich jetzt auch nicht. Hast du meine Version
drinnen? Oder die aus dem Trunk? Nicht das ich da wieder was zerlegt
habe beim mergen ;-) Kriegen wir alles in den Griff. Der Falk ist nur
gerade ausgelastet mit den neuen Leseroutinen. Auf die warte ich schon
ganz gespannt. Da hängt der Trigger noch etwas verschoben und es gibt
noch keinen Noise-Filter. Sonst aber schon echt klasse.

Hallo Stefan,

ich habe deine Ver.(OS.092 Alpha) drinnen, bis jetzt habe ich nicht's zu
beanstanden, auch die Nullinien-Calibrierung hat sich etwas gebessert
(habt ihr daran geschraubt?)
Wenn ich jetzt das DSO wieder einschalte bleibt die Calibrierung, wo sie
vor dem Ausschalten war, erhalten!
Also dein Nois-Filter funzt.
Vielleicht brate ich später noch die 50 Ohm Wiederstände rein, wie sieht
es mit der SW-Anpassung für diese aus, geht da was?

Gruß Michael

Hallo Michael,

also ich habe nichts an der Nulllinienkalibrierung gemacht.
Jedenfalls nicht absichtlich.

Probiere doch mal die Version im Trunk. Vielleicht ist damit der Fehler
vom Screenshot behoben. Auf den neuen Trigger brauchst du damit auch
nicht mehr verzichten. Der ist mittlerweile eingepflegt. Zusammen mit
ein paar Fixes. Mir ist jetzt kein gröberer Fehler mehr aufgefallen.
Vielleicht magst du ja nochmal testen.

50 Ohm-Anpassung dürfte mit Falks Routinen kein Problem sein, wenn Sie
denn mal funktionieren.

Michael D. schrieb:
> Hallo Stefan,
>
> [...]
> Vielleicht brate ich später noch die 50 Ohm Wiederstände rein, wie sieht
> es mit der SW-Anpassung für diese aus, geht da was?

Du meinst im Bezug auf die Pegel/Aussteuerung? Morgen kommen Widerstände
hier an, dann schaue ich mir mal an, ob und wie sich da was ändert
(ich hoffe/denke, wir werden nicht viel anpassen müssen ;)
>
> Gruß Michael


Grüße,

   rowue

Michael D. schrieb:
> Hallo Stefan,
>
> [screenshot]

hmmm - also ich habe den screenshot ohne grosse Probleme mit
der OS 0.92 am laufen - wobei meiner aus dem Trunk sein dürfte -
haben wir vielleicht vergessen 'ne neue Version in's Netz zu stellen? ;)

>
> Gruß Michael

Grüße,

   rowue

Hallo Rolf,

er hatte meine Branch-Version drauf, die noch einem älteren Stand war.
Ich vermute da liegt der Fehler.

Stefan E. schrieb:
> Hallo Rolf,
>
> er hatte meine Branch-Version drauf, die noch einem älteren Stand war.
> Ich vermute da liegt der Fehler.

Zwischen 0.91 und 0.92 gibt es, soweit ich weiß, keine Unterschiede.

Allerdings habe ich inzwischen schon öfter von Problemen mit den
Screenshot unter Windows gehört.

Vielleicht kann sich ein Windows-Nutzer mal der Sache annehmen. Das ist
alles recht einfacher C-Code ohne Tricks und Schliche.

Die "Windows"-Versionen der screenshot.exe sind seit 0.91 immer nur
Dinger, die ich irgendwie kompiliert, aber nie getestet habe, weil ich
Windows nur benutze, wenn es sich nicht vermeiden läßt.

Falk

also, ich habe erst die 092er vom Falk drauf vom 20091025 ohne 3.
Trigger!
Dann die vom Stefan, 092er Alpha vom 20091028 mit 3. Trigger!
...meine Festplatte läuft hier bald über...
Wann habt ihr denn die Aktuelle rein gesetzt? Ich blick hier nicht mehr
durch, seid doch so lieb und setzt die aktuellste Version mal hier rein,
heißt da der 3. Trigger auch STANDART?

Falk,
Ich habe die 47 Ohmler wieder rausgeschmissen und 33er rein gesetzt(2.
Kanal), denn irgendwie sehe ich mit den 47ern keine Besserung!
Morgen Abend setze ich mal ein paar Aufnahmen hier rein, damit ihr den
Unterschied seht!
Der 2. Kanal wird wohl etwas besser mit den (33) Ohmlern, aber irgendwie
zickt der noch rum!
Kann das sein, das das an den Leitungen (2. Kanal)liegt, die
nachträglich verlegt worden sind?

Gruß Michael

Michael D. schrieb:
> also, ich habe erst die 092er vom Falk drauf vom 20091025 ohne 3.
> Trigger!
> Dann die vom Stefan, 092er Alpha vom 20091028 mit 3. Trigger!
> ...meine Festplatte läuft hier bald über...
> Wann habt ihr denn die Aktuelle rein gesetzt? Ich blick hier nicht mehr
> durch, seid doch so lieb und setzt die aktuellste Version mal hier rein,
> heißt da der 3. Trigger auch STANDART?

Die OS 0.92a (Bugfix) findest Du hier:

    Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
oder hier
    http://sourceforge.net/projects/welecw2000a/files/

die Ram-Version von Stefan ist hier:

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

Wenn Du es aktueller haben möchtest, musst Dir die entsprechende
Version aus dem svn auschecken und selbst durch den Compiler treten,
allerdings können da noch ungetestete Änderungen drin sein.
>
> Falk,
> [Widerstände]
>
> Gruß Michael

Grüße,
   rowue

Genau so ist es. In der Datei die ich hier gepostet habe sind evtl noch
nicht alle Änderungen enthalten gewesen, die bereits im svn waren. Im
svn sind die Änderungen mittlerweile auch enthalten. Außerdem versuche
ich dem Oskar noch beizubringen, das es gefälligst an der Mittelachse
vom Bildschirm zu zoomen hat, falls die Timebase im Stop-Modus geändert
wird. Momentan verschiebt sich das immer gewaltig.

Hi.
Den neuen Trigger finde ich eine gute Idee, das Ticket bzgl.
Triggerproblemen deshalb zu schließen ist aber nicht korrekt -
schließlich sind die Probleme nach wie vor vorhanden, wenn man den
Normaltrigger benutzt.
Und dieser hat durchaus seinen Sinn, vor allem wenn man eher selten
auftretende Ereignisse betrachten möchte. Dazu eignen sich weder Auto-,
noch Standard-, noch Singletrigger.
Ich freue mich, dass an dieser Front gearbeitet wird und bin schon
gespannt auf das Ergebnis, möchte aber nochmal betonen, dass der
Normaltrigger aus gutem Grund in allen gängigen Oszis vorhanden ist.


Gruß
Michael

Hm,

ich konnte keinen Fehler mehr beobachten. Ich arbeite selber oft im
Normal-Modus und das geht eigentlich alles mittlerweile so wie es soll.
Ich werde es aber weiter im Auge behalten.

Bitteschön:
http://consult42.com/W20XXA-prereleases/TomCat-31102009.ram

Was geht: ADC-Kalibrierung, Trigger von Stefan.

Was nicht geht (unvollständig):
Quick-Measure, DAC-Kalibrierung, Zeichnen im Stop-Modus, Delayed.

Falk

Wird schon. Die Geschwindigkeit ist angenehm. Ein paar Fehler sind noch
drinnen. Aber die bekommen wir auch noch raus ;-)

...no?
Seid ihr noch am Leben? Was gibt's Neues an der Entwicklerfront?

Gruß Michael

Ich lebe noch. Bin aber gerade gut eingedeckt mit anderem Zeugs. Es
kommt schon mal wieder mehr Zeit...

ich lebe auch noch, hatte/habe aber im Job auch etwas zu tun, nebenher
habe ich die Widerstände mal zum Test eingelötet und musste einen Bug
(Signalverzerrung bei W2022A, siehe
http://sourceforge.net/apps/trac/welecw2000a/ticket/45) "filen" ;)

Grüße,

   rowue

das ist schön, das ihr noch lebt!
Ich hab's mal getestet, liegt definitiv an der FW.
Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben!

Gruß Michael

Das Problem hat sich bei mir durch drehen an der Timebase aufgelöst. Mal
Default-Setup gemacht?

Jedes mal, auch mal zwischendurch, falls da noch Reste gewesen wären...
Ab 100nS fängt's (zuckt)an, dann bei 50nS wird es extrem und bei 20nS
gibt's dann richtige Treppchen, egal welche Spannung ich einstelle. Der
1. Kanal funzt einwandfrei.
Bei der 91er tritt es auf keinen Fall auf!
Was da wohl schiefläuft?

Wie bist du vor gegangen mit der Timebase?

Stefan:(hast du meine Mail nicht bekommen?)

Gruß Michael

Michael D. schrieb:
> das ist schön, das ihr noch lebt!
> Ich hab's mal getestet, liegt definitiv an der FW.
> Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben!

Erstmal würde ich mich freuen, wenn Fehler im Ticket diskutiert
werden - hier können schnell mal drei-vier Posts dazwischen kommen
und dann wird's unübersichtlich.

Wie aus dem Ticket ersichtlich, tritt der Fehler beim Übergang
von 0.91 zu 0.92a ab r245 auf. Das ist der Punkt, wo "wir" Hayos
0.96HE "reingemerged" haben. Bei Hayo verläuft der Übergang zwischen
0.87Beta und 0.92HE. Es scheint nur die Hardware-Version /C7.0L/
betroffen zu sein, welche für Problematiken mit Spikes bekannt
ist (wurden die damals beseitigt- wenn ja: wie?).

Die anscheinende Zeitbasenabhängigkeit des Fehlers liegt in der
Darstellung - für Zeitbasen >= 100ns werden Werte entfernt/gemittelt,
bei 50ns haben wir etwa eine 1/1 Darstellung, bei Zeitbasen <= 20ns
werden die Linien interpoliert - da fällt der einzelne "Ausreisser"
stärker in's Gewicht.
>
> Gruß Michael

Grüße,

   rowue

PS: Michael: Du hattest noch festgestellt, dass die Null-Linie nicht
ganz sauber mit wandert - hast Du Lust, dazu mal ein Ticket (mit
ein-zwei
Screenshots) zu erstellen?

Rolf Würdemann schrieb:

> Erstmal würde ich mich freuen, wenn Fehler im Ticket diskutiert
> werden - hier können schnell mal drei-vier Posts dazwischen kommen
> und dann wird's unübersichtlich.

gut!
>

> Es scheint nur die Hardware-Version /C7.0L/
> betroffen zu sein, welche für Problematiken mit Spikes bekannt
> ist (wurden die damals beseitigt- wenn ja: wie?).

...hm, die HW-Ver. hab' ich natürlich '8C7.0L'
>
> Die anscheinende Zeitbasenabhängigkeit des Fehlers liegt in der
> Darstellung - für Zeitbasen >= 100ns werden Werte entfernt/gemittelt,
> bei 50ns haben wir etwa eine 1/1 Darstellung, bei Zeitbasen <= 20ns
> werden die Linien interpoliert - da fällt der einzelne "Ausreisser"
> stärker in's Gewicht.
...allerdings, sehr stark!

>
> Grüße,
>
>    rowue
>
> PS: Michael: Du hattest noch festgestellt, dass die Null-Linie nicht
> ganz sauber mit wandert - hast Du Lust, dazu mal ein Ticket (mit
> ein-zwei
> Screenshots) zu erstellen?

...mach ich!
Stimmt, dadurch das diese nicht gescheit mitwandern, ist dann auch bei
beiden Kanälen, je nach Stellung, mehr oder weniger Rauschen zu
verzeichnen!


Gruß Michael

Sagt mal wurde eigentlich jemals geklärt, wo man ansetzen müssten, um
den zeitlichen Versatz zwischend den Kanälen zu entfernen?
Vermutlich führt da kein Weg am neuen VHDL Design vorbei, weil es an der
Ansteuerung der ADCs liegt, oder?
Kürzlich bin ich da nämlich wieder drübergestolpert, ist schon ziemlich
hässlich.

Gruß

Michael

so, ich hab' jetzt mal das Ticket 46 (Zeroline-Correktion) in's SF rein
gesetzt, hier mal der link dazu:
https://sourceforge.net/apps/trac/welecw2000a/ticket/46

hoffe es kommt einigermaßen ruber.

Gruß Michael

Michael H. schrieb:
> Sagt mal wurde eigentlich jemals geklärt, wo man ansetzen müssten, um
> den zeitlichen Versatz zwischend den Kanälen zu entfernen?

Wir können in der Signal-Aquise ansetzen und einen "Shift" der Werte
einbeziehen ;)

> Vermutlich führt da kein Weg am neuen VHDL Design vorbei, weil es an der
> Ansteuerung der ADCs liegt, oder?

Wir können es auch in der Nios-FW - bis zu einem gewissen Grad
korrigieren - ein Vorschlag war damals über viele Geräte die
Offsets zu messen, allerdings denke ich, dass da auch ein
selbstkonsistenter Abgleich am Gerät möglich ist ;)

> Kürzlich bin ich da nämlich wieder drübergestolpert, ist schon ziemlich
> hässlich.

Sieht nicht gut aus ;) - Hast Du Lust da auch mal ein Ticket
zu "filen" ;)
>
> Gruß
>
> Michael

Grüße,

   rowue

Michael D. schrieb:
> so, ich hab' jetzt mal das Ticket 46 (Zeroline-Correktion) in's SF rein
> gesetzt, hier mal der link dazu:
> http://sourceforge.net/apps/trac/welecw2000a/ticket/46

Sieht doch schon mal sehr gut aus ;)
>
> hoffe es kommt einigermaßen ruber.

Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst
wird ;)

Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter,
es gibt zwar anscheinend nicht so viele nicht deutschsprachige
Nutzer, aber so sieht jmd., der der deutschen Sprache nicht
mächtig ist, dass der Fehler bekannt ist ...

Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen,
wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf
des Links ;)

Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen,
dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;)

>
> Gruß Michael

Grüße,

   rowue

Rolf Würdemann schrieb:
> Sieht doch schon mal sehr gut aus ;)
...danke.
> Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst
> wird ;)
ok, werde ich korrigieren!

> Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter,
> es gibt zwar anscheinend nicht so viele nicht deutschsprachige
> Nutzer, aber so sieht jmd., der der deutschen Sprache nicht
> mächtig ist, dass der Fehler bekannt ist ...
...dann werde ich das auch noch auf englisch ergänzen!

> Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen,
> wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf
> des Links ;)
...das ist ja dumm, habe es gerade bemerkt.
Wie kann ich denn, statt der Links, die Fotos gleich sichbar mmachen?
Finde irgendwie die Option nicht, komisch...

> Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen,
> dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;)
...stimmt, hatte ich garnicht dran gedacht.
>>
>
> Grüße,
>
>    rowue

Gruß Michael

Michael D. schrieb:
> Rolf Würdemann schrieb:
>> [...]
>> Kommt es - wobei das Rauschen selbst von dem Fehler nicht beeinflusst
>> wird ;)
> ok, werde ich korrigieren!

O.K. ;)
>
>> Vorschlag 1: Evtl. wäre eine englische Fehlerbeschreibung netter,
>> es gibt zwar anscheinend nicht so viele nicht deutschsprachige
>> Nutzer, aber so sieht jmd., der der deutschen Sprache nicht
>> mächtig ist, dass der Fehler bekannt ist ...
> ...dann werde ich das auch noch auf englisch ergänzen!

Wunderbar - Schau mal nach, ob Du unten den Ticket-Text
ändern darfst (oder ob das auf "Ticket-Admin" beschränkt ist ;)

>
>> Vorschlag 2: Wenn Du mal in Ticket 45 schaust, kannst Du sehen,
>> wie Bilder gleich im Ticket angezeigt werden, spart den Aufruf
>> des Links ;)
> ...das ist ja dumm, habe es gerade bemerkt.
> Wie kann ich denn, statt der Links, die Fotos gleich sichbar mmachen?
> Finde irgendwie die Option nicht, komisch...

[[Image(screenshot-0000.png)]]

z.B. - das findest Du auch, wenn Du auf das "Bild-Symbol"
rechts in der Leiste unten clickst ;)
>
>> Vorschlag 3: Beim Posten des Links "https" gegen "http" austauschen,
>> dann brauchen sich die Leute beim Anschauen nicht einzuloggen ;)
> ...stimmt, hatte ich garnicht dran gedacht.

Wird uns allen noch 42.000 Mal passieren ;)

BTW: Für Committer empfehlen sich noch folgende Tags:
           #TICKETNUMMER in der Commit-Msg: erzeugt Verweis auf die
                     Ticketnummer
           rREVISION im Ticket: verweist auf die Revisionsnummer
                     des commit ;)

>>>
>>
>> Grüße,
>>
>>    rowue
>
> Gruß Michael

Grüße,

   rowue

ich kann den Text nicht mehr ändern!
Aber die Fotos mit gleichen Namen ersetzen, hängt sich aber unten
an...so'n Käse!
Das mit dem Imsge einsetzen habe ich jetzt gepeilt!
Am besten wäre das ganze Ticket zu löschen, dann kreiere ich ein
Neues!!!
Wer kann das Löschen, oder wer ist befugt???

Ich wart's mal ab, bevor das aussieht als wäre da was eingeschlagen...

Gruß Michael

Michael D. schrieb:
> ich kann den Text nicht mehr ändern!
> Aber die Fotos mit gleichen Namen ersetzen, hängt sich aber unten
> an...so'n Käse!
> Das mit dem Imsge einsetzen habe ich jetzt gepeilt!
> Am besten wäre das ganze Ticket zu löschen, dann kreiere ich ein
> Neues!!!
> Wer kann das Löschen, oder wer ist befugt???

Mach das neue Ticket fertig, dann setze ich das alte auf "close",
"duplicate" ;)
>
> Ich wart's mal ab, bevor das aussieht als wäre da was eingeschlagen...
>
> Gruß Michael


Grüße,

   rowue

Hallo Rainer,

Du hast warscheinlich die falsche Welec-Updater Version benutzt!
Melde dich mal hier an damit ich dir eine PN schicken kann, oder schick
mir eine, wie auch immer...

Gruß Michael

Die WelecUpdater Version 0.4.8A22 war schon ok. Das Backup hat damit
jetzt an einem PC mit echtem Com-Port prima geklappt. Der USB-Seriell
Wandler (mit Prolific Chip, Treiber V.2.0.2.1) war wohl bei 115kBd etwas
an seiner Grenze. Bei Screenshots mit dem W2000a-screenshot V0.91 sind
damit auch oft Macken drin.

Danke nochmal, Rainer

Michael D. schrieb:
> Ich hab's mal getestet, liegt definitiv an der FW.
> Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben!

Ich habe den Test auch noch mal auf meinem W2024A gemacht, d.h. Flanke
des ProbeComp-Signals mit FW 1.2.OS.0.91 (Build: Falk 10. Aug. 16:43,
RAM ) bzw. FW 1.2.OS.0.92 (Build: falk - 20091025, Flash), jeweils nach
"Default Setup" und Kalibierung (ADC, Zero, DAC) mit Norm-Trigger. Ich
sehe manchmal die gleichen Fehler, aber mir ist unklar unter welchen
Bedingungen sie auftreten. Eine Versionszuordnung sehe ich nicht so
klar.
(Graphiken sind für bessere Lesbarkeit nachbearbeitet)

Gruß, Rainer

Rainer W. schrieb:
> Michael D. schrieb:
>> Ich hab's mal getestet, liegt definitiv an der FW.
>> Linkes Foto ist die 092er, rechtes die 091er...kaum zu glauben!
>
> Ich habe den Test auch noch mal auf meinem W2024A gemacht, d.h. Flanke
> des ProbeComp-Signals mit FW 1.2.OS.0.91 (Build: Falk 10. Aug. 16:43,
> RAM ) bzw. FW 1.2.OS.0.92 (Build: falk - 20091025, Flash), jeweils nach
> "Default Setup" und Kalibierung (ADC, Zero, DAC) mit Norm-Trigger. Ich
> sehe manchmal die gleichen Fehler, aber mir ist unklar unter welchen
> Bedingungen sie auftreten. Eine Versionszuordnung sehe ich nicht so
> klar.
> (Graphiken sind für bessere Lesbarkeit nachbearbeitet)

Die Versionszuordnung dürfte dann klarer werden, wenn Du schaust,
ob der Fehler in der 0.91 überhaupt auftritt. Dies scheint nicht
der Fall zu sein. Das der Fehler in der 0.92a alternierend auftritt
ist hingegen eine sehr interessante Info. Wenn Du mal rausfindest,
wie Du das ein- und ausschalten kannst, wäre das eine interessante
Info für das Ticket-System ;)
>
> Gruß, Rainer


Grüße,

   rowue

Hallo Rolf,

ich kann mich entsinnen, das ich dasselbe Phänomen wie bei Rainer,
schonmal beobachtet hatte!
Es war allerdings nur ein einziges Mal aufgetreten (92er Ver.), das
beide Kanäle ( beim Rainer 4 Kanäle) schön gleich waren, da hatte ich
ein 27MHz. Rechteck-Signal gemessen!
Wie schon mehrmals beschrieben worden ist, tritt die Flankenferkelei, ja
erst bei 1GSa/s 100nSek. abwärts an !

Gruß Michael

Hallo,

Ich habe das problem nur auf kanal1 bemerkt und screenshots gemacht,
allerdings ist es nun nach einem default setup nichtmehr vorhanden...
Beide Kanäle sehen jetzt aus wie Kanal 2.
Nicht Reproduzierbar, bisher...
Kann eventuell starttemperatur mit reinspielen?

Was mir noch aufgefallen ist, ist das Linien verschwinden wenn man vom
XY betrieb zurück auf Main wechselt.
Wenn man Quickmeasur aufruft deutet die anzeige und die Cursor darauf
hin das diese allerdings nur unsichtbar sind.
Abhilfe Neustart oder Autoscale drücken.

Im 4. Bild sieht man artefakte im menue. Diese entstehen bei mir nur
wenn ich die settings im Math Menue aufrufe.

Aufgefallen ist mir auch das die gelbe "1" in der Tittelzeile neben dem
spannungsbereich verschwindet wenn man die 0 Linie von kanal1 nach unten
verscheibt.

Kleinigkeiten...

Hardware:8C7.0H
Software:0.92a

Gruß
Torsten

Hallo Torsten,

Torsten Otten schrieb:
> Hallo,
>
>
> Was mir noch aufgefallen ist, ist das Linien verschwinden wenn man vom
> XY betrieb zurück auf Main wechselt.
> Wenn man Quickmeasur aufruft deutet die anzeige und die Cursor darauf
> hin das diese allerdings nur unsichtbar sind.
> Abhilfe Neustart oder Autoscale drücken.
...einmal den Triggerknob vor u. wieder zurück betätigen, dann sind die
auch wieder da!
>
>
> Aufgefallen ist mir auch das die gelbe "1" in der Tittelzeile neben dem
> spannungsbereich verschwindet wenn man die 0 Linie von kanal1 nach unten
> verscheibt.
>
> Kleinigkeiten...

...wohl wahr!

> Hardware:8C7.0H
> Software:0.92a
>
> Gruß
> Torsten

Eine kurze Rückmeldung zum USB-Host:

Prinzipiell funktioniert er jetzt. Farb- und S/W-Screenshots können in
verschiedenen Dateiformaten (bmp, ppm, pbm) abgespeichert werden. Auch
die CSV Daten können verarbeitet werden.
Nur die raw-CSV Daten können nicht gespeichert werden weil sie in der
falschen Reihenfolge reinkommen. Evtl. fällt mir da noch eine Lösung
ein.

Zur Zeit kommen die screenshot Daten von einer PC Software weil sie in
2kByte Blöcken gesendet werden müssen und die Software nach jedem Block
auf eine Bestätigung vom µC warten muss.

Die Möglichkeit auf eine Bestätigung über RS-232 warten zu können ist
auf dem Oszi leider noch nicht gegeben und mir fehlt der Durchblick um
es selber zu realisieren.

Es wäre schön wenn einer der Firmware Profis sich daran versuchen
könnte. Z.B. für die CSV Daten:

for(i=0;i<16384;i++) //16k Samples
{
  for(j=0;j<4;j++)  //4 Kanäle
  {
      putchar(...); //sieht auf dem Oszi anderes aus
      outcount = outcount + 1;
      
      //Wenn 2kB übertragen wurden, auf Bestätigung vom PC/µC warten
      if(outcount == 2048)
      {
         while(ComRead(comport) != 'w'); //Warte auf Bestätigung 
         outcount=0;
      }
  }
}

Zu 1.: Dein Oszilloskop triggert nicht richtig. Deshalb steht das Signal
nicht stabil.

Zu 3.: Auto Mode heißt, dass nach einer gewissen zeit automatisch ein
Triggerimpuls ausgelöst wird, ob eine Flanke da war oder auch nicht
(Bild zappelt, wenn keine richtige Flanke da ist). Normal Mode wartet
bis eine gültige Flanke erkannt wurde. Was du suchst ist der
Single-Shot-Modus.

MfG
Marius

Hallo Chris
>Als Updater hab ich V0.4,8A22 genommen

nimm das Perl-Skript, das den Releases beiliegt. Das spart Nerven und
Zeit.

Die Anzeige der Cursor-Daten erhältst du wenn du zweimal auf Cursors
drückt. Dann müsste die Freequenz und so sichtbar werden.

Normal und Auto-Modus hast du richtig erklärt. Zumindest der
Normal-Modus funktioniert eigentlich ordentlich. FÜr den Auto-Modus gibt
es im nächsten Release Ersatz.. Wenn du darauf nicht warten möchtest,
musst du dir selber die aktuellen Dateien aus dem Sourceforge-Trunk
compilieren.


@Kurt,
ich kann mir dein Problem mal anschauen. Vielleicht schreibst du mir
eine PM, was du genau willst brauchst. Hab das noch nicht genau
verstanden.


Ich werde jetzt mal die Sourcen zwischen 0.91 und  0.92 durchforsten, ob
daa etwas auffällig wegen den Flanken ist. Bitte unbedingt an der Stelle
weiter testen, wann, wo, unterr welchen Umständen.

Gruß,
Stefan

Hallo Chris,

siehe hier:
Beitrag "Re: Wittig(Welec) W2022A Firmware sichern und Update durchfüren?"

...und im Dateianhang ein Log von einer FW-Einspielung!

Gruß Michael

Hallo Chris,

also wenn du ein Bild auf dem Schirm siehst sollte dein FPGA laufen und
damit auch dein Trigger soweit funktionieren ;-) Es gibt, schlagt mich,
wenn es anderst ist, da keine weitere Hardware dafür außer dem FPGA.

Erkläre doch mal was du wo misst und wie du genau auf welchem Kanal
triggerst, bei welchen Einstellungen, Triggerlevel, Firmware-Version
usw. Schalte mal den Modus um und wieder zurück, mach ein Default-Setup.

Also ich denke wirklich nicht, dass es ein Hardwarefehler ist.

Der USB Host funktioniert schon für CSV Daten. Ich muss noch ein paar
Tests machen und die restlichen screenshot Funktionen anpassen. Danach
werde ich ausführlicher berichten.

Hallo,
ich glaube ich habe eine möglichkeit gefunden das sporadische auftreten
der flanken zu reproduzieren.

1. Ich mache defaultsetup, gerät aus, nochmal defaultsetup. (nur so
reproduzierbar bei mir)

2. Internes Testsignal anhängen.

3. Ohne kalibrierung Autoscale. Das gerät geht in stopmodus und auf
normtrigger.

4. Stop/Run taste drücken, Zeitbasis auf 10ns ggf. Pretrigger
verstellen, und die zackigen flanken sind da.

Wenn ich vorher die Adc calibrierung mache tritt das Problem nicht auf.

Frage: Setzt defaultsetup wirklich alles zurück?

Gruß
Torsten

Hallo Torsten,
du mußt nach dem defaultsetup die Timebase verstellen, damit die
Anderungen geseichert werden.

Hallo Kurt,
gerade probiert, dann ist das problem auch ohne ausschalten
reproduzierbar.

Gruß
Torsten

Wenigstens etwas...

Du könntest mal eine ältere Firmware probieren, z.B. 0.91. Wenn der
Fehler dann noch auftritt könnte es an der Hardware liegen.

Hallo Kurt,
hab die 0.91 mal in den Ram geschoben und ein wenig getestet.
Die Zacken waren immer auf kanal1, hab sie auch nicht wegbekommen.
Die Zacken sahen aus wie bei der frisch eingespielten 0.92a.
Bei der 0.92a die ich zur zeit drauf habe kann ich die alte form der
zacken, wie hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
nichtmehr reproduzieren.
Ich habe die zacken auch entweder garnicht oder auf beiden Kanälen...

Sehr seltsam, der fehler sieht auf jedenfall nicht immer gleich aus...

Gruß
Torsten

Hast du mal Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware" durchgearbeitet?
Da gab es solche Probleme schonmal.

Was sagen die anderen dazu?

morn,

der Rainer (Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") hatte
dasselbe Prob. mit seinem 4 Kanal ! Bei der 092a Ver. war der 1. Kanal
ok, die Anderen nicht. Nach dem einspielen der 091er Ver. in das RAM,
hatte er dasselbe wie der Torsten beobachtet, also auch nur sporadisch!
Ansonsten tritt der Fehler bei mir (W2022)überhaupt nicht bei der 091er
auf, nur bei der 092a!
Weiter oben hat ja Rolf schon beschrieben, das es ein BUG in der 092a
ist(Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)") !!!
Also definitiv kein Hardwarefehler !!!

Ic würde sagen, wir warten ab, bis dieser BUG behoben ist und dann sehen
wir weiter!
Vielleicht hat ja Stefan oder Rolf schonmal eine Vorabversion, wo dieser
schon gefixt ist.

Gruß Michael