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

[Roberto (Gast)]

Hallo werte W20xxA Besitzer und Interessierte!

Da der Thread:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware"
Schon recht lange ist, habe ich den mal gesplittet!

Bitte hier weiterschreiben. Danke :-)
l.G. Roberto

[Jürgen (Gast)]

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

[Ingo M. (ingom)]

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

[alex008_ (Gast)]

Hallo!

Ingo, ich teile den Wunsch voll und ganz mit dir!

Was mir generell bei Open-Source-Projekten wie auch hier aufgefallen 
ist, dass sich die Entwicker, Promoter, Tester und Kunden generell nicht 
einig sind, was wo getan werden soll.

Leider wirkt eine Aufforderung sich auf ein Internet-Portal oder einen 
Entwicklungszweig zu einigen, genauso wie ein Aufschrei nach einem 
Wirtshaus- oder Diskowechsel von einem vollem Lokal mit guter Stimmung 
zu einem leeren Lokal, da es dort ein Freigetränk gibt. Solchen 
Aufschreien folgen meist nur wenige.

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. Auch wenn man diese Gründe vorweisen 
kann, ist ein scheitern möglich, da falls den Interessenten sein Weg zu 
aufwendig oder kompliziert ist. Zusätzlich müssen alle Kritikpunkte 
anderer ernst genommen und in der Regel behoben werden.

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.

Glücklicherweise verwenden fast alle Open-Source-Entwickler eine 
Subversionsverwaltung wie svn, bzr oder cvs. Das ist auch bitter nötig, 
da sonst ein absolutes Chaos mit dem Source-Code-Versionen herrscht, wer 
welchen Bug bei welcher Version korrigiert hat.
Es gibt viele Open-Source-Projekte, wo Verbesserungen von Personen aus 
der Angst, wieder alte Fehler einzubauen, ignoriert werden, falls diese 
nicht auf einen nachweislich aktuellen Softwarestand der 
Subversionsverwaltung gemacht wurden.

MfG
Alexander

[Kurt B. (kurt)]

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.

[Anonymer Poster (Gast)]

Die meisten profitieren ganz erheblich von der Arbeit, die die 
Entwickler, allen voran Hayo, leisten.

Wer dagegen zu bequem ist, sich bei sourceforge.net zu registrieren, 
darf meinetwegen gerne darauf verzichten, sich an Diskussionen zu 
beteiligen.

Auf die Beiträge von solchen, die nicht fähig sind, ein Pseudonym, eine 
email-adresse und ein Passwort einzutippen, kann man getrost verzichten.

Das mag hart klingen, aber ich spreche aus Erfahrung.

Und wer sich vor Spam fürchtet, soll sich doch einfach eine email bei 
GMX oder WEB einrichten. Das ist immer noch weniger Aufwand als zehn 
Zeilen Code zu schreiben.

Klaus

[Kurt B. (kurt)]

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.

[Bruno W. (brunowe)]

Hallo Kurt,

mir ist nicht ganz klar was du mit neues Thema genau meinst.
Hast du das gelesen:
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=7&t=31

(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/viewtopic.php?f=20&t=40

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

[Kurt B. (kurt)]

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/viewtopic.php?f=17&t=41

[Bruno W. (brunowe)]

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?

[Michael D. (mike0815)]

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/viewtopic.php?f=16&t=37

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Rolf W. (rowue)]

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/viewtopic.php?f=5&t=43

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

[Michael D. (mike0815)]

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

Gruß Michael

[Rolf W. (rowue)]

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

[Rolf W. (rowue)]

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

[Rolf W. (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

   [e-mail]

   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

[Michael D. (mike0815)]

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

[Michael D. (mike0815)]

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

Gruß Michael

[Default U. (shyguy)]

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

[Blue F. (blueflash)]

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

[Default U. (shyguy)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Default U. (shyguy)]

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

[Guido (Gast)]

Hallo Stefan,

beschreib das doch mal genau, dann kann man sich drum kümmern. In 
welchen
Timebaseeinstellungen geht der Trigger nicht? Mir ist da nichts 
aufgefallen.
Lass den Norm-Modus, der ist Anachronismus, in Auto bleibt nichts 
stehen.

Gruß, Guido

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

@Guido

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

Gruß Hayo

[Default U. (shyguy)]

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

[Michael H. (stronzo83)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

Mir geht es wie Hayo. Ich habe gerade eine Periode über den
gesamten Schirm und das wird sauber getriggert. Es hüpft halt
etwas hin und her, was an kleinen Differenzen beim Samplen
liegt.

Gruß, Guido

[Blue F. (blueflash)]

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

[Michael H. (stronzo83)]

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

[Michael H. (stronzo83)]

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

[Michael H. (stronzo83)]

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

[Default U. (shyguy)]

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

[Jürgen (Gast)]

Hallo Hayo,

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

bin eben zufällig auf die zwei TB gestoßen. Ist aber nicht gut 
reproduzierbar!?? Hatte wild auf Run/Stop und Single zu drücken und dazu 
die TB zu verstellen. Habe alles in ein Logfile kopiert.
Vielleicht sagen Dir die Werte etwas?

'1.2-OS-0.92 Alpha', W2024A, Ch1 95,000KHz Sinus mit ca 5V, NORMAL-Mode

Gruß Jürgen

[Default U. (shyguy)]

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

[Odic (Gast)]

Ihr sprecht mir aus der Seele!!!

Ich verwende fast ausschließlich den Normal-Modus und stolpere auch 
regelmäßig darüber, dass die Triggerung bei unterschiedlicher Zeitbasis 
bzw. bei unterschiedlicher Skalierung der Amplitude unterschiedlich gut 
funktioniert - oder eben auch nicht.

Beispielsweise betrachte ich bestimmte Bytes einer serieller 
Kommunikation:
Aufgrund der Baudrate benötige ich eine bestimmte Zeitbasis. Triggerung 
ist ok. Bei einer anderen Übertragung habe ich eine andere Baudrate und 
möchte daher eine andere Zeitbasis verwenden, und bekomme plötzlich kein 
Trigger-Event mehr. Signalamplitude und Triggerschwelle sind wohlgemerkt 
unverändert. Ähnliches konnte ich auch schon beobachten, wenn ich die 
Skalierung der Amplitude ändere.

Leider muss ich gestehen, mir nie genaue Notizen über die jeweiligen 
Einstellungen gemacht zu haben. Asche über mein Haupt... ;-)
Beobachten lässt sich das Verhalten bis einschließlich 0.96 HE.

Für mich persönlich bzw. meinen Verwendungszweck ist die Zuverlässigkeit 
der Triggerung das Grösste Manko des Gerätes.

Beste Grüße,
odic

[Michael H. (stronzo83)]

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

[Default U. (shyguy)]

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 ?

[Blue F. (blueflash)]

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

[Default U. (shyguy)]

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

[Guido (Gast)]

Hmmh,

ich habe jetzt mal mit einem 100-kHz-Rechteck probiert. Sollte
ja Ähnlichkeit mit I2C-Signalen haben. Das triggert in allen
Modi und bei allen relevanten Zeitbasen sauber.

Kannst du mal genauer angeben, was ich probieren sollte?

@ Hayo: Zumindest in diesen Bereichen wird im Delayed-Mode der
im 2. Fenster dargestellte Bereich mit den roten Linien wohl
nicht richtig dargestellt. Oder verstehe ich was falsch?

Gruß, Guido

[Default U. (shyguy)]

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.

[Michael H. (stronzo83)]

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

[Michael H. (stronzo83)]

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.

[Michael H. (stronzo83)]

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.

[Guido (Gast)]

O.k. Stefan,

aber das sind ja nichtperiodische Signale. Wie versuchst du die
zu triggern, bzw. wie machst du das mit einem anderen Oszi?

[Blue F. (blueflash)]

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

[Default U. (shyguy)]

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

[Guido (Gast)]

Hallo,

ich habe gerade mal mit NMEA-Daten mit 9600 Baud experimentiert.
Da muss man dann schon fix sein mit dem Stopp-Button, dann gehts.

Optimal geht das wohl mit dem PW-Trigger, aber da hat sich halt
noch niemand berufen gefühlt sich drum zu kümmern. Prinzipiell
geht es, aber es existieren nicht alle nötigen
Einstellmoglichkeiten (IMHO kein Zufall). In diesem Modus bekomme
ich aber auch Hänger in manchen Zeitbasiseinstellungen.

Ansonsten kann ich im Norm-Modus keine Verbesserung gegenüber dem
Auto-Modus feststellen, da lohnt sich keine Mühe.

Der Delay-Mode hat aber ganz schön gelitten :-(. Ich habe mit den
langsamen Einstellungen lange nicht mehr probiert, meine aber, dass
es schon schöner funktioniert hat.

Korrigiert mich wenn ich falsch liege: bei 10 ms/div werden 3276
Samples erfasst, also ca. 5 Bildschirme horizontal. Da müsste man
im Stopp-Mode doch dicke scrollen können?

Gruß, Guido

[Blue F. (blueflash)]

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

[Guido (Gast)]

@ Hayo: Guter Tip, das werde ich mal probieren.

Gruß, Guido

[Michael H. (stronzo83)]

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

[Stefan E. (stefan_e)]

@ Michael H.

Also ich sehe deine Posts...

[Guido (Gast)]

Hallo Michael H.,

auch ich sehe deine Posts, kann die aber nicht nachvollziehen.
Bei mir ist es nicht so, deshalb mal abwarten, ob sich andere
melden. Dann können wir vllt. eine Systematik erkennen.

Gruß, Guido

[Jürgen (Gast)]

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!
(Bitte nicht die deutsche Kurzanleitung nutzen, die ist in diesem Punkt 
nicht gut übersetzt, meine ich.)
Ist ja schliesslich vom Agilent-Schwesterscope fast komplett 
übernommen?!
Da haben wir doch schon ein perfektes Pflichtenheft!
Natürlich dürfen auch Erweiterungen eingebaut werden (FFT,serielle 
Protokollanalyse), wenn die gröbsten Bug's entfernt sind ;-)
Über die Grundfunktionalität müssen wir aber nicht immer wieder 
diskutieren.

Grüsse,
Jürgen

[Michael H. (stronzo83)]

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

[Blue F. (blueflash)]

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

[Stefan E. (stefan_e)]

>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 (Gast)]

Hayo schrieb:

>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

Aber sicher muss es diese Buffer geben!
Leider habe ich eben im Coding auf die Schnelle nicht die Stelle 
gefunden, wo Du die Adresse des Triggerereignisses im ausgelesenen 
Datenfeld bei der Anzeige auf dem Display zuordnest bzw. ermittelst? :-(
Zur Anzeige benötigst Du doch eben genau die Angabe über die Länge des 
Pretriggerbuffers. Alles was zeitlich vor der Triggermarker im Datenfeld 
liegt ist eben der Pretriggerbuffer und wird auf dem Display links vom 
Triggermarker dargestellt. Was danach übrig bleibt ist der 
Posttriggerbuffer.
Die Frage ist doch eher, wie diese Funktionalität in den vorhandenen 
Registern kodiert ist?

Gruß Jürgen

[Blue F. (blueflash)]

@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

[Marius W. (mw1987)]

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.

[Jürgen (Gast)]

@ Hayo

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

Na sach ich im Prinzip doch! :-)

"Alles was zeitlich vor der Triggermarker im Datenfeld ( = Buffer = 
16384 Byte ) liegt ist eben der Pretriggerbuffer und wird auf dem 
Display links vom Triggermarker dargestellt. Was danach übrig bleibt ist 
der
Posttriggerbuffer."

Und das entspricht genau den Darstellungen im Handbuch! Dort heisst 
dieser Gesamtbuffer Acquisitionmemory (page 3-2) . Es ist einfach eine 
Frage der Bezeichnungen.

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

Ich freue mich schon auf eine neue Version!

Gruß Jürgen

[Blue F. (blueflash)]

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

[Michael W. (slackman)]

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

[Blue F. (blueflash)]

@Jürgen

Sach ich doch! Idealisierte Darstellung ;-)

Hayo

[Blue F. (blueflash)]

@Michael

Default setup hast Du gemacht?

Hayo

[Michael W. (slackman)]

@ Hayo,

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

Michel

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

@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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

@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

[Michael D. (mike0815)]

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

[Jürgen (Gast)]

Hallo Marius Wensing,

hatte im Anfang auch mal solche Probleme. Hänge doch mal die Datei mit 
dem kompletten Dump hier an und ich schaue mal drüber. Vielleicht ist es 
das gleiche Problem, was ich hatte. Dann kann ich die Datei vielleicht 
reparieren und zurück senden.

Gruß Jürgen

[Michael D. (mike0815)]

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

[Marius W. (mw1987)]

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

[Michael D. (mike0815)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

Und noch meine 2 Cents:

Ich habe die Peaks gelegentlich auch, aber nach ca. 3 min
Warmlaufzeit verschwinden sie dann (W2012A).

Gruß, Guido

[Marius W. (mw1987)]

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

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

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

Falk

[branadic (Gast)]

Hallo zusammen,

ich bitte noch mal den Trigger etwas genauer unter die Lupe zu nehmen. 
Die exorbitanten Spikes kommen m.E. eindeutig daher.
Das lässt sich sehr schön mit dem einfachen Kalibriersignal testen. Man 
schalte auf 100ns/div und 200mV/div. Verschiebt man nun den Pretrigger 
hin und her, dann sieht man, dass am rechten Bildschirmrand immer eine 
Flanke nach oben bleibt, die aber nicht die nächste Signalflanke ist.
Möglicherweise ist hier ein allgemeines Triggerproblem vorhanden???

Gruß, branadic

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[branadic (Gast)]

Tag auch,

Timingprobleme möchte ich fast vollständig als Ursache ausschließen, 
dafür sind die Spikes zu systematisch. Auf dem Oszi selbst lässt sich 
das nicht erkennen, wohl aber mit dem entstehenden Programm FFTscreener 
von Bruno.
Hier werden die Daten eines Kanales via RS232 übertragen und auf dem 
Bildschirm vollständig dargestellt (natürlich kann das Programm noch 
einiges mehr und wird mehr können, aber das ist hier nicht Gegenstand 
der Diskussion). Jedenfalls kann man sehr schön erkennen, wie diese 
Spikes innerhalb des Signales systematisch an den gleichen Stellen immer 
und immer wieder auftauchen. Das kann kein Zufall sein. Es sei 
angemerkt, dass hier reine Rohdaten übertragen werden.

Beste Grüße, branadic

[Guido (Gast)]

Hallo branadic,

ist das denn auf allen Kanälen? Ich habe den Sommer über gar
keine Spikes bemerkt, jetzt muss ich wieder warmlaufen lassen.
Auf Kanal 1 sehe ich sie (auf dem eingebauten Bildschirm) nicht,
nur auf Kanal2.

Rohdaten sind es nicht mehr die übertragen werden. Es hat dann
wuhl schon Offsetkorrektur ... stattgefunden, die gleich nach
dem Auslesen des FIFOs durchgeführt werden.

Gruß, Guido

[Falk W. (dl3daz)]

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

[Stefan V. (svaudio)]

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

[Guido (Gast)]

Hallo Stefan V.,

häng doch mal ein Terminalprogramm an die ser. Schnittstelle
(115 kB, 8N1) und schau dir die Startmeldungen an. Dann solltest
du erkennen wo es hängt.

Gruß, Guido

[Stefan V. (svaudio)]

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

[Bruno W. (brunowe)]

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/viewtopic.php?f=20&t=40 
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

[Michael D. (Gast)]

hallo leute!
was ist das denn mit den vielen firmware versionen? welche macht was? 
was ist BF.0.97? 0.97 HE? SVN? 0.91 OS?????

bastelt da jeder seinen eigenen kram?

und dann sind da auch versionen mit leon und nios und zpu? aber die kann 
ich nicht benutzen.....

Michael

[alex008_ (Gast)]

Hallo,

ich entwickle das LEON3 HW-Design. Die Spikes in der original Software 
halte ich hauptsächlich für Setup-/Holdtime Verletzungen. Diese treten 
wahrscheinlich im WELEC-FPGA-Design bei den Datentransfers zwischen den 
zeitversetzten ADC-Takten auf.

http://nigamanth.net/vlsi/2007/09/13/setup-and-hold-times/

Dieser Fehler alleine rechtfertigt schon eine komplette Neuentwicklung 
des FPGA-Designs.

Zum Trigger möchte ich meine Neuentwicklung anführen.

Der Trigger des LEON3 Designs kann
         auf ein Sample genau triggern (auch bei 1GS/s),
         einen Glitch von einem Sample triggern (auch bei 1GS/s),
         PreTriggern unabhängig auf was getriggert wird,
         besitzt eine Hysteresekurve
und liegt hinter diskreten Tiefpass-Filtern, die es ermöglichen sollten 
auch auf verrauschte Signale zu triggern.

Bis das ganze aber Benutzertauglich ist, vergeht mindestens noch ein 
Jahr!
Ich freue mich natürlich über jede Hilfe (SW+HW)!

MfG
Alexander

[Falk W. (dl3daz)]

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

[Jörg H. (idc-dragon)]

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

[Mike B. (Gast)]

Hallo,

da ich mich berufsbedingt in den nächsten Monaten wieder mehr mit Matlab 
beschäftige, hab ich mir mal die neue PC-GUI von brunowe angesehen. 
Trotz installiertem Matlab hab ich mit der Windows-exe Version 
gearbeitet- gibts da auch ein M-File dazu? Optisch macht das echt schon 
einiges her. Allein die wesentlich bessere Farbdarstellung und 
Zoomingfunktion im Vgl. zum Scope rechtfertigen schon den Einsatz dieser 
SW. Ich bin wirklich gespannt was da noch an Features folgt!
Da ich oft Langzeitmessungen durchführe (Verhalten von elektr. 
Schaltungen im Betrieb bis zu 3Std) bin ich besonders froh die 
gemessenen Daten endlich vernünftig aufzeichnen und anschließend 
auswerten/ vergleichen zu können.
Bruno, ich bin so frei und schick dir mal ein paar Spezialwünsche zu, 
evtl. lässt sich ja das ein oder andere davon verwirklichen. Jetzt 
müsste nur noch das Scope etwas besser werden... (die alten FW- 
Versionen kenne ich nicht- ist vielleicht auch besser so?)
Nachdem was ich bisher so gelesen habe, ist die, auf das ursprüngliche 
NIOS1 aufbauende, FW ziemlich an ihre natürlichen Grenzen gelangt?!
Dennoch: Herzlichen Dank an alle AKTIVEN Entwickler.

Gruß, Mike

[Ingo M. (ingom)]

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 (Gast)]

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

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

Michael schrieb:
> Ist das Oszi eigentlich Fernsteuerbar?

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

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

[Stefan E. (stefan_e)]

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

[Falk W. (dl3daz)]

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 W. (dl3daz)]

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

[Falk W. (dl3daz)]

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

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

Falk

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

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

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

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

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

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

[Michael D. (mike0815)]

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?

[Falk W. (dl3daz)]

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

[branadic (Gast)]

Hallo Michael,

nicht verwechseln, das im SF ist die OS.091 von Falk und hier ist die 
BF0.97 von Hayo aktuell. Das sind mittlerweile leider zwei getrennte 
Entwicklungsbäume. Wenn du wissen willst wie es dazu gekommen ist, so 
ist das alles hier auf µC nachzulesen.

Das auf SF so wenig diskutiert wird liegt leider schlichtweg an der 
Sturheit einiger Leute. Wir sind den Deutschen Mitstreitern / Usern 
innerhalb einer eigentlich internationalen Entwicklung sogar soweit 
entgegen gekommen und haben eine deutschsprachige Diskussionsplattform 
eingerichtet. Von dem Ergebnis kannst du dich ja selbst überzeugen und 
dir dein Urteil bilden.

Vieles wird auch außerhalb des Forum diskutiert (Skype). Ich weiß nicht 
wie oft wir angeboten haben dazu zu stoßen. Einige ganz wenige haben den 
Sprung zu uns geschafft und diskutieren mit uns mit. Das geht auf einer 
Plattform wie Skype nun mal schlichtweg schneller, als irgendwo zu 
posten und dann ewig auf Antwort zu warten.
Von der Unübersichtlichkeit hier will ich nicht schon wieder anfangen.

Auf SF ist alles im Wiki sauber dokumentiert. Im Forum kann zumindest 
jeder mitlesen und die Übersichtlichkeit ist gewahrt.

Du siehst, wir haben aus unserer Sicht (BrunoWe, crazOr, Falk und ich) 
eigentlich alles getan, um die Entwicklergemeinde zu bündeln. Der 
absolute Erfolg war uns aber leider nicht gegönnt und deswegen sind die 
Infos so verstreut.

Gruß, branadic

[Kurt B. (kurt)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Odic (Gast)]

Guten Abend zusammen,

eigentlich habe ich mir ja fest vorgenommen, mich aus diesen 
Diskussionen rauszuhalten... aber ich fürchte, ich habe versagt. ;-)

Gestattet mir bitte eine einzige Frage:

Ich verstehe ja viel. Angefangen von unterschiedlichen Zielsetzungen bei 
der Entwicklung über verschiedene Präferenzen bei den verwendeten 
Werkzeugen bis hin zu persönlichen Differenzen. Daher bin ich der 
Letzte, der über zwei Entwicklungszweige den Kopf schüttelt. Ihr alle 
betreibt das Ganze als Hobby, und jeder soll schließlich nach seiner 
Fasson Spaß daran haben.

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

Ich denke, jeder hat genug Sinn für Realität um zu wissen, dass ihr die 
beiden Versionen entweder JETZT zusammenführt oder NIE. Die Unterschiede 
werden doch von Tag zu Tag größer. Versteht mich bitte nicht falsch. Ich 
möchte gar keine bestimmte Entscheidung herbeiführen. Aber ich würde es 
begrüssen, wenn es ÜBERHAUPT mal eine Entscheidung gäbe.

In diesem Sinne wünsche ich allen einen schönen Abend.

Beste Grüße,
odic

[Guido (Gast)]

Hallo,

jetzt muss ich doch mal wieder einiges klarstellen. Es macht einfach
keinen Sinn ein Forum gegen das Andere auspielen zu wollen, da jeder
Nutzer seine eigenen Interessen hat.

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. 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. Zeitweilig sind auch einfach die Ladezeiten von
SFN unakzeptabel.

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. Eine Menge Änderungen (ca. 273) wurden durchgeführt,
die wohl alle völlig ungetestet sind. Diese Version würde ich daher
als für die Weiterentwicklung ungeeignet betrachten und daher bevorzugen
eine neue Trunk-Version auf Basis von Hayos letztem Release zu 
erstellen.

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.

So erstmal, Guido

[Guido (Gast)]

@ Odic: Da haben wir uns ja gut getroffen (zeitlich): Nein, die 
Versionen
können wieder zusammengeführt werden. das macht halt viel Arbeit, aber
es gibt hierzu trotz SVN keine Mechanniken.

Gruß, Guido

[Bruno W. (brunowe)]

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/welecw2000a/pc/FFTscreener/

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

[Falk W. (dl3daz)]

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

[Falk W. (dl3daz)]

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.

[Guido (Gast)]

Hallo Falk,

keine Frage ist es jedesmal ein großer Aufwand mehrere Branches
in einen Release-Candidate zusammenzuführen. Es geht aber halt
nicht anders. Wer sagt uns, dass z.B. du nicht in nächster Zeit
aus beruflichen Gründen nicht mehr die Möglichkeit hast deine
Änderunegen zu pflegen? Sie müssen daher ausreichend getestet sein,
bevor du entscheidest sie in den neuen Trunk einzupflegen. Wie
schon gesagt (wenn auch mit Typo), gibt es hierfür halt keine
Automatismen.

@ brunowe: schon klar, schnattert da nur weiter ;-). Aber ab und
zu mal ein Posting darüber wäre halt nicht schlecht. Ich habe
schon erlebt, dass sich ein Entwickler ausgerechnet hier beschwert
hat, dass seine Arbeit nicht gewürdigt wird. Wenn ich sie nicht
kenne, kann ich sie nicht würdigen.

Grüße, Guido

[Jürgen (Gast)]

Hallo,
können die SF-Protegisten nicht mal auf die klaren und sachlichen 
Argumente von Guido und Odic eingehen, anstatt immer wieder die gleichen 
Dinge zu wiederholen?
Anfügen muß ich, daß Hayo zu Beginn eine klare Festlegung zu Änderungen 
in den Sourcen festgelegt hatte:
1. Änderungen werden von den Entwicklern gekennzeichnet ( eventuell auch 
mit Beginn und Ende )
2. Kommentare sind einzufügen
Wobei Kommentare für einen professionellen Entwickler eigentlich 
selbstverständlich sein sollten!! Leider fehlen die bei vielen 
Änderungen in der OS-Firmware. ( Dies betrifft ausdrücklich nicht die 
hervorragende Arbeit von Alexander!!)

Jürgen

[branadic (Gast)]

Hallo Guido,

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

Das kann und will ich so nicht stehen lassen oder glaubst du ernsthaft 
daran, dass sich das Wiki auf mysteriöse Art und Weise von allein 
gefüllt hat?

Ich kann mich nicht erinnern, dass du da einen einzigen Beitrag zu 
geleistet hast!

Das nicht jedes einzelne Wort während der Entwicklungsgespräche in Skype 
hier noch einmal wiedergegeben wird, weil das schlichtweg unsinnig ist, 
solltest auch du einsehen.
Und auch du bist einer der Sturköpfe, die sogar auf mehrfaches Bitten zu 
Skype oder IRC dazuzustoßen, um schneller Dinge besprechen zu können, 
nicht reagiert haben.
Von unserer Seite werden sämtliche neue Erkenntnisse für jeden im Wiki 
zugänglich gemacht. Darüber hinaus sind es die wenigen Leute aus Skype, 
die die Diskussion in SF-Board pflegen, sei es englisch- oder 
deutschsprachig.

Lass also bitte die Kirche im Dorf.

Gruß, branadic

[Falk W. (dl3daz)]

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/welecw2000a/fpga/nios/oss/trunk/src/display_t.cpp?r1=269&view=log

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/welecw2000a?view=rev&revision=172

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.

[Falk W. (dl3daz)]

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

[Holger M. (nezaya)]

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

[Falk W. (dl3daz)]

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)

[Michael D. (mike0815)]

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

[Falk W. (dl3daz)]

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/viewforum.php?f=14

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

[Michael D. (mike0815)]

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/viewforum.php?f=14
>
> 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 (Gast)]

Hallo Falk,

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

>Wann hat Hayo das "festgelegt"?

Er hat das in der ersten veröffentlichen Version 0.38 in der 
"readme.txt" so geschrieben und auch durchgehalten.

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

>Das macht Subverion automatisch beim Einchecken.

Du weisst genau, ich meine die Kommentare in den Sourcen!

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

Suche nach "//BF".  Da ganz in der Nähe stehen dann auch Kommentare ;-)

....

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

Sicher weniger als eine Meldung...?

>Nachtrag:
>Leute, beruhigt Euch mal wieder.

Das klingt wirklich gut!

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

Ich meine nach wie vor, daß das Problem sicher nicht der gute Wille ist!

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?

Gruß
Jürgen

Sorry, der Post ist viel zu lang!

[Rolf W. (rowue)]

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

[Falk W. (dl3daz)]

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

[Guido (Gast)]

Jepp Falk,

das Bild kannte ich auch schon ;-). Ich hoffe, dass damit das Thema
Rauschen endgültig erledigt ist, da die Änderungsvorschläge ja immer
kurioser wurden.

Gruß, Guido

[Michael H. (stronzo83)]

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

[Kurt B. (kurt)]

Nochmal die Frage direkt an Falk:

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

Mfg,
Kurt

[Falk W. (dl3daz)]

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

[Kurt B. (kurt)]

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.

[Falk W. (dl3daz)]

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

[Jürgen (Gast)]

Rolf schrieb:

>Solange die Änderungen nicht an gleich Stelle stattfinden
>sind Differenzen zwischen dem SVN-Repository und der lokalen
>Kopie i.A. kein Problem.
>..... wobei die verschiedenen Versionen noch auf der
>Platte liegen und im Source die entsprechenden Stellen gekennzeichnet
>sind.

Ok, danke Rolf, ich hab den Editor jetzt gefunden.

Gruß Jürgen

[Torsten W. (wirehead)]

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

Gruß
Torsten

[Odic (Gast)]

Hallo zusammen,

ich möchte mich an der Klärung irgendwelcher Schuldfragen nicht 
beteiligen, weil ich sie nicht für zielführend halte. Daher die 
folgenden Punkte bitte nur auf der Sachebene betrachten und bitte NICHT 
versuchen, zwischen den Zeilen zu lesen. DANKE.

@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? Ich möchte ungern Stunden darauf verwenden, den 
ganzen Thread noch einmal durchzugehen. ;-)
Danke.

@Guido:

Dass sich zwei beliebige ASCII-Dateien immer irgendwie mergen lassen, 
ist mir schon klar. Nur ab einem gewissen Umfang der Unterschiede muss 
man nicht nur über den Aufwand, sondern auch über die SINNHAFTIGKEIT 
einer solchen Zusammenführung sprechen. Ich habe wahrscheinlich schon 
Mann-Monate meiner Arbeitszeit darauf verwendet, irgendwelche 
uralt-Spezial-Versionen einer SW in einem bis dato besch... 
Variantenmanagement wieder in den aktuellen trunk zu integrieren bzw. 
branches sinnvoll aufzubauen. Es geht ja nicht nur um die textuelle 
Zusammenführung. Mit der Zeit ändert sich von der Zielsetzung der SW 
über Schnittstellen bis hin zu Laufzeiten so einiges, was beim Mergen 
erhebliches Kopfzerbrechen bereiten kann. Und über den Spaßfaktor 
solcher Unternehmungen brauchen wir gar nicht erst reden...

@all:

- Jemand hat angemerkt, dass es für neu hinzukommende sehr schwierig 
ist, einen Einstieg zu finden bzw. einen Überblick zu bekommen. Die 
gleiche Person, nämlich Holger, hat gleichzeitig angeboten, selbst Zeit 
und Energie einzusetzen, um diesen Zustand zu ändern. Ich persönlich 
finde das SUPER und würde mich darüber freuen, wenn er von den 
Hauptakteuren von SF auch das angefragte OK dazu bekommen würde.

- An die Autoren der OS-Version: Mich würde eure bisherige Erfahrung mit 
dem offenen System bzw. nähere Infos zu getroffenen Konventionen 
interessieren. Wie funktioniert die Abstimmung zwischen den aktiven 
Entwicklern bzgl. bearbeiteter Code-Teile/Funktionalitäten? Gibt es 
irgendwelche Vorgaben für Änderungen? (Coding-Konventionen und 
dergleichen) Wie sind künftig Releases geplant? (Welche Zustände der SW 
sind geplant? Gibt es irgendwelche Freezes, was funktionale Änderungen 
angeht? Gibt es irgendwelche Testphasen? Wer released bzw. wieviele 
unterschiedliche Leute tun/dürfen dies?) 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?

Beste Grüße,
Odic

[Falk W. (dl3daz)]

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

[branadic (Gast)]

Hallo Holger,

ich grübel die ganze Zeit auf was deine Bemühung hinauslaufen soll. Alle 
Info's finden sich doch im Wiki. Zugegebenermaßen auf Englisch, aber das 
bringt ein Projekt auf internationaler Ebene nun mal mit sich.
Wir wollen nicht vergessen, dass die ursprünglichen Schaltpläne aus 
Russland kamen.
Meine Befürchtung ist, dass es letztlich darauf hinauslaufen soll, dass 
alles auf Deutsch wiedergegeben werden soll, nur weil man der englischen 
Sprache nicht mächtig ist oder sich aus irgendeinem Grund weigert 
englisch zu sprechen/lesen.
Ganz davon ab lässt sich die Startseite von SF nicht einfach ändern, 
geht ja hier im µC auch nicht.

Wenn du dir die Arbeit unbedingt machen möchtest, dann schlag ich dir 
vor, dass alles zu schreiben und wir schieben es als pdf auf SF hoch und 
verlinken es dort.

Gruß, branadic

[Guido (Gast)]

Hallo,

@ odic: natürlich hast du prinzipiell recht, aber soweit ich es
überblicke sind wir vom Grenzpunkt noch entfernt. Sauberer Stil
ist es, nur Funktionen zu ändern und bis auf die Änderung der
Teilerfaktoren des Spannungsteilers wurde das imho bisher auch
eingehalten. Natürlich divergieren die Versionen immer mehr,
deshalb mein Aufruf Branches anzulegen. 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. Aber klar, das sind Anfangsprobleme,
die aber bitte nicht einfach ignoriert werden sollten.

@ branadic: Hallo nochmal, ich schätze deine Arbeit sehr wohl. Nur
bekomme ich halt davon nichts mit, weil dieses Forum
für diese Art der Freizeitbeschäftigung leider völlig ungeeignet
ist, oder so. Das Wiki ist gut für einen Neueinsteiger, der in
kurzer Zeit einen umfassenden Überblick erhalten möchte. Aber,
sorry, ich komme nicht auf die Idee, dieses regelmäßig durchzusehen,
ob sich etwas geändert hat. Deshalb die Bitte einfach einen kurzen
Post zu setzen (hier oder im SFN), nach dem Motto "habe im Wiki...".

Grüße, Guido

[Holger M. (nezaya)]

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

[Kurt B. (kurt)]

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

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

[Stefan E. (stefan_e)]

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.

[Falk W. (dl3daz)]

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

[Blue F. (blueflash)]

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

[Falk W. (dl3daz)]

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

[Stefan E. (stefan_e)]

@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 :-)

[Kurt B. (kurt)]

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?

[Falk W. (dl3daz)]

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

[Kurt B. (kurt)]

Und wo wird der Pfad eingetragen. Makefile oder Systemvariablen?

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

[Kurt B. (kurt)]

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 (Gast)]

Hallo Falk,

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.

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.

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

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

Gruß, Guido

[Rolf W. (rowue)]

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

[Falk W. (dl3daz)]

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

[Falk W. (dl3daz)]

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/RemoteControlAPI
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/OFWVariables ein.

Falk

[Guido (Gast)]

Hallo Falk und Rolf,

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.

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

Grüße, Guido

[Rolf W. (rowue)]

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

[Falk W. (dl3daz)]

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 (Gast)]

Hallo zusammen,

leider kann ich dir, Falk, deine Frage, ob ich mich an der 
Firmwareentwicklung beteiligen möchte, momentan nicht bearbeiten. 
Derzeit versuche ich in Erfahrung zu bringen wie ihr arbeitet, stelle 
mich aber anscheinend nicht sonderlich geschickt dabei an...

Entschuldigt, wenn meine Fragen / Anliegen bisher zu unklar formuliert 
waren. Versuchen wir's also mal von einer anderen (deutlicheren) Seite:

<Klartext>

Es ist nicht nötig, irgendwelche Links erneut zu posten. Ich kann sowohl 
lesen als auch Suchfunktionen benutzen. Ich habe auch nicht gefragt wie 
ihr kommuniziert, sondern wie die inhaltliche Abstimmung zwischen euch 
läuft bzw. wie ihr absehbare Schwierigkeiten handhabt.
Auch wollte ich nicht wissen welches Versionsverwaltungssystem ihr 
verwendet, sondern ob es eine klare Entscheidung zu den beiden aktuell 
existierenden Entwicklungszweigen gibt. (Danke an Hayo für die 
Stellungnahme in diesem Punkt.)
Auch habe ich keinen Bedarf, mich an emotionalen Auseinandersetzungen zu 
beteiligen, im Gegenteil: sie interessieren mich nicht im geringsten. 
Mein Bedarf gilt lediglich sachlichen Informationen, die ich hier aber 
bislang nicht bekommen habe.

Fazit:
Ich habe überhaupt keine Lust, in meiner Freizeit Energie in eine 
ziellose Rumcodiererei von Bastlern zu stecken, bei der aufgrund 
fehlender Abstimmung und andauernd hochkochender Emotionen Effizienz und 
Spaß auf der Strecke bleiben. Wenn meine Fragen also als unerwünschte 
Einmischung empfunden werden, dann sagt es bitte. Das spart mir und euch 
viel Zeit, für die wir bestimmt alle eine wesentlich sinnvollere 
Verwendung finden.

Aber:
Wenn ich hingegen erfahrene und professionell arbeitende Entwickler 
dabei unterstützen kann, aus dem Scope das bestmögliche herauszuholen, 
sieht die Welt ganz anders aus. In dem Fall wäre ich für Antworten auf 
meine Fragen dankbar.

</Klartext>

Ich hoffe, dass mein Anliegen nun etwas greifbarer geworden ist. 
Vielleicht finden wir ja doch noch einen gemeinsamen Nenner - ich 
jedenfalls würde mich freuen.

Einstweil allen einen schönen Abend.

Beste Grüße,
Odic

[Jörg H. (idc-dragon)]

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

[Guido (Gast)]

Hallo Odic,

mach ruhig mit. :-)

Es ist einfach im Moment ein Umbruch im Gange und ich, wie andere
versuchen das irgendwie in den Griff zu bekommen. Zunächst hat
Hayo allein den Sourcecode aufbereitet und weiterentwickelt.
Ein paar Leute (wie ich) haben ihn so gut es ging dabei
unterstützt und ihre Änderungen am Code an ihn weitergegeben,
woraufhin er ihn eingebaut oder verworfen hat. Ich hatte nie
ein Problem damit, bin aber auch kein Programmierer und habe auch
nie C++ gelernt.

Mittlerweile sind einige, offensichtlich kompetente, Entwickler
dazugekommen, die ihre eigenen Ideen und den zugehörigen Code
einbringen möchten.

Dementsprechend müssen wir eine Form finden, in der das möglich
ist und dieser Prozess läuft gerade. Alle Teilnehmer sind aber
IMHO vernunftbegabte Wesen und legen keinen großen Wert auf
Flaming. wenn meine Postings so empfunden werden, dann sorry,
ich bin seit über 15 Jahren im INet unterwegs und das ist für
mich normaler Stil in diesem Umfeld.

Frag ruhig weiter, Guido

[Rolf W. (rowue)]

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

[Falk W. (dl3daz)]

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

[Rolf W. (rowue)]

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

[Kurt B. (kurt)]

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

[Falk W. (dl3daz)]

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

[Michael H. (stronzo83)]

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

[Michael H. (stronzo83)]

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

[Falk W. (dl3daz)]

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

[alex008_ (Gast)]

Ich habe mich kaum mit der originalen Software beschäftigt, konnte aber 
so aus den Beiträgen herauslesen, dass die Triggerung in Kombination von 
Software und Hardware geschieht und das Pretrigger nur für den 
dargestellten Bereich existiert, und somit kein HW Pretrigger ist.

In der Signaldatenerfassung müssen pro 125-MHz-Takt 8 Werte gleichzeitig 
oder vielleicht auch Phasenverschoben im internen FPGA-Ram abgespeichert 
werden. Dies bedeutet, falls der Trigger Bugs hat (einige Messdaten 
werden am Begin oder Ende überschrieben oder nicht aufgezeichnet), dass 
deren Probleme mit einem kleinsten Intervall von 8 Werten auftreten.


MfG
Alexander

[Rolf W. (rowue)]

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

[Michael D. (mike0815)]

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

Gruß Michael

[Michael D. (mike0815)]

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

Gruß Michael

[Falk W. (dl3daz)]

Ja

[Stefan E. (stefan_e)]

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

[Falk W. (dl3daz)]

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

[Stefan E. (stefan_e)]

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.

[Falk W. (dl3daz)]

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

[Stefan E. (stefan_e)]

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

[Rolf W. (rowue)]

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

[Rolf W. (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

[Michael D. (mike0815)]

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

[Stefan E. (stefan_e)]

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.

[Michael D. (mike0815)]

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

[Stefan E. (stefan_e)]

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.

[Rolf W. (rowue)]

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

[Rolf W. (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

[Stefan E. (stefan_e)]

Hallo Rolf,

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

[Falk W. (dl3daz)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Stefan E. (stefan_e)]

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.

[Michael H. (stronzo83)]

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

[Stefan E. (stefan_e)]

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.

[Falk W. (dl3daz)]

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

[Stefan E. (stefan_e)]

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

[Michael D. (mike0815)]

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

Gruß Michael

[Stefan E. (stefan_e)]

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

[Rolf W. (rowue)]

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

[Guido (Gast)]

Hallo rowue,

sehe ich das richtig, dass die Störung nur auf dem 2. Kanal
sichtbar ist? Da kann ich fast nicht glauben, dass es an der
Firmware liegt. 5-MHz-Dreieck, mein Funktionsgenerator geht
nur bis 2 MHz. Werde aber morgen mal probieren.

Gruß, Guido

[Michael D. (mike0815)]

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

[Stefan E. (stefan_e)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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?

[Michael D. (mike0815)]

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

[Michael H. (stronzo83)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Rolf W. (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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

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

[Rainer W. (Gast)]

Hallo,

nachdem ich die tollen Fortschritte bei der Firmware nun schon eine 
Weile mitlese, wollte ich meinen W2024A endlich updaten, bin aber gleich 
beim Backup gescheitert. Ziel: Backup mit WelecUpdater.exe über 
USB-Seriell Wandler. Vorweg: Ich würde ungern nur deswegen auf Verdacht 
100 MB Perl installieren und einen echten Com-Port hat mein PC leider 
auch nicht.

Nach dem Lesen vom SF-Wiki und vergeblicher Suche bei 
http://sourceforge.net/projects/welecw2000a/files/ unter PC-Software, 
habe ich unter http://groups.google.com/group/welec-dso/files die 
Version 0.4.8A22 für WinXP gefunden. Der Download damit ist ziemlich 
kläglich gescheitert, weil es zu Übertragungsfehlern kommt und er dann 
mit "Reinitalisierung ..." hängt (siehe angehängtes Debug-Log, Ads in 
Statuszeile läuft nicht weiter). Es sieht so aus, als ob der Handshake 
und das nochmalige Abrufen von Speicherblöcken nicht funktioniert. Gibt 
es da eine aktuellere Version?

Nächste Frage: Welches sind die relevanten Speicherbereiche, wenn ich 
nicht stundenlang auf den ganzen Bereich 00040000-007FFFFF warten 
möchte. Für die Gerätefunktion/-kalibrierung sind doch mindestens die 
ganzen Signale (0x00100000-0x005FFFFF) und wohl auch 
0x00600000-0x006BFFFF nicht weiter relevant, oder? Für Nicht-Insider 
wäre die Info hierzu im SF-Wiki unter Backup ganz prima.

Danke für jeden Tipp.
Gruß, Rainer

[Michael D. (mike0815)]

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

[Rainer W. (rawi)]

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

[Rainer W. (rawi)]

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

[Rolf W. (rowue)]

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

[Michael D. (mike0815)]

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

[Torsten W. (wirehead)]

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

[Michael D. (mike0815)]

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

[Chris (Gast)]

Wie sieht son Firmwaredownload eigentlich aus? Muss der während des 
ganzen Vorgangs die Daten sichtbar durchlaufen lassen? Bei mir ists so 
dass sie am Anfang laufen und dann nach mehr oder weniger Zeit stehn 
bleiben. Die Uhr läuft noch weiter, zuerst noch rückwärts und irgendwann 
wird die Zeit wieder mehr. Ne Meldung kommt auch nach 2 Stunden noch 
nicht. Getestet hab ichs auf 2 verschiedenen Rechnern, bei beiden ist XP 
drauf mit nem richtigen COM Port.

Als Updater hab ich V0.4,8A22 genommen

[Kurt B. (kurt)]

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

[Chris (Gast)]

Jetzt hats bei mir doch funktioniert mit der Sicherungskopie und dem 
Updaten der neuen Software. Aber son Paar Fragen sind noch offen:

- Ich habe als Testsignal ein PWM mit 5V Amplitude, etwa 5kHz und 25% 
Pulsweite. Warum zappelt das Signal laufend und steht nicht stabil?

- Früher war auf der rechten Seite mal ein Menü wo man z.B. Werte 
ablesen konnte wie Deltas zwischen Cursoren oder so, jetzt geht das 
Oszillogramm über den ganzen Schirm. Wo krieg ich jetzt das Menü wieder 
her?

- Zum Mode: Sollte es nicht so sein dass im Normal Mode das Bild nach 
einem einzelnen Triggerpuls stehen bleibt wenn weitere Triggerpulse 
ausbleiben, während im Auto Mode das Bild laufend aktualisiert wird? 
Oder wars andersrum? Bei mir ists auf jeden Fall so dass egal was ich 
einstelle das Signal nie stehenbleibt, was ich ziemlich unpraktisch 
finde, wie soll ich denn da Schaltverhalten ansehen?

[Marius W. (mw1987)]

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

[Stefan E. (stefan_e)]

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

[Michael D. (mike0815)]

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

[Chris (Gast)]

Vielen Dank für all die Erklärungen.

Dass das mit dem Normal Mode nicht richtig funktioniert in der aktuellen 
Version ist ja kein Problem, dachte nur dass ich vielleicht was falsch 
mache oder falsch verstanden habe.

Wenn aber nach euren Aussagen der Normal Mode funktionieren sollte, bei 
mir das Bild aber nicht stehen bleibt, dann befürchte ich fast dass ich 
eine defekte Hardware habe. Bei der Original Software war das schon 
genau das gleiche Problem.

Wie ists mit dem Trigger? Gibts da noch Probleme mit der Software dass 
er nicht alle erkennt? Wenn ich ein PWM Signal mit konstanter Frequenz 
habe springt es immer mal wieder, d.h. der Triggerzeitpunkt wird 
scheinbar wo anders erkannt. Wenn ihr mir bestätigen könnt dass das kein 
Softwarefehler ist, dann wäre das ein weiteres Indiz dafür dass in der 
Triggerung ein Hardwaredefekt vorliegt, das würde auch erklären dass 
beim Normal Mode nie das Bild stehen bleibt. Noch hätte ich Garantie...

[Chris (Gast)]

Ahso, nochwas: Ist auch sowas wie ein Force Trig angedacht? Das fehlt 
mir oft sehr.

[Stefan E. (stefan_e)]

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.

[Guido (Gast)]

Hallo Chris,

zuverlässiges Triggern geht meist besser, wenn du den Triggerpegel sehr
hoch drehst. Knapp unter die eingeschaltete Spannung. Auch die sonstigen
Triggereinstellungen solltest du überprüfen.

Was ist ein "Force-Trigger"?

@ Stefan E.: Ich bin mir mit der Hardware nicht so sicher. Vielleicht
hat das schon jemand rausgefunden? Es gibt ja die Extraschaltung zur
Triggerung mit Video-Lineseparator usw. Hätte ich die Schaltung
entworfen, hätte ich nur den Eingang dieser Schaltung auf alle (max.)
5 Eingänge umschaltbar gemacht. Ich weiß aber bisher nicht, ob es
so realisiert ist.

Gruß, Guido

[Chris (Gast)]

Ich messe ein PWM Signal mit etwa 5kHz Frequnz, 5V Amplitude und 
verschiedenen Tastverhältnissen (zum Zeitpunkt der Messung natürlich ein 
konstantes Tastverhältnis). Das Signal generiere ich mit einem ATtiny13. 
Dass der Trigger besser funktioniert wenn man höher dreht hab ich auch 
schon festgestellt, aber dadurch kann ich das Problem nicht beseitigen. 
Angeschlossen ist das Signal auf Ch1, Ch2 ist aus.

Ich benutze 1.2-OS-0.92a auf einem W2012A.

Ob ich auf steigende oder fallende Flanke triggere ändert nichts am 
zappeln. Soweit ich das sehe ists auch nicht so dass das Gerät wenn es 
zappelt mal zwischen steigender und fallender Flanke nicht unterscheiden 
kann, sondern triggert an ner stelle wo das Signal auf Null ist.

Default Setup ändert auch nichts.

Force Trigger kann man im Normal Mode benutzen wenn nichts angezeigt 
wird und grad keine Triggerbedingung kommt. Durch Drücken von Force Trig 
löst er einen Triggervorgang manuell aus. Das kann man gut nutzen um zu 
sehen was das Signal gerade treibt, z.b. ob es low oder high ist oder 
völlig außerhalb des eingestellten Messbereichs. Wenn man beim Welec auf 
dem Stop Modus ist kann man sowas ähnliches mit Druck auf Single 
auslösen. Wobei da aber auch schon wieder die Frage ist: was sollte das 
Gerät eigentlich machen? Nichts bis ein Triggerimpuls kommt und nach 
diesem einen Puls anzeigen und stehen lassen? Oder ist das wirklich die 
Auslösung einen Triggerimpulses in dem Moment wo ich auf den Knopf 
drücke?

[Kurt B. (kurt)]

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.

[Torsten W. (wirehead)]

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

[Kurt B. (kurt)]

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

[Torsten W. (wirehead)]

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

Gruß
Torsten

[Kurt B. (kurt)]

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.

[Torsten W. (wirehead)]

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

[Kurt B. (kurt)]

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

Was sagen die anderen dazu?

[Michael D. (mike0815)]

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

[Rolf W. (rowue)]

Moin ;)

nach dem kleinen Wink mit dem berühmten Zaunpfahl habe ich mich
dann mal hingesetzt und die Zeit wo ich hier noch das W2022A habe
ausgenutzt: 
http://sourceforge.net/apps/trac/welecw2000a/ticket/45#comment:3

Wer die Version testen möchte: Flash- und Ram-Version anbei. Wie sieht
das eigentlich aus: Kann man sich als normaler Nutzer beim 
Trac/Sourceforge
auf ein Ticket "CCen" (also gibt es da (unten) ein Feld mit CC, wo 
mensch
sich eintragen kann)? - Damit bekommt man alle Staus-Meldungen zum
Ticket mit.

Es wäre mir lieb, wenn jmd. anderes die Version (am besten flashen
und Kaltstart) mal testen kann, dann kann ich die Änderungen
comitten und das Ticket schliessen.

Grüße,

   rowue

PS: Screenshot: 5MHz Dreieck

[Stefan E. (stefan_e)]

Hallo rowue,

habe gerade mal angefangen, den Fehler mit der Verzerrung zu suchen. 
Problem bei mir ist, dass die Verzerrung bei der .91er (r244) auftritt 
und bei der .92er (r245) alles OK ist.

Ich werde mal deine Flash testen.

[Stefan E. (stefan_e)]

@rowue

Nach deiner Änderung bring ich jetzt die Verzerrungen (nur Kanal 1) 
nicht mehr weg ;-) Davor hats gepasst g

[Michael D. (mike0815)]

Hallo Rolf,
das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft, 
dachte ich...

Was eine Reaktion, ich bin beeindruckt und werde es gleich mal testen!
Ist sonst noch was geändert worden, was du (mit meinen bescheidenen 
Mitteln) getestet haben möchtest?

Oh man, ich wollte doch noch das Ticket #46 
(Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett?

Gruß Michael

[Rainer W. (rawi)]

Rolf W. schrieb:
> 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 ;)
> Grüße,
>
>    rowue

Unter FW OS-0.92 sind die 250 MHz Störungen auf der Flanke 
reproduzierbar an- und abschaltbar. Die gleiche Bedienungssequenz führt 
bei der FW OS-0.91 nie zu Störungen.

@Michael D.: Du hattest Recht

Ich habe das mal als Ticket eingetragen
http://sourceforge.net/apps/trac/welecw2000a/ticket/49

Was mir auch noch in der 0.92 (Build stefan 20091030) aufgefallen ist: 
"Autotrigger" endet (oft) im Stop-Zustand, aber mit grüner 
"Run/Stop"-Taste und wenn die Störungen da sind, muß ich unrealistisch 
hohe Pretrigger-Werte einstellen, damit ich die triggernde Flanke zu 
sehen bekomme.

Gruß Rainer

[Rolf W. (rowue)]

Stefan E. schrieb:
> @rowue
>
> Nach deiner Änderung bring ich jetzt die Verzerrungen (nur Kanal 1)
> nicht mehr weg ;-) Davor hats gepasst *g*

Hi Stefan ...

ich beim Test so vorgegangen, dass ich erstmal mit der 0.91
geflasht habe, Kaltstart, flashen mit der 0.92a-test, Kaltstart
und dann geschaut habe ..

Weisst Du noch aus dem Kopf, ob der Fehler bei der alten
0.91 auftauchte (kannst Du auch von SVN ziehen) - könnte
sonst evtl. ein Einspielen Deines alten Backup von der Orginal-FW
eine Option sein? Hayo hatte am Start-Up-Code was geändert
und einige Werte "festgenagelt". Allerdings unterscheiden sich
die Werte aus dem "Protected" von den eingestellten.

Grüße,

   rowue

[Rolf W. (rowue)]

Rainer W. schrieb:
> Rolf W. schrieb:
>> 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 ;)
>> Grüße,
>>
>>    rowue
>
> Unter FW OS-0.92 sind die 250 MHz Störungen auf der Flanke
> reproduzierbar an- und abschaltbar. Die gleiche Bedienungssequenz führt
> bei der FW OS-0.91 nie zu Störungen.
>
> @Michael D.: Du hattest Recht
>
> Ich habe das mal als Ticket eingetragen
> http://sourceforge.net/apps/trac/welecw2000a/ticket/49

Danke für das schöne Ticket!
Der Fehler tritt btw. bei mir mit beiden Geräten auf. Ich würde
diesen Fehler im Autoscale suchen.

>
> [Trigger]
>
> Gruß Rainer

Grüße,

   rowue

[Stefan E. (stefan_e)]

Hallo Rainer/Michael,

#49 funktioniert bei mir auch. Es scheint, also ob durch den Aufruf von 
Autoscale und die damit verbundenen Registerwechsel der FPGA verstellt 
wird.

Hallo rowue,
ja mit dem Einspielen der "original" FW (ich habe nur noch die von 
brunow) hat sich der Fehler bisher immer beseitigen lassen.

Dann kommt eine neue FW drauf und irgendwann verstellen sich die 
Register so, dass das Signal verzerrt ist.

Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im 
laufenden Betrieb zu ändern.

[Rolf W. (rowue)]

Stefan E. schrieb:
> Hallo Rainer/Michael,
>
> #49 funktioniert bei mir auch. Es scheint, also ob durch den Aufruf von
> Autoscale und die damit verbundenen Registerwechsel der FPGA verstellt
> wird.
>
> Hallo rowue,
> ja mit dem Einspielen der "original" FW (ich habe nur noch die von
> brunow) hat sich der Fehler bisher immer beseitigen lassen.
>
> Dann kommt eine neue FW drauf und irgendwann verstellen sich die
> Register so, dass das Signal verzerrt ist.
>
> Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im
> laufenden Betrieb zu ändern.

setvars.pl aus dem Trunk (misc-tools) kennst Du?

[Rainer W. (rawi)]

Hallo Rolf,

ich habe gerade deine ram raufgespielt (build rowue - 20091116 aus
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)")

Bei mir auf dem W2024A sind damit die Flankenstörungen definitiv noch 
da.
Hast du meine Sequenz zum Reproduzieren des Störungen-Modus mal 
probiert?

Rolf W. schrieb:
> Es wäre mir lieb, wenn jmd. anderes die Version (am besten flashen
> und Kaltstart) mal testen kann, dann kann ich die Änderungen
> comitten und das Ticket schliessen.
>
> PS: Screenshot: 5MHz Dreieck

Gruß Rainer

[Rolf W. (rowue)]

Rainer W. schrieb:
> Hallo Rolf,
>
> ich habe gerade deine ram raufgespielt (build rowue - 20091116 aus
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)")
>
> Bei mir auf dem W2024A sind damit die Flankenstörungen definitiv noch
> da.
> Hast du meine Sequenz zum Reproduzieren des Störungen-Modus mal
> probiert?
>

Ja, der (#49) Fehler lag woanders ....

es fehlten im Autoscale die Zeilen:

    triggering_bak = triggering;
    ctrl_reg_bak = ctrl_reg;
    adc_ctrl_reg_bak = adc_ctrl_reg;

die irgendwann wohl den Weg des Zeitlichen gefunden haben müssen.
Leider werden die Register nach dem Autoscale mit den Werten aus
den [c]_bak[/b] geladen - und da kann es durchaus interessante
Effekte geben.

Gerade im trunk gefixt.

> Rolf W. schrieb:
>> [...]
>>
>> PS: Screenshot: 5MHz Dreieck
>
> Gruß Rainer

Grüße,

    rowue

@Rainer: prüfst Du mal Deine Hardware-Version - das waren hier
zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L)
und einmal der Autoscale (#49).
PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;)

[Rolf W. (rowue)]

Rolf W. schrieb:
> Rainer W. schrieb:
>> [...]
> PS: Hier der Flash

[Rolf W. (rowue)]

Michael D. schrieb:
> Hallo Rolf,

Hi Michael,

> das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft,
> dachte ich...

Du Socke ;) - rate mal, weshalb ich das Ticket-System des Trac
bevorzuge ;)
>
> Was eine Reaktion, ich bin beeindruckt und werde es gleich mal testen!
> Ist sonst noch was geändert worden, was du (mit meinen bescheidenen
> Mitteln) getestet haben möchtest?

Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der
Fehler bei Dir auch weg ist, dann committe ich das schon mal
und vielleicht finden wir dann (irgendwann) das Problem, was
Stefan hat.
>
> Oh man, ich wollte doch noch das Ticket #46
> (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett?
>

5 ;)

> Gruß Michael

Grüße,

   rowue

[Rainer W. (rawi)]

Rolf W. schrieb:
> [...]
> @Rainer: prüfst Du mal Deine Hardware-Version - das waren hier
> zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L)
> und einmal der Autoscale (#49).
> PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;)

Mein W2024A hat die HW 1C9.0L

Rainer

[Rolf W. (rowue)]

Stefan E. schrieb:
> Hallo Rainer/Michael,
>
> [Autoscale]
>
> Hallo rowue,
> ja mit dem Einspielen der "original" FW (ich habe nur noch die von
> brunow) hat sich der Fehler bisher immer beseitigen lassen.
>
> Dann kommt eine neue FW drauf und irgendwann verstellen sich die
> Register so, dass das Signal verzerrt ist.
>
> Ich versuch mal, meine Originalregistereinstellungen zu dumpen und im
> laufenden Betrieb zu ändern.

Also ich kann mir vorstellen, dass es da im Source noch
einige Spielereien a'la #49 gibt - und die zerlegen Dir
irgendwann die Register (branadic hatte da ja auch schon
"Spass" ;)

Im trunk sind in "flash_t.cpp" einige Zeilen auskommentiert,
die Dir die Inhalte aus dem Protected auf die Serielle dumpen.

adc_change12_reg:
                OrginalFW: 0x2020800
                Falk     : 0x20000
                Hayo:    : 0x1000000

chan_adr_add:
                Protected: 0x570a
                Hayo     : 0x5f0a

chan_adr_add2:
                Protected: 0x5f5f
                Hayo     : 0x0000 /* not used */

Die Zeilen sind ~2516ff, wenn Du möchtest, kannst Du Dir auch noch das
diff aus dem Ticket ziehen und Deinen trunk damit patche (dann werden
wieder die Werte aus dem Flash genommen und nicht die genagelten)

Grüße,

    rowue

[Rolf W. (rowue)]

Rainer W. schrieb:
> Rolf W. schrieb:
>> [...]
>> @Rainer: prüfst Du mal Deine Hardware-Version - das waren hier
>> zwei Fehler: einmal ein falscher Umgang mit der Hardware (#45, .0L)
>> und einmal der Autoscale (#49).
>> PS: Willst Du 'nen Flash "mit den Eiern oben drauf"? ;)
>
> Mein W2024A hat die HW 1C9.0L

Interessantes Gerät ;)

probier mal das Flash aus:

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

das sollte Deinem Problem abhelfen ;)

>
> Rainer

Grüße,

    rowue

[Michael D. (mike0815)]

Rolf W. schrieb:
> Michael D. schrieb:
>> Hallo Rolf,
>
> Hi Michael,
>
>> das war fies, gelle? Aber nicht so gemeint! Bevor das hier überläuft,
>> dachte ich...
>
> Du Socke ;) "ICH HABE GERADE KEINE AN"- rate mal, weshalb ich das Ticket-System 
des Trac
> bevorzuge ;)
>>
...ich kann'S mir vorstellen...

> Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der
> Fehler bei Dir auch weg ist, dann committe ich das schon mal
...der Fehler is'wech (freu)
Habe auch beim 'switschern' auf 'AUTOSCALE' keine Treppen mehr auf Kanal 
2, außer das Gezappel im Automodus (Triggerlevel keine Wirkung)!
Aber das war ja voher schon so! 'RUN/STOP dann SINGLE-Shot, PRE-Triggern 
bis Flanke da ist...

> und vielleicht finden wir dann (irgendwann) das Problem, was
> Stefan hat.
Er hat eine andere HW-Version als ich!
Ich habe (W2022) die besagte 8C7.0L

>>
>> Oh man, ich wollte doch noch das Ticket #46
>> (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett?
>>
>
> 5 ;)
hmpf...danke schön.
>> Gruß Michael
>
> Grüße,
>
>    rowue
Gruß Michael

PS. Was hier los ist?!?

[Rolf W. (rowue)]

Michael D. schrieb:
> Rolf W. schrieb:
>> Michael D. schrieb:
>>> Hallo Rolf,
>>
>> Hi Michael,
>>
>>> [Trac und µPC]
>>>
> ...ich kann'S mir vorstellen...
>
>> Generell nur das. Eins nach dem anderen - wenn Du sagst, dass der
>> Fehler bei Dir auch weg ist, dann committe ich das schon mal
> ...der Fehler is'wech (freu)

O.K. - habe den patch jetzt committet und das Ticket dicht gemacht ;)

> [...]
>
>> und vielleicht finden wir dann (irgendwann) das Problem, was
>> Stefan hat.
> Er hat eine andere HW-Version als ich!
> Ich habe (W2022) die besagte 8C7.0L

Also nach
http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument

würde ich davon ausgehen, dass Stefan auch ein .0L hat.

>
>>>
>>> Oh man, ich wollte doch noch das Ticket #46
>>> (Zeroline-Correction)bearbeiten, voll verpeilt, wer war denn da so nett?
>>>
>>
>> 5 ;)
> hmpf...danke schön.

Letzter Stand war, dass Du evtl. ein neues Ticket wg. englischem
Text machen wolltest - anyway - wenn ich mit #44 "durch" bin, setze
ich mich daran - ich hab's ja auch "verbockt" (und kenne nur zwei
Punkte, an denen es liegen kann ;)

>>> Gruß Michael
>>
>> Grüße,
>>
>>    rowue
> Gruß Michael
>
> PS. Was hier los ist?!?

Postschweinegrippe/-erkältungswelle ;)


Grüße,

   rowue

[Rainer W. (rawi)]

Rolf W. schrieb:
> probier mal das Flash aus:
>
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
>
> das sollte Deinem Problem abhelfen ;)

S U P E R - damit sehen bei mir die Signal jetzt immer "sauber" aus.

Was noch da ist, ist nach dem "Autoscale" der (meist) gestoppte Zustand 
mit grüner "Run/Stop" Taste und der merkwürdige Pretrigger-Wert.

Gruß Rainer

[Michael D. (mike0815)]

Hallo Rolf,

Ich habe jetzt nochmal deine letzte FW (20091116) drauf gespielt und mit 
dem internen Signal bis (200mV/Div) 5n/S getriggert, allerdings mit dem 
Standart-Trigger und mal 2 Bildchen gemacht!
1. ist ohne Denoising das 2. mit Denoising (Noise Filter geht jetzt bis 
2nS ???)
Ich denke es sieht aus wie es soll!!!!!!!


Irgend Jemand wollte doch mal den internen Generator auf 25MHz 
aufpumpen,(Sinus,Rechteck ist ja vorhanden) oder? Das wäre doch mal was, 
wenn das dann noch optional einstellbar... was ein Highlight!!!
Außerdem besteht ja die Möglichkeit das Generatorsignal nach außen zu 
führen.

Gruß Michael

[Stefan E. (stefan_e)]

Hallo,

ich teste gerade mal noch die Registerwerte aus. Am interessantesten 
scheint adc_change12_reg zu sein. Wie sieht es aus mit euch? Seid ihr 
bereit ein paar Registerwerte über Falks-Perl Skript durchzuprobieren, 
was sie bei euch für Auswirkungen haben? Vielleicht können wir da eine 
Tabelle ins Wiki stellen.

[Torsten W. (wirehead)]

Wenns unter windows geht bin ich dabei. (versuch grade nen upload mit 
perlscript)

[Torsten W. (wirehead)]

Hab jetzt mal die aktuelle testversion drauf, Kanal1 sieht noch nicht 
schön aus...
Das konnte ich bisher auch nicht beseitigen.

Gruß
Torsten

[Michael D. (mike0815)]

was ist das denn? Was für ein Signal hast du da gemessen? Intern oder 
Extern? Was für eine Frequenz hat Dieses?

Gruß Michael

[Torsten W. (wirehead)]

Internes 1khz
Mein Generator steigt nämlich noch langsamer...

[Michael D. (mike0815)]

Hallo Torsten,

also ich jetzt mal deine Messung nachvollzogen, weil ich mich schon 
gewundert habe, das du so eine niedrige Amplitude hast!
Ich nehme mal an, das du den Tastkopp auf 10x stehen hast?!?

Habe mal mit deinen Einstellungen einen Shot gemacht ohne Denoising, 
interne 1KHz, 20mV/Div, 5n/S,  Tastkopp auf 10x ohne Anpassung an die 
Scalierung dann kommt das bei mir raus!!!
(Ich sehe gerade, das ich da eine Verschiebung habe, hm)

Bedienungsfehler Deinerseits vielleicht?

Gruß Michael

[Michael D. (mike0815)]

....boah, hier der richtige Shot!!! Hammer's bald?

[Torsten W. (wirehead)]

Ich messe sowohl mit dem fluke als auch mit dem oszi (mit anpassung der 
taskopf einstellung 1:10) 370mV RMS
Was soll da denn offiziell rauskommen aus dem anschluss?

Edit: Sieht doch aus wie bei mir, nur ohne Zacken ;-)

Gruß
Torsten

[Michael D. (mike0815)]

hmm, ich habe 250mV RMS gemessen!

stimmt, sieht genauso aus, nur hatte ich die Zacken 'früher' auf dem 
2.Kanal!
Mit der letzten 092a die hier zur Verfügung stand, seit dem nicht mehr, 
alles wie es sein soll.

Gruß Michael

[Rolf W. (rowue)]

Stefan E. schrieb:
> Hallo,
>
> ich teste gerade mal noch die Registerwerte aus. Am interessantesten
> scheint adc_change12_reg zu sein. Wie sieht es aus mit euch? Seid ihr
> bereit ein paar Registerwerte über Falks-Perl Skript durchzuprobieren,
> was sie bei euch für Auswirkungen haben? Vielleicht können wir da eine
> Tabelle ins Wiki stellen.

Schau mal auf SFN, da hatte Falk schon einiges aufgeschrieben ;)

(im Trac-Wiki ;)

[Stefan E. (stefan_e)]

@Rolf W.

Jo, dass hab ich mittlerweile auch rausgefunden. Dennoch, wissen wir 
nicht, wie sich welche Hardware-Version mit welchen Werten verhält. Beim 
einen läufts mit der einen Einstellung, der andere braucht eine andere. 
Da hat sich etwas im FPGA geändert.

@all
Bei der 92a habe ich die beim mergen einen anderen Wert für das eine 
Register übernommen. Entweder den von Hayo oder den von Falk. Weiß grad 
nimmer. Der schein bei einigen nicht richtig zu funktionieren. Ich werde 
deshalb eine Möglichkeit bereitstellen, einen der Werte einfach über das 
Menü (erstmal nur das Menü der seriellen Schnittstelle) auszuwählen und 
zu speichern. Außerdem wird man den Standardwert einstellen können, wenn 
einem die Spikes zu stark nerven und einen die Signalverzerrung bei 
hohen Frequenzen nicht stört.

[Rolf W. (rowue)]

Stefan E. schrieb:
> @Rolf W.
>
> Jo, dass hab ich mittlerweile auch rausgefunden. Dennoch, wissen wir
> nicht, wie sich welche Hardware-Version mit welchen Werten verhält. Beim
> einen läufts mit der einen Einstellung, der andere braucht eine andere.
> Da hat sich etwas im FPGA geändert.

O.K. - dass heißt viel Spielen mit verschiedenen Hardware-Versionen ...
>
> @all
> Bei der 92a habe ich die beim mergen einen anderen Wert für das eine
> Register übernommen. Entweder den von Hayo oder den von Falk. Weiß grad
> nimmer. Der schein bei einigen nicht richtig zu funktionieren. Ich werde
> deshalb eine Möglichkeit bereitstellen, einen der Werte einfach über das
> Menü (erstmal nur das Menü der seriellen Schnittstelle) auszuwählen und
> zu speichern. Außerdem wird man den Standardwert einstellen können, wenn
> einem die Spikes zu stark nerven und einen die Signalverzerrung bei
> hohen Frequenzen nicht stört.

Naja, zum Auslesen und Setzen von Werten gibt es zumindest im trunk
unter "misc-tools/setvars" setvar.pl - ansonsten würde ich es
überwiegend vorziehen, die Werte aus dem Flash zu nehmen.
Bis auf die adc_changeXX scheinen die ja noch einigermassen
o.k. zu sein (wenn sie nicht aus versehen überschrieben oder
auf uninitialisierte Werte) gesetzt werden.

Grüße,

    rowue


@Stefan: Was Du gemerged hast, sollte aus dem Diff im trac
deutlich ersichtlich sein - geh mal auf "Revision Log" vom trunk,
da kannst Du Dir zwei Versionen als diff gegeneinander
stellen lassen ;)

[Bruno W. (brunowe)]

Hallo,

da ich nicht abschätzen kann wie viel Zeit ich die nächsten zwei Wochen 
habe, hier der Link zum versprochenen FFTscreener V0.0.2.
Das zip enthält das Handbuch (pdf) und die FFTscreener.exe. Da ich die 
Matlab compiler runtime nach deren Lizenzbed. nicht öffentlich 
zugänglich machen darf, gibts diese erstmal, wie gehabt auf pers. 
Anfrage bei mir.

http://sourceforge.net/projects/welecw2000a/files/FFTscreener/Version%200.02/FFTscreener_V0.0.2.zip/download

Der Umfang der Funktionen im FFTscreener ist gewaltig angestiegen, 
leider konnte ich noch bei weitem nicht alle Unzulänglichkeiten und Bugs 
beseitigen, ich bleibe aber weiter dran...

Gruß, brunowe

[Rainer W. (rawi)]

Hallo,

zum Thema Störungen/Signalerfassung habe ich bei meiner Kiste (W2024A, 
orig. FPGA, FW OS-0.92 20091116) zwei Merkwürdigkeiten beobachtet, die 
ich hier einfach mal zur Diskussion stellen möchte, weil dazu im Thread 
konkret nichts zu finden war.

Ich sehe, verstärkt bei eingeschaltetem Noise-Filter, auf den Signalen 
sporadische 3er-Gruppen von schnellen Spikes, die auf allen 4 Kanälen 
(fast) synchron auftreten. Die Spikes haben einen Abstand von 8 ns und 
sind am besten zu sehen, wenn der Persist Modus des Displays aktiviert 
ist, sonst huschen sie ab- und zu mal durch. Soweit ich das 
Raw-Datenformat richtig verstehe, sieht es so aus, als ob von jedem 
Kanal die Daten eines ADCs betroffen sind und der Wert 0 gelesen wird. 
In dem zeilennummerierten Ausschnitt gehts bei (Original-)Zeilennummer 
14820 mit so einem Burst los. Die Spikegruppen haben anscheinend eine 
feste Struktur: Ch. 1, 2+3, 1+4, 2+3, 1+4, 2+3, 4.

Weiter wundert mich der Zeitversatz zwischen den Kanälen. Bezogen auf 
Ch.1 sind das etwa 9, 11 und 18 ns (ProbeComp Signal, 1:10, Ch3 mit 2x27 
Ohm).

Mich macht stutzig, dass die Spikes einerseits anscheinen statistisch 
auftreten und andererseit kräftig mit dem Noise-Filters korreliert sind. 
So gesehen ist mir nicht klar, ob das Firmware, FPGA oder Hardwaredesign 
ist. Oder hat mein Scope 'ne unbekannte Macke?

Gruß Rainer

EDIT: Das kurze sind die richtigen Raw-Daten dazu

[Rainer W. (rawi)]

> EDIT: Das kurze sind die richtigen Raw-Daten dazu
Neuer Versuch mit wesentlichem Teil des Anhangs

(Mist, die Anhänge lassen sich anscheinend nicht editieren)

[Bruno W. (brunowe)]

Hallo Rainer,

>(Mist, die Anhänge lassen sich anscheinend nicht editieren)

Tja... unter Sourceforge wäre das kein Problem!.

Deine Spikes sind bei weitem keine neue Erscheinung! Bei mir treten 
diese Spikes besonders bei kaltem Gerät auf. Diese Spikes hängen ganz 
offensichtlich mit dem adc_change12_reg zusammen...dreht sich nicht die 
Diskussion hier seit einigen Monaten um nichts anderes mehr?

Auch der Zeitversatz zwischen den einzelnen Kanälen wurde vor einigen 
Monaten schon intensiv besprochen- es gibt dazu sogar eine Aufstellung 
wie groß der Versatz bei den einzelnen Geräten ist.
Hier sind die einzelnen Posts halt nicht einem spezifischem Thema 
zuzuordnen, daher ellenlang und total unübersichtlich!


Gruß, brunowe

[Torsten W. (wirehead)]

Hallo,
Ist die Liste mit dem Zeitversatz der einzelnen Planes irgenwo auf SF zu 
finden?

Was mir noch aufgefallen ist: Im Delayed Mode der Build: rowue-2009116 
ist mir ein Problem aufgefallen. Es wird die information links NEBEN dem 
Cursor Window auf der unteren Schirmhälfte angezeigt. Wenn man nun das 
Fenster an den linken Rand schiebt werden ungültige Daten angezeigt.

Ist der Bug bekannt (oder sogar in der 92a gefixt) oder soll ich dazu 
ein Ticket schreiben?

Die Bedienung des Pretriggers könnte noch in soweit verbessert werden 
als das man den Triggerpunkt Zeitbasisübergreifend per Menueauswahl über 
der 2. Gridline von links oder über die mittlere Gridline "Festnageln" 
kann.
Eventuell per Tabelle.

Punkt für Wishlist?

Fehlt unter Mode/Coupling nicht noch ein Punkt "Off" im Rejectmenue?
Oder versehe ich das falsch?

Gruß
Torsten

[Rainer W. (rawi)]

Bruno We schrieb:
> Deine Spikes sind bei weitem keine neue Erscheinung!
Ich hatte hier im Thread nur von Spikes auf festen Positionen, auf 
einzelnen Kanälen usw. gelesen, was für diese 3er-Gruppen nicht 
zutrifft.

Weil bei 50ns/div (oder schneller) immer alle Samples zu sehen sind, 
hoffte ich, dass die Korrelation mit dem aktiven Noise-Filter und das 
feste Muster bei der Ursachenforschung helfen könnten.

> ... daher ellenlang und total unübersichtlich!
wie wahr. ;-)

Was tut die Noise Filter Funktion eigentlich genau? Ich hatte die so 
verstanden, dass sie nur nicht angezeigte Werte zu einem Anzeigewert 
mittel, d.h. bei 50ns/div sollte sie gar nichts tun. Ist das der Stand 
der Dinge? Lassen sich solche Algorithmen vielleicht im Wiki 
dokumentieren unter "Inside of the W20xxA"?

Gruß Rainer

[alex008_ (Gast)]

Hallo zusammen!

Die Spikes entstehen nach meinen neuesten Erkenntnissen anscheinend im 
Digitalteil der AD-Wandler, falls diese eine Überspannung am Eingang 
anliegen haben (Fachbegriff signed/unsigned overflow).

Das unbekannte change_adc_reg12 könnte sehr ähnlich aufgebaut sein, wie 
auch ich es bei dem LEON3 FPGA-Design implementiert habe, siehe 
Dateianhang!

In meinem FPGA-Design und mit dessen Software bekam ich ohne eine 
Addition oder Multiplikation auf das Signal zu machen auch diese 
Effekte.
Dies geschah aber erst zu einem Zeitpunkt, als ich anfing, die analogen 
Einstellungen zu tätigen (DC-Offset mit dem DAC, analoge 
Verstärkungseinstellungen,...).

Übrigens habe ich es geschafft, den Firmware-Upload des LEON3s mit 
meiner selbstgeschriebenen Software zu erledigen. Damit kann die 
Entwicklung völlig ohne kostenpflichtige Software vorangetrieben werden!

Ein Demoversion mit verstellbarer Abastzeit und noch ein paar Dingen 
(vielleicht Spannungsbereiche, Triggerlevel, DC-Offset, ...) wird bald 
folgen.

Bei vorzeitigen Interesse bitte bei mir melden!

MfG
Alexander

[Rolf W. (rowue)]

Torsten Otten schrieb:
> Hallo,
> Ist die Liste mit dem Zeitversatz der einzelnen Planes irgenwo auf SF zu
> finden?
>
> Was mir noch aufgefallen ist: Im Delayed Mode der Build: rowue-2009116
> ist mir ein Problem aufgefallen. Es wird die information links NEBEN dem
> Cursor Window auf der unteren Schirmhälfte angezeigt. Wenn man nun das
> Fenster an den linken Rand schiebt werden ungültige Daten angezeigt.
>
> Ist der Bug bekannt (oder sogar in der 92a gefixt) oder soll ich dazu
> ein Ticket schreiben?

Also wenn das ein Build von mir (rowue-20091116) ist, dürfte
er in der 92a nicht gefixt sein - meinst Du evtl. den trunk?

Generell würde ich zu jedem Bug, der in einer aktuellen Version
auffällt sagen: schreibt ein Ticket, allerdings schaut vorher,
ob es dort schon eins gibt (oder ggf. gab) - evtl. sollten
wir eine "known-Bugs" Liste schreiben (von Dingern, die wir
nicht fixen könne/wollen ;)

>
> Die Bedienung des Pretriggers könnte noch in soweit verbessert werden
> als das man den Triggerpunkt Zeitbasisübergreifend per Menueauswahl über
> der 2. Gridline von links oder über die mittlere Gridline "Festnageln"
> kann.
> Eventuell per Tabelle.
>
> Punkt für Wishlist?

Im Ticket-System gibt es auch den Punkt "Feature Request" ;)

>
> Fehlt unter Mode/Coupling nicht noch ein Punkt "Off" im Rejectmenue?
> Oder versehe ich das falsch?
>
> Gruß
> Torsten



Grüße,

     rowue

[Rainer W. (rawi)]

alex008_ schrieb:
> Die Spikes entstehen nach meinen neuesten Erkenntnissen anscheinend im
> Digitalteil der AD-Wandler, falls diese eine Überspannung am Eingang
> anliegen haben (Fachbegriff signed/unsigned overflow).

Um aus einem Overflow in einem einzelnen Wandler immer 3er Gruppen von 
Spikes synchron auf allen 4 Kanäle zu erzeugen, auch wenn ein Kanal z.B. 
auf Masse liegt, muß noch mehr passieren. Und wieso sollte das immer 
jedes 2te Sample betreffen? Ich denke das hat einen anderen Grund.

Gruß Rainer

[Rainer W. (rawi)]

Beim Vergleich der 3er-Spikes von FW OS-0.91 (Falk 20090810) zu OS-0.92 
(rowue 20091116) fällt eine geänderte Sequenz auf:

0.91:  Sequenz 1, 2+3+4, 1,   2+3+4, 1,   2+3+4
0.92:  Sequenz 1, 2+3,   1+4, 2+3,   1+4, 2+3,   4

In beiden Fällen sieht man im Raw-File, wie die Spikes auf 0 gehen.

                    OS-0.91    OS-0.92
adc_change12_reg      20000      20000
adc_change34_reg    200000A      20000

@brunowe: Gibt es die bisherigen Erkenntnisse zu den Spikes irgendwo 
schon in geordneter Form oder ist das hier auf mehrere Threads gut 
verteilt? Bei SF konnte ich nichts dazu finden.

Gruß Rainer

[Bruno W. (brunowe)]

Hallo Rainer,

meines Wissens gibt es noch nirgends eine geordnete Sammlung über das 
Auftreten der Spikes... Da ich in der FW- Entwicklung auch keine Karten 
habe, kann ich kaum mit nützlichen Informationen dazu dienen. So weit 
mir bekannt ist, sind da allerdings einige Leute am basteln (Falk, 
Jörg...).
 In der FW- Version 0.92 hatte sich bei mir das Problem massiv 
verschlimmert, weswegen ich immer noch mit der 0.91 OS gearbeitet habe. 
Im Zuge der FFTscreener- Programmierung werde ich auch direkt auf die OS 
0.93 wechseln.

Grüße, brunowe

[Falk W. (dl3daz)]

Bruno We schrieb:
> Hallo Rainer,
>
> meines Wissens gibt es noch nirgends eine geordnete Sammlung über das
> Auftreten der Spikes...

Die Spikes hängen direkt mit dem adc_NN_change Register zusammen. Setzt 
man das Bit, das die Spikes verhindert, gibt es die elenden Verzerrungen 
ab ~50MHz.

Daher auch das Auftreten des einen oder anderen Problems in 0.91, 0.92, 
0.93.

Mir war mal aufgefallen, daß die Spikes ohne Trigger (Auto) immer am 
Ende des Samplebuffers erscheinen. Die Dinger haben auch immer den 
gleichen Wert, der sich aber bei Änderung an der Zeitbasis ändert.

Nach dem Einschalten haben die, wenn ich mich richtig erinnere, immer 
den Wert 0. Ich habe mal ein paar Raw-dumps animiert: 
http://www.youtube.com/watch?v=3uFKkHVfNQI

Es sollte kein Problem sein, die in der FW zu eliminieren.

Ich mir habe die aber immer nur bei 1GS/s angesehen.

Falk

[Rolf W. (rowue)]

Bruno We schrieb:
> Hallo Rainer,
>
> meines Wissens gibt es noch nirgends eine geordnete Sammlung über das
> Auftreten der Spikes... Da ich in der FW- Entwicklung auch keine Karten
> habe, kann ich kaum mit nützlichen Informationen dazu dienen. So weit
> mir bekannt ist, sind da allerdings einige Leute am basteln (Falk,
> Jörg...).
>  In der FW- Version 0.92 hatte sich bei mir das Problem massiv
> verschlimmert, weswegen ich immer noch mit der 0.91 OS gearbeitet habe.
> Im Zuge der FFTscreener- Programmierung werde ich auch direkt auf die OS
> 0.93 wechseln.

Hi Bruno,

hast Du mal den Build probiert, den ich hier vor einigen
Tagen reingestellt habe? Da habe ich auch die adc_change_XX
wieder auf die Werte von Falk zurückgedreht ....
>
> Grüße, brunowe


Grüße,

   rowue

[Torsten W. (wirehead)]

Hallo,
also ich habe heute die Build rowue-2009116 wieder durch die aktuelle 
0.92a erstezt.
Anbei ein Persist über 15min von den Spikes.
Das kuriose ist das die spikes bei der Build 2009116 auf der anderen 
seite der flanke waren und zwar von oben nach unten... Sah da genau so 
aus.
Ein weiteres Puzzelstückchen.

Gruß
Torsten

[Falk W. (dl3daz)]

Torsten Otten schrieb:

...

> Anbei ein Persist über 15min von den Spikes.

Das gleiche hatte ich bei 50ns/Div. gemacht: 
http://consult42.com/tmp/screenshot-0000.gif

Edit: Noch eins: http://consult42.com/tmp/triggerprobs3.gif

> Ein weiteres Puzzelstückchen.

Und noch eins...

Falk

[Torsten W. (wirehead)]

Bei mir kam leider nie so ein schönes muster raus, bzw. traten die 
spikes nicht auf bei so kleinen zeitbasen.

[Rainer W. (rawi)]

Hallo Falk,

Falk Willberg schrieb:
> Mir war mal aufgefallen, daß die Spikes ohne Trigger (Auto) immer am
> Ende des Samplebuffers erscheinen. Die Dinger haben auch immer den
> gleichen Wert, der sich aber bei Änderung an der Zeitbasis ändert.

Spikes an fester Position sehe ich bei mir auch, und zwar wenn das Scope 
mit Auto-Trigger (od. Standard) frei läuft, d.h. wenn kein triggerndes 
Signal anliegt. Dann sehe ich mit 1GSa/s 50nm/div (oder schneller) 
stabile Spikes bei einer Pretrigger-Einstellung von 8.04 us.

Ein fester Zeitbezug zum Autostart der Aufzeichnung macht die Dinger 
vielleicht etwas greifbarer.

Nebenbei sind mir noch drei Dinge in der 0.92 aufgefallen:
----------------------------------------------------------
1. Im Screenshot zeigt sich noch ein Darstellungsfehler beim genau 
zeichnenden Linienalgorithmus. Es werden oben manchmal Punkte gezeichnet 
(hier rote vom Ch4), die anscheinend die "Verlängerung" von zu weit nach 
unten geschobenen Signalen sind.

2. Die Zahlenangaben für die Cursorpositionen hinken beim Verschieben 
eines Cursors manchmal endlos (ca. 4s) hinter den dargestellten 
Linienpositionen hinterher.

3. Wieso sind die Zeitangaben für die Cursor X-Positionen eigentlich auf 
den Bildschirmrand bezogen? Für's praktische Leben ist doch der 
Zeitbezug zur Triggerposition die entscheidende Größe. Dann wäre das 
auch konsistent mit den Y-Angaben, die sich ja auch auf einen bestimmten 
Signalnullpegel beziehen. -> Verbesserungsvorschlag

Gruß Rainer

[Rainer W. (rawi)]

Huhu, lebt hier noch jemand?

@Hayo: Hast du im Delayed Fenster noch eine größere Baustelle offen?

Auf jeden Fall ist da noch der Wurm drin:
Bei 1 GSa/s habe ich mit der OS-0.92 bei mir Signalverschiebungen von 
mehr als 1 us zwischen Main und Delayed Fenster beobachtet. Dadurch 
tritt anscheinend auch das von Torsten beschriebene Problem auf 
(Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"). Beim Ticket 
http://sourceforge.net/apps/trac/welecw2000a/ticket/34 habe ich dazu mal 
ein paar konkrete Beispiele hinzugefügt. Ist das noch "minor"?

Gruß Rainer

[musashi (Gast)]

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

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

[Falk (Gast)]

Musashi,
DON'T PANIC! ;-)

please see http://sourceforge.net/apps/trac/welecw2000a/wiki/FWdownload 
and http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload

This should give all information, you will need.

A forum, which is not limited to German language, is located here: 
http://sourceforge.net/apps/phpbb/welecw2000a/

HTH,
Falk

[cristi s (Gast)]

hello
trying to run fftscreener version 02 and getting

C:\Program Files\MATLAB\R2009b\bin\win32>fftscreener
Fatal error finding symbol mclMlfFeval in C:\Program 
Files\MATLAB\R2009b\bin\win
32\mclmcr.dll Error:

or

C:\Program Files\MATLAB\R2009a\bin\win32>fftscreener
Fatal error finding symbol mclMlfFeval in C:\Program 
Files\MATLAB\R2009b\bin\win
32\mclmcr.dll Error:

any help apreciated

[Bruno W. (brunowe)]

hello christi s,

to run the fftscreener you have to install the Matlab compiler runtime. 
If You've got Matlab on your PC installed, the fftscreener.exe should 
work in a proper way (if the MCR is up to date). I assume Matlab (or the 
MCR at least) isn't installed on your system. Because of the license 
agreements of Mathworks/ Matlab it isn't possible to post a unprotected 
link to the MCR. Anyhow its allowed to share this file ;).

To anybody who needs this MCR, please send my a PN (use
[e-mail]) and I'll post you a link to the needed 
MCR.

For further request and support please use this forum: (splitted in 
german and english). You could post there (and I also answer) in Spanish 
or Russian if needed.
http://sourceforge.net/apps/phpbb/welecw2000a/


regards
brunowe

[Georg X. (schorsch666)]

Hallo Leute,

ich habe einen Welce 2014A mit der orignalen FW V1.4.

Ich möchte gerne Screenshots von meinen Messungen machen und diese aufm 
PC als JPG oder BMP oder ein anderes Bildformat abspeichern.

Hab mir mal die SW von der Welec- Homepage angeschaut. Dieses scheint 
aber irgendwie nicht wirklich fertiggestellt worden zu sein. Die 
Screenshots sind unvollständig und die Angaben über die Zeit- und 
Spannungsauflösung stimmen überhaupt nicht.

Wenn ich mir so eure Screenshots anschaue gefällt mir dass schon besser.
Kann mir jemand sagen ob es da schon ne andere SW dafür gibt?

Wenn ja, wo finde ich diese?

Gruss und Danke,
Schorschi.

[Hans Knall (Gast)]

Auf Hayo's Homepage kannste alles finden

[Georg X. (schorsch666)]

Hallo,

wie ich dass sehen konnte gibts da den sorce.
Gibts iegendwo auch eine fertig kompilierte Applikation?

gruss,
georg

[Roberto (Gast)]

>Hayo's Homepage??
Link ?

[alex008 (Gast)]

Hallo!

Ich habe auch keine Ahnung, wo Hayo's Homepage sein soll.

Georg X: Auf unserer Sourceforge Homepage gibt es ein paar 
vorkompilierte Releases zum Runterladen!
http://sourceforge.net/projects/welecw2000a/files/

Das was du suchst, ist unter Open Source Firmware.

Das W2000L Release ist das, mit dem ich mich momentan beschäftige. Das 
ganze ist noch nicht einmal in einem Alpha Stadium. Falls dir aber die 
Frequenzauflösung und der Spannungsbereich egal ist, und dir ein perfekt 
funktionierender Trigger gepaart mit einer besseren Signalqualität bei 
den 2 und 1 V/div wichtiger ist, kann ich dir das schon mal zum 
Probieren empfehlen!

MfG
Alexander

[Blue F. (blueflash)]

Hallo werte W20xx Gemeinde,

frohes neues Jahr an alle.

Ich war einige Zeit beruflich im Ausland und bin daher zu nichts 
gekommen. Ich muß mich erstmal hier durch die Beiträge lesen um auf den 
aktuellen Stand zu kommen, dann werde ich mal sehen wo ich wieder 
einsteigen kann. Das wird wohl einige Tage dauern bis ich da im Bilde 
bin.

Zu den letzten Beiträgen:

Eine eigene Homepage habe ich nicht, aber wie Alex schon geschrieben hat 
gibt es eigentlich alles Wichtige auf der SF-Projekt-Homepage.

Sonst gibt es noch die alte Google-Groups Adresse

http://groups.google.de/group/welec-dso/

Hier kann man auch einige Sachen runterladen. Allerdings sind die 
Firmwareversionen nicht mehr auf dem aktuellen Stand.

Gruß und bis bald

Hayo

[Michael H. (Gast)]

Hi Hayo
ein gutes Jahr 2010 wünsche ich Dir!
Wir dachten schon alle, dass du dem Welec den Rücken gekehrt hast...ich 
freue mich, dass dem nicht so ist!

Viele Grüße
Michael

[Cra Z. (crazor)]

Moin Leute,

ich habe noch immer ein W2012A abzugeben. Schaut mal hier: 
Beitrag "[V]: Welec W2012A"
Sorry wegen der Werbung, aber die Leute, die hier mitlesen, haben sicher 
am ehesten noch Interesse am Gerät und wissen es zu schätzen ;)

LG

[Blue F. (blueflash)]

Hi Leute,

nach längerer Zeit mal wieder eine Rückmeldung von mir. Leider läßt mir 
der Beruf momentan nicht so viel Zeit zum Programmieren und tüfteln wie 
ich gerne möchte. Nichtsdestotrotz versuche ich hier weiter am Ball zu 
bleiben.

Hat sich das Problem mit den adc_change_XX Registern inzwischen geklärt?

Ansonsten hier noch ein Hinweis:

Nachdem Falk herausgefunden hatte dass da ein direkter Zusammenhang mit 
der Schwingneigung besteht und den Registerwert auf  0x20000 gesetzt 
hatte
hab ich eine ganze Zeit mit diversen Werten rumexperimentiert und 
festgestellt, dass meine beiden DSOs am besten mit dem Wert 0x1000000 
laufen, da sich damit auch hohe Frequenzen prima darstellen lassen und 
keine störenden Spikes entstehen. Bei mir läuft das damit eigentlich 
völlig problemlos.

Habt Ihr da neue Erkenntnisse, evtl. Unterschiede bei verschidenen 
Geräten? Bei mir handelt es sich um ein W2014A und ein W2022A.

Desweiteren:

- Die Datei mit den verschiedenen Kanalversätzen kann ich gerne hier 
posten wenn Ihr die braucht

- irgendwann wollte doch jemand bei Conr... Netzschalter besorgen -> wie 
sieht es damit aus?

- Ja, im Delayedbereich gibt es noch einige Baustellen die 
liegengeblieben sind, genauso im FFT-Bereich wo ich noch einiges 
hinzufügen wollte

- @Stefan -> wenn Du Hilfe beim Menü brauchst (ist wirklich etwas 
unübersichtlich mit den ganzen Strukturen für Werte und Texte) um Deine 
Triggerfunktion da einzuhängen kann ich Dir gerne Tipps geben

- meine letzte Baustelle vor meinem Auslandseinsatz war eigentlich die 
Änderung der Timebases und der Timebasesteuerung. Da wollte ich evtl. 
wieder ansetzen falls da nicht schon jemand anderes was geklöppelt hat.

Gruß an alle Mitstreiter

und Welec-Besitzer

Hayo

[Michael D. (mike0815)]

...da isser ja!
Du meine Güte, hast ja Recht! Ich muß zu meiner Schande gestehen, das 
ich die Schalter völlich verpeilt habe, die liegen hier rum und wollen 
zu ihren neuen Besitzen...du wolltest 2 Stck.? Die Anderen muß ich mal 
nachschauen oder ihr meldet euch nochmal...wie peinlich!

Bei deinen letzten FW's, war ein Fehler (extremes Rauschen bzw. 
Treppchen im oberen Frequenzbereich vom 2. Kanal), der in der Vers. vom 
Rolf behoben wurde (Flash_1.2-OS-0.92a, 
Flash_TomCat_16112009_Rolf(rowue)) ...nur mal zur Info!
Schick mir doch mal bitte deine Adr., damit ich dir die Schalter 
zukommen lassen kann.

Grüsse aus Hessen

[Blue F. (blueflash)]

Hi,

@Michael

-> die Mail mit meiner Anschrift ist raus!

Das  Problem mit den Treppchen etc. hatte ich so grob beim Nachlesen 
mitbekommen. Ist denn nun geklärt woran es lag?


@Rolf

was hast Du denn im Detail geändert?

Gruß Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> Hi,
>

Hi, sorry erstmal für's lange nicht melden, resp. für's
späte melden, ich ziehe zum 01.03. für einige Zeit nach
Freiburg und bin hier etwas im Umzugsstress....
> [...]
>
>
> @Rolf
>
> was hast Du denn im Detail geändert?

Zwei Dinge:

a) werden einige Werte wieder aus dem Flash gelesen
b) habe ich die adc_change Regs wieder auf 0x20000 gesetzt

Die Änderungen im Detail:

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

Das Ticket mit dem Problem:

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

<frotzel>
Schön, dass es sowas wie svn und trac gibt
</frotzel>

An der Signalstörung im Bereich 250/500 MSa/s bin ich noch dran,
allerdings sieht es so aus, als ob die "Verwürfelungen"
Kanal-Abhängig sind und da ich mir den vierten Kanal
gerade "verlötet" habe (schwingt jetzt), werden weitere
Aktionen da etwas warten müssen.

Als ich "routinemässig" den 1GSa/s Bereich mit 'nem Dreieck
(zweistellig MHz) gemessen habe, ist mir noch aufgefallen,
dass die Sampling-Abstände zwischen den einzelnen ADC's
nicht äquidistant sind, sondern, dass es eher so aussieht,
als würden zwei zur gleichen Zeit abgefeuert. Dies ist auch
sehr schön zu sehen, wenn mensch die Flanke vom Probe-Signal
mit 1GSa/s misst (Treppen). Ich sehe mal zu, dass ich da noch
was zusammengefasst bekomme.
>
> Gruß Hayo

Beste Grüße,

     rowue

[Blue F. (blueflash)]

Hi Rolf,

danke für die Antwort. Wie Du siehst ist bei mir die Zeit im Augenblick 
auch etwas knapp, daher bin ich auch nicht so oft hier online. Will aber 
auf jeden Fall weitermachen und die Firmware weiterentwickeln.

Auf der Softwareseite scheint ja im Moment nicht allzuviel zu passieren, 
wenn ich das hier so sehe. Wird wohl mal Zeit wieder in dei Hände zu 
spucken.



@Michael

Hattest Du meine Mail bzgl. der Schalter bekommen??


Gruß Hayo

[Uwe M (Gast)]

Hallo zusammen,

ich habe folgendes Problem bei meinem W2014 nach dem Firmware-Update auf
Version 0.92a entdeckt.
Der Kanal 4 ist grundsätzlich aktiv.
Nach drücken der Taste "Kanal 4":
+ LED "Kanal 4" geht aus,
+ Mathematik-Funktionen werden aktiviert, "FFT" aktiviert.

Nach erneutem drücken der Taste "Kanal 4":
+ "Kanal 4" wieder aktiviert.

Nach drücken der Taste "Math":
+ Mathematik-Funktionen werden aktiviert, "FFT" aktiviert.

Wechsle ich nun auf eine der anderen Funktionen (Mult, Sub, Ass):
+ Kanal 4 bleibt aktiviert/angezeigt.
+ mit Taste "Kanal 4" kann ich das magentafarbene Funktionssignal
"zuschalten".

Kennt jemand von euch ein ähnliches Phänomen?

Grüße,
Uwe

PS: Entschuldigung für das Doppelposting, ich habe aus versehen auf 
"Neuen Beitrag" anstatt auf "Antwort" geklickt und es erst hinterher 
bemerkt.

[Roberto (Gast)]

Hallo Uwe

Ich habe Version 1.2.OS.092 (W2024A)

Wenn ich einschalte ist das Fenster mit der Version, nur mehr ganz kurz 
sichtbar. (vorher war es länger ..)
und Kanal-1 Led leuchtet (Taste).
Am Bildschirm habe ich links aber  drei gelbe Anzeigen: 1,T, 1T
und die grüne Anzeige (2) und die rote(4)
Es ist aber nur Kanal 1 ein und oben im Fenster auch nur Kanal 1 
sichtbar.
Horizontale Linien sehe ich keine..

Wenn ich Kanal 2 Aus und Ein Schalte, ist dann links nur mehr Kanal 1 zu 
sehen..

Die Linie für Kanal 1 sehe ich aber erst, wenn ich Kanal 4 AUS und EIN 
schalte :-(

l.G. Roberto

[Kurt B. (kurt)]

Hallo Leute,
wer arbeitet denn noch an der Nios Firmware?

Es sind in der 1.2.OS.0.92a noch einige Tickets offen. Siehe 
http://sourceforge.net/apps/trac/welecw2000a/report/2

Mfg,
Kurt

[Michael D. (mike0815)]

oje, der Roberto steht noch im Dunkeln, vielleicht setzt du mal ein paar 
Bildchen hier rein, dann könnte man das evtl. ewas besser 
nachgvollziehen???

Gerade das Ticket 46 (Zeroline Correction) geht mir immer wieder auf'm 
S... !
Bist fertig mit dem Messen und es wird immer noch eine Spannung 
angezeigt, obewohl alles abgeklemmt is', also wieder alles auf 'NULL' 
calibrieren,
sehr lästig...

Das Ticket 37 ist mir noch garnicht aufgefallen, werde das mal 
testen...hat Jemand, ausser razer6, dasselbe Problem ?

Gruß Michael

[Blue F. (blueflash)]

Hallo Leute,

bin grad aus dem Türkeiurlaub zurück (endlich mal wieder Sonne...).

@Kurt

Hatte leider immer noch nicht viel Zeit für die Entwicklung, wollte aber 
mal wieder weitermachen.


@Michael

Eigentlich wollte ich mal die Kanalverschiebung in Angriff nehmen, wie 
wichtig ist denn Ticket 46, sonst werf ich da erst einen Blick drauf. 
Eigentlich dachte ich die Nullpunktgeschichte (Kalibrierung) wäre 
erstmal einigermaßen akzeptabel wenn auch noch nicht so komfortabel.

Ach ja, was machen denn die Schalter, hattest Du meine Mail bekommen?

Gruß Hayo

[Michael D. (mike0815)]

Hallo Hayo,

Ich hatte vor ein paar Wochen den PC Supergau, (aufgeblasene 
Kondensatoren) sehr ärgerlich!
Ich habe zwar mehrere Rechner, da man ja einen nicht so vollpumpen kann, 
ich verdiene meine Brötchen mit der Werbetechnik, da reicht einer nicht.
Gerade der mit der Buchhaltung und Emailprogramm...bin also immer noch 
am Daten retten...
Schicke dir jetzt noch mal eine PN

Ticket 46, also wie beschrieben, die Nulllinien verändern sich manchmal 
selbstständig während des messens, dann sind die Messwerte auch nicht 
mehr korrekt! Wenn das schon mal behoben würde, wäre ich etwas 
glücklicher, vielleicht nicht nur ich...

Ach ja, die Schalter- Daten habe ich schonmal gefunden, 2,70€ habe ich 
hier stehen.
Die Verpackung mit Klammern (das die Post hineingucken darf oder muss) 
und Versand käme dann nochmal auf 1,10 €
Immer noch günstiger als die 6,50€ von 'C' denke ich!
Also bis dann...

Gruß Michael


EDIT: Bernd und Hayo, ich hatte noch mal nach geschaut und den Rabatt 
vergessen, habe ja 10Stck. gekauft da gabs 8% also kommt ein Schalter 
auf 2,48€ ...wollte mich jetzt nicht an euch bereichern

[Blue F. (blueflash)]

Michael D. schrieb:

> Ich hatte vor ein paar Wochen den PC Supergau, (aufgeblasene
> Kondensatoren) sehr ärgerlich!
Fu... - das ist in der Tat echt übel. Dann ist das wohl ein eher älterer 
Rechner oder? Denn die neueren sollten das eigentlich nicht mehr haben.

Der Grund meiner etwas längeren Abstinenz ist auch unter Anderem, dass 
ich auf einen neueren Rechner und auch eine neue Linuxversion 
umgestiegen bin. Über die damit verbundene Odysse (AMD Linux 
Grafiktreiber etc.) will ich lieber nicht viel erzählen, aber in der 
Zeit hätte ich locker eine komplette neue Firmware schreiben können ;-)

> Ticket 46, also wie beschrieben, die Nulllinien verändern sich manchmal
> selbstständig während des messens, dann sind die Messwerte auch nicht
> mehr korrekt! Wenn das schon mal behoben würde, wäre ich etwas
> glücklicher, vielleicht nicht nur ich...

Das Ticket bzw. das Problem kannte ich noch gar nicht, muß ich mal 
checken ob das bei mir auch auftritt. Hatte ich jedenfalls bislang noch 
nicht bewußt wahrgenommen. Gibt es eventuell einen direkten Zusammenhang 
mit einer bestimmten Firmwareversion, oder gibt es das schon von Anfang 
an bzw. auch bei der original Firmware?

-> hab Dir übrigens nochmal meine Adresse geschickt

Gruß Hayo

[Michael D. (mike0815)]

Hallo Hayo,
Du hast Post!

Das Zeroline-Problem ist seit dem ich das Teil in Betrieb genommen habe 
und mit Jeder FW.
Bei der Originalen weiß ich es nicht, hatte die ja gleich runter 
geschmissen, war ja nicht der Reisser!!!
Ich denke mal, das die Anderen dasselbe Prob. haben, vielleicht kann das 
Jemand bestätigen?!?

Ich denke, das mit den Tickets noch was geht bevor das Redesign der 
neuen FW. und Eingangsstufe(Huckepackplatine) fertig ist!

Gruß Michael

[Kurt B. (kurt)]

Auf http://sourceforge.net/apps/trac/welecw2000a/wiki/Leon%20Binaries 
gibt es die Firmware für das Leon3 Design fertig compiliert zum 
Ausprobieren.

Anleitung zur Installation unter 
http://sourceforge.net/apps/trac/welecw2000a/wiki/leon3design

[Blue F. (blueflash)]

Michael D. schrieb:

> Das Zeroline-Problem ist seit dem ich das Teil in Betrieb genommen habe
> und mit Jeder FW.

Das kann eigentlich nicht sein, ich habe mir das mal angesehen und bei 
mir überprüft. Das ist ein Problem mit den Skalierungsfaktoren. Bei 
meiner Firmware tritt das definitiv nicht auf. Habe das mal 
durchgespielt und da stimmt die Nulllinie in der Mitte genauso wie im 
oberen und unteren Bereich. Auch das Rauschen ist unverändert.

Damit Du das mal selbst prüfen kannst hier die Version mit der ich das 
geprüft habe.

Gruß Hayo

[Roberto (Gast)]

Hallo Hayo
Schön das Du wieder zurück bist :-)
Danke für das einspielen deines Files.
Habe das jetzt auf das DSO geladen und alles funktioniert soweit gut :-)
Irgendwie habe ich eh schon länger den Überblick über die Versionen 
verloren :-(
Hatte halt das letzte vom Forum draufgespielt..
1.2-OS-0.92a.zip
und das funktionierte nicht so richtig...

Aber, gab es da nicht mal eine Trennung von den Firmware-Entwicklern ?
Nur weis ich jetzt nicht, was zu wem gehört :-(

Und weil ich gerade beim Fragen bin und englisch nicht so gut kann :-(, 
wie funktioniert das mit dem neuen Leon3  ?
Brauche ich dafür eine neue Hardware oder ist der Leon3 nur eine neue 
Programmierung für den FPGA ?
Wie kann ich die Einspielen und bringt die schon was, oder kann man 
damit noch nicht vernünftig arbeiten ?

Danke für Antworten :-)
und auch Danke an alle Entwickler, nur fehlt halt leider ein bisschen 
der Überblick ;-)

l.G. Roberto

[Blue F. (blueflash)]

Roberto schrieb:
> Hallo Hayo
> Schön das Du wieder zurück bist :-)
> Danke für das einspielen deines Files.

Gern geschehen

> Habe das jetzt auf das DSO geladen und alles funktioniert soweit gut :-)
Auch die Nullliniensache? Wie sieht es mit Spikes aus? Siehe Beiträge 
weiter oben.

> Irgendwie habe ich eh schon länger den Überblick über die Versionen
> verloren :-(
> Hatte halt das letzte vom Forum draufgespielt..
> 1.2-OS-0.92a.zip
> und das funktionierte nicht so richtig...
Über den Stand der Dinge bei der offiziellen OS Version bin ich zur Zeit 
nicht im Bilde.

> Aber, gab es da nicht mal eine Trennung von den Firmware-Entwicklern ?
> Nur weis ich jetzt nicht, was zu wem gehört :-(
Die Versionen mit dem BF sind direkt von mir. Das sind keine offiziellen 
Open Source Versionen, sondern meine eigenen Versionen in denen ich erst 
die Funktionen ausprobiere bevor ich sie freigebe.

Meine Version unterscheidet sich von der OS-Version:

- der neue Trigger von Stefan fehlt noch, soll aber noch implementiert 
werden

- die Remotesteuerung von Falk ist noch nicht auf dem aktuellsten Stand

- einige zentrale Register werden anders gesetzt

- die Screenshotversion passt nicht zu der offiziellen Version


> Und weil ich gerade beim Fragen bin und englisch nicht so gut kann :-(,
> wie funktioniert das mit dem neuen Leon3  ?
> Brauche ich dafür eine neue Hardware oder ist der Leon3 nur eine neue
> Programmierung für den FPGA ?
> Wie kann ich die Einspielen und bringt die schon was, oder kann man
> damit noch nicht vernünftig arbeiten ?

Das LEON Design ersetzt das alte NIOS Design im FPGA. Da sich dadurch 
die Hardware und die Adressen aus Sicht der Firmware komplett ändert ist 
auch eine neue Firmware notwendig. Wie weit der Stand dort ist weiß ich 
allerdings nicht. -> siehe Hardwarethread.

> Danke für Antworten :-)
> und auch Danke an alle Entwickler, nur fehlt halt leider ein bisschen
> der Überblick ;-)

Jo, kein Problem

Gruß Hayo
> l.G. Roberto

[Blue F. (blueflash)]

Hi,

ich bin mir nicht so ganz sicher, ob ich beim zusammenstellen der 
Downloaddatei etwas durcheinander gekommen bin mit den Versionen.
(welche Version wird angezeigt?)

Daher hier nochmal die richtige BF.0.97 mit Historie

Gruß Hayo

[mike0815 (Gast)]

Hallo Hayo und Roberto,

Roberto, wenn du das neue Nios-Design mal testen möchtest, stehe ich 
gerne zur Verfügung, denn die Programierung ist nicht ohne...
Lade dir schonmal den QUARTUS-Programmer herunter und den USB-Blaster, 
installiere alles und schicke mir eine PM dann sehen wir weiter!!!

Die Benutzeroberfläche ist schon mal eine ganz Andere, es sind nur 
einige Funktionen verfügbar, das Signal glasklar und null Rauschen, 
unglaublich, das so etwas mit dem Welec möglich ist!
An dieser Stelle ein Lob an die Macher, die hier unglaubliches geleistet 
haben, Oskarreif...
Wenn ich heute dazu komme, setze ich mal ein paar Screenshots rein!

Gruß Michael

[Michael D. (mike0815)]

Hallo Hayo,
Du hattest weiter oben die BF097_Beta eingesetzt, das war deine letzte 
Version.
Ist die mit der 'Historie' eine Andere???

Zu der Nulllinie: Habe jetzt noch mal 1Std. getestet und Screenshots 
gemacht.
Die ersten beiden Shots sind von Rolfs 092er Version(11162009), erstes 
Shot ist die Grundstellung mit Auto-Trigger, 5V-DIV, 1GSa/s 1µs und kein 
Signal anliegen!
Der 2. Shot sind die Linien Verschoben!

Der 3. Shot ist von deiner Ver., also 097Beta, auch hier die 
Grundstellung und mit ADC sowie Dac Calibrierung und Einstellungen wie 
oben!

Der 4. Shot ist dann wieder verschoben, 1.Kanal nach unten und 2.Kanal 
nach oben gezogen, auch hier ist was nicht in Ordnung.
Jetzt habe ich aus dieser Stellung eine DAC-Calibrierung durch geführt 
und habe danach die Kanäle wieder in die Grundstellung gezogen, danach 
sieht es so wie auf dem 5. Shot aus!

Ist das jetzt nur bei mir so, oder hat das jetzt mal noch Jemand 
getestet???

Gruß Michael

EDIT: Zur Info!!!
Die screenshot_0.91 funktioniert nur mit der--- FW092 mit 3. Trigger--- 
vom Rolf(11162009)

Für Hayo's FW's nur diese Ver. screenshot_0.4BF ---Hayo 097beta---

Ok, hoffe ihr blickt durch...

[Michael D. (mike0815)]

Da hier einige Fragen über die bisherigen FW-Versionen gestellt wurden, 
habe ich mal von meinen Ordnern einen Screenshot von den bisherigen 
FW-Versionen gemacht:
Die BF 1.2 sind vom Hayo.

Die FW 1.2.OS sind vom Rolf(rowue), Guido und Stefan mit z.B. 3. Trigger 
usw.
Der Grau unterlegte Ordner sind noch rasche Testversionen mit 
Datumsangabe!

Ich hoffe einen kleinen Überblick verschafft zu haben.

(das nimmmt schon bald eine eigene Festplatte in Anspruch)

Gruß Michael

[Blue F. (blueflash)]

Hi,

hab soeben nochmal gegengetestet mit W2014 und mit W2022. Keine 
Verschiebung!

Das deutet auf eine Abweichung der Verstärkung auf der Hardwareseite hin 
- Bauteiletoleranz vermute ich mal.

Die Faktoren in der Firmware (Skalierungsfaktor und DAC-Faktor) sind ja 
abgestimmt auf die Eingangsverstärkung der Eingangsstufe. Wenn es da 
Abweichungen gibt kommt es zu diesem Verhalten. Ich habe eine ganze Zeit 
rumgetüftelt bis es stimmte. Allerdings habe ich als Referenz natürlich 
nur meine beiden Geräte.

Würde mich mal interessieren ob das bei anderen auch auftritt, und ob 
das evtl. mit der Hardwarerevision zusammenhängt.

Normalerweise macht man bei ADCs auch noch eine Verstärkungskorrektur 
die dann sowas auch mit ausbügeln kann, die habe ich aber nach einigen 
Tests wieder rausgenommen, da die Performance darunter ziemlich gelitten 
hat.

Gruß Hayo

[Michael D. (mike0815)]

Jetzt fällt mir gerade was ein!
Kann mich erinnern, das wir das Thema schonmal hatten.
Nämlich der Tausch der NULL-OHM Wiederstände gegen 33 Ohmler, die das 
Signal-Rauschen um einiges reduzierten!
Wir aber keine Softwareanpassung gemacht haben, da haben wir ja die 
Leiche!

Was meinst du, soll ich die Wiederstände wieder raus schmeissen oder 
wäre eine SW-Anpassung sinnvoller? Evtl. als Kalibrierungsoption könnte 
man das einbauen oder ist der Auwand dafür zu groß???

Wenn das nicht so eine Popelei wäre würde ich gleich den Lötkolben in 
die Hand nehmen...

Gruß Michael

[Michael D. (mike0815)]

Hier mal ein Foto von dem Umbau. Da wo jetzt der 33 Ohmler sitzt, klebte 
vorher der Nuller Wiederstand.
Das ganze natürlich 2mal pro Kanal!

[Michael D. (mike0815)]

ich schon wieder...

Hayo,
Die BF097beta ist mit der BF097-Historie identisch, haben beide dasselbe 
Datum 21.10.2009 und dieselbe Uhrzeit!

Bevor ich das Welec ausschalte, habe ich mal 2 bildchen gemacht.
Das 1Khz Rechtecksignal auf dem 1.Kanal ist vom Probcomp.
Die Einstellung auf dem 1. Foto ist 50mV/div, Timebase auf 5MS/s.
Auf dem 2.Foto 50mV/div und die Timebase auf 1MS/s.
Die Signale sind sehr sauber und werden präzise dargestellt, soweit ic 
das beurteilen kann.
Der 2.Kanal hat irgendwie keine Lust etwas anzuzeigen.
Bei der Triggerverstellung sowie bei der Spannungswahl, friert ab und zu 
das Bild ein.
Jetzt stand in der Preview nur die W2000a.sof vom 27.11.2009 zur 
Verfügung, die laut Beschreibung, noch etwas mit Fehlern behaftet ist.
Könnte sein, das das der Grund für die Freeser sind!

Ansonsten finde ich das neue Design sehr schön gemacht.

Meine Vorgehensweise zum aufspielen der Nios-SW:
Erst den USB-Blaster installieren, dann meldet sich das DSO als 
NIOS-Evulation-Board.
Nach dem installieren des Quartus-Programmer auf Auto-Detectet drücken.
Danach 'ADD-File' und die W2000a.sof auswählen.
Jetzt sind 2 x Dateien im Quartusfenster zu sehen, die ober sollte 
entfernt werden, da es sonst Probleme geben könnte.

Jetzt auf Program drücken und warten bis oben rechts im Fenster 100% 
stehen.
Unten ist noch ein Log, der mitteilt ob auch alles glatt gegangen ist!

Der Bildschirminhalt vom DSO verschwindet nach der Programmierung, also 
keine Panik!
Quartus kann geschlossen werden, abspeichern kann man, muß man aber 
nicht.

Jetzt die Preview1.0 entpacken, die Parameter von der 'Welec_sram.bat' 
angleichen Comport, Baudrate, etc... dann Speichern und wieder 
schliesen.
Die neue sram.bin habe ich in der Preview schon umbenannt, muß also 
alles im selben Verzeichnis sein!

Jetzt nur noch die 'Welec_sram.bat' starten die den Waverecorder in gang 
setzt und die Daten werden im Dosfenster zum DSO übertragen.
Jetzt ist das DSO betriebsbereit. Damit sich was tut, muß erst ein 
Signal dran (1.Kanal, der 2.Kanal zickt)

Ich habe noch mal alles zusammen gepackt inkl. 2 Gifbilder vom 
Quartus-Programmer.


Dann mal viel Spass beim testen

Gruß Michael

[Michael D. (mike0815)]

Hier noch die beiden Fotos vom neuen Nios-Design...

[Robert (RaZer6) (Gast)]

Hallo Leute,

Ich möchte auch wieder einmal ein Lebenszeichen von mir geben.
In den letzten Tagen konnte ich den ersten Commit zum Welec-Projekt 
geben. Genauergesagt arbeite ich an der Firmware des Softcores des 
Leon-Designs.

Unter http://sourceforge.net/apps/trac/welecw2000a/wiki/Leon%20Binaries 
kann man eine Binary des letzten Softwarestandes downloaden, die dann 
mit dem Waverecorder geflasht werden kann. Dieser beinhaltet die erste 
Version eines modularen GUI-Frameworks angelehnt vom Aussehen an die 
Orginal GUI.

Ich lade die Mitentwickler gerne ein, beim Leon-Design zu helfen. Das 
FPGA Design ist sehr vielversprechend denn die digitale 
Signalverarbeitung sowie der Trigger laufen hervorragend. Hier gilt 
wirklich ein großes Lob an Alexander!!

@Michael, hast du die welec_sram.bat im Archiv vergessen?

Liebe Grüße
Robert

[Robert (RaZer6) (Gast)]

Michael D. schrieb:
> er 2.Kanal hat irgendwie keine Lust etwas anzuzeigen.
> Bei der Triggerverstellung sowie bei der Spannungswahl, friert ab und zu
> das Bild ein.
> Jetzt stand in der Preview nur die W2000a.sof vom 27.11.2009 zur
> Verfügung, die laut Beschreibung, noch etwas mit Fehlern behaftet ist.
> Könnte sein, das das der Grund für die Freeser sind!

Der 2. Kanal sollte prinzipell auch funktionieren. Hast du den Trigger 
auf Kanal 2 umgeschalten?

Die Bilddarstellung stoppt sobald nichts mehr getriggert werden kann. 
Das kann passen wenn der Triggerlevel nichtmehr im Signalbereich ist 
(Triggerlevel über dem Signal), hervorgerufen durch eine Änderung der 
Spannung pro Division oder eben des Triggerlevels selbst.

Dies Design ist kein NIOS Design ;) Der NIOS ist eine 
Softcoreimplementierung der Fa. Altera. In diesem Design wird ein Leon3 
Softcore von Aeroflex Gaisler verwendet.

lg Robert

[Michael D. (mike0815)]

Robert (RaZer6) schrieb:
> Hallo Leute,
>
>
> @Michael, hast du die welec_sram.bat im Archiv vergessen?
>
> Liebe Grüße
> Robert

nö, habe eben noch mal nachgeschaut!

Wie kommst du darauf? Hast du sie nicht gefunden?

[Michael D. (mike0815)]

So'n Käse, da fehlt ja noch mehr, ist mir zu hoch!!!

Hier nochmal das komplettes File, gebe dem Kind einen anderen Namen!

Vielleicht ist ein Moderator so nett und nimmt die obere Preview raus?

Gruß Michael

[Robert (RaZer6) (Gast)]

Ich habe eben mehrmal getestet. Im Archiv sind alles Dateien vom 
27.11.09 (auch die alte Softcore Firmware). Aber Welec_sram.bat ist da 
keine drinnen.

Folgende Dateien habe ich im Archiv:
linux (Ordner)
sram.bin
Readme.txt
WaveRecorder.exe
W2000.sof
Quartus_Start_Programmer.png

Sind alles Dateien aus dem ursprünglichen Preview Package von SF.

lg Robert

[Michael D. (mike0815)]

Robert (RaZer6) schrieb:
> Dies Design ist kein NIOS Design ;) Der NIOS ist eine
>
> Softcoreimplementierung der Fa. Altera. In diesem Design wird ein Leon3
>
> Softcore von Aeroflex Gaisler verwendet.

Recht hast du!!! Danke für den Hinweis!
Natürlich meinte ich das Leon3, hatte ständig das NIOS-Evulations-Board 
im Kopp entschuldigt den Fehler.

Gruß Michael

[Michael D. (mike0815)]

oh mann, jetzt hat sich das hier überschnitten.

Das umbenannte ZIP-File ist jetzt aber komplett!

Ist die Anleitung Ok so oder hab' ich was vergessen?

Ich konnte dir keine PN schicken, bist nicht angemeldet?


Der 2.Kanal hat seine eigene Triggereinstellung?
Habt ihr das irgenwo Dokumentiert?

Gruß Michael

[Robert (RaZer6) (Gast)]

Ja ist grad blöd gelaufen.... Mods werden es schon richten ;)

Im Menü von der Taste "Mode Coupling" kann der Triggerkanal auf Kanal 2 
gesetzt werden.

Da das der erste GUI-Test ist, gibt es dazu noch keine Doku.

lg Robert

[Michael D. (mike0815)]

au weia, die falsche Preview wurde 32 mal runter geladen, dafür werde 
ich bestimmt gesteinigt!

Robert,
Jetzt geht der 2.Kanal...

Wie sieht's mit den 10mV/Div aus? Bei 20mV/Div is' schluß!

Kann das Signal nach dem Zoomen verschoben werden? Wie kann ich die 
Flanken Sichtbar machen?

Gruß Michael

EDIT: noch was, Trigger 'NORMAL' ist klar! Was ist Glitch und was hat es 
mit dem Externen auf sich? Bei Extern-Trigger zappelt das Signal ja gut 
ab...

[Blue F. (blueflash)]

Michael D. schrieb:
> Jetzt fällt mir gerade was ein!
> Kann mich erinnern, das wir das Thema schonmal hatten.
> Nämlich der Tausch der NULL-OHM Wiederstände gegen 33 Ohmler, die das
> Signal-Rauschen um einiges reduzierten!
> Wir aber keine Softwareanpassung gemacht haben, da haben wir ja die
> Leiche!

Na das erklärt natürlich einiges. Bei mir ist alles noch im 
Originalzustand.

> Was meinst du, soll ich die Wiederstände wieder raus schmeissen oder
> wäre eine SW-Anpassung sinnvoller? Evtl. als Kalibrierungsoption könnte
> man das einbauen oder ist der Auwand dafür zu groß???

Mann könnte eine manuelle Umschaltung der Faktoren einbauen, allerdings 
gibt es glaube ich auch Leute mit andern Widerstandswerten (23.5Ohm). Da 
wären dann wieder andere Faktoren nötig. Das größte Problem ist 
allerdings, dass ich die Faktoren nicht ermitteln kann, da ich kein 
Gerät mit entsprechenden Widerständen habe.

Bringen denn die Widerstände tatsächlich soviel?

-> Kannst due das Ticket 46 noch entsprechend ändern, damit wir das 
nicht nochmal irgendwann vergessen?


Gruß Hayo

[alex008 (Gast)]

Hallo!

Ich möchte nun ein paar Fragen zum Leon3-Design beantworten:

Tommi aus dem Skype Forum fragte mich, ob die Signaldarstellung ohne der 
neuen Huckepackplatine von branadic und Walter so rauschfrei ist, meine 
Antwort:
Ich wüsste nicht, dass jemand außer branadic und Walter diese Platine 
hätten.
Das Leon3-Design ist bei den 2V, 1V, 200mV, 100mV, Spannungsbereichen 
rauschfreier als das NIOSI-Design.
Die andere Rauschreduktion wird mit einen digitalen Tiefpass-Filter vor 
dem Trigger und der Messwertspeicherung durchgeführt. Das führt 
unweigerlich zu einer Bandbreitenbegrenzung, die das Signal verfälscht. 
Nimmt man bspw. Messdaten mit 1MS/s auf und man hat den Filter von 1GS/s 
-> 100 MS/s eingeschaltet, reduziert sich das Rauschen und die 
Bandbreite ungefähr um den Faktor 8! (Dieser eine Filter sollte hier 
momentant immer eingeschalten sein!)
Bei dem Beispiel von oben darf man dann die Signalveränderung in der 
Regel verhachlässigen! Wenn man diese Filter verwendet, verhält sich das 
Oszilloskop wie ein Oszilloskop mit höherer Genauigkeit und wesentlich 
geringerer Bandbreite.

@Michael
--> Wie sieht's mit den 10mV/Div aus? Bei 20mV/Div is' schluß!

Aufgrund der Austauschbarkeit von Geschwindigkeit und Messgenauigkeit 
geben die digitalen TP-Filter ein 16 Bit Signal aus! (ungleich 16 Bit 
Genauigkeit).
Die Trigger-Messwerterfassung ist so aufgebaut, dass Sie entweder 4*8 
Bit, 2*16 Bit oder 1*32 Bit mit 1 GS/s aufnehmen kann.
Leider hat sich ein kleine Fehler im Trigger eingeschlichen, dass 
momentan nur der 8 Bit Mode richtig funktioniert.
Mit 16 Bit lässt sich dann gefiltert triggerbare Messbereich theoretisch 
bei geringen Abtastraten um den Faktor 2^8=256 verkleinern. Ungefähr den 
Faktor 50 halte ich für sehr realistisch.

@Michael
-->noch was, Trigger 'NORMAL' ist klar! Was ist Glitch ...

Der Glitch-Trigger, welcher auf die steigende Flanke triggert, triggert 
falls die LOW Zeit vor dem Triggerereignis kürzer als ein bestimmter 
Wert ist, NORMAL-Trigger macht das umgekehrt!

Den externen Trigger habe ich noch nicht getestet und es sind 
theoretisch mehrere externe Trigger möglich (digitale Eingänge, 
PC-Steuererung,... für andere Plattformen)!
Der externe Trigger Nr.0 ist ein interes Togglesignal, welches verwendet 
wird, um Signale ohne Triggerung aufzunehmen (Auto-Trigger).
Der externe Trigger Nr.1 sollte auf der Extern BNC Buchse hängen.

Vielen Dank gilt Robert für die neue GUI-Basis!

MfG
Alexander

[Michael D. (mike0815)]

Halloo Hayo,
Habe mal die Doku's über den Einbau der 33 Ohm Widerstände zusammen 
gesucht.
Der 1. Link zeigt an, wo diese auf dem Board zu finden sind:

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Der 2. Link zeigt die ausgetauschten Widerstände:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"


Der 3. Link zeigt das Rauschen vom 1.Kanal vor dem Tausch und das 2.Foto 
nach dem Tausch der Widerstände.
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Schaue es dir an und sag' mir deine Meinung ob es sich lohnt die jetzt 
drinnen zu lassen oder nicht.
Wenn der Aufwand für die SW-Anpassung zu aufwändig ist, dann schmeiß ich 
die wieder raus.
Im HW-Thread, konnte ich mich erinnern, das der Rolf(war's der Rolf?) 
meinte, eine SW-Anpassung vorgesehen sei, will mich da jetzt aber nicht 
festlegen. Das Thema ist hier ja Kilometer lang, bis man da mal was 
findet...

Gruß Michael

[Michael D. (mike0815)]

ich noch mal...

Wie ich sehe, wird die

W2000L_Preview1.0.zip (420,6 KB, 37 Downloads)

weiter herunter geladen, als Hinweiß: Dies ist die Vorgänger-Version vom 
letzten Jahr des LEON3

Die aktuelle Datei ist die: ------W2000L_Preview1.0_komplett.zip------

Drinnen muß sein die schon umbenannte 'sram.bin' , und die 'Batchdatei' 
für den 'Waverecorder'

Vielleicht könnten die Mod's mal Hand anlegen und diese Austauschen???
Dann könnte auch mein restlicher Müll hier gelöscht werden...


Gruß Michael

[anderer Michael (Gast)]

Hallo Leute

Möchte mich einfach einmal bedanken für die tolle Arbeit, die Ihr 
macht!!!

Sowohl Hayo und Kollegen, die aus dem Welec erstmalig ein einsatzfähiges 
DSO gemacht haben, als auch der Truppe um Alex, die mit dem Leon3 Design 
ganz neue Möglichkeiten erschliessen.

Habe heute einmal das Leon3 Design aufgespielt. Das sieht ja schon 
unglaublich gut aus!!! Damit steigt das Welec in ganz andere Dimensionen 
auf.

Also, ehrlich. Vielen Dank für Euer Engagement.

Anderer Michael

[hauptschüler (Gast)]

Hab das neue FPGA design auch gestern mal ausprobiert. Die 
Geschwindigkeit und Triggerstabilität ist ja wohl absolut geil!
Echt Respekt! Weiter so.

Gruß
Torsten

[Blue F. (blueflash)]

@Michael D.

Hi Michael,

ich antworte Dir mal auf diesem Wege, damit alle anderen die auch 
Interesse an der Sache haben mitlesen können.

>Das mit den Widerständen hat mir natürlich keine Ruhe gelassen und habe >bis 
heute Nacht die Dinger wieder getauscht...mit der 10-Fachlupe, 3 >Pinzetten, 
Löthonig, Wattestäbchen und Aceton.......was eine Popelei !

>Wie auch immer... wenn man mal ein einigermassen rauschfreies Signal >gewöhnt ist 
und schaut sich nach dem Tausch das Ergebnis an........
>Ich muß sagen, es besteht ein großer Unterschied ! Die Nullinienkorrektur >hat 
sich natürlich verbessert, das Rauschen hat aber gewaltig zu >genommen !!! Sieht 
furchtbar aus, vielleicht könnte man doch eine >Softwareanpassung in Betracht 
ziehen?

Also wenn der Unterschied so groß ist wäre eine Softwareanpassung 
(umschaltbare Faktoren) sicher ganz praktisch. Damit das Ganze aber 
nicht zu unübersichtlich wird müßte man sich zumindest auf einen 
Widerstandswert einigen. Ich habe da Werte zwischen 20 und 33 Ohm in 
Erinnerung.Welcher Wert ist denn da am meisten vertreten bzw. empfohlen?

Dann würde ich bei mir mal ein Gerät umrüsten damit ich die neuen 
Faktoren ermitteln kann. By the way, was für ein Gehäuse (Bezeichnung) 
ist das  und wo kriegt man die?

Ach ja, ich bin übrigens eifrig am Programmieren. Die Kanal-Delay 
Korrektur funktioniert schon ganz gut.

Gruß Hayo

[Guido (Gast)]

Hallo, jetzt muss ich mich auch mal wieder einmischen. Bei meinem
W2012A ist noch immer ein Kanal mit 22-Ohm-Widerständen manipuliert,
der 2. Kanal im Originalzustand. Ich kann diese Offsetverschiebung
aber nicht nachvollziehen. vielleich kapiere ich das Problem nicht.
Wenn ich die Kanäle rauf- und runterschiebe, erhalte ich maximal
1/10 div Offsetänderung am Kanal in Originalzustand. Das würde ich
aber auf unzureichendes Warmlaufenlassen schieben.

Wie sieht das denn bei den anderen aus?

Grüße, Guido

P.S. @ Hayo: Kümmer dich lieber um den Delayed-Mode ;-).

[Roberto (Gast)]

Hallo mike0815 und andere
Danke für die Erklärung zu dem Leon3
Bei Gelegenheit werde ich es vielleicht probieren..
Derzeit bin ich froh dass es aber wieder so läuft... siehe unten.

Hallo Hayo

Habe deine Version noch mal getestet.
Nulllinienverschiebung habe ich keine!

>- die Screenshotversion passt nicht zu der offiziellen Version
Ja, leider!
Hatte mir das so schön eingerichtet und jetzt funktioniert das leider 
mit deiner Version nicht :-(

Habe dann mal probiert das "About Osciloskop"
Leider komme ich dann aus diesem Fenster nicht mehr raus..
Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann 
nicht mehr weg :-(
Hatte versehentlich auch Kanal 3 Eingeschalten (blau)
Irgendwann, kam ich dann irgendwie raus und auf einmal hatte das Gitter 
eine blaue Farbe :-( :-(

Wollte dann eine neue Version aufspielen, aber mit dem Hauptrechner ging 
es einfach nicht mehr.... Ging dann mit dem Laptop.
Jetzt habe ich wieder die OS Version drauf.
Hier geht der Screenshot wenigstens.

Leider passiert jetzt das, das es zwei verschiedene SW-Versionen gibt 
und in jeder gibt es ein paar gute Dinge.
Leider aber nicht alle in einer Version :-(
Wenn man die eine nimmt, muss man leider auf Dinge der anderen 
verzichten :-(

Im Anhang zwei Bilder zur SW   1.2.OS.0.92
Bild 2 : ist nach dem Einschalten.
Sehe links die Zahlen für die Kanäle, aber keine Linie!
Hier dürfte aber nur Kanal 1 EIN sein.

Bild1 : das passiert, wenn ich mit dem Trigger nach oben fahre...
Ein Haufen von Trigger-Pfeilen
Die Linie von Kanal1 sehe ich erst, wenn ich am Kanalrad drehe 
(Verstärkung)
Die Nummern der anderen Kanäle gehen erst weg, wenn ich einen anderen 
Kanal AUS und EIN schalte...

l.G. Roberto

[Michael D. (mike0815)]

Hallo Hayo,

>Also wenn der Unterschied so groß ist wäre eine Softwareanpassung
>(umschaltbare Faktoren) sicher ganz praktisch. Damit das Ganze aber
>nicht zu unübersichtlich wird müßte man sich zumindest auf einen
>Widerstandswert einigen. Ich habe da Werte zwischen 20 und 33 Ohm in
>Erinnerung.Welcher Wert ist denn da am meisten vertreten bzw. empfohlen?

Die Gehäuse sind '402' mit 1% Tol. ! Man muß aufpassen, das man sie 
nicht aus Versehen einatmet. Guido hat seine 24 Ohmler aus einem CD-Rom 
Laufwerk, glaube ich!
Die 0603er  sind noch vertretbar, hatte in den 2.Kanal mal diese Grösse 
mit '47 Ohm' bestückt, brachte aber keinen deutlichen Unterschied .
Ich denke, das man mit den 33 Ohm am besten fährt!
Ich hatte diese vorher durch gemessen und alle 4 hatten den absolut 
selben Wert.
Im Schaltplan, den ich mal hier anhänge, wird an Pin 2 vom AD8131 eine 
Spannung von 1,4V als Ideale Einstellung für den ADC-Eingang 
(Adjustment) angegeben.
Ich werde das mal messen, mal schauen, was bei raus kommt!
Hoffentlich habe ich keinen HW-Defekt!


Hallo Guido,

Genau, wie es bei den Anderen aussieht, würde mich auch sehr 
interessieren!
Im 'Ticket 46' Zeroline... ist es nochmal beschrieben.

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


Hallo Roberto,

>Habe dann mal probiert das "About Osciloskop"
>Leider komme ich dann aus diesem Fenster nicht mehr raus..
>Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann
>nicht mehr weg :-(

Dasselbe Problem hatte ich auch mit Hayo's 097er FW !!!
Hatte das File mehrmals geflasht, da der Germsloader ja keine 
Fehlermeldung ausgibt, weißt du nie, ob alles übertragen wurde.

Das blaue Gitter kenne ich auch!

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:
>
>>Habe dann mal probiert das "About Osciloskop"
>>Leider komme ich dann aus diesem Fenster nicht mehr raus..
>>Habe dann ein paar Tasten gedrückt, aber das Versionsfenster geht dann
>>nicht mehr weg :-(
>
> Dasselbe Problem hatte ich auch mit Hayo's 097er FW !!!
> Hatte das File mehrmals geflasht, da der Germsloader ja keine
> Fehlermeldung ausgibt, weißt du nie, ob alles übertragen wurde.
>
> Das blaue Gitter kenne ich auch!


Hallo Jungs,

ja das Problem hatte ich auch schon bemerkt - und auch beseitigt.

Habe meine neue Version fast fertig mit einigen neuen Guties zum 
Ausprobieren

-> BF.0.98 coming soon...

Gruß Hayo

[Roberto (Gast)]

Hallo toll dass es weiter geht!!!
wird 0.98 dann schneller anzeigen wie die Version von Rolf oder so 
langsam wie immer? Welche screenshot.exe braucht man dafür????

R.

[Roberto (Gast)]

He, wer schreibt mit meinem Namen ?
Hallo Hayo

Mir würde es sehr gefallen, wenn deine  Version auch mit der neuen 
Screenshot funktionieren würde!
l.G. Roberto

[Kurt B. (kurt)]

Hallo Roberto,
welchen Vorteil versprichst du dir davon? Alles was Hayo's BF Version 
kann, sollte doch auch in der OS Version vorhanden sein? Oder kannst du 
es nur nicht erwarten etwas neues auszuprobieren? ;-)

Mfg,
Kurt

[Roberto C. (Firma: ompjn) (roberto-der-echte)]

Roberto schrieb:
> He, wer schreibt mit meinem Namen ?

Dein Name?

> Hallo Hayo
>
> Mir würde es sehr gefallen, wenn deine  Version auch mit der neuen
> Screenshot funktionieren würde!

mir täte es gefallen wenn die geschwindigkeit so schnell wäre wie bei 
Rolf (rowü?)

l.G. Roberto

[Bernd O. (bitshifter)]

Hallo zusammen,

ich habe ein Hardware-Problem mit meinem 2024. Als ich das Oszi vor ca. 
5 Monaten zum letzten Mal genutzt habe war noch alles in Ordnung. Nun 
passiert nach dem Einschalten folgendes:

Der Lüfter läuft los, die Hintergrundbeleuchtung des Bildschirms 
leuchtet, sämtliche LEDs gehen an, aus und wieder an - und dann 
geschieht nichts weiter. Durch Drücken der beiden linken Tasten wird das 
LCD weiß und der Germs-Loader startet. Ich kann dann beispielsweise ein 
Flash- oder RAM-Image runterladen. Nach dem Runterladen gehen die LEDs 
wieder an, aus und wieder an - und das war's. Aus- und wieder 
Einschalten über den Hauptschalter führt zum gleichen Ergebnis.

Wenn das Oszi ca. 15 Minuten in diesem Zustand eingeschaltet bleibt, 
dann läuft es irgendwann wie erwartet los und alles funktioniert wie 
erwartet. Auch wenn ich das Oszi dann über den Hauptschalter aus- und 
wieder einschalte, startet es problemlos.

Scheint also ein thermisches Problem zu sein, das sich warum auch immer 
nur auf die "höheren" Funktionen des Oszis auswirkt. Der Germs-Loader 
funktioniert aber schon direkt nach dem Einschalten problemlos.

Kennt jemand dieses Fehlerbild bzw. kann mir jemand einen Tipp geben, wo 
ich hier suchen soll?

Gruß,
Bernd

[Blue F. (blueflash)]

Hallo Bernd,

um den Zeitpunkt des freezing weiter einzugrenzen solltest Du Dir 
mittels Terminalprogramm während der Startphase die Meldungen anschauen. 
Wenn die Startmeldungen alle durchlaufen würde ich auf ein 
Displayproblem tippen, ansonsten müßte man mal sehen welches die letzte 
Meldung ist.

@Roberto (1+2)

Ich schau mal was ich machen kann.



Gruß Hayo

[Blue F. (blueflash)]

So Ihr Lieben,

ich war bis eben recht fleißig, aber jetzt ist mal Schluß. Irgendwann 
muß auch mal der gemütliche Teil des Wochenendes anfangen.

Ich kann dafür mit etlichen Guties zum Ausprobieren aufwarten - ich 
denke es wird Euch gefallen:

- die Remoteschnittstelle ist jetzt kompatibel zur O.S.92a
- die Screenshotfunktion ist jetzt kompatibel zur aktuellen Version

Beides habe ich bislang nicht getestet - ich bitte um Rückmeldung.

- ich habe den neuen Triggermodus von Stefan eingebaut. Er heißt bei mir 
allerdings Combi-Trigger (wegen kombiniertem Auto und Normalmodus)
- es gibt ein neues Utilitysubmenü, hier findet Ihr:

- Eine Auswahlmöglichkeit wie die ADC-Register gesetzt werden
- Eine Kanalverschiebungskompensation

- Desweiteren habe ich die DAC-Kalibrierung stark überarbeitet. Es 
braucht jetzt nur noch einmal kalibriert zu werden. Es werden alle 
Spannungsbereiche auch der nicht aktiven kanäle in einem Durchgang 
kalibriert.

Die DAC-Korrekturwerte stehen jetzt im Protected Flash. Durch die 
diversen Änderungen muß nach dem Flashupdate erstmal das Scope neu 
kalibriert werden:

1. default setup drücken
2. Zerolines suchen
3. ADC-Kalibrierung
4. DAC-Kalibirerung

Die aktuelle Menüstruktur entnehmt Ihr bitte der beigelegten Programming 
Map. Alles andere steht im Changelog.

Viel Spass

Hayo

[Michael H. (Gast)]

Hi Hayo,
super, dass du dich zurückmeldest und gleich wieder so fleißig bist! 
Vielen Dank dafür!
Ich habe deine Firmware schonmal draufgehaut, allerdings erst ganz 
flüchtig getestet - mangels Signalgenerator kann ich leider nicht 
allzuviel probieren. Macht auf jeden Fall einen guten Eindruck!

Allerdings wollte ich noch - etwas verspätet - melden, dass ich dasselbe 
Problem wie der andere Michael habe: wenn ich nen Kanal hoch- oder 
runterverschiebe, dann verhaut es mir die ganze Kalibrierung, vor allem 
beim nach oben schieben. Es tritt auf allen Kanälen auf, allerdings 
unterschiedlich stark und nach jeder Kalibrierung etwas anders. Wenn man 
den Kanal wieder runterschiebt, passt wieder alles. Haben das noch 
andere und fällt jemandem dazu eine plausible Erklärung ein?
Irgendwie will mir das nicht ganz einleuchten, aber vielleicht hat es 
doch was mit den Widerständen zu tun, denn ich habe auch 33Ohm in Serie 
zu den ADCs liegen...

Viele Grüße
Michael

[Michael H. (Gast)]

Der Offset ist sehr merkwürdig: wenn ich die Spannungsbereiche 
durchschalte, bleibt die Linie auf der Stelle, d.h. der Offset skaliert 
in der Darstellung immer schön mit, so als würde sich der Absolutwert 
beim Umschalten von 5V auf 10V verdoppeln.
Zum Vergleich wollte ich gerade die Sourceforge Version 0.91 testen, 
aber die scheint nicht mehr zu funktionieren, nachdem die neue BF drauf 
war...Scope lässt sich nur noch zu Schnappschüssen überreden, nicht mehr 
zu Dauersamplen.

Leider bin ich mir nicht mehr sicher, ob das Offsetproblem vor dem 
Einsetzen der Widerstände auch schon so aussah.
Wie sieht das beim Rest der Crew aus?

Gruß
Michael

[Michael H. (Gast)]

Keine Sorge, der vorerst letzte Post zu dem Thema:
Bei 0.92a Sourceforge tritt das Problem identisch auf.
Meine Hardwarerevision ist 8C7.C9.

Gruß
Michael

[Michael D. (mike0815)]

Hi Hayo,
der 3. Trigger ist eingebaut, totschick...

Die Nullliniencalibrierung funzt auch, wie beschrieben, mußte nur 1x den 
DAC wiederholen, dann hat es gepasst!
Kann das sein, das das Rauschen in den 5er DIV.-Bereichen abgenommen 
hat?

Was hat es mit der ADC-Setting: FACTORY, HIGH FREQ. und den TEST1-3 auf 
sich und wie wird diese bediehnt?


Hallo Michael H.,

Ich hatte auch die 33 Ohmler drinnen, ärgere mich jetzt ein bißchen, das 
ich diese wieder getauscht habe, da das Grundrauschen um Einiges zu 
genommen hat!
Die Linienverschiebung ist mit den 0 Ohm etwas minimaler, aber trotzdem 
noch vorhanden.
Während der Messungen, hatten sich die Linien verschoben, so das noch 
Spannungen angezeigt wurden, die garnicht mehr da waren. Werde das mit 
der neuen FW. mal testen, ist ja Einiges gebaut worden...

Unter "UTILITY" ist die Option "MORE" für einen "Channnel-Delay" CH1, 
CH2, von 0-16nS !
Vielleicht testest du mal einige Einstellungen damit. Je höher der 
Delay, desto weiter runter kommt die Line. Mußt aber nach jeder 
Delay-Auswahl neu calibrieren, sonst tut sich nix!!!

Wie sieht's denn bei dir mit dem Rauschen nachdem Tausch der Widerstände 
aus?

Gruß Michael

[Michael H. (Gast)]

Hi Michael.
Wie bei allen anderen ist auch bei mir das Rauschen durch die 
Widerstände merklich besser geworden, weshalb ich sie auch ungern wieder 
rausnehmen möchte.
Die Delayeinstellungen sind eine tolle Sache, muss ich mal testen. 
Allerdings bestimmt nicht, um damit den Offset zu kompensieren! Die sind 
doch dafür da, um den zeitlichen Versatz zwischen den Kanälen 
auszugleichen, der durch die Verwendung von zwei FPGAs in den 
Vierkanalgeräten auftritt.
Ich kann mir beim besten Willen auch nicht vorstellen, dass das den 
Offset irgendwie beeinflusse sollte, aber wenn du jedes Mal neu 
kalibrierst ist es natürlich klar, dass sich was ändert.

Die ADC settings sollen es Leuten mit verschiedenen Geräteversionen 
ermöglichen, die für sie optimale Einstellung zu wählen, es hat sich ja 
gezeigt, dass es da wohl Unterschiede gibt. Allerdings siehst du den 
Unterschied nur bei sehr kleinen Zeitbasen / hohen Frequenzen.

Michael

[Michael D. (mike0815)]

Hi Michael H.

>Die Delayeinstellungen sind eine tolle Sache, muss ich mal testen.
>Allerdings bestimmt nicht, um damit den Offset zu kompensieren!

Das hatte ich mir fast gedacht. Deshalb ja meine Frage, was es mit den 
"MORE-Optionen so auf sich hat!
Ich habe das W2022, da besteht das Problem ja nicht.

Wenn die Widerstände per SW angeglichen werden könnten, wäre das eine 
feine Sache, dann würde ich die wieder einbauen!

Ich habe heute mal mit einem XR2206 einen FG. auf dem Breadboard 
zusammen geschustert, der ist wohl nur mit 1MHz angegeben, da ging aber 
noch was, wie man sieht!
Vielleicht wäre das eine vorübergehende Alternative für dich?!?

Hier mal ein Foto mit der neuen FW. vom Hayo.

Gruß Michael

[Blue F. (blueflash)]

Noch ein kurzer Kommentar bevor ich für heute abtauche:

- die Offsetverschiebung hängt mit Sicherheit mit den Widerständen 
zusammen. Bei meinen beiden Geräten tritt das nicht auf. Vielleicht kann 
da jemand mit ebenfalls unveränderter Hardware was zu sagen?

- die ADC-Registereinstellungen kann man nach der Einstellung im 
Utility-Submenü einfach überprüfen indem man sich mittels 
Terminalprogramm und der Taste "," die Variablen anzeigen läßt.

Hier noch mal schnell ein kleiner Überblick_

- High Frequ -> adc_change12 = adc_change34 = 0x01000000 diese 
Einstellung hat sich bei meinen beiden Geräten insbesondere bei hohen 
Frequenzen bewährt.

- Factory -> die ADC-Register werden mit den Werkseinstellungen aus dem 
Protected-Flash gesetzt. Bei mir ist das für adc_change12 = 0x02020f00 
und für adc_change34 = 0x0200000a. die add-Register werden ebenfalls aus 
dem Flash geladen (add12 = 0x5f0a, add34 = 0x5f5f).

- Test1 -> das ist der Registerwert von Falk, der auch in der O.S. 
Version benutzt wird (0x00020000)

- Test2 -> adc_change12 = adc_change34 = 0x00000000

- Test3 -> adc_change12 = adc_change34 = 0x01020800 - Diese einstellung 
verursacht bei mir die schon bekannten Störungen auf den Signalflanken

Auf Wunsch kann man da auch andere oder zusätzliche Werte hinterlegen.

Gruß Hayo

[Michael D. (mike0815)]

Ab 250MSa/s 5µs aufwärts (bei beiden Kanälen), hauen wieder die Spikes 
durch den ganzen Bildschirm.
Verschiebe ich das Signal nach unten oder oben, werden diese mal mehr, 
mal weniger! Hatten wir ja schon mal.

Michael H.

Du hast doch noch die 33 Ohm Widerstände drinnen, wie sieht das bei dir 
aus mit den Spikes?

Gruß Michael

[Michael D. (mike0815)]

ich noch mal,

gestern hatte ich bei der Obigen Messung (Bild XR2206) den 
'NOISE-FILTER' an, der die Spikes fast völlig unterdrückt. Währe 
interessant zu wissen, ab welcher Frequenz der Noise-Filter einsetzt!

Gruß...

[Blue F. (blueflash)]

Michael D. schrieb:
> Ab 250MSa/s 5µs aufwärts (bei beiden Kanälen), hauen wieder die Spikes
> durch den ganzen Bildschirm.

Bei welcher Einstellung?

Als Referenz am besten Factory Setting benutzen. Da sollte ja eigentlich 
alles hinhauen. Wenn nicht -> die anderen Einstellungen ausprobieren!

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:

> gestern hatte ich bei der Obigen Messung (Bild XR2206) den
> 'NOISE-FILTER' an, der die Spikes fast völlig unterdrückt. Währe
> interessant zu wissen, ab welcher Frequenz der Noise-Filter einsetzt!


Der Noise Filter arbeitet bei allen Nicht-USTB Zeitbasen! Die 
Wirksamkeit hängt allerdings von dem jeweiligen Zeitfaktor ab, da dieser 
dafür verantwortlich ist wieviel überschüssige Samples für die 
qualitative Verbesserung des Signals verwendet werden können.

Gruß Hayo

[Michael D. (mike0815)]

Hallo Hayo,

die Spikes treten schonmal bei 5v, 2V und 1V division auf! Zeitbasen von 
250Msa/s -1Gsa/s
Ich teste das mal mit der Factorie-Einstellung, was bewirkt diese denn?
Muß ich nach der Auswahl, Factorie z.B., jedes mal eine komplette 
Neucalibrierung durchführen oder wird diese gleich in das ADC-Register 
geschrieben?

Hayo W.

> Der Noise Filter arbeitet bei allen Nicht-USTB Zeitbasen! Die
> Wirksamkeit hängt allerdings von dem jeweiligen Zeitfaktor ab, da dieser
> dafür verantwortlich ist wieviel überschüssige Samples für die
> qualitative Verbesserung des Signals verwendet werden können.
>
>

...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde 
das geändert?

Gruß Michael

[branadic (Gast)]

Michael D. schrieb:
> ...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde
> das geändert?

Das war schon immer so! Da das Oszi 1GS hat, woher sollen die 
zusätzlichen Samples für ein Noise-Filter herkommen?
Das Noise-Filter macht doch nichts anderes, als mit den zusätzlichen 
Samples einen Mittelwert zu bilden. Sprich, bei der Timebase mit 500MS 
sollten das zwei Werte sein, bei 250MS entsprechend vier. Also kann das 
Noise-Filter bei 1GS faktisch nicht mehr funktionieren.

branadic

[Blue F. (blueflash)]

Michael D. schrieb:

> Ich teste das mal mit der Factorie-Einstellung, was bewirkt diese denn?
siehe oben

> Muß ich nach der Auswahl, Factorie z.B., jedes mal eine komplette
> Neucalibrierung durchführen oder wird diese gleich in das ADC-Register
> geschrieben?

die neuen Settings sind sofort aktiv. Neukalibrierung ist nicht 
notwendig, da diese mit den Registereinstellungen nichts zu tun hat

Gruß Hayo

[Blue F. (blueflash)]

branadic schrieb:
> Michael D. schrieb:
>> ...ab 1GSa /s und 10ns ist der NOISE-Filter nicht mehr aktiv, oder wurde
>> das geändert?
>
> Das war schon immer so! Da das Oszi 1GS hat, woher sollen die
> zusätzlichen Samples für ein Noise-Filter herkommen?
> Das Noise-Filter macht doch nichts anderes, als mit den zusätzlichen
> Samples einen Mittelwert zu bilden. Sprich, bei der Timebase mit 500MS
> sollten das zwei Werte sein, bei 250MS entsprechend vier. Also kann das
> Noise-Filter bei 1GS faktisch nicht mehr funktionieren.

Das ist so nicht korrekt!

Der theoretische Vorteil wenn man nur überschüssige Werte verwendet ist, 
dass keine Bandbreitenbegrenzung auftritt.

Das Noise-Filter arbeitet auch bei den 1GSa/s Zeitbasen. Der Unterschied 
zu den Zeitbasen mit Werteüberschuss (draw_factor > 1) ist jedoch, dass 
die Werteüberlappung zu einer Bandbreitenbegrenzung führt. Ich habe die 
Überlappung jedoch so klein gewählt, dass der Bandbreitenverlust nur die 
Frequenzen betrifft, die das Scope ohnehin nicht mehr brauchbar sampeln 
kann. Man kann die Filterfunktion also ohne Verlustängste haben zu 
müssen einsetzen.

Gruß Hayo

[branadic (Gast)]

Hallo Hayo,

also handelt es sich bei 1GS-Zeitbasen um ein gleitendes 
Mittelwertfilter? Irgendwoher muss ja die Information genommen werden!?

brandic

[Blue F. (blueflash)]

Ja, die Informationen stammen von den Nachbarwerten. In diesem Fall zwei 
Werte davor und ein Wert danach. Bei den anderen Zeitbasen sind es je 
nach Faktor mehr Werte. Je mehr Werte verwendet werden, desto besser 
arbeitet das Filter.

Gruß Hayo

[Michael D. (mike0815)]

Hallo Hayo,

Das Filter arbeitet wirklich gut, bei den 5V, 500mV und 50mV/DIV sind 
die Signale auch ohne Filter gut.
Bei den restlichen Spannungsbereichen sieht das ohne Filter nicht so 
toll aus, wurde in der Bedienungsanleitung von Welek ja auch so 
beschrieben!


...ich bekomme die Spikes nicht in den Griff, egal welche 
Einstellung(Factory...etc.) ich teste, auch nach einer mehrstündigen 
Warmlaufzeit nicht! Ab 250Msa/s -1Gsa/s und allen Spannungsbereichen, 
sobald ein Signal anliegt, egal ob internes 1KHz-Rechteck-Signal oder 
Externes!

Gruß Michael

[Michael H. (Gast)]

Ich muss meinem Namensvetter leider zustimmen: die Spikes sind bei mir 
auch nicht kleinzukriegen, sie treten bei den verschiedenen ADC settings 
lediglich unterschiedlich oft auf. Vielleicht ist das mal wieder ein 
Punkt, in dem sich die Geräteversionen merklich unterscheiden und für 
die Revision von uns Michaels bräuchte man noch eine andere Einstellung? 
Da das Oszi in letzter Zeit nicht benutzt wurde, bin ich mir nicht mehr 
völlig sicher, ob die Spikes bei der letzten Version auch auftraten oder 
nicht, ich werde das aber gleich nochmal überprüfen.
Die Idee mit der Umschaltung finde ich auf jeden Fall recht gut, so kann 
man vielleicht nach und die optimalen Einstellungen für alle 
Osziversionen finden und dort einpflegen.

Gruß

Michael

[Michael H. (Gast)]

Also bei der 0.92 SF tritt das Spike-Problem bei mir ebenfalls auf, es 
ist also definitiv kein Problem von Hayos neuer Firmware. Das hatte ich 
mir auch schon gedacht, war mir aber nicht mehr völlig sicher.
Die neue Bf 0.98 ist meines Erachtens also im Moment definitiv die beste 
Wahl.

Gab es denn nicht schonmal eine Lösung, die sowohl die Spikes als auch 
die hässliche Treppenbildung im Signal unterbindet?

Kann mir jemand sagen (Alex weiß das doch bestimmt), ob es noch 
unbenutzte IOs an den FPGAs gibt und ob Welec davon welche rausgeführt 
hat?

Gruß
Michael

[Michael D. (mike0815)]

Na, da bin ich ja beruhigt, das das nicht bei mir nur so ist, dachte 
schon, ich hätte was kaputt gemacht...

Nach RUN-Stop habe ich mal die Zeitbasen bei 250Msa/s durch geschaltet, 
in der 2µs, 5µs Stellung sind die Spikes am heftigsten, habe mal ein 
Foto davon gemacht.
Komischerweise ist ab 1Gsa/ nicht's mehr zu sehen, blick da net mehr 
durch

Michael H.
Du hast doch ein W2024, oder?
Ich habe das  W2022A HW-Ver. 8C7.OL

Gruß Michael

[Roberto (Gast)]

Hallo Michael D.
Habe mal deinen Versuch nachgestellt...

Bei mir kommen ab und zu Striche, im letzen Wellenberg von der 
Sinusschwingung.
Passiert max. bis zum zweiten Wellenberg von rechts.
Der Strich geht dann aber nach unten!

Habe aber jetzt wieder die OS verion drauf.. 1.2.OS.0.92
W2024A  Hardware Verson 8C7.C9

Signal 200kHz pk-pk 10V
Eingestellt 2V/div

Warum zeigt es bei dir eigentlich 21V an ? Misst er da die Spikes mit ?
Bei mir kann ich aber nur 250MSa/5us  und 500MSa/2,5us einstellen ?!


Habe jetzt nochmal gemessen:

Bei mir tritt das jetzt auf von ca.
25MSa/s 10us   bis     1GSa/s 100us

Das Ganze ist auch stark abhängig von der Frequenz.

z.B. habe ich mit 200kHz bei 1GSa/s 200ns nix, aber wieder bei 20kHz 
etwas.
Teilweise ist es so, je weniger von der Schwingung dargestellt wird, je 
mehr Störungen gibt es..

l.G. Roberto

[Roberto (Gast)]

ups.... Du hattes ja nur 100kHz
Je nach Frequenz tritt der Effekt dann auch am ganzen Schirm auf
(link bis rechts)

[Michael D. (mike0815)]

Hallo Roberto,

hast Recht, bei 200KHz sind die Spikes etwas weniger!
Und je nach dem, wohin das Signal verschoben wird(hoch o. runter), 
wird's mehr oder weniger...komisch

Die 21V sind natürlich nicht korrekt, hatte aus versehen den Prob auf 
2:1, hatte mich schon gewundert wo die hohe Spannung plötzlich herkommt.

Gruß Michael

[Blue F. (blueflash)]

Hi,

kurzer Zwischenbericht:

Ich experimentiere gerade an einer Umschaltung für die Verstärkung 
herum, dammit wir eine Lösung sowohl für die "Standard" Geräte als auch 
für die modifizierten finden.

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> Na, da bin ich ja beruhigt, das das nicht bei mir nur so ist, dachte
> schon, ich hätte was kaputt gemacht...
>
> Nach RUN-Stop habe ich mal die Zeitbasen bei 250Msa/s durch geschaltet,
> in der 2µs, 5µs Stellung sind die Spikes am heftigsten, habe mal ein
> Foto davon gemacht.
> Komischerweise ist ab 1Gsa/ nicht's mehr zu sehen, blick da net mehr
> durch


So, habe mir die Sache mit den Spikes noch mal näher angesehen und 
festgestellt, das diese bei mir ebenfalls wie beschrieben auftreten, nur 
war mir das nie so aufgefallen, da ich meistens in den 1 GSa Bereichen 
teste.

Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem 
am ADC-Register Setting. So konnte ich bei mir beobachten, dass die 
Spikes beim Factory Setting am geringsten sind und auch bevorzugt am 
Ende der Meßstrecke auftauchen. D.h. wenn man im Memoryfenster bis an 
den Anfang kurbelt treten sie fast überhaupt nicht mehr auf.

Eine Erklärung habe ich dafür Momentan nicht. An dieser Stelle möchte 
ich allerdings Stefan nochmal mein dickes Lob aussprechen für den sehr 
gelungenen neuen Triggermodus, der die Signale mit eiserner Faust im 
Griff hält wo der Automodus nur am hin und her zappeln ist - super!

Gruß Hayo

[Falk W. (dl3daz)]

Hayo W. schrieb:

...

> So, habe mir die Sache mit den Spikes noch mal näher angesehen und
> festgestellt, das diese bei mir ebenfalls wie beschrieben auftreten, nur
> war mir das nie so aufgefallen, da ich meistens in den 1 GSa Bereichen
> teste.

> Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem
> am ADC-Register Setting.

So ist es: Entweder man hat übel verzerrte Signale oder Spikes. 
(http://www.youtube.com/watch?v=aD_A3JPSxlc)

Wenn ich mich richtig erinnere, erscheinen die Spikes immer am Ende des 
Readout-Buffers, wenn der Trigger durchlief und hatten immer den 
gleichen Wert und den gleichen Abstand. Dieser änderte sich, wenn die TB 
geändert wurde.

Hier sieht man das ganz schön: 
http://www.youtube.com/watch?v=5tb16NtTws0

Falk,
der momentan kaum zum Basteln kommt.

[Michael D. (mike0815)]

Hi Hayo,

Hayo W. schrieb:
> Ich experimentiere gerade an einer Umschaltung für die Verstärkung
>
> herum, dammit wir eine Lösung sowohl für die "Standard" Geräte als auch
>
> für die modifizierten finden.

...sag' blos, das das möglich ist! Da käme Freude auf, denn in den 1er, 
2er, 100, 200mV/DIV, usw. -Bereichen, macht das Messen ohne Nois-Filter 
keinen Spaß!

Hayo W. schrieb:
> Das Ganze hängt definitiv nicht an der Firmware, sondern unter anderem
>
> am ADC-Register Setting.

...je nach Stellung der Nulllinie, verändern sich diese (Spikes) 
ebenfalls.
Es reicht manchmal nur ein 'Klick', nach oben oder unten.


Der 3. Trigger ist wirklich eine feine Sache, da brauch man den 
Auto-Modus nicht unbedingt und kann diesen vernachlässigen!


Im HW-Thread, hat branadic noch an der Vorstufe getüfftelt, mal sehen, 
was dabei heraus kommt. Bin schon ganz gespannt!

Gruß Michael

[Blue F. (blueflash)]

Also mein Workaround für die Spikes ist folgender:

- ADC-Setting auf "Factory"
- den Memorybrowser ganz zum Anfang kurbeln
- Noisefilter an

Mit diesen Einstellungen sind die Spikes so gut wie verschwunden


@Michael

Ja die Umschaltung ist schon eingebaut. Aber das Problem ist, wie schon 
beschrieben, die richtigen Faktoren zu ermitteln da ich noch kein 
umgerüstetes Gerät habe. Dazu kommt das es noch keine einheitlichen 
Werte gibt. Wenn ich mich recht entsinne empfiehlt der Reference Guide 
24 Ohm. Einige von Euch haben 33 Ohm oder 47 Ohm oder 22 Ohm oder auch 
11 Ohm.

Ich suche gerade auf alten Platinen nach geeigneten Widerständen - mal 
sehen.

Gruß Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> - ADC-Setting auf "Factory"
>
> - den Memorybrowser ganz zum Anfang kurbeln
>
> - Noisefilter an
>
>
>
> Mit diesen Einstellungen sind die Spikes so gut wie verschwunden

...sag' ich doch! Ich denke, damit könnte man leben.


Ich hatte die 24 Ohm, 33 Ohm und dann die 47er drinnen!
Die 33 Ohm waren am effektivsten, die 47 Ohm brachten keine merkliche 
Besserung!
Das mal zur Info.

Gruß Michael

[Blue F. (blueflash)]

Na dann werde ich mal nach 33 Ohm Ausschau halten. Ich werde nachher 
noch eine neue Oster-Version hier einstellen, da könnt Ihr dann schon 
mal mit den Verstärkungen rumspielen.

Gruß Hayo

[Blue F. (blueflash)]

Also hier ist sie, die Easter Edition.

Die Verstärkung läßt sich erstmal nur via Terminal und Shift + G (für 
Gain) umstellen (Menü kommt später).

Gain Index 0: Standard gain und standard Faktoren
Gain Index 1: alle Bereiche mit gain 1.25 (statt 1 in den 1er + 2er)
              die Faktoren sind auf Null Ohm Widerstände ausgelegt.
Gain Index 2: wie 1, aber mit geändertem Zeroscale Faktor.

Voreingestellt ist Gain Index 1. Bitte beachten das für Gain Index 2 die 
Faktoren erst mal aus dem hohlen Bauch heraus gewählt sind und natürlich 
noch angepasst werden müssen wenn ich erstmal die Widerstände drin habe. 
Nach dem Ändern des Gain Index immer erstmal DAC-Kalibrierung 
durchführen!

Ich bin dann erstmal über Ostern weg. Ich wünsche Euch schöne 
Feiertage...

Bis dann

Hayo

[Blue F. (blueflash)]

p.s. @Michael

wie sieht es mit den Netzschaltern aus? Wollte die mal nach Ostern 
tauschen.

Gruß Hayo

[Rainer W. (rawi)]

Hayo W. schrieb:
> Ich suche gerade auf alten Platinen nach geeigneten Widerständen - mal
> sehen.

Ich habe bei mir größere Widerstände eingesetzt, sofern das 
angeschlossene OP-Beine direkt neben dem 2ten Pad liegen. Der Widerstand 
hängt dann als "Brücke" zwischen erstem Pad und OP-Anschluß - 
erleichtert die Suche.

Schöne Ostern - Gruß Rainer

[Roberto (Gast)]

Hallo
Habe gerade was anderes zu den Spikes gefunden:
http://www.youtube.com/watch?v=zuE-jkpyN4Q&feature=related
Irgendwie schauen die bei uns auch so aus, nur nicht so gleichmässig.. 
und nicht so oft.
Zum Testen würde ich einen durchstimmbaren Frequenzgenerator empfehlen.
Bei 200kHz waren die Spikes zuerst auch nur ganz rechts. Bei anderen 
Frequenzen sind sie aber überrall möglich.
l.G. Roberto

[Rolf W. (rowue)]

Nabend allerseits ...

nun bin ich einigermaßen hier unten gelandet, die Geräte sind ausgepackt 
und grob getestet und anscheinend schon mal nicht schlechter geworden ;)

a) Zu den Vorwiderständen: ich denke, dass das Rauschen selbst nicht 
besser wird, allerdings wird durch die Widerstände die Gesamtamplitude 
an den ADC's geringer (etwa 70%) und somit fällt das Rauschen nicht mehr 
so auf.
Durch die schlechtere Quantisierung wird der Quantisierungsfehler 
(Quantisierungsrauschen) sogar größer.

b) Zur Anpassung an die Widerstände: im svn findet sich ein Ansatz von 
Falk, mit welchem die Darstellung bei gleich-aussteuernden 
Verstärkerstufen (1,2,5), wie z.B. in der svn-Firmware, beschleunigt 
wird. Diese Routinen lassen sich mit etwas Arbeit so erweitern, dass 
diese "automatisch" auf die entsprechenden Widerstandskombinationen 
ausgeweitet werden können.

c) Es gibt keine "rowue-Version" - ich hatte aus dem svn eine Version 
zusammengestellt, nach dem sich bei der 0.92 ein böser Fehler 
eingeschlichen hat. Die Firmware (zumindest aus dem svn) besteht aus der 
Arbeit von hr. Fellnhofer(sp?), Hayo, Falk, Stefan und mir - wenn ich da 
nicht noch jmd. vergessen habe

d) Hatte ich ja - vor meinem Umzug - noch erzählt, dass ich einen 
weiteren, bösen Fehler gefunden habe. Dazu mehr im nächsten Post.

Beste Grüße,

   rowue

[Rolf W. (rowue)]

Hi, wie vor einiger Zeit beschrieben, bin ich bei meinen Messungen zu 
den Verwürfelungen in den 250 und 500 MSa/s Modi im 1GSa/s Modus auf ein 
anderes Problem gestossen.

Die Samples im 1GSa/s Modus sind nicht äquidistant!

Zu sehen ist das sehr schön an dem Screenshot einer steigenden Flanke, 
die Plateaus (rote Ellipsen) sind ein Zeichen dafür, dass "zu nah" 
gemessen wird. Die Auswertung eines 15.55 MHz Dreieck-Signals (6 Bit/ns 
Steigung) zeigt das Problem deutlich. Die relativen Samples 2 und 3, 
sowie 6 und 7 werden nahezu zeitgleich genommen. Die grauen Kreise 
stellen die notwendigen Sample-Punkte dar.

Da dies ein Fehler im FPGA ist, werden wir auf Seiten der Nios-FW wenig 
machen können. Wir können die theoretischen Werte lediglich 
interpolieren, wobei es auch hier zu Fehlern kommen wird. Welcher Weg 
hierbei gegangen wird, sollte im Vorwege diskutiert werden.

Vorschläge:

 * lineare Interpolation: Aus dem gemessenen Werten n(1) und n(2), sowie 
n(3) und n(4) werden die wahrscheinlichen Werte für n(2) und n(3) linear 
interpoliert.
 * Zusammenfassung auf 500MSa/s: über die Mittelwerte der richtig 
abgetasteten Werte wird das Signal mit einer Abtastrate von 500MSa/s 
abgeleitet - auch dies ist mit Fehlern für nicht-lineare Signalverläufe 
verbunden.

Beste Grüße,

   rowue

[banadic (Gast)]

Hallo Rolf,

weiterer Vorschlag:

Energie in die Entwicklung der Firmware für das LEON3-Design stecken und 
NIOS vergessen. Je mehr Leute sich daran beteiligen, desto eher ist das 
Leon3-Design sinnvoll nutzbar.

Gruß und frohe Ostern, branadic

[Rolf W. (rowue)]

Hi André,

Möglichkeit vier:

 Schauen, ob da evtl. wieder was im Source verbockt wurde. Ich erinnere 
mich gerade grob an die Verstärker-Einstellungen (1.25, 2, 4 ggü. 1, 
2.5, 5). Ich könnte mir vorstellen, dass auch an dieser Stelle etwas 
schlecht dokumentiert oder nicht verstanden wurde.

Beste Grüße,

 schöne Ostern,

  rowue

[banadic (Gast)]

Hallo Rolf,

bisher ist das Interesse der Programmierer am Leon-Design etwas mager. 
Das ist, in Anbetracht der Tatsache das diese Plattform vollständig 
OpenSource ist, sehr schade. Zumal ich die größere Hoffnung in das 
Leon-Design, gerade auch im Zusammenspiel mit der neuen Eingangsstufe 
setze.

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

Wenn das komplette KnowHow, das ihr in das NIOS-Design steckt, in das 
Leon-Design investiert würde, wäre der Mehrgewinn wahrscheinlich um 
Welten größer. Zumal es eine Plattform ist, an der ihr euch so richtig 
austoben könnt.

Letztlich ist das euere Entscheidung, aber ich denke das alle 
Zeichen/Fehler darauf hindeuten, diesen Schritt endlich machen zu 
müssen, denn das NIOS-Design können wir nun mal nicht beeinflussen.

Gruß, branadic

[Michael D. (mike0815)]

Hallo Andre,

ich sehe das auch so. Was ich bisher im LEON-Design gesehen habe, hat 
mich sehr beeindruckt, auch ohne Huckepack, sind schon Welten 
dazwischen!

Wenn ich mich da auskennen würde, wäre ich selbstverständlich dabei.

Gibt es denn schon einige Fortschritte, ausser in der letzten Preview1.0 
?

Gruß Michael

P.S.  Eure Platine ist schon eine Meisterleistung, sollte hier mal 
erwähnt werden!!!

[banadic (Gast)]

Hallo Michael,

zum aktuellen Stand kann ich dir nicht all zu viel sagen, weil ich da 
schlichtweg nicht im Bilde bin.
Ich weiß, dass Robert seinen aktuellen Stand ins SVN eingecheckt hat, 
sodass eine gemeinsame Grundlage für die Firmwareprogrammierung 
vorhanden ist, die eine rudimentäre GUI-Grundlagebeinhaltet.
Jetzt könnte man sich nach herzenslust austoben und bspw. 
Mathe-Funktionen implementieren, Delay-Menues und dergleichen.

Danke für das Lob, wenn die Huckepack-PCB jetzt auch noch grandios 
funktioniert, dann sind wir, Walter und ich, auch noch zufrieden. Ich 
möchte an dieser Stelle auch noch mal auf die aktualisierte Messdatei 
von Walter aufmerksam machen:

http://welecw2000a.sourceforge.net/docs/Hardware/Messung_13.3.pdf

Gruß, branadic

[Kurt B. (kurt)]

Hallo Leute,
auch wenn es richtig ist dass man jetzt mehre Energie in das Leon Design 
stecken sollte, meine ich dass man noch die vorhandenen Fehler in der 
Nios Firmware beseitigen sollte.

Zum Beispiel das einfrieren des Gerätes beim Einschalten. Erst wenn man 
am V/Div Knopf eines beliebigen Kanals dreht beginnt die Triggerung. Das 
passiert so auch wenn der Trigger auf Auto steht. (W2024A, 0.92a)

Es wäre schade wenn die "verbugte" 0.92a der Schluss der Nios 
Entwicklung wäre.

Mfg,
Kurt

[Gyppe (Gast)]

Hayo thanks for the gift of Easter, version 0.99 is really good, thanks! 
:)

Happy Easter to everyone.

[Roberto (Gast)]

Hallo

Also ich würde es auch richtiger finden, die Energie eher in den neuen 
Leon zu stecken.. besonders wenn dann irgendeinmal die Grenze kommt, wo 
man mit dem alten Design sowieso nicht mehr weiter kommt.

Fragt sich nur, wie schnell kann man mit dem Leon eine vergleichsweise 
Version schaffen ?
Kann man bestehenden Code dann für den Leon compilen oder muss man das 
ganze FW. neu programmieren ?

Aber ich habe leicht reden, ich muss (kann) es nicht programmieren ;-)
l.G. Roberto

[alex008 (Gast)]

Liebe Gemeinde!

Ich möchte hier auch zur Frage NOIS-Firmware oder der LEON3-Firmware 
Diskussion noch 11 Argumente einbringen.

1.) Das LEON3-Design ist völlig Open-Source und auch für andere 
Plattformen portierbar, ohne dass sich viel am Source-Code ändert!

2.) Das Rauschen ohne Filter ist aus mir unbekannten Gründen auch 
weniger.

3.) Der Signalerfassungsteil des LEON3-Design kann für jede Samplingrate 
32 KB Daten speichern. Der Roll-Mode (theoretisch über 1 MB für die 
Signale) sollte funktionieren, falls das nicht der Fall ist, liegt es an 
der Software.

4.) Die Software ist auch mit einer höheren Qualität geschrieben (fast 
kein Copy/Paste drinnen, wenig Magic numbers)

5.) Ein optimales Triggersystem, dass noch erweitert werden kann.

6.) HW-Bugs im LEON3-Design können ausgebessert werden, das gilt nicht 
für das NIOS-I Design.

7.) Der Zu-und Abschaltbare Filtermechanismus vor den Trigger, welcher 
theoretisch unter 1 mV/div messen zulässt.

8.) Der LEON3-Softcore ist wesentlich schneller als der NIOS-I-Softcore.

9.) Weniger Code-Redundanzen bedeuten zugleich ein kleineren 
Speicherbedarf im SRAM und ROM und eine leichtere Erweiterbarkeit von 
Programmteilen.

10.) Aufgrund der Portierbarkeit könnte das LEON3-Design in 10-20 Jahren 
einen Status wie Linux am PC bekommen.

11.) Als Open-Source Programmierer sollte man versuchen, Nutzern einen 
Vorteil seiner Arbeit zu geben, nicht irgendeiner Firma, die Mist gebaut 
hat und einem nichts bezahlt oder weiterhift.

Bis dahin gibt es noch viel zu tun. Bei mir nimmt meine neue (bezahlte) 
Arbeit viel Zeit in Anspruch, weitermachen werde ich hier auf jeden Fall 
noch.
Robert hat noch! keine Ahnung von VHDL, versteht aber die Software des 
LEON3-Designs genauso gut (beim Grafikteil sogar besser) als ich.

Schöne Grüße
Alexander

[Johannes S. (demofreak)]

alex008 schrieb:
> zur Frage NOIS-Firmware

Freud'scher Vertipper? :-D

SCNR

[TO-2 (Gast)]

This version is really very good, thank you very much Hayo!
I tested it on W2012A and W2022A and it's excellent!
The only problem is that often after the use of mathematical functions 
or FFT must reload the default settings to return to normal operation.
Whatever is truly impressive, truly another world!
I have no words!
Thank you and all those who contributed to the miracle!
Regards

[Blue F. (blueflash)]

Hallo Allerseits,

bin gerade aus dem Urlaub zurück und freue mich über die Resonanz.



@Gyppe + @TO-2

It's nice to hear that the new firmware version improves Your DSOs.



@LEON3 + Co.

Also ich möchte nochmals darauf hinweisen, dass das bisherige und 
momentane Engagement in Sachen NIOS + Firmwareaufbereitung keinesfalls 
bedeutet, dass die alternativen Designs nicht interessant wären. Im 
Gegenteil - es ist völlig klar, dass es wirklich entscheidende 
Verbesserungen bei speziellen Details nur auf dieser Basis geben kann.

Aufgrund der verschiedenen Ansätze, die es seit dem Start des Projekts 
gegeben hat, habe ich erstmal abgewartet wo es die vielversprechenste 
Basis gibt.

Die bisherigen Änderungen an der NIOS-basierten Firmware erfolgten auch 
mit dem Hintergedanken an die Portierung auf ein neues Design.

Ich bin konkret an einer, im ersten Schritt, parallelen Unterstützung 
beider Designs interessiert um dann ab einer gewissen Stufe komplett auf 
das neue Design umzuschwenken. Mir fehlen hierzu jedoch noch sämtliche 
Informationen. Für die Entwicklung bräuchte ich folgendes:

- Entwicklungsumgebung für C/C++ mit entsprechenden Bibliotheken (so wie 
für den NIOS - Linux/Windows)

- evtl. schon vorhandenes Beispielcoding auf das man aufsetzen kann 
(z.B. Grafikausgabe, ADC-Ansteuerung, Drehgeber etc.)

- eine Adressmap mit den Adressen der Register der neuen Hardware und 
Peripherie mit kurzer Beschreibung der Funktionen (Timer, ADC-Register 
etc.)

- eine kurze Anleitung wie die Firmware geflasht wird. Funktioniert das 
genauso mit dem GERMS-Monitor über die RS232 wie beim NIOS-Design, oder 
hat sich da was geändert?



Stehen denn FPGA-seitig die wichtigsten Funktionen schon zur Verfügung?

Wie sieht es also aus? Wenn alles soweit passt, könnte ich sofort mit in 
die Entwicklung einsteigen.

Gruß Hayo

[Blue F. (blueflash)]

TO-2 schrieb:

> The only problem is that often after the use of mathematical functions
> or FFT must reload the default settings to return to normal operation.

I will check this! The Math-Functions are still under construction...

Hayo

[Guido (Gast)]

Hallo Hayo,

einen Schnellüberblick findest du auf SF:

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

Allerdings hat sich wohl noch niemand um Linux gekümmert. Ich
habe auch keine Ahnung, ob es Quartusunterstützung hierfür
gibt. Eine Toolchaine um GCC sollte kein Problem sein, da
könnte ich mal zusammensuchen.

Da ich das Oszi nicht zum Messen brauche, wäre ich prinzipiell
auch mit LEON dabei, ob ich aber viel helfen kann ...
Wenn du da einsteigst, läuft die Sache ;-)

Gruß, Guido

[Blue F. (blueflash)]

Hi Guido,

ja den Grobüberblick hatte ich mir auch schon angesehen.

Danke

Hayo

[Robert S. (razer)]

Hallo miteinander,

Schön, dass sich andere Entwickler für das Leon-Design interessieren. Im 
alternativen FPGA-Design liegen noch viele versteckte Kräfte und werden 
das NIOS-Design in Zukunft alt aussehen lassen.

Generell die Entwicklung kann unter Windows als auch unter Linux 
passieren.

Um mit der Entwicklung starten zu können wird zuerst Quartus II 
benötigt. Damit wird der FPGA konfiguriert. Das wird unter 
https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp 
zur Verfügung gestellt. Es gibt das Programm frei in der Linux und auch 
für Windows (Web Edition). Da der FPGA direkt (über den USB Blaster) 
konfiguriert wird, muss das bei jeder Trennung vom Strom erfolgen.

Der USB-Blaster ist ein JTAG Programmiergerät. Dazu muss die Firmware 
des FX2 USB Controller des Oszilloskops neu programmiert werden: 
http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster Quartus 
erkennt dann das Oszilloskop als Programmiergerät und der FPGA kann 
konfiguriert werden.

Der C-Compiler kommt von Gailer Aeroflex, dem Entwickler des Leon3 
Cores.
Wieder gibt es den Compiler für Windows und Linux: 
ftp://gaisler.com/gaisler.com/bcc/bin/ Die Installation ist im PDF 
Dokument des Archivs erklärt.

Ich persönlich verwende zum Entwickeln Eclipse. Damit zu arbeiten ist 
sehr komfortabel, finde ich. Bei Interesse kann ich dazu auch das 
Projektfile schicken, denn das ist nicht im SVN-Trunk. Damit kann ich 
direkt kompiliern und auch die Softcore-Firmware flashen ohne auf die 
Konsole zu müssen.

Das Flashen der Softcore-Firmware erfolgt über die serielle 
Schnittstelle mittels dem "Waverecorder"-Programm entwickelt von Alex. 
Das Flashen des FPGAs über USB.

Zu den Beispielcode, hier kann man auf den letzten Commit aufbauen. Hier 
habe ich ein kleines GUI-Framework entwickelt. Weiters funktionieren die 
auch Drehgeber und Tasten. Darauf kann man aufbauen!

Zu den Registern, die sind in einer eigenen Header Datei beschrieben. Am 
Besten lädst du dir den Trunk einmal runter und siehst es dir an. Vorher 
kannst du auch erstmal den FPGA konfigurieren und dann die kompilierte 
Binary flashen und den aktuellen Entwicklungsstand anssehen.

Bei Fragen kannst du sie hier, oder im Skype Chat stellen. Der Chat hat 
den Vorteil, dass die Entwickler unter "sich" sind und er deutlich 
kürzere Latenzzeiten hat und einem sehr schnell geholfen wird - So war 
es bei mir wie ich mir den Überblick einmal verschaffen musste. Mein 
Benutzername lautet xxrazer6xx - ich kann dich auch dem Chat hinzufügen

@Alex: Die ersten VHDL Erfahrungen konnte ich bereits machen. 
Blinklichter, RGB-PWM Modul, und ein paar Zustandsautomaten habe ich 
bereits beschrieben :) Macht eigentlich sehr viel Spaß :)

Noch einen schönen Abend
Robert

[Roberto (Gast)]

Hallo

Noch ein Frage:
Falls ich mich für das Leon-Design entscheide, muss ich wohl 
zwangsläufig auch auf dem Leon FW bleiben..?
Eine alte Nios FW wird vermutlich sehr Umständlich wieder zum einspielen 
sein. (FPGA wieder auf NIOS programmieren)

Also für einen, der nur "EIN" Dso hat, wird das vermutlich ein harter 
Schritt.
Also nix mit mal kurz ausprobieren..?!
Dann muss ich vermutlich noch ein bisschen warten, bis man mit dem Leon 
auch ein bisschen vernünftig arbeiten kann.

Dann bin ich aber gerne dabei :-)
l.G. Roberto

[Robert S. (razer)]

Hallo Roberto,

Da das Leon Design derzeit noch nicht im Flash gespeichert wird (ist ja 
noch in der Entwicklungsphase), meldet sich nach jeder Trennung vom 
Strom wieder das NIOS Design. Von daher ist das kein Problem.

Von daher spricht nichts gegen ein "ausprobieren".

lg Robert

[Guido (Gast)]

@ Robert.S: Gibt es für die Altera-Umgebung nicht einen schönen
kleinen Player (wie Impact bei Xilinx), damit man sich nicht
die gesamte Entwicklungsumgebung aufspielen muss?

[Blue F. (blueflash)]

Hi,

bin gerade erst wieder Zuhause eingetrudelt. Vielen Dank für die 
ausführliche Beschreibung. So wie es aussieht muß ich wohl erstmal 
einiges an Software auf meinen Rechner kippen um das Ganze zu starten. 
Ich versuche das mal morgen in Angriff zu nehmen, wenn mir die Firma 
nicht dazwischen funkt.

Gruß Hayo

[Robert S. (razer)]

Hallo Guido,

Danke für den Hinweis. Für Windows gibt es den Quartus II Programmer: 
https://www.altera.com/support/software/download/programming/quartus2/dnl-quartus2_programmer.jsp

Das Programm hab ich aber nicht getestet. Für Linux habe ich leider auf 
die schnelle nichts gefunden :(

Grüße Robert

[Blue F. (blueflash)]

Hi,

nach einigen Stunden des Softwarezusammensuchens und Registrierens bei 
Cypress und Altera hab ich jetzt erstmal genug.

Die Datei USBDevStudio_1511.exe scheint es nicht mehr zu geben.

Auch den Waverecorder den man ja anscheinend braucht um die Firmware zu 
laden kann ich beim besten Willen nicht finden. Bei der Gelegenheit ist 
mir auch wieder aufgefallen, dass die Navigation auf der 
SFN-Projektseite ziemlich unübersichtlich ist...


Gruß Hayo

[Robert S. (razer)]

Hallo Hayo,

Stimmt, das ist leider veraltert. Du benötigst die CyConsole. Die gibt 
es hier: http://www.cypress.com/?rID=34870 (Wird mitinstalliert) Ich 
werde das auf SF ändern.

Den Waverecorder bekommst du kompiliert aus dem Preview Package 
(http://downloads.sourceforge.net/project/welecw2000a/LEON3%20FPGA%20Design/Previews/W2000L_Preview1.0.zip?use_mirror=heanet) 
(in dem ist auch das erstellte FPGA Design). Der Waverecorder ist dort 
jedoch eine ältere Version. Ansonsten kannst du dir den Waverecorder 
auch einfach selbst kompilieren (make ist dein Freund). Die Sourcen 
dafür sind im Trunk 
\welecw2000a\fpga\leon3\grlib-W2000A\software\dso\WaveRecorder

lg Robert

[Guido (Gast)]

Hmmh,

den FX2 sollte doch fxload initialisieren können. Dann bräuchte
man nur passende udev-Rules, die schnell erstellt sind. Oder
übersehe ich da etwas?

[Michael D. (mike0815)]

Hallo Robert,

Hayo hat schon Post, habe's mal zusammen gepackt inkl. USB-Blaster, 
ausser den Quartus-Programmer, der hat ja gepackt 96 MB und ist wohl zu 
groß zum verschicken...


und für Diejenigen, die es nochmal testen möchten...
hier der Link für das 1. Leon3-Design ohne Waverecorder.

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


und hier der 2. Link mit kompletter Preview 1.0,  inkl. Waverecorder SOF 
und umbenannter SRAM ! Die Batch-Datei muß nur noch angepasst 
werden...COM-PORT etc.

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

Gruß Michael

[Blue F. (blueflash)]

Hi,

vielen Dank für die Unterstützung. Das nennt man wohl 
Entwicklungshilfe...;-)

Einiges hatte ich mir ja schon zusammengesucht, ist aber schon etwas 
mühselig. Werd gleich mal anfangen zu installieren.

@Michael

Wie sieht es an der Schalterfront aus? Die Überweisung sollte letzte 
Woche bei Dir eingegangen sein.

Gruß Hayo

[Blue F. (blueflash)]

Ich bin erstmal bedient! Seit fast zwei Tagen versuche ich jetzt diesen 
besch... Blastertreiber zu installieren. Nach etlichen Versuchen hatte 
ich die Sache sogar soweit, dass mein W2014A vom Altera Programmer 
erkannt wurde - allerdings wurde das EEPROM nicht gefunden. Daraufhin 
hab ich das dann mit dem W2022A versucht - jetzt geht nichts mehr.

Ich hab jetzt die Systemwiederherstellung angeworfen und alles vom 
Rechner gelöscht.

Wenn es da eine bessere Möglichkeit gibt probiere ich das gerne 
irgendwann noch mal (über JTAG Connector??).

Gruß Hayo

[egberto (Gast)]

könnte da nicht jemand eine funktionsfähige VM mit lauffähiger 
Konfiguration irgendwo hochladen....

[Kurt B. (kurt)]

Hallo Hayo,
hast du ein gutes (kurzes) USB Kabel verwendet?

Bei mir findet der Altera Programmer das Oszi nicht wenn ich es über 
einen USB Hub anschließe.

Auf dem Laptop habe ich es auch noch nicht geschafft den Treiber zu 
installieren.

Mfg,
Kurt

[Blue F. (blueflash)]

Das wäre natürlich auch mal eine Idee...

Dann würde ich das glatt nochmal probieren. Allerdings braucht man dafür 
im WWW eine Möglichkeit große Dateien hochzuladen.

Ich könnte dies nur temporär anbieten über einen Server hier bei mir.

Gruß Hayo

[Blue F. (blueflash)]

Kurt Bohnen schrieb:
> Hallo Hayo,
> hast du ein gutes (kurzes) USB Kabel verwendet?

Das originale USB Kabel vom DSO

> Bei mir findet der Altera Programmer das Oszi nicht wenn ich es über
> einen USB Hub anschließe.

direkt an den USB-Port des Rechners

> Auf dem Laptop habe ich es auch noch nicht geschafft den Treiber zu
> installieren

Stationärer PC mit Athlon Doppelkern und aktueller Hardware, System ist 
Win XP.



Gruß Hayo

[Thomas (kosmos)]

bei mir funktionierte es jeweils nur einmal direkt nach Rechnerneustart, 
beim 2ten Programmieren kam schon ein Fehler.

[Blue F. (blueflash)]

Hi nochmal,

es hat mir keine Ruhe gelassen, habs nochmal ausprobiert. Diesmal 
kürzeres USB-Kabel, anderer USB-Port gleiches Ergebnis.

Wenn ich der Anleitung folge klappt es bis zu dem Punkt, wo es heißt 
HID-Device löschen, Info-Cache löschen, Reboot und dann wieder 
anstöpseln. Bei mir erscheint zwar auch kurz das "Scope Interface" 
Device, es verschwindet aber nach kurzer Zeit wieder und dafür erscheint 
wieder das HID-Device (siehe Bild) mit der VID_4242 statt der neuen VID.

Gruß Hayo

[Thomas (kosmos)]

vielleicht hat dein Motherboard 2-4 nromale USB Anschlüsse und die 
restlichen 4 laufen über einen onboard-HUB. Ziehe vielleicht mal alle 
anderen USB Geräte ab oder probiere eine andere USB Buchse aus. Ich habe 
das gleiche Probleme, habe es ein paar mal geschafft das es einmalig 
funktioniert, nach einer Weile Arbeit am PC gehts aber komischerweise 
nicht mehr nur direkt nach einem Neustart. Keine Ahnung welche Anwendung 
hier dazwischenfunkt wobei bei mir nur der Browser Seamonkey dauerhaft 
läuft.

[branadic (Gast)]

@ Hayo,

versuch doch mal den Treiber des HID manuell gegen den 
USBBlaster-Treiber zu tauschen. Also Rechtsklick auf das richtige 
HID-Device --> Treiber aktualisieren --> Nein, diesmal nicht --> 
Software von einer Liste oder ...

Bei mir funktioniert das mit dem USBBlaster absolut einwandfrei.

Die Alternative ist den FX1 zu flashen, vorher aber das originale Flash 
wegspeichern.

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

--> siehe: Permanently flashing the FX1's config flash

Den Widerstand an deinem 4-Kanalgerät hast du drin?

Gruß, branadic

[Guido (Gast)]

Unter Linux mit fx2_programmer klappt es problemlos. Das Oszi
wird als Altera NIOS II Evaluation Board angezeigt.
Jetzt muss ich nur noch rausfinden, wo ich eine EEPROmer-Stage
für fxload finde.

Gruß, Guido

[Blue F. (blueflash)]

branadic schrieb:
> @ Hayo,
>
> versuch doch mal den Treiber des HID manuell gegen den
> USBBlaster-Treiber zu tauschen. Also Rechtsklick auf das richtige
> HID-Device --> Treiber aktualisieren --> Nein, diesmal nicht -->
> Software von einer Liste oder ...

Hmm, so hab ich es eigentlich die ganze Zeit gemacht, steht ja auch so 
in der SFN-Anleitung, oder meinst Du da was anderes?

> Die Alternative ist den FX1 zu flashen, vorher aber das originale Flash
> wegspeichern.

Ja sowas hatte ich auch schon in Erwägung gezogen, aber

1. muß man dazu die CyUsb.inf Datei ändern und die Anleitung war mir 
etwas undurchsichtig -> hat jemand evtl. eine funktionierende gepatchte 
.inf Datei?

2. auch hier muß man dem HID Interface einen anderen Treiber zuweisen, 
und ich habe das Gefühl, es wird dabei die gleichen Probleme geben.
-> gibt es da andere Möglichkeiten das Flash zu sichern bzw. zu 
überschreiben?


> Den Widerstand an deinem 4-Kanalgerät hast du drin?

Wie jetzt Widerstand? Ich denke das Ganze geht ohne Eingriff ins Gerät? 
Zuletzt habe ich allerdings sowieso das Zweikanalgerät benutzt. Aber 
vielleicht wurde deshalb bei meinem ersten Versuch mit dem 2014 das 
EEPROM nicht erkannt.


@Guido

Wenn das funktioniert, kannst Du das dann noch mal in kleinen Schritten 
(für Begriffsstutzige ;-)) erklären

Gruß Hayo

[Blue F. (blueflash)]

Thomas O. schrieb:
> vielleicht hat dein Motherboard 2-4 nromale USB Anschlüsse und die
> restlichen 4 laufen über einen onboard-HUB.

Hab ich auch schon überlegt. Die ersten Versuche incl. dem ersten 
semi-erfolgreichen habe ich an den herausgeführten USB-Ports gemacht. 
Dann habe ich es mit den hinteren direkt auf dem Mainboard versucht - 
nix.

Bleibt natürlich noch die Möglichkeit es mit einem meiner anderen 
Rechner zu versuchen.

Gruß Hayo

[Guido (Gast)]

> Wenn das funktioniert, kannst Du das dann noch mal in kleinen Schritten
> (für Begriffsstutzige ;-)) erklären

Kein Problem:

- fx2_programmer downloaden und mit make compilieren (google hilft
es zu finden).

- ./fx2_programmer 000 000 dump_busses
In der Ausgabe das Welec mit Prod-ID=4242 und Ven-ID=0200 suchen,
Bus und Device ablesen (bei mir Bus=002 und z.B. Device=011)

- ./fx2_programmer 002 011 set 0xE600 1
Bus und Device von oben einsetzen

- ./fx2_programmer 002 011 program /pfad/USB_Blaster.hex

- ./fx2_programmer 002 011 set 0xE600 0

Dann kannst du /proc/bus/usb/devices anschauen und findest das
Evaluation-Board.

Jetzt bräuchte ich quartus_pgm, bisher habe ich es nicht gefunden.
Wäre zu dämlich deswegen 2,2 GB downzuloaden.

Gruß, Guido

[Johannes S. (demofreak)]

Hayo W. schrieb:
> Dann würde ich das glatt nochmal probieren. Allerdings braucht man dafür
> im WWW eine Möglichkeit große Dateien hochzuladen.

Damit könnte ich durchaus dienen.

[Michael D. (mike0815)]

Hallo Hayo,

Hast da ja jede Menge Fragezeichen in deiner Sys-Steuerung!

Die CyUsb.spt muß in dieses Verzeichnis kopiert werden!!!

...am besten mit dem angegeben Unterverz. ----CyUsb----

-----c:\Windows\system32\CyUsb\CyUsb.spt------

Den Teiber mit der ---- .inf  und  .sys -----
in den  ---- Driver ---- Ordner auf Laufwerk --- C: --- Kopieren

C:\Windows\inf\Driver

(manchmal hängt es auch an der Pfadtiefe)

Dann in die SYS-Steuerung:

Bei der HID-Devices und USB- HID(Human Interface)
muß in einer dieser beiden diese VID-PID Nummer stehen:
----------HID-device whith VID-PID 4242-0200------------

nimmst du die Falsche, funzt das nicht!!!

Diese gegen die CyUsb manuell tauschen! Also ---C:\Windows\inf---(die ja 
da drinnen sein sollte)
1.FOTO

Danach muß das dann so aussehen!
2.FOTO

...hoffe geholfen zu haben

Gruß Michael

[Blue F. (blueflash)]

Johannes Studt schrieb:
> Hayo W. schrieb:
>> Dann würde ich das glatt nochmal probieren. Allerdings braucht man dafür
>> im WWW eine Möglichkeit große Dateien hochzuladen.
>
> Damit könnte ich durchaus dienen.

Das ist doch schon mal nicht übel, dann fehlt nur noch die VM...

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> Hallo Hayo,
>
> Hast da ja jede Menge Fragezeichen in deiner Sys-Steuerung!

Hi, danke für die Unterstützung, die Fragezeichen sind nur da wenn die 
Option ausgeblendete Devices anzeigen aktiv ist.

> Die CyUsb.spt muß in dieses Verzeichnis kopiert werden!!!
>
> ...am besten mit dem angegeben Unterverz. ----CyUsb----
>
> -----c:\Windows\system32\CyUsb\CyUsb.spt------>

Ja, hab ich auch so gemacht.

> Den Teiber mit der ---- .inf  und  .sys -----
> in den  ---- Driver ---- Ordner auf Laufwerk --- C: --- Kopieren

hatte ich in C:\temp\driver, sollte aber wohl keinen Unterschied machen 
oder?

> C:\Windows\inf\Driver

Bist Du sicher? ich hatte das in den Ordner C:\Windows\system32\Drivers
kopiert

> (manchmal hängt es auch an der Pfadtiefe)
>
> Dann in die SYS-Steuerung:
>
> Bei der HID-Devices und USB- HID(Human Interface)
> muß in einer dieser beiden diese VID-PID Nummer stehen:
> ----------HID-device whith VID-PID 4242-0200------------

Jupp hatte ich auch gemacht

> nimmst du die Falsche, funzt das nicht!!!

ja die untere muß es sein

> Diese gegen die CyUsb manuell tauschen! Also ---C:\Windows\inf---(die ja
> da drinnen sein sollte)
> 1.FOTO
>
> Danach muß das dann so aussehen!
> 2.FOTO

Genauso sah es beim ersten Mal mit dem 2014 auch aus. Der 
Quartus-Programmer hat es dann auch gefunden. Nur nach meinem Wechsel 
auf das 2022 will jetzt garnichts mehr funktionieren

Gruß Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> hatte ich in C:\temp\driver, sollte aber wohl keinen Unterschied machen
>
> oder?
>
...das ist "Windoof" ...und voller Geheimnisse!
Ich habe da schon Dinger erlebt...

>
>
>> C:\Windows\inf\Driver
>
>
>
> Bist Du sicher?

Ja, ganz sicher!
Ist für den späteren Treibertausch auch besser wieder zu finden...auch 
für Windoof!

>ich hatte das in den Ordner C:\Windows\system32\Drivers
>
> kopiert

normalerweise sollte das auch gehen.
Nur wo ist jetzt das Problem? Findet er jetzt den Treiber nicht mehr?
Kann ja nicht sein, das wenn du ein anderes DSO anschliesst, das da nix 
mehr geht, unglaublich!!!

Bevor du Jemanden umbringst, würde ich noch ein alternatives 
Kommunikationsmittel in erwägung ziehen, dann würde ich den Treiber 
deinstallieren und wir könnten dann parallel die Installation 
durchführen, kann ich dir anbieten!

Gruß Michael

[Blue F. (blueflash)]

Danke für das Angebot,

hab gerade das Ganze mal auf meinem Nettop durchgespielt. Gleiches 
Ergebnis.

Es wird zwar erstmal kurz "Scope Interface" angezeigt, aber danach 
wechselt es wieder zur Anzeige "USB-HID". Dann wird auch kein anderer 
Treiber angenommen wie man in den Treiberdetails sehen kann.


Gruß Hayo

[Torsten W. (wirehead)]

bei mir hatte ich ein ähnliches problem, hilfe brachte erst das löschen 
der INFCACHE.1 (C:\WINDOWS\inf) eventuell löschen der PNFs.
Diese dateien werden beim nächsten neustart wieder neu erzeugt (dauert 
etwas) .
Danach bin ich genau nach der anleitung vorgegangen und es hat geklappt.

(ohne garantie)

[Blue F. (blueflash)]

Torsten W. schrieb:
> bei mir hatte ich ein ähnliches problem, hilfe brachte erst das löschen
> der INFCACHE.1 (C:\WINDOWS\inf) eventuell löschen der PNFs.

Ja den Cache hab ich auch jedesmal gelöscht, die PNFs muß ich mal 
probieren

Gruß Hayo

[Michael D. (mike0815)]

Also beim Hayo läuft definitiv was falsch!

Auf 2 verschiedenen Rechnern, unglaublich!

Ich habe diesen Treiber mehrmals ausgetauscht und das ohne Probleme!
Der Quartus-Programmer funzt auch eiwandfrei!

Da mein vorheriger Rechner, auf dem es übrigens auch alles funzte, 
abgeraucht ist (aufgepumte Elkos), ist dieser jetzt hier mit ettlichen 
Sachen zu gemüllt und es lässt sich trotzdem installieren!

...jetzt weiß ich auch nicht mehr weiter

[Robert S. (razer)]

Hallo Leute,

Ich hatte leider auch Probleme bei der Installation des Treibers. Mein 
Workaround war, einen Pin des I2C EEproms, der am FX2 Controller 
angeschlossen ist, abzulöten.

Dadurch wird das Gerät nicht mehr als HID Gerät erkannt bei der 
USB-Enumeration. Während des Betriebes habe ich nun den einen Pin wieder 
"auf die Platine gedrückt" und den den EEprom programmiert. Hat 
eigentlich gut funktioniert.

Ich kann nur Empfehlen in den Skype Chat zu kommen, hier kann man in 
"Echtzeit" helfen. Der Daniel=Crazor konnte mir bei dem FX2 Problem sehr 
gut helfen.

lg Robert

[Guido (Gast)]

@ Hayo: Probier mal mit dem fx2_programmer! Nicht dass es
ein Hardwareproblem gibt.

Gruß, Guido

[Michael D. (mike0815)]

jetzt habe ich mal eine andere  Frage:
Wie geataltet sich denn dieses  "Testsignal" im Menu Utility? Wird das 
im DSO intern generiert mit 3,90MHz und 26,8V Peak to Peak? Oder wie 
geht das vor sich?

Dann noch was:
Hat schon Jemand mit modifierten Widerständen die neuen Optionen für den 
ADC-Offset getestet?

Gruß Michael

[Blue F. (blueflash)]

Guido schrieb:
> @ Hayo: Probier mal mit dem fx2_programmer! Nicht dass es
> ein Hardwareproblem gibt.

Das glaube ich eigentlich nicht, denn ich habe inzwischen mit beiden 
Geräten!!! einen weiteren Versuch auf einem jungfräulichen Win XP 
unternommen. Keine Chance. Das Gerät wird konsequent immer als HID 
Device eingestuft nachdem es kurzzeitig als Scope Interface auftaucht.

Werde das aber mal prüfen nach Deiner Anleitung

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> jetzt habe ich mal eine andere  Frage:
> Wie geataltet sich denn dieses  "Testsignal" im Menu Utility? Wird das
> im DSO intern generiert mit 3,90MHz und 26,8V Peak to Peak? Oder wie
> geht das vor sich?

Anstatt den ADC auszulesen wird direkt in den Signalpuffer geschrieben 
-> siehe angehängtes Coding

> Dann noch was:
> Hat schon Jemand mit modifierten Widerständen die neuen Optionen für den
> ADC-Offset getestet?
genau, das würde mich auch interessieren


Gruß Hayo

[Blue F. (blueflash)]

Guido schrieb:

> - ./fx2_programmer 000 000 dump_busses
> In der Ausgabe das Welec mit Prod-ID=4242 und Ven-ID=0200 suchen,
> Bus und Device ablesen (bei mir Bus=002 und z.B. Device=011)
>
> - ./fx2_programmer 002 011 set 0xE600 1
> Bus und Device von oben einsetzen
>
> - ./fx2_programmer 002 011 program /pfad/USB_Blaster.hex
>
> - ./fx2_programmer 002 011 set 0xE600 0

Die Anleitung ist ganz gut, aber was macht man da eigentlich?
Wird das EEPROM dadurch dauerhaft programmiert, oder ist das nur 
temporär?

Kann man damit den EEPROM-Inhalt sichern?

Gruß Hayo

[Guido (Gast)]

Nö, das schreibt nur in das RAM des FX2, so dass dieser Vorgang
nach jedem Einschalten wiederholt werden muss. Der nächste
Schritt wäre mit fxload das EEPROM zu beschreiben, dafür bräuchte
man ein Programm, das statt USB_Blaster geladen wird und dieses
tut. Ich kann aber auch so damit leben.

[egberto (Gast)]

Um noch mal auf dei Entwicklungs VM zu kommen......

Unter Windows steht ja dann das Problem der legalen Lizensierung (könnte 
man nur z.B. über eine Windows PE CD lösen).

Gibt es da denn auch eine (funktionierende!) Entwicklungsumgebung für 
Linux? Die USB-Geschichte ist dann ja eventuell auch stabiler (wenn man 
sie mal hingefrickelt hat).

Grüße,

egberto

[Blue F. (blueflash)]

Ja das fände ich auch interessant, da ich alles Andere eigentlich 
meistens auch unter Linux entwickle (obwohl ich auch die Windows 
Umgebung installiert habe)

Gruß Hayo

[Blue F. (blueflash)]

@Guido

make läuft bei mir auf Fehler. Brauche ich da noch extra SDCC?

Hier das Protokoll:

fx2_programmer.c:337: warning: format ‘%s’ expects type ‘char *’, but 
argument 3                                            has type ‘int’
fx2_programmer.c:346: warning: format ‘%s’ expects type ‘char *’, but 
argument 3                                            has type ‘int’
fx2_programmer.c: In function ‘program_eeprom’:
fx2_programmer.c:375: error: ‘current_handle’ undeclared (first use in 
this func                                           tion)
fx2_programmer.c: In function ‘main’:
fx2_programmer.c:411: warning: implicit declaration of function 
‘usb_init’
fx2_programmer.c:412: warning: implicit declaration of function 
‘usb_find_busses                                           ’
fx2_programmer.c:413: warning: implicit declaration of function 
‘usb_find_device                                           s’
fx2_programmer.c:426: error: dereferencing pointer to incomplete type
fx2_programmer.c:426: error: dereferencing pointer to incomplete type
fx2_programmer.c:427: error: ‘current_handle’ undeclared (first use in 
this func                                           tion)
fx2_programmer.c:427: warning: implicit declaration of function 
‘usb_open’
fx2_programmer.c:474: warning: pointer targets in passing argument 1 of 
‘upload_                                           ram’ differ in 
signedness
fx2_programmer.c:501: warning: implicit declaration of function 
‘usb_close’
make: *** [fx2_programmer] Fehler 1


Fehlt mir da noch eine Library oder so?

Gruß Hayo

[Guido (Gast)]

Sieht seltsam aus? Du brauchst sonst nur libusb, den SDCC nur
um eine neues Programm für den FX2 zu erstellen. Ich hänge das
Compilat mal an.

[Guido (Gast)]

So, ich habe mal etwas recherchiert wie das alles unter Linux
klappen könnte (das soll nichr bedeuten, dass es unter Win nicht
so ght!):

- USB_Blaster auf den FX2, sollte mit fx2_programmer erledigt sein.
( @ Hayo: implicit declaraion... besagt, dass libusb wohl nicht
installiert ist (ev. devel?).

- das FPGA-Design sollte in ein SVF gewandelt werden, das Altera-
Geheimformat .sof ist für OS eh ein Witz. Könnte das einer der
Hardware-Entwickler übernehmen?

- Das SVF könnte ev. mit urjtag aufgespielt werden, dies unterstützt
angeblich den USB_Blaster.

- Die Firmware müsste dann ja über ein Terminal oder den
Waverecorder aufgespielt werden können.

Anmerkungen willkommen, Grüße Guido

[Blue F. (blueflash)]

Guido schrieb:

> ( @ Hayo: implicit declaraion... besagt, dass libusb wohl nicht
> installiert ist (ev. devel?).

libusb ist installiert. dev muß ich mal probieren


> - Das SVF könnte ev. mit urjtag aufgespielt werden, dies unterstützt
> angeblich den USB_Blaster.
>
> - Die Firmware müsste dann ja über ein Terminal oder den
> Waverecorder aufgespielt werden können.

das wär ja mal cool wenn das ginge

Gruß Hayo

[Guido (Gast)]

OOps,

urjtag sollte USB_Blaster schon unterstützen, ist ja vom selben
Author (sorry Kolja). Nun brauche ich ein SVF zum testen. Ich
finde aber noch nicht mal die Quellen für das LEON-Design. Hat
mal jemand einen Link?

Gruß, Guido

[Michael D. (mike0815)]

Hallo Giudo,

Welches Leon-Design meinst du denn?
Wenn du das Aktuelle vom Robert meinst, dann kann ich dir nur das Paket 
anbieten wo auch der Waverekorder drinnen ist...


hier der Link:

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



Gruß Michael

[Michael H. (Gast)]

Hey Guido,
wolltest du hierhin?

https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/leon3/

Gruß
Michael

[Michael D. (mike0815)]

mosche, moin!

...dachte schon, ich hätte doppelt gepostet.

Schau mal einer an, den Link kannte ich ja noch gar nicht!

Ich würde mal vorschlagen eine Liste mit Inhaltsverzeichnis zu 
erstellen, wo was zu finden ist!
Vielleicht eine komplette Linkliste, sonst verliert man ja den 
Überblick!

Gruß Michael

[Roberto (Gast)]

Hallo Hayo
Habe deine letzte Verssion jetzt mal aufgespielt.
Funktioniert soweit :-)
Screenshot geht jetzt :-) About geht auch .

Unter FFT geht nicht viel... es ändert sich kein Signal.

Unter Delayed wird auch was falsch dargestellt.
Da sieht man oben das richtige Signal und unten dann die ersten zwei 
Spalten ein ängeres Signal und der Rest der Linie dann nur misst.
Eigentlich sollte unten ja der Ausschnitt von dem oberen Signal sein..?!
(Vergrösserung)
Habe das nur mal so erwähnt...

Derzeit kämpfst Du ja mit anderen Problemen... Viel Glück :-)
l.G. Roberto

[Robert S. (razer)]

@Guido: Welche Quellen suchst du? Die der Firmware des Softcores? Oder 
die des FPGA Designs?

Alle Sourcen die dem Leon Projekt angehören befinden sich in: 
\welecw2000a\fpga\leon3

Firmware:
\welecw2000a\fpga\leon3\grlib-W2000A\software\dso

Waverecorder:
\welecw2000a\fpga\leon3\grlib-W2000A\software\dso\WaveRecorder

FPGA-Design:
\welecw2000a\fpga\leon3\Scope\synW2000A (für das W2000, bin mir aber 
nicht sicher ob das jetzt da die Toplevel Entity für die Synthese ist. 
Das FPGA Design ist portable geschrieben und wurde auch auf anderer 
Hardware getestet)

Ich kann ein nur raten, kommt in den Skype Chat. Der Daniel ist auch oft 
online. Der kann bezüglich dem FX2 Problem sicher kompetent helfen.

Ich hatte auch Probleme beim aufspielen der neuen Firmware auf den FX2.

@Hayo: Ein sichern der aktuellen Firmware des FX2 ist mittels der 
CyConsole möglich. Ich habe hier einen korrekten EEprom-Dump bei mir.

lg Robert

[Guido (Gast)]

Hallo,

und danke für die Links, ist immer wieder verblüffend, was man
im SF alles findet, wenn man weiß wo es ist. ;-)

@ Robert: Zunächst bräuchte ich das FPGA-Design. Könnte einer
von euch daraus ein SVF erstellen. Das müsste unter Quartus
gehen, irgendwie Optionen so umstellen, dass anstelle des .sof
ein .svf erstellt wird.

Ich probiere gerade mit urjtag. Bisher findet er das Kabel (Oszi)
und eine JTAG-Chain. In der Chain dann ein unbekanntes Device von
Altera. Eigentlich hätte ich mindesten 2 erwartet, so ganz scheint
das noch nicht zu klappen. Ich probiere später weiter (Device-Id
vergleichen ...).

Gruß, Guido

[Michael D. (mike0815)]

hallo Guido,
schau doch mal, ob du mit dieser ---Hello_W2000.SVF--- etwas anfangen 
kannst, ich habe sie im Quartus konvertiert!

Sach mal bescheid ob die ok ist.

Gruß Michael

[Michael D. (mike0815)]

...dann hätte ich hier noch eine, die ist von hier:

welecw2000a - Revision 333: /fpga/leon3/Scope/synW2000A

ich weiß jetzt nicht, ob das dieselbe wie die 'HelloW2000...' ist!

schau halt mal

Gruß Michael

[Michael D. (mike0815)]

So, jetzt hab' ich einigermaßen durchgeblickt!

Die ---HelloW2000--- ist vom Slog

Die ---welecw2000a--- ist von hier(wie schon angegeben)--- Revision 333: 
/fpga/leon3/Scope/synW2000A
Wenn ich die aufspiele und danach die sram.bin aufsetze, passiert 
nüscht.



Die ---20032010_Welec2000.svf.zip--- ist die Aktuelle(LEON-Design) mit 
der dazugehörigen   ---sram180310.bin---


Ich habe die letzte ---Welec2000A.sof--- in das "Seriel Vector Format" 
(SVF) umgewandelt, ich hoffe der Guido kann jetzt was mit anfangen.

Gruß Michael

[alex008 (Gast)]

Hallo an alle!

Ich bin nun positiv überrascht über das Interesse an meinem entwickelten 
LEON3 FPGA-Design.

/fpga/leon3/Scope/synW2000A ist der Ordner in dem die Synthese statt 
findet!

Im Moment sollte jedoch das FPGA-Image von meinem Preview-Release 
verwendet werden!

Zur Betriebssystemfrage:
Ich habe das FPGA-Design bis Dezember 2009 auf Windows XP entwickelt. 
Bei mir hat das Installieren von Slog's USB-Blaster tadellos 
funktioniert. Programmieren ging nur, wenn kein interner oder externer 
HUB vorhanden war.
Mit dem Erscheinen des Quartus Linux Beta's bin ich auf Linux 
umgestiegen!
Bei Quartus habe ich noch keine gravierenden Fehler gefunden, die die 
Entwicklung beeinflussen.
Ab ungefähr der Kernel Version 2.6.31-17 wurde udev entfernt, welches 
die vorigen USB-Blaster Installations-HOWTOs nicht mehr korrekt sein 
lässt.

Workaround USB-Blaster unter Linux für neuere Kernel Versionen:
[code]
# for udev support
#  sudo mount -t usbfs /dev/bus/usb/ /proc/bus/usb
# for newer not udev supporting kernels
  sudo mount --bind /dev/bus /proc/bus
  sudo ln -s /sys/kernel/debug/usb/devices /proc/bus/usb/devices
[\code]

Waverecorder:
Falk hat mir den Waverecoder auf Linux portiert. Der Unterschied liegt 
nur in der PCUart.h und PCUart.cpp und ein paar includes!
Da sich der Waverecoder teilweise den Source-Code mit dem 
Oszilloskop-Firmware teilt (Remote Steuerung des Oszilloskopes mit und 
ohne CPU!), kompiliert das im Moment nur mit 32 Bit unter Windows, Linux 
und warscheinlich auch MAC!

Zur Ordnerstruktur:
Das FPGA-Design ist portabel geschrieben. Das bedeutet, dass ein paar
Kleinigkeiten zu den verschiedenen Plattformen vorhanden sind. Diese 
werden mit #ifdef usw. abgefragt. Hier habe ich das so gelöst, dass es 
für jede Plattform zwei Ordner (Firmware für die Simulation und die 
Wirklichkeit) zum kompileren der Software gibt. In dem Ordner sind diese 
#defines im Makefile abgelegt.

Ich rate jedem ab, sich mit den LEON3 make Befehlen auseinanderzusetzen 
(make scripts echo Bug und die Textformat-Probleme unter Windows), da 
die nicht ohne weiters auf jeder Plattform funktionieren. Deshalb gibts 
die sepparaten Synthese-Ordner.

Ansonsten ist die Toolchain und der Rest für den LEON3 sehr brauchbar.

Viel Freude beim Ausprobieren und Weiterentwickeln!
Alexander

[Blue F. (blueflash)]

Hi,

nachdem ich im Augenblick mit USBBlaster und LEON nicht so richtig 
weiterkomme bin ich jetzt wieder dabei die aktuelle NIOS-Firmware zu 
überarbeiten. Aktuelles Thema ist der Delayed Mode, den ich gerade 
komplett überarbeite und erweitere.

Ziel ist bei mir für die nächsten Wochen die NIOS-Firmware so stabil zu 
machen, dass ich die Version von 0.xx beta auf 1.xx stable setzen kann.

D.h. der Schwerpunkt liegt nicht auf neuen Features sondern auf 
Fehlerbeseitigung und Verbesserung vorhandener Funktionen.

Wenn der Punkt erreicht ist, kann ich mich auch mehr auf die 
LEON-FW-Entwicklung konzentrieren.

Gruß Hayo

[Guido (Gast)]

Hallo Hayo,

ein weiser Entschluss. Ich habe mich mal etwas mit dem urjtag
beschäftigt und es wird wohl noch etwas dauern, bis das alles
läuft. Zunächst muss ich wohl die Definitionen für den EP2C35
nachrüsten, die nötigen Daten habe ich hoffentlich endlich
beisammen.

Nichts überstürzen. ich will ja auch nichts zerschießen.

Gruß, Guido

[Michael D. (mike0815)]

...es scheint hier noch Probleme mit dem Blaster zu geben.

Ich habe hier ein Tool, welches alle USB-Geräte anzeigt, die im 
Gerätemanager nicht angezeigt werden!

Es ist möglich damit Geräte ein-oder auszuschalten!
Des weiteren hat man noch die Option USB-Treiber zu deinstallieren.

Das Tool ist Freeware, ich hänge es mal an...


Gruß Michael


Hayo, du hast Post, schmeiß sie nicht wieder weg...

[Blue F. (blueflash)]

...echte Post oder virtuelle??? ;-)

Ich schau mal nach wenn ich wieder zu Hause bin - kann etwas später 
werden.

Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> Hi,

Hi Hayo,

>
> [Erstmal nicht lean, sondern nios]

wie sieht es denn aus? Könntest Du Dich mit
der Entwicklung im svn (OS) anfreunden?
>
>
>
> Gruß Hayo

Beste Grüße,

   rowue

[Guido (Gast)]

O.k.

der Cyclon II wird jetzt erkannt. Wie erwartet ist mit urjtag aber
nicht mehr möglich, als das Aufspielen von SV-Files. Da muss ich
mir Gedanken um ein Backup des Config-Roms machen. Hat schon
jemand sowas in VHDL geschrieben oder muss das doch per Hardware
erfolgen? Ich traue dem urjtag noch nicht ganz, mit einem einfachen
XC9536 hat er sich beim Aufspielen aufgehängt (naja, das 
Xilinx-USB-Kabel
ist auch depricated). Falls noch jemand probieren möchte, das sollte
mit Cygwin auch unter Windows funktionieren, kann ich gerne eine
Beschreibung liefern.

Gruß, Guido

[Blue F. (blueflash)]

Rolf W. schrieb:

> wie sieht es denn aus? Könntest Du Dich mit
> der Entwicklung im svn (OS) anfreunden?

Hi, habs versucht. Nachdem ich mein SVN schon soweit eingestellt hatte, 
das es sich synchronisiert, scheint sich in der Zwischenzeit etwas 
geändert zu haben - jedenfalls geht jetzt nichts mehr und meine Versuche 
eine Verbindung hinzukriegen waren leider erfolglos.

Da mir dadurch einfach zu viel Zeit nur an rumgewurschtel verloren 
gegangen ist habe ich mich mich jetzt lieber wieder auf die Firmware 
gestürzt um mal wieder Erfolge verzeichnen zu können.

Gruß Hayo

[mike0815 (Gast)]

Hallo Hayo,

Hayo W. schrieb:
> ...echte Post oder virtuelle??? ;-)

Hat es trotz Anleitung nicht geklappt?

Hat das Tool auch nix gebracht?


Gruß Michael

[Rolf W. (rowue)]

Hayo W. schrieb:
> Rolf W. schrieb:
>
>> wie sieht es denn aus? Könntest Du Dich mit
>> der Entwicklung im svn (OS) anfreunden?
>
> Hi, habs versucht. Nachdem ich mein SVN schon soweit eingestellt hatte,
> das es sich synchronisiert, scheint sich in der Zwischenzeit etwas
> geändert zu haben - jedenfalls geht jetzt nichts mehr und meine Versuche
> eine Verbindung hinzukriegen waren leider erfolglos.

Hmmm - Dein SVN? Hast Du versucht, zwei Repos miteinander zu 
synchronisieren? Das dürfte mit SVN eher schwierig werden ;)
Für dezentrale Versionsverwaltung müssen wir mit git oder
mercury arbeiten. (was ich mir manchmal wünschen würde, da
ich die Programmierung an der WS mache und brennen, testen,
etc am Notebook ;)
>
> Da mir dadurch einfach zu viel Zeit nur an rumgewurschtel verloren
> gegangen ist habe ich mich mich jetzt lieber wieder auf die Firmware
> gestürzt um mal wieder Erfolge verzeichnen zu können.

Verständlich. Falls Du doch noch einen Versuch mit SVN starten
möchtest, maile mich kurz an, dann mache ich Dir 'ne kurze Doku
mit einigen Screenshots (xfce + rapidsvn) fertig - eigentlich
ist das Arbeiten mit SVN sehr einfach ...
(zusammensetzen wird jetzt eher schwierig, da liegen 750km
zwischen ;)
>
> Gruß Hayo


Beste Grüße,

        rowue

[Blue F. (blueflash)]

mike0815 schrieb:
> Hallo Hayo,
>
> Hayo W. schrieb:
>> ...echte Post oder virtuelle??? ;-)
>
> Hat es trotz Anleitung nicht geklappt?
>
> Hat das Tool auch nix gebracht?

Hi, hab keine Post bekommen (keine echte und auch keine elektronische). 
Läuft da was schief?

Gruß Hayo

[Blue F. (blueflash)]

@Rolf

Ich hatte mir vor einiger Zeit KDE-SVN eingerichtet und es hat mir das 
Repository problemlos runtergeladen. Hochladen wäre sicherlich auch 
gegangen, aber ich hatte aus Zeitgründen ohnehin nicht mehr 
weiterentwickelt. Als ich vor einigen Tagen versuchte den aktuellen 
Stand runterzuladen kam keine Verbindung zum Repository zustande. Auch 
stundenlanges rumgefrickel brachte keine Lösung.

Na gut ich dengel derzeit an meinen BF Versionen weiter und versuche die 
tatsächlich brauchbaren Sachen aus der OS-Version zu übernehmen. Einiges 
gefiel mir nicht so gut, daher hab ich es dann bei mir auch weggelassen.

Gruß Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> @Rolf
>

re

> [SVN und SF]

Hmm - ich habe am WE aktualisiert (update), 'nen neuen Zweig
aufgemacht und da auch schon den einen oder anderen commit
gemacht - keine Probleme, allerdings hat SF manchmal auch
'nen schlechten Tag ;)

>
> Na gut ich dengel derzeit an meinen BF Versionen weiter und versuche die
> tatsächlich brauchbaren Sachen aus der OS-Version zu übernehmen. Einiges
> gefiel mir nicht so gut, daher hab ich es dann bei mir auch weggelassen.

5 - die Gedanken kenne ich ;) - Dann sollte ich fast mal nachsehen,
ob Du die Umstellung der Verstärkerstufen und die Anpassung an
die Bildschirmdarstellung übernommen hast ;)
>
> Gruß Hayo

Beste Grüße,

    rowue

[Blue F. (blueflash)]

Rolf W. schrieb:

> 5 - die Gedanken kenne ich ;) - Dann sollte ich fast mal nachsehen,
> ob Du die Umstellung der Verstärkerstufen und die Anpassung an
> die Bildschirmdarstellung übernommen hast ;)

Die Umstellung der Verstärkung ist in meiner aktuellen Version via 
Terminal umschaltbar! Ich habe allerdings andere Faktoren verwendet - 
einer der Punkte die mir nicht so gut gefielen, denn bei einer Änderung 
der Verstärkung müssen nicht nur die Skalierungsfaktoren angepasst 
sondern auch die DAC-Faktoren darauf abgestimmt werden.

Um hier unterschiedliche Hardware (0Ohm, 24Ohm, 33Ohm) bedienen zu 
können habe ich in der Zeichenroutine keine Konstanten verwendet (wie in 
der OS-Version) sondern Arrays.

Gruß Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> Rolf W. schrieb:
>
>> [Verstärkungsfaktoren]
>
> Um hier unterschiedliche Hardware (0Ohm, 24Ohm, 33Ohm) bedienen zu
> können habe ich in der Zeichenroutine keine Konstanten verwendet (wie in
> der OS-Version) sondern Arrays.

Will ich für die nächste OS-Version auch umstellen - Kalibrierung
über den DAC ;)

Die Faktoren für den DAC glaube ich noch umgestellt zu haben ...


>
> Gruß Hayo

Beste Grüße,

   rowue

PS: kann es sein, dass Du die Widerstände eine Grössenordnung
zu hoch ansetzt? Habe da was von 33 Ohm im Kopf - btw: der Widerstand
über dem ADC soll 'ne Grössenordnung zu groß sein (1k5 anstellen von
150 Ohm) - dazu gab es mal was im Hardware-Thread.

[Guido (Gast)]

Hallo Rolf,

ist nur falsch gelesen. deshalb immer ein Leerzeichen zwischen
Wert und Einheit. :-) Gerade bei Ohm.

Ich kann mir nicht vorstellen, dass die Widerstände die
DAC-Kalibrierung beeinflussen. Da ist die Differenz zum
Eingangswiderstand der Wandler zu groß (bei weniger als
8-Bit.Auflösung).

Gruß, Guido

[branadic (Gast)]

Hallo die Herren,

um das noch mal richtig zu stellen, damit es nicht falsch in den Köpfen 
bleibt:

Zwischen dem letzten AD8131 sind, wie wir alle wissen, 0 Ω Widerstände 
eingelötet, die von einigen Leuten durch Werte zwischen 15 Ω  - 33 Ω 
ersetzt wurden. Bei mir sind es übrigens 24,9 Ω. Messungen mit der 
neueren BF-Firmware habe ich aber nicht vor durchzuführen, weil ich 
darin persönlich kaum mehr Sinn sehe und mich lieber auf die neue 
Eingangsstufe konzentriere, wo eh die Skalierungsfaktoren wieder 
angepasst werden müssten. Egal.

Zwischen positivem Signalzweig und Negativem (Differenzsignal zum ADC) 
befindet sich noch ein Abschlusswiderstand von 150 kΩ (vergleiche auch 
folgenden Beitrag Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ).
Dieser liegt also direkt parallel zum Eingangswiderstand der vier ADCs 
und dürfte bei den meisten Leuten noch unangetastet geblieben sein.

Beste Grüße, branadic

[Michael D. (mike0815)]

Hallo, branadic

branadic schrieb:
> Zwischen positivem Signalzweig und Negativem (Differenzsignal zum ADC)
> befindet sich noch ein Abschlusswiderstand von 150 kΩ (vergleiche auch
> folgenden Beitrag Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ).
> Dieser liegt also direkt parallel zum Eingangswiderstand der vier ADCs
> und dürfte bei den meisten Leuten noch unangetastet geblieben sein.

Auf der Platine ist der 150 k lokalisiert, in den vorhandenen 
Schaltplänen kann ich ihn nicht ausmachen oder sind die nicht komplett?

Ob man mal einen Versuch starten sollte, den Wert mal zu halbieren?
Mich würde mal interessieren, was dabei raus kommt.


...bin ganz gespannt, wenn dein 'Platinchen' zum Einsatz kommt!

Gruß Michael

[Torsten W. (wirehead)]

Naja eiegntlich müsste man den mal durch sowas wie 168Ohm ersetzen. Die 
ADCs haben ja selber zusammen noch 1,1k. Das würde die Scalierung aber 
vollkommen über den haufen werfen.

Gruß
Torsten

[branadic (Gast)]

Hallo Torsten,

das der Wert falsch dimensioniert ist und dadurch viel Signal verschenkt 
wird steht außer Frage, aber wie du gerade auf einen Wert von 168 Ω 
kommst ist mir etwas schleierhaft.
Ich schätze, man hatte ursprünglich vor die Ausgänge des letzten AD8131 
auf eine definierte Impedanz zu bringen, indem man an die Stelle wo 
jetzt die 0 Ω Widerstände drin sind beispielsweise 50 Ω bestückt. Um den 
Ausgang richtig abzuschließen befindet sich dann vor den Eingängen des 
ADC ein Anpasswiderstand.
Im Beispiel mit den 50 Ω würde das bei den genannten 1,1 kΩ in Summe 
durch die 4 ADC bedeuten 110 Ω zu bestücken.
Der bestückte 150 kΩ hat nur einen geringen Einfluss auf die Amplitude, 
wenn man sich überlegt, dass resultierend 1,0919 kΩ vorhanden sind.
Korrekterweise müsste man hier mal angreifen. Das wird, zumindest im 
Zuge der Einpflanzung der Huckepackplatine in das Welec, eh geschehen.

Gruß, branadic

[Blue F. (blueflash)]

Hi,

den 150k Widerstand mal probeweise zu tauschen bietet sich ja eigentlich 
an. Ob es was bringt sieht man dann ja. Für geänderte verstärkungen 
lassen sich bei meiner Version auch unterschiedliche Faktoren 
hinterlegen. Eine Umschaltung per Menü ist noch in Arbeit.

Zur Zeit beackere ich gerade den Delayed Mode, leider sind recht 
umfangreiche Umbaumaßnahmen erforderlich, aber ich mache gute 
Fortschritte.

Die nächste Schnupperversion steht in den Startlöchern...


@Michael

die Schalter sind heute gekommen, vielen Dank! :-)

Gruß Hayo

[Guido (Gast)]

Nö,

Rumprobieren mit diesen Widerständen ist absolut witzlos. Wenn
man etwas verbessern möchte, nimmt man die Werte aus dem Datenblatt
des VideoAmp. Wie der Designer berücksichtigt hat, verschenkt man
damit Auflösung des ADC und diese wird eh nicht zufriedenstellend
ausgenutzt. Auch die DAC-Kalibrierung würde hierdurch beeinflusst.
Wenn man daran rumspielen möchte, muss man gleichzeitig die
Verstärkung der Eingangsstufe erhöhen. Bisher war es aber nichteinmal
möglich sich darauf zu verständigen, den OPA fest auf 1,25x zu legen.
Immer wieder kam ein Witzbold und erzählte was von Rauschen.

Schön, dass der Delayed-Mode bald wieder funktioniert. Der hat für
mich bisher den Charme des Gerätes ausgemacht. :-)

Grüße, Guido

[Michael D. (mike0815)]

branadic schrieb:
> Im Beispiel mit den 50 Ω würde das bei den genannten 1,1 kΩ in Summe
> durch die 4 ADC bedeuten 110 Ω zu bestücken.
> Der bestückte 150 kΩ hat nur einen geringen Einfluss auf die Amplitude,
> wenn man sich überlegt, dass resultierend 1,0919 kΩ vorhanden sind.

Dann wäre das an den beiden Ausgängen des AD8131 2x 24,9 Ohm anstatt 0 
Ohm und 110 Ohm anstelle des 150k, nach deiner Rechnung?
Wenn dem so ist, dann werde ich das mal testen!
Ich werde vor der Bestückung mal ein 500 KHz Sinus und Rechteck-Signal 
mit versch. Amplituden anlegen und einen Shot machen.
Nach dem Tausch dasselbe in Grün, damit wir einen Vergleich haben!
Wenn es Recht ist, teile ich dann das Ergebnis mit.

Guido schrieb:
> Bisher war es aber nichteinmal
> möglich sich darauf zu verständigen, den OPA fest auf 1,25x zu legen.

...warum eigentlich nicht?


> Immer wieder kam ein Witzbold und erzählte was von Rauschen.

Da bin ich wohl Einer davon...

Hayo W. schrieb:
> die Schalter sind heute gekommen, vielen Dank! :-)
>
>
>
> Gruß Hayo

...das ist ja unglaublich, waren die jetzt eine Woche unterwegs?

Gruß Michael

[Roberto (Gast)]

>Schön, dass der Delayed-Mode bald wieder funktioniert. Der hat für
>mich bisher den Charme des Gerätes ausgemacht. :-)
Freut mich auch :-) Danke Hayo :-)
l.G. Roberto

[Blue F. (blueflash)]

Guido schrieb:

>  Bisher war es aber nichteinmal
> möglich sich darauf zu verständigen, den OPA fest auf 1,25x zu legen.
> Immer wieder kam ein Witzbold und erzählte was von Rauschen.

??? Bei meiner letzten Beta (.BF.99 EE) sind wie ich auch beschrieben 
habe in der Standardeinstellung alle Verstärkungen auf 1.25 eingestellt. 
Man kann aber auch zum Vergleich via Terminal auf die alte Einstellung 
zurückschalten.

> Schön, dass der Delayed-Mode bald wieder funktioniert. Der hat für
> mich bisher den Charme des Gerätes ausgemacht. :-)

Ich kämpfe noch (Unkraut entfernen), bin aber schon recht weit.

Gruß Hayo

[Guido (Gast)]

>??? Bei meiner letzten Beta (.BF.99 EE) sind wie ich auch beschrieben
>habe in der Standardeinstellung alle Verstärkungen auf 1.25 eingestellt.

Oops, übersehen. Ich hoffe, dass ich bald wieder etwas mehr Zeit habe.

Gruß, Guido

[Blue F. (blueflash)]

Ein kurzer Zwischenstand nach einem wirklich schönen Tag.

Der neue Delayed Mode funktioniert schon richtig gut und hat einige neue 
delayed Zeitbasen bekommen. Ich muß nur noch einige Kleinigkeiten machen 
dann ist die nächste Version fertig.

Da ich morgen etwas eingespannt bin wird es wohl Dienstag oder Mittwoch 
soweit sein.

Gruß Hayo

[Blue F. (blueflash)]

Da ich heute nicht zum Programmieren komme, hier einige Detail-Infos zum 
Delayed Mode vorab.

Da eine gute Programmierung darauf basiert, dass man sich vorher!! über 
die Sache Gedanken macht habe ich hier mal die aktualisierten 
Programming Maps angehängt in der Ihr die neue Delayed Timebase Table 
findet auf der meine Umsetzung basiert.

Der Programmierer von Welec ist das Ganze viel zu kompliziert angegangen 
und hat sich dann (was abzusehen war) mit den ganzen Arrays und Indizes 
verhaspelt. Ich habe das Ganze komplett umgestellt und viel einfacher 
aufgebaut. Dadurch konnte ich das Coding im Timebasehandler deutlich 
reduzieren und auch diverse (unübersichtliche) Steuerarrays einsparen 
bzw. reduzieren.

Wie Ihr in der Delayed Timebase Table sehen könnt sind einige Timebases 
hinzugekommen (rote Schrift). Ich habe hier aber nicht das technisch 
machbare Maximum umgesetzt sondern habe nur die sinnvoll benutzbaren 
Timebases zur Verfügung gestellt.

Die eigentliche Delayed-Tb Steuerung ist auch schon fertig und 
funktioniert prima incl. Verschieben des Fensters und Triggerzeitpunkt. 
Es fehlt nur noch die Implementierung des Timebase-Faktors 2,5 (violett 
gekennzeichent) in der Zeichenroutine. Da werde ich aber erst morgen zu 
kommen.

So long

Hayo

[Blue F. (blueflash)]

Hatte doch noch Zeit heute!

New Version 1.2.BF.0.100 out now! Completely new designed delayed mode - 
enjoy now!

So jetzt aber Schluß, meine bessere Hälfte drängelt schon weil wir noch 
essen gehen wollen.

Ich bitte um Rückmeldung ob wirklichalles so gut funktioniert wie bisher 
von mir getestet.

Gruß Hayo

[Michael H. (Gast)]

Wie immer bin ich fassunglos, wo du die Energie hernimmst, sowas so 
schnell auf die Beine zu stellen. Irre! Ich habe gerade einen ersten 
Test mit dem Oszi-generierten Rechteck gemacht und da schien alles 
bestens zu funktionieren.
Tolle Sache, danke dafür!

Gruß,
Michael H.

[mike0815 (Gast)]

...der Hayo, da kennt der nix!

Sach mal, hast du da einen Reset-Mode mit eingebaut, weil das Teil nach 
dem Flashen von alleine hochfährt?

Noch eine allgemeine Frage: Hat schon Jemand Erfahrung mit dem USB to 
RS232 Adapter auf Basis des FT232 bezüglich des Flashens gemacht?
Ich meine mal gelesen zu haben, das es da Probleme geben könnte?

Gruß Michael


PS. (Hayo) ...funzen die Schalter?

[Blue F. (blueflash)]

mike0815 schrieb:

> PS. (Hayo) ...funzen die Schalter?

Bin grad zurück, keine Ahnung wegen der Schalter. War das Wochenende 
über weg und hatte noch keine Gelegenheit an der Hardware rumzubasteln.

Gruß Hayo

[Roberto (Gast)]

Hallo Hayo
Gratuliere und danke für die schöne Version!

Habe mal getestet:
Kann es sein dass die Stufen von dem Delay unterschiedlich tief sind ?
z.B. bei 10us habe ich 2 Stufen von Delay, bei 1us habe ich 6 Stufen !?
Bei 6 Stufen ist es super, rein und raus zoomen :-)
Habe mal einige Zeiten durchprobiert und mir ist was aufgefallen:
Signal = 100kHz Rechteck, ss ca. 20V  DSO: 5V/div

Bei 2us und 1us habe ich im Delay-Mode eine sehr schlechte Flanke.
(siehe Bild)
Bei den anderen Zeiteinstellungen nicht!

Noch was:

Kalibrieren:
Soweit ich in Erinnerung habe, werde ja jetzt alle Spannungsbereiche 
automatisch kalibriert?!
Ist das nur unter 1V ? (also ab der 500mV Stufe)
Da klappern die Relais. Bei 5V nicht?!

Noch was :-) (weil Du schon die perfekte Version willst ;-) )
Wenn ich auf Zerro-Linie gehe, gehen die Linien immer aus der 
Mittel-Linie..?!
Mache also zuerst: Calibrate ADC und DAC und alle Linien sind schön.
Wenn ich dann auf Zerro-Line gehe, sind alle Linien wieder wo anders :-(

l.G. Roberto

[Blue F. (blueflash)]

Oh je, da muß ich wohl noch mal einiges erklären, macht aber nix:

Roberto schrieb:
> Hallo Hayo
> Gratuliere und danke für die schöne Version!

Gerne doch!

> Habe mal getestet:
> Kann es sein dass die Stufen von dem Delay unterschiedlich tief sind ?
> z.B. bei 10us habe ich 2 Stufen von Delay, bei 1us habe ich 6 Stufen !?
> Bei 6 Stufen ist es super, rein und raus zoomen :-)

Aber ja doch, das liegt an den unterschiedlichen Sampletiefen der 
Hauptzeitbasis. Ich kann sinnvollerweise nur soweit runter gehen wie ich 
an Wertevorrat im Speicher habe, da ich sonst interpolieren müßte (hab 
ich schon drüber nachgedacht, aber ist das sinnvoll??).

Den genauen Zusammenhang kann man aus der weiter oben eingestellten 
Timebase Table entnehmen.

> Habe mal einige Zeiten durchprobiert und mir ist was aufgefallen:
> Signal = 100kHz Rechteck, ss ca. 20V  DSO: 5V/div

> Bei 2us und 1us habe ich im Delay-Mode eine sehr schlechte Flanke.
> (siehe Bild)
> Bei den anderen Zeiteinstellungen nicht!

Interessant! Das könnte mit dem weiter oben geposteten Problem der 
Wertevertauschung bei ein oder zwei Zeitbasen zusammenhängen. Da kann 
ich aber über den Delaymode nix dran ändern, der kann nix dafür.


> Noch was:
>
> Kalibrieren:
> Soweit ich in Erinnerung habe, werde ja jetzt alle Spannungsbereiche
> automatisch kalibriert?!
> Ist das nur unter 1V ? (also ab der 500mV Stufe)
> Da klappern die Relais. Bei 5V nicht?!

Die Kalibrierung findet bei 5V  2V  1V statt. Das ist dann für alle 
anderen Bereiche auch gültig. Wenn Du schon in einem dieser Bereich bist 
hörst Du nix. Wenn Du aber weiter "unten" bist muß erst hochgeschaltet 
werden und dann klackert es.

> Noch was :-) (weil Du schon die perfekte Version willst ;-) )
> Wenn ich auf Zerro-Linie gehe, gehen die Linien immer aus der
> Mittel-Linie..?!
> Mache also zuerst: Calibrate ADC und DAC und alle Linien sind schön.
> Wenn ich dann auf Zerro-Line gehe, sind alle Linien wieder wo anders :-(

Oh oh! Falsche Reihenfolge! Die Zeroline-Funktion ist noch ein 
Überbleibsel von Welec - daher arbeitet sie wie zu erwarten auch nicht 
so toll. Die anderen beiden Funktionen sind von mir und sollen das 
wieder ausbügeln. Am Besten geht man also von links nach rechts durch 
das Menü:

- erst Zerolines suchen (evtl. vorher default Setup)
- dann ADC kalibrieren
- dann DAC kalibrieren

Danach sollte alles stimmen.

Gruß Hayo

[Blue F. (blueflash)]

mike0815 schrieb:
> ...der Hayo, da kennt der nix!
>
> Sach mal, hast du da einen Reset-Mode mit eingebaut, weil das Teil nach
> dem Flashen von alleine hochfährt?

Das bewirkt die letzte Zeile in der .flash Datei - funktioniert aber 
witzigerweise nicht immer. Man sollte aber auf jeden Fall dann noch 
einen Reset machen, (!!!!) denn das Oszi fährt nicht mit der neuen 
Firmware hoch sondern mit der alten die noch im RAM steht!! Das ist mir 
auch schon öfters passiert und ich hab mich dann gewundert warum von den 
Änderungen nichts zu sehen ist :-)

Hayo

[gyppe (Gast)]

Hayo thanks for the new version of firmware. You're a great worker 
compliments! :)

I have a question, use the basis of time from 1 second activates the 
shift mode and roll, but if you use the trigger voltages does not work, 
I press the trigger to start it and then turn level switch.
It 's a choice or a bug?

I also saw that the software in this mode becomes very slow and does not 
trigger menu.


Thank you.

[Kurt B. (kurt)]

Hallo zusammen,
in wie weit fließen eigentlich die Features der BF-Versionen in die OS 
Version ein?
Gibt es eine Übersicht über die Unterschiede zwischen den Versionen, 
oder gilt wieder Punkt 1?

Mfg,
Kurt

[Blue F. (blueflash)]

gyppe schrieb:
> Hayo thanks for the new version of firmware. You're a great worker
> compliments! :)

Thanks a lot!

> I have a question, use the basis of time from 1 second activates the
> shift mode and roll, but if you use the trigger voltages does not work,
> I press the trigger to start it and then turn level switch.
> It 's a choice or a bug?

There is no triggering at ultra slow timebases because every single 
value is an avarage values of an ADC-line. Therefore triggering makes no 
sense.

> I also saw that the software in this mode becomes very slow and does not
> trigger menu.

Hmm, I checked this at 2s/Div but can't see what You mean. The menu 
reacts faster than in standard mode. Did I understand You right?

Hayo

[Blue F. (blueflash)]

Kurt Bohnen schrieb:
> Hallo zusammen,
> in wie weit fließen eigentlich die Features der BF-Versionen in die OS
> Version ein?

Zur Zeit garnicht, da ich die Sourcen nicht veröffentlicht habe und mit 
dem SVN wie weiter oben beschrieben Probleme hatte.

> Gibt es eine Übersicht über die Unterschiede zwischen den Versionen,
> oder gilt wieder Punkt 1?

Ich habe meine Änderungen jetzt mit einer neuen Nummerierung versehen, 
die Änderungen leichter nachvollziehbar macht. Ich würde vorschlagen wir 
stellen meine Versionen als extra Branch ins OS-Repository und dann kann 
entschieden werden ob Änderungen in die OS-Version übernommen werden 
oder nicht. Dann kommen wir uns nicht ins Gehege.

Gruß Hayo

[Blue F. (blueflash)]

Michael H. schrieb:
> Wie immer bin ich fassunglos, wo du die Energie hernimmst, sowas so
> schnell auf die Beine zu stellen. Irre!

Da geht noch mehr!

New 1.2.BF.0.101 out now!

Was ist neu - What is new?

Neue Utility-Menüstruktur mit neuem Harware-Menü.
New utility menu with new hardware menu

Anbei die Programming Maps mit der neuen Struktur, und wegen der 
Nachfragen auch noch mal eine Anleitung zur Kalibrierung.

Achtung! Die neuen Gain Einstellungen im Hardwaremenü sind noch nicht 
mit korrekten Skalierungen versehen. Im Zweifelsfalle Factory Setting 
benutzen!

Be careful! The new Gain Settings in the hardware menu don't have 
correct scaling factors yet. Please use the factory setting for default.

Viel Spass Hayo

[gyppe (Gast)]

Hmm, I checked this at 2s/Div but can't see what You mean. The menu
reacts faster than in standard mode. Did I understand You right?

Sorry for my bad English. :)
In slow mode not function the trigger menu, to activate the recording 
mode should I press on mode trigger button and rotate the switch level 
trigger, so the recording starts with voltages DC.

[Roland B. (Gast)]

Hallo Hayo,

die "Singletaste" schaltet automatisch ohne daß ein Signal anliegt auf 
"Stop".
ab welcher Version das nicht mehr funktioniert ist mir unbekannt, bei 
Version 0.97 funktioniert es jedenfalls noch.

Grüße

Roland

[Blue F. (blueflash)]

gyppe schrieb:

> Sorry for my bad English. :)
> In slow mode not function the trigger menu, to activate the recording
> mode should I press on mode trigger button and rotate the switch level
> trigger, so the recording starts with voltages DC.

Ok, I got it. You are right, there is a bug because of the new combi 
trigger. I will fix it soon. The new version will be available in a view 
minutes.

@all

Hi Leute, da gibt's einen Bug wegen des neuen Combi Triggers. Ich hau 
gleich mal einen Bugfix raus.

Gruß Hayo

[Blue F. (blueflash)]

Roland B. schrieb:
> Hallo Hayo,
>
> die "Singletaste" schaltet automatisch ohne daß ein Signal anliegt auf
> "Stop".

Ok, ist das gleiche Problem, Fix ist in Arbeit und kommt dann gleich.

Gruß Hayo

[Blue F. (blueflash)]

Alles klar!

Hab gleich noch ein paar kleine Bugs gekillt.

Danke an Roland und gyppe für die Hinweise.

Get here the 1.2.BF.0.102 with newest fixes.

Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> Kurt Bohnen schrieb:
>> Hallo zusammen,
>> in wie weit fließen eigentlich die Features der BF-Versionen in die OS
>> Version ein?
>
> Zur Zeit garnicht, da ich die Sourcen nicht veröffentlicht habe und mit
> dem SVN wie weiter oben beschrieben Probleme hatte.

Beim letzten Male haben wir wohl auch das eine oder andere übersehen,
was im nachlauf zu Problemen führte.
>
>> Gibt es eine Übersicht über die Unterschiede zwischen den Versionen,
>> oder gilt wieder Punkt 1?
>
> Ich habe meine Änderungen jetzt mit einer neuen Nummerierung versehen,
> die Änderungen leichter nachvollziehbar macht. Ich würde vorschlagen wir
> stellen meine Versionen als extra Branch ins OS-Repository und dann kann
> entschieden werden ob Änderungen in die OS-Version übernommen werden
> oder nicht. Dann kommen wir uns nicht ins Gehege.

Von mir aus kein Problem - stellt sich nur die Frage, wie wir es machen.
Willst Du es nochmal direkt mit SF probieren? Von der Struktur her
würde ich sagen, dass wir es neben "oss" und "welec" legen.
(Die SVN-Url wäre dann: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/bf/[trunk, 
branches, tags]) (und http (ohne s) zum Auschecken)

>
> Gruß Hayo

Beste Grüße,

     rowue

[GiBr (Gast)]

Hallo zusammen,

um es kurz um einfach zu machen:
Hut ab!!! Ein großes Lob an Hayo und das restliche Team!
Durch eure Arbeit, macht das Gerät überhaupt erst Spass.


Gruß,
   GiBr

[gyppe (Gast)]

My God very very very thanks Hayo! :) Incredible speed!
Now function very perfect, thanks.

[Michael D. (mike0815)]

Hayo W. schrieb:

Michael schrieb:
>> Sach mal, hast du da einen Reset-Mode mit eingebaut, weil das Teil nach
>
>> dem Flashen von alleine hochfährt?
>
>
>
> Das bewirkt die letzte Zeile in der .flash Datei - funktioniert aber
> witzigerweise nicht immer. Man sollte aber auf jeden Fall dann noch>
> einen Reset machen, (!!!!) denn das Oszi fährt nicht mit der neuen
> Firmware hoch sondern mit der alten die noch im RAM steht!! Das ist mir
> auch schon öfters passiert und ich hab mich dann gewundert warum von den
> Änderungen nichts zu sehen ist :-)
>
...eben, mir ging das genauso, da der DELAY-MODE gar keine Veränderung 
aufwies.
>
>
> Hayo

Was hat denn im Neuen Hardware-Menu die 'PRE GAIN' , 'ADD ON' für eine 
Funktion?
Ich kann zwischen 33 Ohm und ADD ON keinen Unterschied feststellen!

Ansonsten ein fettes Lob für deine Arbeit!!!

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:

> Was hat denn im Neuen Hardware-Menu die 'PRE GAIN' , 'ADD ON' für eine
> Funktion?

"Add On" ist für zusätzliche Hardware. Ich dachte da an das neue Board 
mit der Eingangsstufe welches gerade im Hardwarethread aktuell 
entwickelt wird.

> Ich kann zwischen 33 Ohm und ADD ON keinen Unterschied feststellen!

die drei letzten Einträge haben (noch) alle die gleichen Faktoren, da 
mir hier die Anhaltspunkte mangels geiegneter Hardware fehlen.

Ich bin noch am Überlegen wie man der Sache beikommen könnte, ich hatte 
da folgende Ideen:

- ich ändere die Werte auf Zuruf (ist vielleicht etwas umständlich)
- ich löte mir die Teile ein und tüftle es selbst aus
- ich zeige Euch an welcher Stelle Ihr die Werte ändern müßt und Ihr 
tüftelt die Werte dann aus


By the way, gibt es eigentlich noch ernsthafte Schnitzer die noch 
beseitigt werden müssen bevor ich die Versionsnummer auf Stable Release
umstellen kann?

Gruß Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> Ich bin noch am Überlegen wie man der Sache beikommen könnte, ich hatte
> da folgende Ideen:
>
> - ich ändere die Werte auf Zuruf (ist vielleicht etwas umständlich)
>
Welche Werte benötigst du da? Widerstandswert ist klar, die differenz, 
voher -nacher, oder...

> - ich löte mir die Teile ein und tüftle es selbst aus
>
Bei 4 Kanälen hättest du ja alle Werte abgedeckt!
Man könnte auch im gleichen Zuge die angesprochene Variante mit:

 > branadic schrieb:
>> Im Beispiel mit den 50 Ω würde das bei den genannten 1,1 kΩ in Summe
>> durch die 4 ADC bedeuten 110 Ω zu bestücken.
>> Der bestückte 150 kΩ hat nur einen geringen Einfluss auf die Amplitude,
>> wenn man sich überlegt, dass resultierend 1,0919 kΩ vorhanden sind.

> - ich zeige Euch an welcher Stelle Ihr die Werte ändern müßt und Ihr
> tüftelt die Werte dann aus

...hmm


Gruß Michael

[Blue F. (blueflash)]

verstehe...

[Blue F. (blueflash)]

Michael D. schrieb:

> Welche Werte benötigst du da? Widerstandswert ist klar, die differenz,
> voher -nacher, oder...

Genau. Ich baue sie ein - Ihr testet und sagt mehr oder weniger, bzw. 
postet einen Screenshot

Könnte man so machen

Gruß Hayo

[egberto (Gast)]

Hallo Hayo,

erst mal vielen Dank für die neue Version - schön das es voran geht!!!

Ich habe mal kurz mit der 102 rumgespielt, ein kleines Problem habe ich 
auf die schnelle gesehen: der XY Modus für Kanal 3/4 funktioniert nicht, 
es kommt nur links ein vertikaler Strich von Kanal 3, aber keine Figur 
(habe mit offenen Eingängen getestet, da bekommt man ja auf Kanal 1/2 in 
der Mitte so ein "Knäul" vom Rauschen).

Dann einen schönen Abend und frohes Schaffen!!!

Viele Grüße,

egberto

[Blue F. (blueflash)]

So,

das erste Stable Release BF.1.0 steht in den Startlöchern. Die Tickets 
mit major bugs sollten mit dieser Version erledigt sein:

#24 - checked, scheint ok zu sein
#34 - fixed
#35 - checked, scheint ok zu sein
#37 - fixed
#48 - checked, scheint ok zu sein
#50 - fixed

Falls keinem mehr was einfällt stelle ich die neue Version in Kürze hier 
ein.


Hayo

[Roberto (Gast)]

Hallo Hayo
>By the way, gibt es eigentlich noch ernsthafte Schnitzer die noch
>beseitigt werden müssen bevor ich die Versionsnummer auf Stable Release
>umstellen kann?

Wenn Du unbedingt noch Arbeit brauchst :-)

FFT ist noch eine Baustelle.
Es scheint da so , als ob die Werte nur beim umschalten auf FFT, 
übernommen werden und Angezeigt werden.
Im FFT Modus selbst,tut sich dann nix mehr.

---

Trigger:

Bei mir wandert der Trigger bei einem Signal von 10kHz (Rechteck) und 
einer Einstellung von 10us-1us . Triggermodus= "Auto"
Unter 10us ( z.B. 20us) steht das Signal.
Triggermodus "Normal" und "Compi" passen auch.
Für was ist eigentlich der Triggermodus "Auto" ?

l.G. Roberto

[egberto (Gast)]

und den XY Fehler (siehe oben) bitte auch nicht vergessen...

Wo sehe ich eigentlich die Bugliste für Hayos Version ??

[Torsten W. (wirehead)]

Hallo, hab auch grade die neue version draufgeworfen.
Sieht soweit gut aus.
Problem:
Ich bekomm bei Kanal2 die Nulllinie nicht kalibriert.
Beim ersten mal hat das geklappt. Bei der 2. Kallibrierung nach 
Anleitung bleibt die 0linie nach der DAC Klaibrierung ein halbes div 
unter dem Marker stehen. Obwohl es nach "Search zero" noch halbwegs gut 
aussah.

Kann ich diese Kalibrierungseinstellung im flash irgendwie löschen?

Beim verscheiben der 0linie nach oben wird das rauschen übrigens 
stärker.

Gruß
Torsten

[Blue F. (blueflash)]

Roberto schrieb:
> Hallo Hayo
>>By the way, gibt es eigentlich noch ernsthafte Schnitzer die noch
>>beseitigt werden müssen bevor ich die Versionsnummer auf Stable Release
>>umstellen kann?
>
> Wenn Du unbedingt noch Arbeit brauchst :-)

Stöhn...


> FFT ist noch eine Baustelle.
> Es scheint da so , als ob die Werte nur beim umschalten auf FFT,
> übernommen werden und Angezeigt werden.
> Im FFT Modus selbst,tut sich dann nix mehr.

Ok prüfe ich

> Trigger:
>
> Bei mir wandert der Trigger bei einem Signal von 10kHz (Rechteck) und
> einer Einstellung von 10us-1us . Triggermodus= "Auto"

was meinst Du mit "der Trigger wandert" ?

> Unter 10us ( z.B. 20us) steht das Signal.

Ok prüfe ich

> Triggermodus "Normal" und "Compi" passen auch.
> Für was ist eigentlich der Triggermodus "Auto" ?

Beim Normaltrigger bleibt alles stehen wenn kein Triggerereignis 
eintritt, beim Auto-Trigger läuft das Signal trotzdem nach kurzer Zeit 
weiter.

Der Combi-Trigger ist eine Kombination von Beidem (es wird via Timer 
zwischen beiden hin und her geschaltet).


Gruß Hayo

[Blue F. (blueflash)]

egberto schrieb:
> und den XY Fehler (siehe oben) bitte auch nicht vergessen...

Ok prüfe ich

> Wo sehe ich eigentlich die Bugliste für Hayos Version ??

Es gibt keine explizite Liste, deshalb meine Umfrage hier! Im 
wesentlichen orientiere ich mich aber an den Tickets der OS-Version.

Gruß Hayo

[Blue F. (blueflash)]

Torsten W. schrieb:
> Hallo, hab auch grade die neue version draufgeworfen.
> Sieht soweit gut aus.
> Problem:
> Ich bekomm bei Kanal2 die Nulllinie nicht kalibriert.
> Beim ersten mal hat das geklappt. Bei der 2. Kallibrierung nach
> Anleitung bleibt die 0linie nach der DAC Klaibrierung ein halbes div
> unter dem Marker stehen. Obwohl es nach "Search zero" noch halbwegs gut
> aussah.
>
> Kann ich diese Kalibrierungseinstellung im flash irgendwie löschen?

Also grundsätzliches Vorgehen:

- DSO ausschalten und neu starten
- default Setup aufrufen
- Search Zerolines
- ADC kalibrieren
- DAC kalibrieren

-> dann sollte es stimmen. Klappt bei meinen Beiden immer!

Bitte um Rückmeldung

Hayo




> Beim verscheiben der 0linie nach oben wird das rauschen übrigens
> stärker.
>
> Gruß
> Torsten

[Roberto (Gast)]

>was meinst Du mit "der Trigger wandert" ?
Sorry, meinte; das Signal wandert.(Steht nicht still)
l.G. Roberto

[TO-2 (Gast)]

Hi Hayo.
Thanks so much for the excellent work that you make available to us!
I bought the W2012A because economic and the only compatible with my 
limited finances.
I use the oscilloscope to work, first I was pretty limited in using it 
and I lost a long time to overcome the defects and still I couldn't do 
certain things that I needed.
Then I accidentally discovered this forum and your beautiful software 
and so I started to use them.
Truly a miracle, I could do things that not even dreamed of being able 
to do with my Welec oscilloscope!
All this has allowed me to work better and more efficiently without 
wasting time, allowing me to be able to operate more complex equipment. 
Consequently, this has allowed me to higher profit margins so I could 
also buy a W2022A that helps me in my work and that I needed too.
Thanks to your wonderful work I can more easily meet my clients and I 
have been able to professionally grow!
Now I can say I did certainly a good investment and this thanks to you 
and all those who contributed to the work, so i really have no words to 
thank you Hayo, really I have no words!
I'll always be your debtor!
Regards

p.s. I'm really sorry for my bad English.

[Michael D. (mike0815)]

Roberto schrieb:
>>was meinst Du mit "der Trigger wandert" ?
> Sorry, meinte; das Signal wandert.(Steht nicht still)
> l.G. Roberto

Hallo Roberto,

der Auto- und Normal-Trigger, waren beim Welec schon immer Standart, 
wobei das "Rumzappeln" im Auto-Mode schon immer ein Problem war!
Während der Normal-Mode nur funzt, wenn...(wie Hayo schon erwähnte) 
...ein Triggerereignis vorhanden ist, wenn nicht, bleibt er eben stehen!
Der Auto-Trigger "zappelt" dann weiter, deshalb hat der Stefan letzes 
Jahr ein hin u. her Schalten von Beiden Modis realisiert, da hies er 
"STANDART" und jetzt heißt er "COMBI" !
...der Combi-Modus ist ein absolutes Highlight, finde ich, wäre gar 
nicht mehr weg zu denken!


Hat jetzt endlich mal Jemand mit den modifizierten Widerständen und den 
neuen Calibrierungen experimentiert???
Ich ärgere mich, das ich die wieder gegen die 0 Ohm getauscht 
habe(Aceton, Wattest., Pinzette, 3Fach-10Fach-Lupe und eine Flasche 
Doppelherz...

Gruß Michael

[Michael D. (mike0815)]

Der TO-2 schwebt im 7ten Himmel!
Mich würde mal interessieren, was für ein Landsmann er ist...

Tja Hayo, du hast mit deiner Arbeit gerade eine Existenz gerettet!!!
...mich hat das jetzt schon etwas emotional berührt.

Gruß Michael

[Blue F. (blueflash)]

TO-2 schrieb:
> Hi Hayo.
> Thanks so much for the excellent work that you make available to us!

Hi TO-2,

Thanks a lot for Your nice response. That motivates me to go ahead with 
the development. But don't let us forget those guys around here who did 
their part as well - not at least the guys who are developing new 
FPGA-designs and other hardware stuff! (-> see at hardware thread)

So You should watch out for the first stable release I will post here 
soon.

May I ask from which country You are?

p.s. your english is not as worst as mine ;-)

regards

Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> und eine Flasche Doppelherz...

Benutzt Du das als Flußmittel? (har, har...)

Hayo

[Blue F. (blueflash)]

Roberto schrieb:

> FFT ist noch eine Baustelle.
> Es scheint da so , als ob die Werte nur beim umschalten auf FFT,
> übernommen werden und Angezeigt werden.
> Im FFT Modus selbst,tut sich dann nix mehr.

- Geprüft! Funktioniert alles einwandfrei. Sobald sich die Samplerate 
ändert werden auch die aktuellen Werte angezeigt.

- Was es noch zu tun gibt sind die zusätzlichen Anzeigemodi für die FFT, 
aber das tut dem Stable Release wohl keinen Abbruch, da es ja kein 
Fehler ist sondern nur ein noch nicht implementiertes Extra.

> Trigger:
>
> Bei mir wandert der Trigger bei einem Signal von 10kHz (Rechteck) und
> einer Einstellung von 10us-1us . Triggermodus= "Auto"
> Unter 10us ( z.B. 20us) steht das Signal.
> Triggermodus "Normal" und "Compi" passen auch.

Ja das stimmt, das liegt mit ziemlicher Sicherheit an dem Zusammenspiel 
aus der Periodenlänge des Signals und dem (zu kurzen) Timing der 
Autotriggerrücksetzung.

Aber dafür ist ja extra der Combi-Trigger dazugekommen, der hat nämlich 
ein längeres Timing (500 ms) und wird daher nicht vor dem Ende der 
Signalperiode zurückgesetzt.

Damit sehe ich das auch als gelöst an

Gruß Hayo

[Blue F. (blueflash)]

egberto schrieb:

> Ich habe mal kurz mit der 102 rumgespielt, ein kleines Problem habe ich
> auf die schnelle gesehen: der XY Modus für Kanal 3/4 funktioniert nicht,
> es kommt nur links ein vertikaler Strich von Kanal 3, aber keine Figur
> (habe mit offenen Eingängen getestet, da bekommt man ja auf Kanal 1/2 in
> der Mitte so ein "Knäul" vom Rauschen).

- Geprüft! Funktioniert alles wie es soll. Ich habe auf 1/2 und auf 3/4 
getestet, es kommt jedesmal die gleiche korrekte Figur. Hast Du evtl. 
die Normal-Triggerung angehabt und dann auf dem falschen Kanal 
getriggert?

Anbei ein Screenshot davon, man kann dabei auch die neue 
Screenshotauswahl der BF.1.0 sehen.

Da sich die bisherigen Meldungen zerstreut haben wird es wohl heute 
Abend mit dem Stable Release soweit sein.

Gruß Hayo

[moud (Gast)]

Hallo,

wow, das wäre ja der Hammer! Ich verfolge diesen Thread schon seit einem 
guten halben Jahr und habe immer auf diesen Tag gewartet. Endlich kann 
aus dem mehr oder weniger nutzlosen Kasten ein echtes Oszi werden!

Vielen Dank an alle die geholfen haben!


MfG
moud

[egberto (Gast)]

Hallo Hayo,

habe noch mal getestet - ein "Default Setup" hat wunder gewirkt, geht 
jetzt auch bei mir!

Dann warten wir mal gespannt auf die 1.0.

Viele Grüße,

egberto

[Bernhard M. (boregard)]

Hayo W. schrieb:
> Torsten W. schrieb:
>> Hallo, hab auch grade die neue version draufgeworfen.
>> Sieht soweit gut aus.
>> Problem:
>> Ich bekomm bei Kanal2 die Nulllinie nicht kalibriert.
>> Beim ersten mal hat das geklappt. Bei der 2. Kallibrierung nach
>> Anleitung bleibt die 0linie nach der DAC Klaibrierung ein halbes div
>> unter dem Marker stehen. Obwohl es nach "Search zero" noch halbwegs gut
>> aussah.
>>
>> Kann ich diese Kalibrierungseinstellung im flash irgendwie löschen?
>
> Also grundsätzliches Vorgehen:
>
> - DSO ausschalten und neu starten
> - default Setup aufrufen
> - Search Zerolines
> - ADC kalibrieren
> - DAC kalibrieren
>
> -> dann sollte es stimmen. Klappt bei meinen Beiden immer!
>
> Bitte um Rückmeldung

Hallo,

bei mir der gleiche Effekt.
Ich habe bei meinem 2012 zuerst die Prozedur
 - Search Zerolines
 - ADC kalibrieren
 - DAC kalibrieren
durchgeführt. Danach waren die Nulllinien in Ordnung.
Seit ich:
 - default Setup aufrufen
 - Search Zerolines
 - ADC kalibrieren
 - DAC kalibrieren
ist bei mir auch die Nulllinie des 2. Kanals einen halben Marker zu tief 
(genaugenommen 0.6). Der erste Kanal ist einen viertel zu hoch! Das ist 
jetzt so reproduzierbar. Mache ich die Prozedur ohne "DAC kalibrieren" 
ist siein Ornung, "DAC kalibrieren" schiebt sie nach unten. Das ist auch 
so mit Aus- und Einschalten vorher...

...
So weiter getestet.
Der Offset ist irgendwie auch abhängig von der Position, weiter unten 
ist der Effekt größer, weite oben kleiner. Es scheint auch immer der 
Kanal, der weiter unetn dargestellt wird, stärker betroffen zu sein... 
aber:
Es tritt nur bei 1GS/s auf! Wenn ich die Zeitbasis so verändere, daß 
500MS/s gesamplet werden, dann stimmen die Nulllininen. Und es reicht 
(bei den Vergleichen hier), die DAC Kalibrierung durchzuführen.

Gruß,
Bernhard

[Thomas (kosmos)]

also danke nochmal "Jungs" für die neuen Version.

Kann mir jemand bitte den direkten Link zum Download der neuen Firmware 
schicken, ist mit 53,6 kBit/s etwas mühsam bei Seitenaufbauzeiten die im 
Minutenbereich liegen mich da durchzuklicken.

[Roberto (Gast)]

Hallo Hayo
>> Im FFT Modus selbst,tut sich dann nix mehr.

>- Geprüft! Funktioniert alles einwandfrei. Sobald sich die Samplerate
>ändert werden auch die aktuellen Werte angezeigt.

Habe nochmal probiert. Ja stimmt, jetzt tut er komischerweise etwas..
Wenn ich das Kabel aber vom Osci abklemme, bleibt das Bild stehen.
Vielleicht passte das Signal letztes mal nicht ganz und das Bild blieb 
deshalb stehen ?

l.G. Roberto

[Blue F. (blueflash)]

Hi Leute,

Ihr könnt Euch schlafen legen, ich hab doch noch eine Kleinigkeit zum 
Verbessern gefunden und haue deshalb die 1.0 erst morgen raus.

Seid nicht böse, dafür ist sie auch ein klein wenig besser.

Vielleicht findet ja noch jemand ne Macke die es auszubügeln gibt...

Gruß Hayo

[egberto (Gast)]

Auch gut, da mach ich noch ein Weinchen auf :-)))))

Und falls du mal hier in Stralsund sein solltest, lade ich dich zum 
Griechen ein!! Ist versprochen!!

Viele Grüße,

egberto

[Roberto (Gast)]

Hallo Hayo
>Vielleicht findet ja noch jemand ne Macke die es auszubügeln gibt...
Ich habe ja schon ein schlechtes Gewissen ;-) aber weil du so fragst :-)

Habe jetzt das erste mal den XY-Modus versucht..
Da scheint wirklich was nicht zu stimmen.
Habe mal auf den ersten Kanal ein 100kHz Signal raufgegeben.
Ergebniss im Bild.
Da steht immer so eine komische Linie nach unten/oben ?
Die Horizontale Linie ist das Signal und nach unten schaut eine Linie, 
die nicht passt. ?!
Wenn ich mit dem Offset vom Signal rauf oder runter gehe, zeigt die 
Linie einmal nach unten und einmal nach oben!
Es ändert sich auch mit der Frequenz. Nicht bei allen Frequenzen gleich!
Hat das vieleicht etwas mit den rätselhaften Spikes zu tun ?

Noch ein große Bitte:
Ist mir gerade bei dem Screenshot machen aufgefallen.
Kann deine Version jetzt nur das bmp screenshot?
Bei der anderen Version gingen da noch andere Formate wie: ppm.. u.s.w.
Kannte diese Formate vorher nicht, aber da gibt es das schöne Programm 
"FineView" das dieses Format ganz einfach in .jpg umwandeln kann und 
dann das Bild um das 10fache kleiner macht. :-)

Ich weis , ich nerve ;-)

l.G. Roberto

[Blue F. (blueflash)]

egberto schrieb:
> Auch gut, da mach ich noch ein Weinchen auf :-)))))
>
> Und falls du mal hier in Stralsund sein solltest, lade ich dich zum
> Griechen ein!! Ist versprochen!!

Ist ein Wort! Einstweilen hab ich auch erstmal ein Fläschchen entkorkt - 
einmal am Tag will man sich auch selbst gehören...

Hayo

[Blue F. (blueflash)]

Roberto schrieb:
> Hallo Hayo
>>Vielleicht findet ja noch jemand ne Macke die es auszubügeln gibt...
> Ich habe ja schon ein schlechtes Gewissen ;-) aber weil du so fragst :-)
>
> Habe jetzt das erste mal den XY-Modus versucht..
> Da scheint wirklich was nicht zu stimmen.
> Habe mal auf den ersten Kanal ein 100kHz Signal raufgegeben.
> Ergebniss im Bild.
> Da steht immer so eine komische Linie nach unten/oben ?
> Die Horizontale Linie ist das Signal und nach unten schaut eine Linie,
> die nicht passt. ?!

Das ist die   Startlinie, die ist aber nicht mehr zu sehen wenn man da 
richtige Signale draufgibt - z.b. ein phasenverschobenes Sinussignal, 
der Klassiker quasi wie schon Herr Jules Antoine Lissajous so um 1850 
rausfand.


> Wenn ich mit dem Offset vom Signal rauf oder runter gehe, zeigt die
> Linie einmal nach unten und einmal nach oben!
> Es ändert sich auch mit der Frequenz. Nicht bei allen Frequenzen gleich!
> Hat das vieleicht etwas mit den rätselhaften Spikes zu tun ?

Ich denke nein

> Noch ein große Bitte:
> Ist mir gerade bei dem Screenshot machen aufgefallen.
> Kann deine Version jetzt nur das bmp screenshot?

Nein, es werden weiterhin die Formate bmp, pgm, csv, ascii unterstützt. 
Nur das man das bei der BF-Version vom Menü aus steuern kannn und bei 
der OS-Version über die Parameter des PC-Programms. Unterstützt werden 
aber beide Versionen.

Ab BF.1.0 gibt es eine Auswahl der Screenshotversion im Quickprintmenü.

> Bei der anderen Version gingen da noch andere Formate wie: ppm.. u.s.w.
> Kannte diese Formate vorher nicht, aber da gibt es das schöne Programm
> "FineView" das dieses Format ganz einfach in .jpg umwandeln kann und
> dann das Bild um das 10fache kleiner macht. :-)

das freie Programm Irfanview (mein Favorit) kann das ebenfalls und noch 
etwas mehr...

Hayo

[Blue F. (blueflash)]

Ok, jetzt ist sie raus!

Blue Flash Laboratories proudly presents:

First Stable Release  1.2.BF.1.0 for WELEC W20xxA


Also available here:

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


Nix mehr mit beta.

Viel Spaß

Hayo

[Guido (Gast)]

Hahr,

jetzt wird aufgeräumt, die Beta-Versionen fliegen in den
Mülleimer. :-))

Upload läuft, danke Hayo, Guido

[Guido (Gast)]

Oops,

wie sage ich meinem Welec definitiv, dass es nur 2 Kanäle hat?
Immer mal wieder schaltet es Kanal 3 und 5 an (Leds leuchten)
und dies trübt den Nutzen.

Gruß, Guido

[Blue F. (blueflash)]

Guido schrieb:
> Oops,
>
> wie sage ich meinem Welec definitiv, dass es nur 2 Kanäle hat?
> Immer mal wieder schaltet es Kanal 3 und 5 an (Leds leuchten)
> und dies trübt den Nutzen.
>
> Gruß, Guido


Das habe ich nicht so ganz verstanden, beschreib das mal genauer, dann 
kann ich gleich einen Fix machen - das ist mir ja jetzt unangenehm ;-)

Hayo

[Blue F. (blueflash)]

Hab gerade noch eine Kleinigkeit gefunden und in der BF1.1 auch schon 
wieder behoben.

Und zwar klappt die DAC-Kalibrierung bei einigen Channel-Delays nicht so 
gut. Bei mir gab es bei einem Delay von 7ns auf Kanal 1 und 2 für die 
beiden Kanäle keinen so guten Abgleich.

Ist aber schon gefixt.

Hayo

[Guido (Gast)]

Jetzt ist es mir unangenehm: es passiert nach einigem mal
Ein- und Ausschalten (Schalter pratzelt wieder) nicht mehr.
Gut, dass ich eien Screenshot gemacht hatte, sonst hätte
ich noch an Einbildung geglaubt. :-))

Mit den hohen Frequenzen (> 30 MHz) habe ich jetzt wieder
Probleme. War das nicht durch den Soft-Switch den Falk
herausgefunden hat behoben?

Es ist aber auf alle Fälle eine würdige 1.0 Version. Wenn
man es mit dem Original vergleicht ...

Grüße, Guido

[Michael D. (mike0815)]

Hayo W. schrieb im Beitrag:
> Hab gerade noch eine Kleinigkeit gefunden und in der BF1.1 auch schon
> wieder behoben.

Ich denke mal, das das nicht die Letzte sein wird...nobody is perfect!

Guido schrieb im Beitrag:
> Jetzt ist es mir unangenehm: es passiert nach einigem mal
> Ein- und Ausschalten (Schalter pratzelt wieder) nicht mehr.

....habe noch welche übrig, von der Sammelbest. der Slog z.B. meldet 
sich nicht.

Möchtest du Einen? dann schicke ich den am Montag ab!

Michael D. schrieb im Beitrag :
> Hat jetzt endlich mal Jemand mit den modifizierten Widerständen und den
> neuen Calibrierungen experimentiert???
> Ich ärgere mich, das ich die wieder gegen die 0 Ohm getauscht
> habe(Aceton, Wattest., Pinzette, 3Fach-10Fach-Lupe und eine Flasche
> Doppelherz...(super Flußmittel...harharhar)

...wo ist denn da jetzt die Resonanz??? >>Kopfschüttel<<

Gruß Michael

[Guido (Gast)]

Oh,

> ...wo ist denn da jetzt die Resonanz??? >>Kopfschüttel<<

ich sehe da keinen großen Unterschied. Mit 22-Ohm-Widerstand
scheint es etwas mehr Störungen zu geben, aber das müsste ich
noch exakter probieren, der Untersschied ist nur gering und
schwer zu quantifizieren, da er wohl von der V-Pos abhängt.

Vermutlich haben nicht viele Nutzer diese Widerstände eingelötet,
da es für einige doch zu schwierig/riskant ist.

Gruß, Guido

[egberto (Gast)]

und der Nutzen sich (zumindest mir) nicht so richtig erschließt.....

Mal sehen, was die neue Platine so bringt...

Viele Grüße,

egberto

[Guido (Gast)]

> und der Nutzen sich (zumindest mir) nicht so richtig erschließt.....

Jein, der ist schon klar. Nach meiner Erinnerung hatte Falks Patch
aber mehr gebracht. Mal abwarten.

Gruß, Guido

[Michael D. (mike0815)]

Hallo Guido,
wie kommst du denn jetzt auf 22 Ohm Widerstände?
Normalerweise kämen da 24,9 Ohm oder die maximalen 33 Ohm in Frage, 
höher hatte keinen Sinn!

Ich mache mir mal die Mühe...

1. Kalibrierung:--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" 
---
...sehr interessant ist dieses, hatte ich selbst noch nicht gelesen!
2. ADC-Eingangskanal:
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---

3. Ist es bei dieser Auflösung in der neuen FW von Hayo so geglieben?
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---

4. No? Guido's 22 Ohmler...
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---

5. Hier ein Vergleich:
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---
und hier noch einer:
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---

6. Und brunowe, das hier wäre noch was für die Wunschliste...
--- Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" ---

...nach über einer Std. habe ich jetzt mal die Links zusammen.

Auf die Huckepackplatine warte ich auch, man könnte in der Zeit trotzdem 
modifizieren und evtl. noch angleichen, wenn die Platine komplett fertig 
ist?!?
Wir wissen ja jetzt wie es geht bzw. der Hayo!

Gruß Michael

[Thomas (kosmos)]

ist es eigentlich möglich die Aufnahme automatisch starten zu lassen 
sobald ein Triggerereigniss auftaucht ohne eine Taste(Run/Stop oder 
Single) per Hand drücken zu müssen.

[Rolf W. (rowue)]

Vielleicht eine kurze Anmerkung zu dem Thema Widerstände,
auch wenn den meisten Nutzern so eines Gerätes eigentlich klar
sein sollte, was da wie passiert:

Die Widerstände liegen in Reihe zu den ADC's (inkl. des 
Abschlusswiderstands (1k5 AFAIR)).

Wenn der Widerstandswert dieser Widerstände nun von 0 Ohm in 22 (Oder 
was auch immer Ohm) geändert wird, verringert sich der Spannungsabfall
über den ADC's - diese werden als proportional zu Spannung an der
Widerstandskette geringer ausgesteuert und zeigen somit eine
kleinere Amplitude, ebenso aber auch - auf den ersten Blick - ein 
verringertes Rauschen an.

Bei 1k5 sollte der Effekt des verringerten Spannungsabfalls nicht so 
deutlich sein, aber mir ist damals, als ich die Widerstände eingelötet 
habe, eine deutliche Reduzierung der angezeigten Amplitude aufgefallen 
(evtl. habe ich noch Meßergebnisse hier)

In diesem Sinne sinkt zwar das "gefühlte Rauschmaß", allerdings nimmt 
das "Quantisierungsrauschen" zu (weniger Bits/DIV sehr grob 
ausgedrückt).

Wenn nun in BF Version (nicht getestet) das Rauschen scheinbar stärker 
ist, würde ich die mal auf die Anpassung der Bildschirmdarstellung 
schieben. Desweiteren wollte Hayo (AFAIR) auch die Verstärkerstufen 
durchgehend mit 1.25 auf dem OPA laufen lassen - die OS-Version schaltet 
den OPA aber nur in den 2.5'er und 5'er Stufen um. (Die Patch die 
Verstärkung von 1.25, 2, 4 auf 1, 2.5, 5 umzustellen stammt übrigens von 
mir, die nur zur Qualität gewisser Recherchen ...)

Da Andrés Messungen zu dem Thema Widerstände einen Abfall des 
Verstärkungsfaktors im zweistelligen MHz-Bereich (um und bei 10 MHz 
AFAIR) aufzeigten, möge sich jeder selbst überlegen, welchen Sinn es 
macht, da mit 500 kHz (egal ob Rechteck oder Sinus) reinzumessen.

Beste Grüße,

     rowue

PS: @Hayo: Herzlichen Glückwunsch zur 1.0! (ungetestet)

[Michael D. (mike0815)]

Hallo Rolf,

Rolf W. schrieb:
> Vielleicht eine kurze Anmerkung zu dem Thema Widerstände,
> auch wenn den meisten Nutzern so eines Gerätes eigentlich klar
> sein sollte, was da wie passiert:
>
> Die Widerstände liegen in Reihe zu den ADC's (inkl. des
> Abschlusswiderstands (1k5 AFAIR)).

welchen Abschlusswiderstand meinst du? Die 2x 1k5 (zw. Eing. u. Ausg.)in 
den OP's selbst, oder die 2x 750 Ohm an den Eingängen?

> Wenn der Widerstandswert dieser Widerstände nun von 0 Ohm in 22 (Oder
> was auch immer Ohm) geändert wird, verringert sich der Spannungsabfall
> über den ADC's - diese werden als proportional zu Spannung an der
> Widerstandskette geringer ausgesteuert und zeigen somit eine
> kleinere Amplitude, ebenso aber auch - auf den ersten Blick - ein
> verringertes Rauschen an.

>
> Bei 1k5 sollte der Effekt des verringerten Spannungsabfalls nicht so
> deutlich sein, aber mir ist damals, als ich die Widerstände eingelötet
> habe, eine deutliche Reduzierung der angezeigten Amplitude aufgefallen
> (evtl. habe ich noch Meßergebnisse hier)
>
> In diesem Sinne sinkt zwar das "gefühlte Rauschmaß", allerdings nimmt
> das "Quantisierungsrauschen" zu (weniger Bits/DIV sehr grob
> ausgedrückt).
>
...könnte da nicht ein Tausch des 150k Abschlusswiderstandes gegen 110 
Ohm
wieder ein Ausgleich geschaffen werden?
Also 2x 24,9 Ohm und 110 Ohm, dann wären wir wieder bei 1,1k zu den 
ADC's und einer Amplitudenanhebung.

> Wenn nun in BF Version (nicht getestet) das Rauschen scheinbar stärker
> ist, würde ich die mal auf die Anpassung der Bildschirmdarstellung
> schieben. Desweiteren wollte Hayo (AFAIR) auch die Verstärkerstufen
> durchgehend mit 1.25 auf dem OPA laufen lassen - die OS-Version schaltet
> den OPA aber nur in den 2.5'er und 5'er Stufen um. (Die Patch die
> Verstärkung von 1.25, 2, 4 auf 1, 2.5, 5 umzustellen stammt übrigens von
> mir, die nur zur Qualität gewisser Recherchen ...)
>
> Da Andrés Messungen zu dem Thema Widerstände einen Abfall des
> Verstärkungsfaktors im zweistelligen MHz-Bereich (um und bei 10 MHz
> AFAIR) aufzeigten, möge sich jeder selbst überlegen, welchen Sinn es
> macht, da mit 500 kHz (egal ob Rechteck oder Sinus) reinzumessen.

Die Massnahme würde ja als Filter wirken und mit 10 oder 20 MHz Verlust 
könnte man ja leben.  Welcher Frequenzbereich würde da gedämpft?

>
Gruß Michael

[Guido (Gast)]

Also gut, noch mal zur Wiederholung:

Der Video-Amp vor dem ADC reagiert (wie fast alle Verstärker)
allergisch auf kapazitive Lasten. Sollten diese, wie in unseren
Welecs, unvermeidbar sein, empfiehlt das Datenblatt Reihenwiderstände
von z.B. 24,9 Ohm dazwischenzuschalten. Da ich kein E96 vorrätig habe,
habe ich 22 Ohm als nächsten verfügbaren Wert verwendet. Dadurch
wurde das Überschwingen der Verstärker deutlich reduziert, was man der
Signaldarstellung entnehmen kann. Mit Rauschen hat das mal wieder
garnichts zu tun. Die Signaldämpfung durch diese Widerstände kann man
getrost vergessen. Wer einen Spannungsteiler dimensionieren kann,
wird das bestätigen.

Grüße, Guido

[Michael D. (mike0815)]

...na gut, hab's verstanden!
Das war ja eine klare Ansage.
Dann lassen wir das so und warten mal ab, wie sich das mit der 
Huckepackplatine entwickelt...

Gruß Michael

...jetzt gehe ich grillen, die Leute rennen schon in der Badehose durch 
die Gegend...also manchmal...

[moud (Gast)]

Hey Leute,

kann vielleicht jemand den Updater den man auch auf der SourceForge 
Seite sieht hier hochladen? Ich weiß nicht wo es den geben soll. Auf der 
Wittig Seite gibts nur so n ganz einfachen.


Lg

[Rolf W. (rowue)]

Guido schrieb:
> Also gut, noch mal zur Wiederholung:
>
> Der Video-Amp vor dem ADC reagiert (wie fast alle Verstärker)
> allergisch auf kapazitive Lasten. Sollten diese, wie in unseren
> Welecs, unvermeidbar sein, empfiehlt das Datenblatt Reihenwiderstände
> von z.B. 24,9 Ohm dazwischenzuschalten. Da ich kein E96 vorrätig habe,
> habe ich 22 Ohm als nächsten verfügbaren Wert verwendet. Dadurch
> wurde das Überschwingen der Verstärker deutlich reduziert, was man der
> Signaldarstellung entnehmen kann. Mit Rauschen hat das mal wieder
> garnichts zu tun. Die Signaldämpfung durch diese Widerstände kann man
> getrost vergessen. Wer einen Spannungsteiler dimensionieren kann,
> wird das bestätigen.

Ich kann hier gerne noch mal Messungen mit einer DC-Referenz-Quelle 
machen, aber meiner Erinnerung nach wurde das Signal deutlich bedämpft. 
Und da mir die Ohm'schen Gesetze durchaus geläufig sind, ließ sich dies 
auch nicht mit einem 1k5 Widerstand über den ADC's vereinbaren.

Sonst können wir das auch gerne so machen, dass zwei Leute mit 5V 
Ref-Quellen (einer mit Widerständen, einer ohne) entsprechende Signale 
(Ohne Ref-Quelle, mit Ref-Quelle) reinsamplen und wir die Differenzen in 
der Aussteuerung vergleichen - ist für beide ~ 10 Min Sache (ohne 
aufwärmen des DSO's) - und danach wissen wir mehr.

Btw: Wenn die Widerstände die Aussteuerung am ADC nicht oder nur 
vernachlässigber verändern würden, müssten die Verstärkungsfaktoren, etc 
nicht angepasst werden.

>
> Grüße, Guido

Grüße,

     rowue

[Guido (Gast)]

Hallo Rolf,

ich habe doch den direkten Vergleich, weil ich nur einen Kanal
umgerüstet habe. Der Unterschied ist wie erwartet nur gering,
macht sich aber schon bemerkbar.

Die Anpassung der Verstärkung wäre nur nötig, wenn noch ein
Abschlusswiderstand an den ADCs eingebaut wird. Wir sollten
diese Optimierung aber erstmal lassen, weil ich befürchte, dass
nur wenige Nutzer zu so einer Änderung gewillt/in der Lage sind.
Das würde auf unterschiedliche Firmwareversionen rauslaufen, Das
war, soweit ich mich erinnere, vor einiger Zeit die Entscheidung.

Gruß, Guido

[Michael D. (mike0815)]

moud schrieb:
> Hey Leute,
>
> kann vielleicht jemand den Updater den man auch auf der SourceForge
> Seite sieht hier hochladen? Ich weiß nicht wo es den geben soll. Auf der
> Wittig Seite gibts nur so n ganz einfachen.
>
>
> Lg

Der aktuelle Updater ist inkl. Installationsanleitung ( siehe Ordner 
"DOC" "How to upload via shell script.txt") und dem Germsloader in 
Hayo's neuer SW-Version ---FW1.2.BF.1.0_RELEASE--- für alle Wellec DSO's 
eingepackt!
Hier der Link...

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

Aktiv-Perl installieren, dann das Modul > Win32 Device Serial < 
aktivieren bzw. von Perl's Webseite ergänzen, der Rest ist in der 
skript.txt beschrieben! Comport und Baudrate in der > flashloader.bat < 
angleichen und ab geht's in knapp 2 Min. hat man ein neues DSO!
Default-Setup drücken, calibrieren und sich freuen...

Hab' ich was vergessen?

Wenn noch Fragen sind, schreib mir eine PN!

Gruß Michael

[Michael D. (mike0815)]

Guido schrieb:
> Hallo Rolf,
>
> ich habe doch den direkten Vergleich, weil ich nur einen Kanal
> umgerüstet habe. Der Unterschied ist wie erwartet nur gering,
> macht sich aber schon bemerkbar.
>
> Die Anpassung der Verstärkung wäre nur nötig, wenn noch ein
> Abschlusswiderstand an den ADCs eingebaut wird. Wir sollten
> diese Optimierung aber erstmal lassen, weil ich befürchte, dass
> nur wenige Nutzer zu so einer Änderung gewillt/in der Lage sind.
> Das würde auf unterschiedliche Firmwareversionen rauslaufen, Das
> war, soweit ich mich erinnere, vor einiger Zeit die Entscheidung.
>
> Gruß, Guido

Einen Teil der Anpassung steht doch schon Optional z.B. für die 
Zerolines zur Verfügung, was steht einer weiteren Option für die 
Verstärkung SW-mässig im Wege?
Für ein 2 Kanal Gerät wären das 3 Widerstände pro Kanal getauscht!
In unserem Beispiel: 2x 24,9 Ohm und 1x 110 Ohm 0603er Package 
Abschlusswiderstand
...könnte eine halbe Nachtschicht werden, ist aber nicht's im Vergleich 
zur Vergangennen Zeit die dabei drauf ging...

Um auf die Referenzen zurück zu kommen: Mir stehen z.Z. Sinus bis 1MHz 
3V AC,DC und Rechteck 1,5 MHz 5V AC,DC zur Verfügung, könnte das für 
eine Vergleichsmessung ausreichen oder wäre das 'Undersized' ?

Gruß Michael

[Guido (Gast)]

Ohoh Michael,

wie willst du einem Anfänger dann erklären, was er einstellen soll?

Ich mache mal den Anfang: Kanal 1 mit 22 Ohm, Kanal 2 unverändert mit
0 Ohm. 1-kHz-Signal.

Gruß, Guido

[Blue F. (blueflash)]

Guido schrieb:

> Mit den hohen Frequenzen (> 30 MHz) habe ich jetzt wieder
> Probleme. War das nicht durch den Soft-Switch den Falk
> herausgefunden hat behoben?

So, erstmal von oben nach unten alle neuen Beiträge durcharbeiten.

- das es im Hardwaremenü jetzt eine Einstellmöglichkeit für die ADC gibt 
hast Du mitbekommen oder? Wenn Du auf High-Frequ stellst oder auf Test1 
sollte es auch mit hohen Frequenzen klappen. Defaultmäßig werden die 
Werkseinstellungen gezogen, die aber eben bei hohen Frequenzen nicht so 
toll funktionieren.

Hayo

[Blue F. (blueflash)]

moud schrieb:
> Hey Leute,
>
> kann vielleicht jemand den Updater den man auch auf der SourceForge
> Seite sieht hier hochladen? Ich weiß nicht wo es den geben soll. Auf der
> Wittig Seite gibts nur so n ganz einfachen.

So als nächstes mal hier ne Antwort  - obwohl es ja schon eine gab. Also 
wenn Du nicht mittels beigelegtem Perlscript hochladen möchtest (ca. 2-3 
min)

Kannst Du auch den älteren WelecUpdater von Markus nehmen, der ist etwas 
komfortabler zu bedienen, braucht aber für ein Update ca. 20 min und ist 
eigentlich nur für Windows geeignet.

Den findest Du hier (Fast ganz unten in der Liste):

http://groups.google.com/group/welec-dso/files


Den original Updater von Welec kannst Du nicht verwenden!!! Der ist 
nicht kompatibel zu unseren Firmwareversionen.

Gruß Hayo

[Blue F. (blueflash)]

So, jetzt noch einer zu den Widerständen.

Also erstmal - alle haben Recht! Aber, es ist jetzt die Frage ob die 
Erhöhung des Quantisierungsrauschens die Dämpfung der 
Samplestufenrückwirkung überwiegt oder nicht. Das werden wir allerdings 
nicht durch diskutieren rausfinden, sondern nur (wie Guido schon 
anmerkte) durch try and error. Daher werde ich jetzt an meinem W2022A 
auch den Kanal 1 umrüsten auf 33 Ohm und mal einen Vergleich mit 
korrigierten !!! Skalierungsfaktoren anstellen, was ja dank der neuen 
Gain-Umstellung kein Akt mehr ist. Übrigens bin ich bzgl. der 
Widerstände bei alten Festplatten fündig geworden. Da waren etliche 33 
Ohm und mengenweise 22 Ohm Widerstände drauf.

Anbei ein Schnappschuß meines W2022A auf dem OP-Tisch - wer kann es 
erkennen?

Hayo

[Guido (Gast)]

Hallo Hayo,

jo, mit dem Mikrophon sollte es gehen, sieht bei mir ähnlich aus. ;-)
Sehe ich da ein Tek in der zweiten Reihe von unten?  Kann nichts
schaden.

Das Hardware-Menu habe ich jetzt gefunden und mit Test4 sieht es
gut aus. Muss aber noch genauer testen, das braucht halt Zeit.

Gruß, Guido

[Michael D. (mike0815)]

Guido schrieb:
> Ohoh Michael,
>
> wie willst du einem Anfänger dann erklären, was er einstellen soll?
>
> Ich mache mal den Anfang: Kanal 1 mit 22 Ohm, Kanal 2 unverändert mit
> 0 Ohm. 1-kHz-Signal.
>
> Gruß, Guido

ohooo Guido,

...das war doch gar nicht so schwer! Den Versatz hatte ich damal auch, 
allerdings von links nach rechts!
Dir fehlen ca.250mV, mir fehlten ein paar Herzen.

Mit so einem "Mikrofon", wie Hayo es hat, ist das ja ein Kinderspiel, 
die Teile zu tauschen, ich will auch so eins...

Gruß Michael

[Rolf W. (rowue)]

Guido schrieb:
> [...]

Auch von mir mal einen Stapel Antworten/Kommentare auf die letzten
Postings:

@Michael: Mit Referenz meinte ich eigentlich eine 
Referenz-Spannungs-Quelle.
Das sind nette kleine Chips, in die Du X-Volt reinschiebst und hinten
eine Spannung auf 0.5% und weniger genau rausbekommst.

Um den Frequenzgang zu messen müssten wir bis in den dreistelligen 
MHz-Bereich kommen, und da hört es bei uns derzeit glaube ich bei 50MHz 
auf. (André kommt da noch höher) - Eine Durchgangskurve sollte sich im 
Hardware-Forum finden.

Das Quantisierungsrauschen sollte sich um ~3% (1k5) resp. ~5% (1k1) 
erhöhen. Ich kann auch mal nachsehen, wie stark sich das Eigenrauschen 
durch den OPA verstärkt, allerdings habe ich hier keine Messwerte mit 
der stärkeren Entkopplung.

Von meiner Seite aus sehe ich keine Probleme, in beiden Versionen (BF 
und OS) den OPA auf 1.25 zu setzen, ich hatte die Einstellung 1, 2.5, 5 
damals vorgenommen um if-Abfragen in der Anzeige-Routine zu sparen. Dies 
ist durch Umstellung auf eine Matrix aber obsolete. Ebenso sollte die 
Abbildung über den DAC kalibriert werden können und einer individuellen 
Umstellung auf 150 Ohm sollte nichts mehr im Wege stehen (außer Zeit)
>
> [...]

Grüße,

   rowue

[Rolf W. (rowue)]

Michael D. schrieb:
> Guido schrieb:
>> Ohoh Michael,
>>
>> wie willst du einem Anfänger dann erklären, was er einstellen soll?
>>
>> Ich mache mal den Anfang: Kanal 1 mit 22 Ohm, Kanal 2 unverändert mit
>> 0 Ohm. 1-kHz-Signal.
>>
>> Gruß, Guido
>
> ohooo Guido,
>
> [...]
>
> Mit so einem "Mikrofon", wie Hayo es hat, ist das ja ein Kinderspiel,
> die Teile zu tauschen, ich will auch so eins...

Bei Reichelt & Co. gibt es nette USB-Mikroskope (2M)- der Standfuß ist 
etwas ekelig (habe eine dritte Hand dafür genommen), haben sonst aber 
den Vorteil, dass Du beim Löten auf einen große Schirm schauen kannst.
(Und Heissluft-Löten mit Lupenbrille ist nur sehr bedingt zu empfehlen 
:(

>
> Gruß Michael

Grüße,

   rowue

[Michael D. (mike0815)]

Ich habe die Fotos mit den 33 Ohmlern gefunden. Sind zwar nicht 
überlappend, man sieht aber den seitlichen Versatz!
1.Kanal ist bestückt mit 33 Ohm, der 2. Kanal war noch original.

1.Foto 1KHz Rechteck intern 1GSA/S 10nS
2.Foto 1KHz Rechteck intern 1GSA/S 20nS
3.Foto 5,43 MHz Sinus ext.  1GSA/S 50nS
4.Foto 5,43 MHz Sinus ext.  1GSA/S 100nS

...da hätten wir ja schon mal was.

Gruß Michael

...na Hayo, schon kräftig am löten?

[Michael D. (mike0815)]

Für 200fache Vergrösserung und 59,95 Euro wird das bei der nächsten 
Bestellung mit geordert!
Ich habe einen 26 Zoll Bildschirm und der Läppi hat 17 Zoll, ich denke 
da geht was...
Klasse Rolf, wenn wir dich nicht hätten!!!

...und so sieht's aus...

Wieso ist der Fuß ekelig?

Gruß Michael

[Rolf W. (rowue)]

Michael D. schrieb:
> [USB-Mikro]

Hi Mike, da Du ja auch privat gefragt hattest:

Ja, ich bin zufrieden damit. Du kannst generell auf zwei (drei)
Vergrösserungsfaktoren justieren - 1x etwa bei Faktor 20 und 1x
etwa bei Faktor 200. Zumindest unter Linux solltest Du USB 2.0 haben,
sonst gibt es gerne mal etwas Stress mit der v4l2 und gerade wenn die 
Bilder scharf sind, fliegt Dir der Treiber um die Ohren.

Zur Bildqualität (glaube noch vom alten USB 1.1 Nobo):

https://bone.digitalis.org/pics/Aua.jpg (etwa Faktor 20)
https://bone.digitalis.org/pics/x200.jpg (etwa Faktor 200)

Das Schöne bei dem Gerät ist, dass Du wirklich dem Lot beim
Fliessen zusehen kannst - inkl. evtl. Grabstein-Effekt ;)
>
> ...und so sieht's aus...
>
> Wieso ist der Fuß ekelig?

Naja, der ist noch etwas billig gemacht. Damit verrutscht das
Gerät gerne mal, nachdem Du Abstand, etc eingestellt hast ...

'Ne dritte Hand, wo Du eine Kroko-Klemme gegen das Mikro getauscht hast, 
ist da deutlich schöner.
>
> Gruß Michael

Grüße,

       rowue

[Blue F. (blueflash)]

Oha, vielleicht sollten wir in den Hardwarethread wechseln ;-)

Kann mir jemand ein Foto mit der genauen Lage des 1K5 Widerstands 
posten, dann kann ich den mal probeweise gegen etwas zwischen 100 - 150 
Ohm tauschen.

Ach ja, wieviel kostet das USB-Teil eigentlich?

Gruß Hayo

[Peter .. (Gast)]

Best.-Nr.          Bezeichnung                                Preis
MICROSKOP USB 2M   Digital Mikroskop USB mit 2,0 Mio. Pixel   59,95€

oder alternativ ibääh Art.-Nr. 360256027680 für 49,90€

[Blue F. (blueflash)]

@Peter

Danke



Guido schrieb:

> Sehe ich da ein Tek in der zweiten Reihe von unten?  Kann nichts
> schaden.

Jo, das gute alte 2465A mit einer realen Bandbreite von ca. 400 MHz. 
Damit mache ich meine Vergleichsmessungen am WELEC.

> Das Hardware-Menu habe ich jetzt gefunden und mit Test4 sieht es
> gut aus. Muss aber noch genauer testen, das braucht halt Zeit.

Wenn Du wissen willst welche Registereinstellungen das sind  - einfach 
über Terminal ein "," eingeben. Ich habe die Variablenausgabe etwas 
aufbereitet.

Hayo

[Michael D. (mike0815)]

Tach,
man Hayo, ich hatte den Preis extra dazu geschrieben, du brauchst so ein 
Mikroskop fur den Bildschirm...'Spässle'

...konntest du mit den Fotos was anfangen?

Wieso redet ihr alle von 1k5, habe ich da was verpeilt? Dachte es wäre 
der Abschluss-Widerstand...
Kann es sein, das hier der 150 KILO OHM gemeint ist???
Hier der Link:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Ich habe noch eine Vergleichsmessung im HW-Thread gefunden:
1. Kanal 33 Ohm
2. Kanal 47 Ohm
Der 2. Kanal hat auf den Fotos gezickt, war aber nicht die Schuld der 
Hardware, sondern die der Software, hatte Hayo ja gefixt!!!

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Rolf W. schrieb:
> Ja, ich bin zufrieden damit. Du kannst generell auf zwei (drei)
> Vergrösserungsfaktoren justieren - 1x etwa bei Faktor 20 und 1x
> etwa bei Faktor 200. Zumindest unter Linux solltest Du USB 2.0 haben,
> sonst gibt es gerne mal etwas Stress mit der v4l2 und gerade wenn die
> Bilder scharf sind, fliegt Dir der Treiber um die Ohren.

Das ist ja mal gut zu wissen
Also die Foto's sind sehr überzeugend, schon beachtlich, wie das ins 
Detail geht!
Das Teil muß auf jeden Fall her!!!

Für einen alternativen Halter, hätte ich den 'Klobürstenhalter' hier, 
das Teil steht wie ein Fels in der Brandung:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Gruß Michael

[Blue F. (blueflash)]

Hi,

ja ich meinte den 154 K Widerstand, hab ihn auch schon gefunden, und 
ebenfalls auf einer meiner Organspenderplatinen einige 150 Ohm 
Widerstände. Bin also mittendrin.

Das USB-Mikroskop werd ich mir heute abend mal bei Ibääh ziehen, wie von 
Peter beschrieben für nen Fuffi.

Gruß Hayo

[Guido (Gast)]

Hallo Hayo,

hier hat branadic ein schönes Photo:

http://www.mikrocontroller.net/attachment/61712/Leitungsabschluss.JPG

Zu den Mikroskopen: das entscheidende zum Löten ist, dass es
wirklich ein Stereomikroskop ist. Meins hat Zoom von 8x bis 40x,
das ist gerade optimal, hat aber auch 300 Eur gekostet.

Gruß, Guido

[Guido (Gast)]

oops, zu spät.

[Blue F. (blueflash)]

Äh sorry, meinte natürlich 150 K Widerstand. Die Kennzeichnung ist 154. 
Ich schätze da haben sie sich bei der Montage einfach vergriffen, 154 
und 151 sehen bei der Größe ja auch fat gleich aus.

Schaun wir mal...

[Blue F. (blueflash)]

@Guido

Jupp, das Löten geht mit dem Stereo Mikro echt gut. Meins ist ein altes 
Zeiss (Ost). Lag gebraucht auch so in dem Bereich und ist ein 
Profigerät.

Gruß Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> Äh sorry, meinte natürlich 150 K Widerstand. Die Kennzeichnung ist 154.
> Ich schätze da haben sie sich bei der Montage einfach vergriffen, 154
> und 151 sehen bei der Größe ja auch fat gleich aus.
>
> Schaun wir mal...

Bei 2x 24,9 Ohm waren wir bei nem Abschluss von 110 Ohm ?!?
Bei 2x 33,4 Ohm (hatten exakt alle 4) überflogen um die 100 Ohm, das wir 
gesamt auf 1100 Ohm kommen, oder hab' ich mich da verrechnet?

Rolf,
hast natürlich Recht mit der Referenz, Temperaturdrift etc...
3 Stelliger Megaherzbereich, damit kann ich auf keinen Fall auftreten

Gruß Michael

[Blue F. (blueflash)]

So, es ist vollbracht,

33 Ohm sind drin, kombiniert mit 150 Ohm, die ich gerade zur Hand hatte. 
Ob das zu 100 Ohm so einen großen Unterschid macht?

Naja, erster Eindruck rein visuell:

- ein echter Vergleich ist erstmal nicht möglich, da die Skalierung ca. 
1/3 voneinander abweicht - muß ich noch programmieren

- das Signal wirkt eigentlich genauso wie auf dem unveränderten Kanal, 
wenn man die unterschidliche Verstärkung berücksichtigt

- nur im 1V bereich hat man so etwas den Eindruck, als wäre das Rauschen 
(auf die Skalierung bezogen) etwas weniger.

Gruß Hayo

[Blue F. (blueflash)]

@Michael

der neue Schalter funktioniert super, kein gebritzel mehr

Hayo

[Michael D. (mike0815)]

Die 150k sollen ja nicht so gravierend sein, aber naja...
der Guido hatte das berechnet, glaube ich.

Gerade der 1V, 100mV und 10mV-Bereich, sind ja die Problemkinder!
Die 2V, 200mV und 20mV-Bereiche sind jetzt auch nicht der Reißer.
Die 5er-Bereiche sind ja ok!

Machst du mal ein paar Bilder, so zum Vergleich? Dann könnte ich mir 
meine noch mal betrachten.

Schön, das der Schalter funktioniert!

Gruß Michael

[Moritz Z. (moud)]

Wenn ich euer Fachgespräch nochmal unterbrechen darf:
Ersteinmal vielen Dank für die Antworten. Ich habe es mit dem Perl 
Skript versucht, aber er hat gleich am Anfang abgebrochen weil er etwas 
nicht überprüfen konnte. Jetzt bin ich dabei die Firmware mit dem 
Updater drauf zu machen - mit Windows 7 und USB Adapter für RS232 
allerdings nicht besonders empfehlenswert. Dauert 6 Stunden! Wenn das 
Oszi am Schluss noch lebt funk ich nochmal durch.

Nochmals vielen Dank für eure Arbeit!


Gruß,
Moritz

[Rolf W. (rowue)]

Moritz Z. schrieb:
> Wenn ich euer Fachgespräch nochmal unterbrechen darf:
> Ersteinmal vielen Dank für die Antworten. Ich habe es mit dem Perl
> Skript versucht, aber er hat gleich am Anfang abgebrochen weil er etwas
> nicht überprüfen konnte.

Stand da etwas von "SerialPort"?

Du brauchst:

Device::SerialPort

(evtl. noch mit Win32 dazu)

> Jetzt bin ich dabei die Firmware mit dem
> Updater drauf zu machen - mit Windows 7 und USB Adapter für RS232
> allerdings nicht besonders empfehlenswert. Dauert 6 Stunden! Wenn das
> Oszi am Schluss noch lebt funk ich nochmal durch.
>
> Nochmals vielen Dank für eure Arbeit!
>
>
> Gruß,
> Moritz

Grüße,

   rowue

[Blue F. (blueflash)]

@Moritz

Wenn Du vorhast des öfteren mal eine neue Open Source Firmware 
draufzuspielen, dann solltest Du noch etwas weiter mit dem Perlskript 
rumprobieren.


@Michael

Moment, ich probiere gerade mit den Skalierungen rum, wenn ich was 
Passendes habe, dann lade ich das hier hoch, dann könnt Ihr's Euch 
selbst machen...   ;-)

Hayo

[Moritz Z. (moud)]

So.
Writing line 017224 of 022368 :-)
Wie es geklappt hat?
Also:
1. Baudrate im Gerätemanager auf 115200 setzen
2. Adapter ohne Kabel anschließen
3. Die linken zwei Softbuttons gleichzeitig drücken, gedrückt halten, 
dann den Flash- oder Ramloader starten und sofort beide Tasten 
loslassen.

Nochmal Danke für alles!

Grüße aus dem sonnigen Stuttgart,

Moritz

PS: Danke Michael das du mich Motiviert hast den Vorgang mit dem Updater 
abzubrechen!
*edit:*
PPS: Michael hat sich sogar die Mühe gemacht mir eine lange Email mit 
der genauen Vorgehensweise und möglichen Fehlern zu schreiben. Ich bin 
sprachlos! Tolles Forum!

[Rolf W. (rowue)]

Michael D. schrieb:
> Die 150k sollen ja nicht so gravierend sein, aber naja...
> der Guido hatte das berechnet, glaube ich.

Nehmen wir den André,
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

und stimmt - ich meinte immer den 150K - bloss, da mir die
Amplitude mit den 24.9 (oder was auch immer) Ohm zu sehr
einbrach, waren 1k5 kleben geblieben. (Der 150k liegt halt
parallel zu den Op-Amps mit 1k1)
>
> Gerade der 1V, 100mV und 10mV-Bereich, sind ja die Problemkinder!
> Die 2V, 200mV und 20mV-Bereiche sind jetzt auch nicht der Reißer.
> Die 5er-Bereiche sind ja ok!

AFAIR war es so, dass mit den eingelöteten Widerständen die 
HF-Attraktivität des Gerätes nachließ (Peak am Ende des BGP)
näheres müsste im Hardware-Thread stehen, der aber auch ellenlang
geworden ist.
>
> Machst du mal ein paar Bilder, so zum Vergleich? Dann könnte ich mir
> meine noch mal betrachten.
>
> Schön, das der Schalter funktioniert!
>
> Gruß Michael

Grüße,

    rowue

@Hayo: Conrad hat doppelseitig klebende Thermofolie.

[Guido (Gast)]

So, mit den richtigen Einstellungen (im Hardware-Menü usw.) machen
die Widerstände wirklich kaum eien Unterschied. Immer noch: gelb
mit 22 Ohm, grün mit 0 Ohm. Die Phasenverschiebung halt, sonst
fällt mir nichts auf.

Ich werde mal mit 100 MHz und mehr testen, aber habe ich bisher
einen rel. starken Frequenzgang. Mal weiter probieren.

Gruß, Guido

[Michael D. (mike0815)]

Moritz Z. schrieb :
> Grüße aus dem sonnigen Stuttgart,
>
> Moritz
>
> PS: Danke Michael das du mich Motiviert hast den Vorgang mit dem Updater
> abzubrechen!
> *edit:*
> PPS: Michael hat sich sogar die Mühe gemacht mir eine lange Email mit
> der genauen Vorgehensweise und möglichen Fehlern zu schreiben. Ich bin
> sprachlos! Tolles Forum!

...ja ja, so ein 'bißchen'  kann ich was!

Sag' mal Guido, wie kommt das bei dir mit den Rauschlosen Signalen 
zustande??? Die Linien sind ja wie gemalt!!!

Hallo Rolf,

> Conrad* hat doppelseitig klebende Thermofolie.

Gib doch mal bitte die Art-Nummer, beim Conrad ist das immer so eine 
Aktion, bis man da was findet, wäre nett, danke!
Den Conrad in FFM hatte ich mal zwecks der Folie nachgefragt: "hammer 
net" war die Antwort...toll

Gruß Michael

[Rolf W. (rowue)]

Michael D. schrieb:
> Moritz Z. schrieb :
>> Grüße aus dem sonnigen Stuttgart,
>>
>> [Rauschen, etc]

Zum Rauschen würde es m.E. Sinn machen, folgende Meßreihen zu machen:

5-1V, Bandbreitenbegrenzt
50-10mV, nicht Bandbreitenbegrenzt

jeweils auf den gleichen Kanal, mit und ohne Widerstände, ohne
erneute Kalibrierung und ohne äußeres Signal, jeweils 1GSa/s.

Von diesen Messungen zieht mensch sich jeweils 2048 Werte aus
der Mitte und lässt sich die Standard-Abweichung geben.
Dies ist dann ein Maß für das (analoge) Rauschen.

Dazu dann noch die jeweilige Aussteuerung bei einem
Spannungsunterschied von: 30V (5V/DIV), 12V (2V/DIV), 6V (1V/DIV)
(oder halt 10V, 5V mit Ref-Quelle) - hieraus lässt sich das
Quantisierungsrauschen bestimmen.

Wg. des Frequenzganges könnte mensch sich auch mal die Oberwellen (3. 
und 5.) eines entsprechenden Rechtecksignals ansehen. Leider ist mein FG 
nicht kalibriert, so, dass ich nur die relativen Werte angeben könnte 
(wenn ich die Widerstände drin habe) - davon abgesehen ist die 
Auswertung auch etwas Arbeit.
>
>> Conrad* hat doppelseitig klebende Thermofolie.
>
> Gib doch mal bitte die Art-Nummer, beim Conrad ist das immer so eine
> Aktion, bis man da was findet, wäre nett, danke!
> Den Conrad in FFM hatte ich mal zwecks der Folie nachgefragt: "hammer
> net" war die Antwort...toll

Stichwort ist:

WÄRMELEIT-KLEBEFOLIE

darauf bekomme ich drei Treffer, von denen zwei interessant sind:

181132 - 62
181133 - 62

die, die ich mir damals besorgt habe, ist nicht dabei - vielleicht
finde ich noch die Bestell-Nummer.
>
> Gruß Michael

Grüße,

    rowue

[Blue F. (blueflash)]

Das Gefrickel mit den Faktoren erweist sich als etwas zäh. Es dauert 
wohl noch etwas bis ich da was anbieten kann.


@Rolf

Danke für den Tip, ich werde da mal recherchieren.



Hayo

[Blue F. (blueflash)]

Moritz Z. schrieb:

> Wie es geklappt hat?
> Also:
> 1. Baudrate im Gerätemanager auf 115200 setzen
> 2. Adapter ohne Kabel anschließen
> 3. Die linken zwei Softbuttons gleichzeitig drücken, gedrückt halten,
> dann den Flash- oder Ramloader starten und sofort beide Tasten
> loslassen.

Kleiner Nachtrag zu den beiden linken Softbuttons:

- wenn Du erst den Linken drückst und hältst, dann den Rechten kurz 
drückst und wieder losläßt bist Du im GERMS-Monitor über den sich die 
Firmware laden läßt.

- wenn Du erst den Rechten der beiden drückst und hältst und dann den 
Linken kurz drückst, macht das Gerät einen Reset.


> Nochmal Danke für alles!
>
> Grüße aus dem sonnigen Stuttgart,
>
> Moritz
>
> PS: Danke Michael das du mich Motiviert hast den Vorgang mit dem Updater
> abzubrechen!
> *edit:*
> PPS: Michael hat sich sogar die Mühe gemacht mir eine lange Email mit
> der genauen Vorgehensweise und möglichen Fehlern zu schreiben. Ich bin
> sprachlos! Tolles Forum!

Ja wir sind alle mal mit sehr wenig Detailwissen gestartet und waren 
froh über jeden der uns weitergeholfen hat.

Hayo

[Rolf W. (rowue)]

Hayo W. schrieb:
> Das Gefrickel mit den Faktoren erweist sich als etwas zäh. Es dauert
> wohl noch etwas bis ich da was anbieten kann.
>
>
> @Rolf
>
> Danke für den Tip, ich werde da mal recherchieren.

Wenn Du in HH mal an dem Laden in Wandsbek/Dulsberg vorbeikommst,
da hatten die in der "Moder-Ecke" (wenn Du reinkommst rechts
hinten) 'ne Folie als Aktionsangebot, die 'nen Tick besser war.

>
>
>
> Hayo

Beste Grüße,

       rowue

[Blue F. (blueflash)]

So die Faktoren hab ich, aber ich komme erst morgen dazu ein Paket zu 
schnüren.

Hayo

[Luc (Gast)]

First thank all You very much for the hard work done!
Thanks to You I have a new functioning DSO, so many thanks!
I have a W2022A with a 1.4 original firmware by Welec.
Despite it is rated for 200MHz bandwidth I was not able to overcome 
60MHz and the oscilloscope is pretty useless even at much lower 
frequencies...
...with the original Welec's firmware is a disaster, DSO is very 
limited!:-(
Ok, I paid it little money, I would say still too much for what it 
provides.
But now thank to the firmware 1.2.BF.1.0 all my problems are gone!:-)))
Now I can reach 170MHz without problems, I could not test it well 
because my RF generator stops at 170MHz.
So I tested it up to 170MHz sine wave and no problem, everything works 
fantastically, I compared the results with a 150MHz analog oscilloscope 
Hameg model 1500-2.
Unfortunately I do not have a 50ohm termination so my measurements were 
performed with non-adapted line and then with reflections, but the 
1500-2 Hameg showed the same things of Welec W2022A.
The only thing which I find is the mismatch between channel 1 and 
channel 2, ie with the same signal applied to channel 1 and channel 2 
waveforms are out of phase and phase depend by frequency.
I see discussions about this also here in the forum.
However I see in the UTILITY menu items CH1 DELAY and CH2 DELAY, so I 
fix the problem.:-)
I saw other interesting things that were not there before, so I'm a 
little confused about their use and I'd like to know where to find 
information about them.
I've already written about the CH1 DELAY and CH2 DELAY functions and how 
I used them.
Really I must use them so?
Why is the range from 0 to 16nS?
Still in the UTILITY menu in the HARDWARE tab there are items ADC SETUP 
and PRE GAIN.
What about ADC SETUP?
And wath about PRE GAIN?
Inside ADC SETUP I see entries FACTORY, HIGH FREQ, TEST1, TEST2, TEST3 
and TEST4, what are they mean?
How to use them?
My DSO has the original unmodified hardware so I chose FACTORY, but I 
also tried HIGH FREQ and seems to work while TEST1, TEST2, TEST3 and 
TEST4 provide different results.
How do I choose?
What I use?
Another thing about PRE GAIN.
There are entries FACTORY, GAIN 1.25, 24ohm, 33ohm, ADDON, what is they 
mean?
How to use them?
My DSO has the original unmodified hardware, resistances were not 
changed so I chose FACTORY, but other choices do not seem to make 
difference.
How do I choose?
What I use?
And last for now, with AUTO SCALE function i see the SLOW TB entry, I 
think it means SLOW TimeBase, is it correct?
How I must use it?
Inside 1.2.BF.1.0 firmware there are manuals, would be nice if there was 
a list with a description of all functions and their use.
Perhaps already exists somewhere, but I can not find it.
This information would be useful because not all are engineers like You 
then learn how to adjust certain things would be nice.
Again, perhaps this list already exists, perhaps it is right here in the 
forum, unfortunately I do not understand very good German, I'm sorry.:-(
Vielen Dank!:-)

Luc

[Guido (Gast)]

Hello Luc,

thanks for your post, Hayo will like it I guess.

Most of the functions you mentioned still are experimental, just
implemented to overcome users's problems. Some of us are doing
tests with modified hardware and Hayo tries to support this.

ADC-Setup: I tried today with this one. For low frequencies the
factory-setting should be best, but the menu seems to be not
correct. High-Freq seems to be the normal operation, for higher
frequencies test3 or test4 seems to be best.

Pre-Gain: I don't see any difference to.

I seldom use Auto-Scale, Slow-TB surely is Timebase, might be
left from the original firmware.

So long, Guido

[Blue F. (blueflash)]

@Luc

I'm sorry! As Guido found out the entries for Factory and high frequency 
settings in the ADC-Setup menu are exchanged. It is fixed in the next 
version which is available here today.

So let me explain the function. The factory setting results, as You can 
see, in a resonance problem at higher frequencies. The HF-setting 
deactivates some filters in the readout logic of the FPGA.

I always use the HF-Setting because it has the best results on my two 
DSOs.

A few Users had some problems with spikes, so there are some other test 
settings to find out which one matches to Your device.

The Pre Gain menu allows you to override the Factory setting of gain 1 
at the 1er and 2er Ranges with the gain 1.25 - this may have a positive 
effect to the noise level.

The other settings are for hardware modifications in the preamp stage on 
the mainbord. Some users exchanged the line resistors (0 Ohm) at the 
preamp input against 33 Ohm. Due to that You can choose other scaling 
factors in this menu which fit to those modifications.


Hayo

[Blue F. (blueflash)]

So Leute,

bevor ich die aktuelle BF.1.1 raushaue hier vorab einige Erkenntnisse zu 
den so heiß umstrittenen Widerständen.

Als Referenz hier erstmal die drei Meßbereiche mit Gain 1.25 und Null 
Ohm...

[Blue F. (blueflash)]

...dann der 5 V Bereich mit 33 Ohm und 150 Ohm statt 150 KOhm.

besonders auffällig ist die abhängigkeit von der vertikalen Position. 
Wenn man mit dem Drehknopf etwas hin und her dreht wird es mal mehr und 
mal weniger. Daher hier mal die beiden Extreme...

[Blue F. (blueflash)]

...zuletzt die 2er und 1er Bereiche. Hier het es sich meiner Meinung 
nach deutlich verbessert.

Hayo

[Blue F. (blueflash)]

Interessant wäre jetzt noch das Frequenzverhalten. Ich werden das mal in 
der nächsten Zeit prüfen.

Hayo

[Blue F. (blueflash)]

So, damit Ihr auch selbst ausprobieren könnt hier die BF.1.1

Ich habe bei der Gelegenheit alle!!! Skalierungsfaktoren neu berechnet 
und feinjustiert.


Bitte beim 22 Ohm Bereich beachten dass ich hier nur Schätzwerte nehmen 
konnte. Der 33 Ohm Bereich ist auf 33 Ohm mit zusätzlichem 150 Ohm 
Widerstand statt des 150 KOhm Widerstandes ausgelegt evtl. passen die 
Skalierungen nicht zum 150 K Widerstand! -> müßt Ihr testen


Gruß Hayo

[Blue F. (blueflash)]

Ach ja, noch einer!

Wenn Ihr zwischen den Gain-Bereichen wechselt solltet Ihr danach eine 
DAC-Kalibrierung vornehmen, da sich der DAC-Korrrekturoffset evtl. auch 
verändert.

Hayo

[Michael D. (mike0815)]

Hallo Hayo,

Dein Fleiß ist mal wieder beachtlich, wie du da reinhaust, wenn das so 
weiter geht, werden die Dinger bald nicht mehr bezahlbar sein...

Wie hast du denn die Menuefuhrung auf den Screenshot gebracht?

Zum Vergleich mal dieselben Einstellungen, nur ohne Modifizierung!
Mich würde mal interessieren, ob das bei jedem gleich aussieht.

Ich warte jetzt noch das Frequenzverhalten ab, bevor ich was unternehme.

Noch was,
Einige hatten mit dem 2.Kanal Probleme mit der Null-Kalibrierung, bei 
Signalmessungen ist da ein ordentlicher Versatz zu beobachten!
Nach einiger Zeit habe ich heraus gefunden, wie man beide Kanäle exakt 
auf die Nullinie bekommt.
In diesem Fall war Combitrigger 1GSA/s 500µS und beide Kanäle mit dem 
Pfeil übereinander, also PFEIL, nicht die Linie selbst!
Beide Pfeile genau in der Mitte vom Grid, dann eine Dac-Kalibrierung und 
alles ist hübsch!
Bei Signalmessungen die übereinander liegen, sieht man kaum noch die 
verschiedenen Kanalfarben, das hat mir gefallen!
Von der Grundstellung aus ging das bei mir nicht, hoffe der Tip war 
nützlich.

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:
> Hallo Hayo,
>
> Dein Fleiß ist mal wieder beachtlich, wie du da reinhaust, wenn das so
> weiter geht, werden die Dinger bald nicht mehr bezahlbar sein...

Werden die eigentlich noch angeboten? Oder sind die jetzt nur noch 
gebraucht zu kriegen?

> Wie hast du denn die Menuefuhrung auf den Screenshot gebracht?

Den Quick Print Button zweimal kurz hintereinander drücken, dann macht 
er einen Screenshot ohne das Menü zu wechseln.

Die Screenshots entsprechen meinen ersten drei ganz oben, die sind auch 
ohne Modifizierung bei Gain 1.25 geschossen. Bei Factory Setting ist das 
Rauschen bei mir in den 1er und 2er Bereichen etwas höher.

Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> Michael D. schrieb :
>> Hallo Hayo,
>>
> Werden die eigentlich noch angeboten? Oder sind die jetzt nur noch
> gebraucht zu kriegen?

habe gerade mal nach gesehen, da ich ja so'n 'Mikro' haben will, wurde 
schon einmal überboten, ärgern...
es sind keine mehr zu sehen ausser OWON und ein TEK mit 500MHz für 
kleines Geld...ähem 1999,- öcken
>
>> Wie hast du denn die Menuefuhrung auf den Screenshot gebracht?
>
> Den Quick Print Button zweimal kurz hintereinander drücken, dann macht
> er einen Screenshot ohne das Menü zu wechseln.

...klasse, wieso weiß ich das nicht? Muß jedes mal mit der Kamera und 
Lupe rum rennen, wenn der kompl. Bildschirm drauf soll!
>
> Die Screenshots entsprechen meinen ersten drei ganz oben, die sind auch
> ohne Modifizierung bei Gain 1.25 geschossen. Bei Factory Setting ist das
> Rauschen bei mir in den 1er und 2er Bereichen etwas höher.

ach, diese Einstellung ist dann zu empfehlen?
>
> Hayo
Was macht denn so deine Frequenzmessung, schon was konkretes heraus 
gekommen?
Weil mit dem Beitrag vom branadic der Wind aus den Segeln genommen wird, 
siehe hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:

>>> Wie hast du denn die Menuefuhrung auf den Screenshot gebracht?
>>
>> Den Quick Print Button zweimal kurz hintereinander drücken, dann macht
>> er einen Screenshot ohne das Menü zu wechseln.
>
> ...klasse, wieso weiß ich das nicht? Muß jedes mal mit der Kamera und
> Lupe rum rennen, wenn der kompl. Bildschirm drauf soll!

Hatte ich schon seit der 0.92 drin glaube ich, müßte ich mal als readme 
beifügen...


>> Die Screenshots entsprechen meinen ersten drei ganz oben, die sind auch
>> ohne Modifizierung bei Gain 1.25 geschossen. Bei Factory Setting ist das
>> Rauschen bei mir in den 1er und 2er Bereichen etwas höher.
>
> ach, diese Einstellung ist dann zu empfehlen?

würde sagen ja

>> Hayo
> Was macht denn so deine Frequenzmessung, schon was konkretes heraus
> gekommen?

Komme erst übermorgen dazu, da ich morgen den ganzen Tag aushäusig bin.

> Weil mit dem Beitrag vom branadic der Wind aus den Segeln genommen wird,
> siehe hier:
> Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

mal schaun

Hayo

[Luc (Gast)]

@Guido and @Hayo

Hi guys, Guido, Hayo and all.
Thank You very much for answers and useful information.
OK I understand these are experimental features, however I see that they 
work well.
I have not yet tried the 1.2.BF.1.1 release but I will do soon.
About ADC SETUP I set it as a FACTORY with my W2022A and I have not 
encountered problems with both low and high frequency.
I must clarify that I tested from 1.7MHz to 170MHz, I have not tried 
with low frequency, not even with the internal 1KHz calibrator, but now 
that I know it I will do it certainly!
However it is true, You are right, with some oscilloscopes there are 
problems with spikes.
Today a my friend lent me his W2012A for tests.
First I tried it with a 1.4 original firmware by Welec and despite it is 
rated for 100MHz bandwidth I was not able to overcome 60MHz and the 
oscilloscope is pretty useless even at much lower frequencies just like 
my W2022A (I performed the same tests from 1,7MHz to 170MHz sine wave).
Then I upgraded it to 1.2.BF.1.0 firmware release and so I had some 
surprises.
At the beginning I saw the spikes on track channel's 2.
These spikes were sporadic and the track channel's 1 was totally free of 
spikes.
After a while the spikes disappeared, I thought it was a temperature 
problem i.e. the oscilloscope was switched on recently and had not yet 
reached its steady heat.
Perhaps the spikes disappeared after I set FACTORY's parameters in ADC 
SETUP, I do not know, I have not done carefully.
However the spikes are gone!
Everything worked well like with my W2022A and surprise the W2012A 
easily reach 170MHz just like my W2022A!, I have not noticed significant 
differences.:-)
Now that you have told me as it works, I'll try other settings to see if 
it  further improves: THANKS!:-)))
OK for PRE GAIN's settings.
Yes, perhaps SLOW TB comes from the 1.4 original firmware by Welec, I'll 
try to check in the manual to understand how to use the SLOW TB 
function.
Just one last thing about the CH1 DELAY and CH2 DELAY.
I have already written as I used these function and why but I did not 
understand if I did it correctly.
With the same signal applied to channel 1 and channel 2 waveforms are 
out of phase and I fix the problem with CH1 DELAY and CH2 DELAY 
functions.
I did it correctly?
About modified hardware it is interesting.
I would not have problems to make resistance's change as You suggest and 
certainly I will do it in the future.
But for my purposes with your new firmware the DSO works very well so I 
wait until the warranty expires before putting my hands, although I 
honestly do not know whether or not trust of the manufacturer for 
assistance.
We'll see.
For now, thanks to all!
Vielen Dank!:-)

Luc

[Rolf W. (rowue)]

Michael D. schrieb:
> Hayo W. schrieb:
>> Michael D. schrieb :
>>> [...]
>
> ...klasse, wieso weiß ich das nicht? Muß jedes mal mit der Kamera und
> Lupe rum rennen, wenn der kompl. Bildschirm drauf soll!

Ganz fiese Frage - hast Du mal in den ersten Teil des Threads
geschaut? - Da wurde das bei der Einführung angesprochen ;)
>>
>> [...]
>
> Gruß Michael

Grüße,

   rowue

[Michael D. (mike0815)]

Rolf W. schrieb:
> Michael D. schrieb:
>> Hayo W. schrieb:
>>> Michael D. schrieb :
>>>> [...]
>>
>> ...klasse, wieso weiß ich das nicht? Muß jedes mal mit der Kamera und
>> Lupe rum rennen, wenn der kompl. Bildschirm drauf soll!
>
> Ganz fiese Frage - hast Du mal in den ersten Teil des Threads
> geschaut? - Da wurde das bei der Einführung angesprochen ;)
>>>
boahh, ganz fiese Antwort - hast du mal die Länge des 1.Threads geprüft?
Ich habe bestimmt 7/8tel 'grins' davon gelesen und Einiges ist hängen 
geblieben, denke ich!
Hier gibt's Leute, die haben die letzten 3 Beiträge nicht gelesen und 
fragen trotzdem... dann schickt man halt einen Link und gut is'!
...ich mag dich trotzdem 'lächel' nicht falsch verstehen, bin absolut 
hetero.....

>>> [...]
>>
>> Gruß Michael
>
> Grüße,
>
>    rowue

auch Gruß Michael

...und wieder kein Mikro ersteigert, heut' ist der Wurm drin.

[Guido (Gast)]

Hi Luc,

at the moment I don't suggest any harware modifications. We are testing
about that but the results seem to be only minor advantages. The most
important change was the firmware-hack unenabling some sort of 
FIR-filter
in the FPGA-design. This was done before the 1.0 firmware.

I am aware of the spikes during warmup too, after 2 minutes or so the
spikes vanish.

I own a W2012A andt there seems to be no difference to the W2022A,
maybe Welec did some hardware-selections? I can't imagine.

See you, Guido

[Blue F. (blueflash)]

Luc schrieb:
> @Guido and @Hayo
> I have not yet tried the 1.2.BF.1.1 release but I will do soon.
> About ADC SETUP I set it as a FACTORY with my W2022A and I have not
> encountered problems with both low and high frequency.

In the BF.1.1 I exchanged the values of the menu-entries for factory 
setting and high frequencies - in the BF.1.0 it is the wrong order!


> First I tried it with a 1.4 original firmware by Welec and despite it is
> rated for 100MHz bandwidth I was not able to overcome 60MHz and the
> oscilloscope is pretty useless even at much lower frequencies

In the original Firmwares all the lower timebases are set to the same 
settings as the 50ns Timebase - and therefore are extremely useless!!!


> Everything worked well like with my W2022A and surprise the W2012A
> easily reach 170MHz just like my W2022A!, I have not noticed significant
> differences.:-)

Until now we didn't find any differences in the Hardware between the 100 
MHz and the 200 MHz Version. I myself got a W2022A and a W2014A. My 
HF-Tests revealed no great Differences between the two DSOs.


> Yes, perhaps SLOW TB comes from the 1.4 original firmware by Welec, I'll
> try to check in the manual to understand how to use the SLOW TB
> function.

Hmm, I didn't use this until now. I will check it.

> Just one last thing about the CH1 DELAY and CH2 DELAY.
> I have already written as I used these function and why but I did not
> understand if I did it correctly.

Yes, You did. We (the guys here in the forum) checked the channel 
phaseshift of our DSOs and found out that they differ about 2ns and 8ns
between the channels. So I think the maximum of 16 ns for each channel I 
provided in the delay menu are more than enough to bring all channels in 
phase.

Please notice, that the BF.1.0 has a little bug in the DAC-Calibration 
function which only appears at some channel delays (I tried 7ns).
It is fixed in the BF.1.1.

I think I should write a little manual for the new functions...

For example the the Quick Print function. Pushing it two times initiates 
the screenshot function without changing the menu - did You know that?


Hayo

[Michael D. (mike0815)]

Hayo W. schrieb:
> I think I should write a little manual for the new functions...
>
...fine!
>
>
> For example the the Quick Print function. Pushing it two times initiates
>
> the screenshot function without changing the menu - did You know that?
>
>
no, I didn't and I bet that someone else didn't know that ether ;)
...but now I, we do! :)
>
>
>
> Hayo

Greetings Michael

[Guido (Gast)]

Hallo,

mit der 1.1 habe ich jetzt große Unterschiede zwischen den beiden
Kanälen. Werden die jetzt unterschiedlich behandelt? Würde ja
Sinn machen.

Ich probiere im Moment mit Pre-Gain = 1,25, da sollten doch beide
Kanäle gleich behandelt werden.

Gruß, Guido

[Blue F. (blueflash)]

Guido schrieb:
> Hallo,
>
> mit der 1.1 habe ich jetzt große Unterschiede zwischen den beiden
> Kanälen. Werden die jetzt unterschiedlich behandelt? Würde ja
> Sinn machen.

Eigentlich nicht...

> Ich probiere im Moment mit Pre-Gain = 1,25, da sollten doch beide
> Kanäle gleich behandelt werden.

vielleicht hab ich da noch nen Zinken drin. Beschreibe doch mal was da 
unterschiedlich ist bzw. poste es als screenshot.

Hayo

[Guido (Gast)]

Hallo Hayo,

es sind einfach die Amplituden der beiden Kanäle stark verschieden und
das Ganze frequenzabhängig. Aus der Erinnerung:

bei 1 kHz zeigt Kanal 2 (0 Ohm) ca. eine um 30 % höhere Amplitude an,
bei 30 MHz dann Kanal 1 (22 Ohm) etwa die doppelte Amplitude gegenüber
Kanal 2.

Ich werde das später noch mal genauer untersuchen, aber der Aufbau
steht eigentlich noch von meiner Frequenzgangmessung.

Gruß, Guido

[Blue F. (blueflash)]

Verstehe ich das richtig, dass Deine Kanäle unterschiedlich bestückt 
sind?

Hayo

[Guido (Gast)]

Ja, ist doch schon länger so. Hast du alle Kanäle geändert?

Wenn es an der 1.1 läge, müsste das doch auch jemand anders
aufgefallen sein?

[Blue F. (blueflash)]

Dann ist es aber doch klar, dass die Kanäle unterschiedlich aussehen. Da 
versteh ich das Problem nicht so richtig. Bei meinem W2022A hab ich auch 
einen Kanal original und einen mit 33 Ohm bestückt. Da gibt es natürlich 
auch Unterschiede in der Amplitude - Frequenzabhängigkeiten hab ich 
allerdings noch nicht getestet.

Gruß Hayo

[Guido (Gast)]

Schon aber der Unterschied war sehr gering (1/4 Div oder so).
Den Frequenzgang habe ich ja vorgestern verglichen (s.
Hardwarethread). Jetzt dagegen die großen Unterschiede?

[Guido (Gast)]

Oops, peinlich. Ich habe das Problem gelöst:

Wenn man einen SA als Abschlusswiderstand nimmt, solte dieser
auch eingeschaltet sein. Etwas verblüffend, dass sich das auch
bei sehr niedrigen Frequenzen (1 kHz) bemerkbar macht.

Gruß, Guido

[Blue F. (blueflash)]

...na dann ist ja alles gut (schwitz...)

Hayo

[Blue F. (blueflash)]

So, neue (alte) Erkenntnisse zum Frequenzverhalten. Da ich zu faul bin 
meine Messreihen in Exel zu tippen, hier eine grobe Zusammenfassung.

Zum Messaufbau:

Meine Möglichkeiten zum HF-Messen sind leider sehr begrenzt. Bis 60 MHz 
Grundfrequenzreicht mein Generator. Trotzdem sind die Resultate sehr 
interessant und bestätigen die Messungen die im Hardwarethread gepostet 
wurden.

Generator: HP3325A  20MHz mit Amplituden bis 40V, 60 MHz mit 0dB
Referenz Oszi: Tek 2465A (350 - 400 MHz Bandbreite)

Bei Frequenzen bis 20 MHz gibt es zwischen der 0 Ohm Variante und der 33 
Ohm Variante keine nennenswerten Unterschiede. Mit steigender Frequenz 
steigt die Amplitude bei der Originalbestückung deutlich an während die 
33 Ohm Variante da eheblich genauer ist.

Das Signal bei 60 Mhz hat Überschwinger mit Frequenzanteilen die 
deutlich höher sind als die Grundfrequenz.

Die gemessenen Amplituden incl. Überschwinger:

Referenz Tek:     464 mV
Welec mit 0 Ohm:  744 mV
Welec mit 33 Ohm: 528 mV

Das sind 280 mV zuviel bei 0 Ohm und nur 64 mV bei 33 Ohm.

Der Amplitudengang verläuft also mit den 33 Ohm Widerständen deutlich 
linearer als mit den 0 Ohm Widerständen.

Zusammen mit der Tatsache das auch das Rauschen in den 1er und 2er 
Bereichen etwas abnimmt ist das für mich Grund genug auch den Rest mit 
33 Ohm zu bestücken.

Hayo

[Blue F. (blueflash)]

Noch ein kleiner Nach(t)gedanke:

es kann natürlich sein, dass der ausgetauschte 150 KOhm Widerstand 
(gegen 150 Ohm) maßgeblich am Fequenzgang beteiligt ist und nur die 
Kombination aus beidem diesen positiven Effekt hat.

Hayo

[Guido (Gast)]

Jo, den Nachtrag halte ich auch für relevant. Ich werde später
auch nochmal nachmessen, ich fürchte mein letzter Frequenzgang
war durch den SA verzerrt. Dann haben wir den vergleich mit
150 kOhm.

Gruß, Guido

[Luc (Gast)]

@Guido and @Hayo

Hi Guido, Hayo and all guys.
Thank You very much for for the useful details!
OK, for changes in the hardware I think like You Guido.
In fact, to be honest watching the screenshots I think the improvements 
are marginals, but I could be wrong because I do not understand very 
well the German language.
I believe that the new firmware make the difference, the hardware is 
what it is and it can be left as it is.
However we will see.
For spikes problem which I wrote and Guido confirm, I think it's a warm 
up problem, once thermally stabilized the DSO works without problems.:-)
However, the W2022A does not have that problem, at least what I have so 
the hardware-selections hypothesis could be right.
About the wrong  values of the menu-entries of BF.1.0 firmware mentioned 
by Hayo, with my W2022A I have not had problems with both FACTORY that 
HIGH FREQ, as I have already had occasion to write.
Very good for the BF.1.1 firmware version that was promptly corrected by 
Hayo, good as usual, thanks!:-)
Unfortunately I'm still doing tests with the BF.1.0 version but I will 
the upgrade soon.

Hayo W. schrieb:
>
>> First I tried it with a 1.4 original firmware by Welec and despite it is
>> rated for 100MHz bandwidth I was not able to overcome 60MHz and the
>> oscilloscope is pretty useless even at much lower frequencies
>
>In the original Firmwares all the lower timebases are set to the same
>settings as the 50ns Timebase - and therefore are extremely useless!!!
OK, thanks for the information Hayo!:-)
Still using the BF.1.0 firmware, today I did further testing with my 
friend's W2012A.
Using a very crude free oscillator I reached about 250MHz with the 
W2012A.
250MHz is the limit of the frequency meter of my Hameg 1500-2.
Free oscillator signal was not very stable and clean but the W2012A 
showed about the same things of the Hameg 1500-2!:-)
At 200MHz things were better so roughly the W2012A can be considered a 
200MHz, however my tests are not rigorous: I consider the displayed 
waveform rather than their levels.

Hayo W. schrieb:
>> Everything worked well like with my W2022A and surprise the W2012A
>> easily reach 170MHz just like my W2022A!, I have not noticed significant
>> differences.:-)
>
>Until now we didn't find any differences in the Hardware between the 100
>MHz and the 200 MHz Version. I myself got a W2022A and a W2014A. My
>HF-Tests revealed no great Differences between the two DSOs.
I agree.

For the SLOW TB function I must investigate, in case I try with Welec, 
I'll see what they respond to me.
OK Hayo for your answer to my question about CH1 DELAY and CH2 DELAY and 
OK for its bugfix in the BF.1.1 firmware!
Now I understand!:-)

Hayo W. schrieb:
>I think I should write a little manual for the new functions...
>
>For example the the Quick Print function. Pushing it two times initiates
>the screenshot function without changing the menu - did You know that?
I'm Sorry, I did not know this, however I do not often use that function 
but I will do soon.
What can I say?
Very well guys, thanks very much!:-)
Vielen Dank!:-)

Luc

[Michael D. (mike0815)]

Hayo W. schrieb:
> Noch ein kleiner Nach(t)gedanke:
>
> es kann natürlich sein, dass der ausgetauschte 150 KOhm Widerstand
> (gegen 150 Ohm) maßgeblich am Fequenzgang beteiligt ist und nur die
> Kombination aus beidem diesen positiven Effekt hat.
>
> Hayo

Ich gebe mal meinen Senf dazu, weil ich ein wenig aufgepasst habe:

Hier waren ja die Berechnungen (laut Andre?) damit der Abschluss 1100 
Ohm beträgt...
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

dann wäre Hayo's Konstellation mit den 2 x 33 Ohm und dem 150 Ohm,
der Abschlusswiderstand über 1100 Ohm!
Würde die Amnplitude mit 100 Ohm (statt 150 Ohm) noch weiter sinken, was 
ja eigentlich logisch wäre, da der Abschlusswiderstand ja niedriger 
wäre,
oder wie verhält sich das?

Gruß Michael

[Blue F. (blueflash)]

vermute ich auch

Hayo

[Blue F. (blueflash)]

Hi Luc,
a comnent to Your high frequency test. We fomd out that the amplitude
increases at frequencies between 50 ~ and 200 Mhz. So the amplitude 
response
is not linear, but has a maximm aromd 150 Mhz.

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

I made some tests with my modified hardware ( I changed the input
resistances of 0 0hm against 33 0hm and the 150 KOhm parallel resistmce
against 150 Ohm) and fomd out that the amplitude response is much more
linear now.

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

So I think I will change all other resistances too. But in the normal 
case
of measuring at 20 or 30 mz You are right, it is not so importmt as the
firmware with all its functions.

Hayo

[Guido (Gast)]

Ohoh Hayo,

ich habe meine Messungen gerade abgebrochen, Die Quick.Measure-Funktion
scheint unter die Räder gekommen zu sein. Gast du Kästchen gezählt?

ADC war beim Bild auf Factory gestellt.

Gruß, Guido

[Guido (Gast)]

O.k. I'll try this one in english.

If Hayos's results are confirmed and we start changing the resistors,
we should do that according to the datasheet's hints. I'll have a
lokk tomorrow. Doing that we should change the OPA's feedback resistor
as well, to increase the gain and use the ADC's full resolution.
There will be a decrease in bandwith along, but this might be
süperseeded by the increase in gain we jet have with higher
frequencies.

Regards, Guido

[Blue F. (blueflash)]

@Guido

Ich habe meine Messungen nicht mit Quick Measure gemacht, sondern mit 
den manuellen Cursorn. Die Werte die ich da ermittelt habe sind schon 
korrekt.

Hayo

[Blue F. (blueflash)]

Allerdings hast Du recht in Bezug auf die QM-Funktion, ich bin da 
ebenfalls auf Verbesserungspotential gestoßen...


Hayo

[Guido (Gast)]

@ Hayo: Ich habe gerade nachgeschaut, die Cursor-Werte stimmen nur
bei Pre-Gain = Factory. Gibt wohl noch ne Menge Arbeit.

[Blue F. (blueflash)]

Guido schrieb:
> @ Hayo: Ich habe gerade nachgeschaut, die Cursor-Werte stimmen nur
> bei Pre-Gain = Factory. Gibt wohl noch ne Menge Arbeit.

Wie ist das gemeint? Ich habe auch nachgeschaut und die Cursorwerte 
stimmen für alle Bereiche - oder meintest Du QM-Cursorwerte?

Hayo

[Blue F. (blueflash)]

Nichtsdestotrotz hat mir die QM-Sache keine Ruhe gelassen. Es gibt daher 
mal wieder eine neue Version...

What is new:

- Ticket #31 gefixt

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

- QM support für USTB modus

- QM menü Einträge korrigiert (QM-Selection)

Viel Spass

Hayo

[Blue F. (blueflash)]

Ich habe es getan! Das USB-Mikro ist bestellt für 50 Ocken plus 5 Ocken 
Versand.

Bin mal gespannt...

Hayo

[Michael D. (mike0815)]

Hallo Hayo,

eine Screenshot " 1.5 " ???

Die QM hatte nur Probleme ab 60MHz ?

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:
> Hallo Hayo,
>
> eine Screenshot " 1.5 " ???

ja ich hab die Farbpalette noch etwas geändert und dann die 
Versionsnummer auf den aktuellen Stand gebracht. Ist aber völlig 
losgelöst vom dem OS-Screenshot, der auch anders komprimiert.

> Die QM hatte nur Probleme ab 60MHz ?

Wie ist das gemeint?

Hayo

[Michael D. (mike0815)]

Weil Guido's Quick-Measure unter die Räder gekommen sind? Ab wann oder 
wo, tritt das ein?

Hast du was am Auto-Trigger gedreht? Der Zappelt ja garnicht mehr, 
vielleicht hat mein Teil auch nur einen guten Tag!

Die 0,48er sowie die 1.5 Screensh. zickt bei mir rum, ist sehr langsam 
und es tut sich manchmal nix...während die Os-Variante gleich anschlägt 
und hat zackich' das Bild generiert. Die Port-Einstellungen sind alle 
Dieselben. 115200 baut, Datenbits: 8, Parität: keine, Stoppbit: 1, 
Flussst.: keine !
Baudrate, Handshake???

Noch was, beim Quick-Measure habe ich die roten Linien im Signal (oben 
u. unten), das war vorher nur im Curser-Modus.

Gruß Michael

PS.: 2x Quickprint funktioniert prima, feine Sache...

[Guido (Gast)]

Beim Quick-Print habe ich auch das Problem, dass ich erst den
Menüpunkt BF/OS aufrufen muss. Ohne dort etwas zu ändern klappt
es anschließend. Wird doch kein Initialisierungsproblem sein. :-))

@ Hayo: Für 55 Öcken kann man ja nicht viel falsch machen.
Andererseits ist eine Nahlinse für die Digicam auch nicht teurer.

Soll ich mal wieder einen Frequenzgang posten? Mal sehen, ob ich
das irgendwann mal fehlerfrei hinbekomme.

Grüße, Guido

[Blue F. (blueflash)]

Michael D. schrieb:
> Weil Guido's Quick-Measure unter die Räder gekommen sind? Ab wann oder
> wo, tritt das ein?

Keine Ahnung, hatte das Phänomen noch nie, bei mir läuft alles stabil.

> Hast du was am Auto-Trigger gedreht? Der Zappelt ja garnicht mehr,
> vielleicht hat mein Teil auch nur einen guten Tag!

Nix gemacht.

> Die 0,48er sowie die 1.5 Screensh. zickt bei mir rum, ist sehr langsam
> und es tut sich manchmal nix...während die Os-Variante gleich anschlägt
> und hat zackich' das Bild generiert.

Die OS-Version ist tatsächlich einfach schneller! Bei der BF-Version muß 
man etwas länger warten, ich hatte es auch mal, das er das Bild erst 
gespeichert hat nachdem ich am Oszi irgendeine Taste betätigt hatte.

Allerdings ist das bei mir schon länger nicht mehr aufgetreten.

> Noch was, beim Quick-Measure habe ich die roten Linien im Signal (oben
> u. unten), das war vorher nur im Curser-Modus.

Auf Deinem Screenshot oben liegt es daran, das die obere Kante des 
Signals so glatt ist. Normalerweise wird die rote Linie von einzelnen 
Minispikes nach oben gedrückt. Da hab ich aber nichts geändert, ist also 
so wie vorher und auch in der OS-Version.

Hayo

[Blue F. (blueflash)]

Guido schrieb:
> Beim Quick-Print habe ich auch das Problem, dass ich erst den
> Menüpunkt BF/OS aufrufen muss. Ohne dort etwas zu ändern klappt
> es anschließend. Wird doch kein Initialisierungsproblem sein. :-))

Muß ich mal prüfen. Kann es sein, das das nur nach dem Flashen auftritt 
und dann nicht mehr?


> Soll ich mal wieder einen Frequenzgang posten? Mal sehen, ob ich
> das irgendwann mal fehlerfrei hinbekomme.

Ja, aber dann mit kurzer Info über die Widerstandsbestückung der 
Längswiderstände und des Parallelwiderstands.

Gruß Hayo

[Guido (Gast)]

Ich glaube eigentlich nicht, dass es nur nach dem Flashen so ist,
kann das später aber noch probieren.

Zum Frequenzgang: Reihenwiderst. sind angegeben,
Abschlusswiderstand ist im Originalzustand. Die Kurve ist nicht sehr
genau aufgenommen (+-25 mV oder so), soll nur den Trend zeigen.

Gruß, Guido

[egberto (Gast)]

Noch mal zum Verständnis: bis 100 MHz ist es im Originalzustand 
definitiv besser - der Peak kommt halt später.

Bis jetzt bin ich von der Widerstandsmodifikation nicht überzeugt.

(Nicht das mich jemand falsch versteht - vielen Dank, das das jemand 
ausprobiert und dabei seine Kiste aufs Spiel setzt!)

Bringt denn der geänderte Parallelwiderstand etwas?

(Ich habe leider in diesem Monsterthread etwas den Überblick verloren)

Viele Grüße,

egberto

[Michael D. (mike0815)]

hmm, bei 0 Ohm und Noise-Filter, geht das Sig. ganz schön in den Keller, 
während bei der Bestückung sich das in Grenzen hält.
Wenn noch der Abschwiderstand getauscht wäre, würde mich mal 
interssieren, wie's dann aussieht!


Gruß Michael

[egberto (Gast)]

sorry, hab ich ich nicht verstanden - 0 Ohm denoise sieht für mich noch 
am besten aus!? (Ziel ist doch eine waagerechte Gerade oder?)

Viele Grüße,

egberto

[Luc (Gast)]

@Hayo

Hi Hayo and all guys.
Very good for the new BF.1.2, good as usual, thanks!:-)
Soon I will upgrade to the new release.;-)

Hayo W. schrieb:
>
>Hi Luc,
>a comnent to Your high frequency test. We fomd out that the amplitude
>increases at frequencies between 50 ~ and 200 Mhz. So the amplitude
>response is not linear, but has a maximm aromd 150 Mhz.
>
>http://sourceforge.net/apps/trac/welecw2000a/wiki/...
I already read it, anyway thanks for reminding me.

Hayo W. schrieb:
>
>I made some tests with my modified hardware ( I changed the input
>resistances of 0 0hm against 33 0hm and the 150 KOhm parallel resistmce
>against 150 Ohm) and fomd out that the amplitude response is much more
>linear now.
>
>Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
>
>So I think I will change all other resistances too. But in the normal
>case of measuring at 20 or 30 mz You are right, it is not so importmt as
>the firmware with all its functions.
I know and I agree.
As I said my tests are not rigorous, I consider the displayed waveform 
rather than their levels.
I often use old vacuum state tube oscilloscopes of the 50s of last 
century and I do comparative rather than quantitative measures because 
they are not "calibrated".
So I can do same with Welec, this is the meaning of what I wrote.
In this context for me is more important the fidelity of the track 
rather than its actual values of amplitude.
Then it is obvious that if it is possible to make more linear the 
amplitude response better is and I would be happier also.:-)
But I think already the software does a very good job without having to 
alter the hardware.
I also think that change the hardware is not for everyone, I would not 
have problems but I believe that not for all would be so easy.
The firmware update instead is accessible to all and at present I think 
it bring many more benefits that the change of resistances, in the 
future we will see.
Vielen Dank!:-)

Luc

[Guido (Gast)]

Hallo,

jepp egberto, das siehst du richtig. es sollte eine Gerade über
200 mV sein und die ursprünglichen Widerstände kombiniert mit
Hayos Rauschfilter liefern das beste Ergebnis. Allerdings habe
ich bei dieser Messung ("wer misst misst Mist") schon so viele
Fehler begangen, dass es mich nicht wundern würde, wenn es morgen
wieder anders aussieht. Wäre daher schön, wenn das andere auch
nur teilweise nachmessen könnten.

@ Luc: We all are lacking optimal equipment. we just try to find
out the most reliable values for the resistors in the input-stage.
The overall response could then be linearized by software.
By the way: The user branadic is engineering a new input stage. We
are looking forward upon this.

Gruß, Guido

[mike0815 (Gast)]

Ich bin ja doof, hatte da visuell etwas verwechselt...

[Blue F. (blueflash)]

Noch ein kurzes Zwischenergebnis.

Ich habe den Parallelwiderstand auf 100 Ohm gesetzt und nochmal gemessen 
- keine Änderung (außer der Skalierung) im Amplitudengang gegenüber den 
150 Ohm. D.h. ich werde auf 150 Ohm zurückrüsten, da hier die Skalierung 
günstiger ist.

Grundsätzlich kann man aber schon sagen, dass die Umrüstung auf 33/150 
Ohm
für HF-Messungen Sinn macht. Ansonsten (< 20 MHz) wirkt es sich nicht so 
stark aus, insbesondere wenn man den Noisefilter benutzt.

Da ich ja zwei Geräte habe, werde ich das W2022A umrüsten und das W2014A 
original lassen, dann hat man auch immer einen Vergleich.


Hayo

[Blue F. (blueflash)]

@Guido

Du solltest auf jeden Fall auch den Parallelwiderstand austauschen (150 
Ohm bietet sich an), sonst macht das nur wenig Sinn.

Wenn Du bei 22 Ohm für die Serienwiderstände bleiben willst brauchst Du 
geänderte Skalierungsfaktoren. Ich kann Dir anbieten das Coding zu 
schicken incl. kurzer Anleitung was Du tun must.

Hayo

[Guido (Gast)]

@ Hayo: Ich muss das erst mal durchrechnen. Wie schon geschrieben
möchte ich bei der Gelegenheit gleich die Verstärkung anheben, so
dass die ADCs bis auf +-127 ausgesteuert werden.

Ich baue später mal einen Frequenzvervielfacher (ICS502) auf,
damit ich das Welec mal mit Rechtecksignalen bis 100 MHz
traktieren kann.

Gruß, Guido

[Guido (Gast)]

Sorry für Doppelpost.

@ Hayo: Mit den Widerständen musst du die Spannungen mit 1,44
multiplizieren, liege ich da richtig?

[Blue F. (blueflash)]

Guido schrieb:
> Sorry für Doppelpost.
>
> @ Hayo: Mit den Widerständen musst du die Spannungen mit 1,44
> multiplizieren, liege ich da richtig?

nicht ganz:

bei 33/150 Ohm sind es 1,51
bei 33/100 Ohm sind es 1,65

Hayo

[Gyppe (Gast)]

Hello, could someone explain me how to hardware modify? I want to change 
the resistance but can not find a schematic to identify those to be 
replaced. And then use that value, 24 or 33ohm?
What benefits you have with this change? Higher linearity and lower 
noise, right?

Thanks, Gyppe.

[Blue F. (blueflash)]

Hi Gyppe,

thats right. I will post a Photo in the Hardwarethread in a few minutes

Hayo

[Blue F. (blueflash)]

You will find the Pictures here:

Beitrag "Wittig(welec) DSO W20xxA Hardware"


Hayo

[Michael D. (mike0815)]

Guido schrieb:
> @ Hayo: Ich muss das erst mal durchrechnen. Wie schon geschrieben
> möchte ich bei der Gelegenheit gleich die Verstärkung anheben, so
> dass die ADCs bis auf +-127 ausgesteuert werden.
>
Hallo Guido,

...da bin ich mal gespannt!

> Ich baue später mal einen Frequenzvervielfacher (ICS502) auf,
> damit ich das Welec mal mit Rechtecksignalen bis 100 MHz
> traktieren kann.

Rechteck mit 100MHz? Wie sieht das dann noch aus???
>
> Gruß, Guido

Gruß Michael

[Guido (Gast)]

So, ein Problem habe ich jetzt eingekreist:

Wenn beim Abschalten das Oszi im FFT-Modus war und ich diesen
nach dem nächsten Einschalten verlassen will, werden bei meinem
W2912A Kanal 3 und 4 aktiviert und lassen sich nicht mehr
ausschalten (hab ja keine Taster dafür). Dann hilft nur noch
Default-Setup, worauf dann aber auch die Kalibrierung der ADC
und der DAC zum Teufel ist.

Den umgekehrten Fall muss ich noch genauer untersuchen, da gibt
es aber auch Probleme.

Gruß, Guido

[Blue F. (blueflash)]

Wieso ist nach einem Default Setup die Kalibrierung zum Teufel???

Die sollte eigentlich nicht geändert werden.

Das Problem mit Kanal 3 + 4 werde ich mir mal ansehen.


Hayo

p.s. hast Du ein neues Modell W2912A? ;-)

[Guido (Gast)]

> Wieso ist nach einem Default Setup die Kalibrierung zum Teufel???

Ja, das wundert mich auch. Ich erjenne es nur an den Störungen, die
nach neuer Kalibrierung wieder besser sind.

> p.s. hast Du ein neues Modell W2912A? ;-)

Naja, nach jedem Zerlegen die V-Nummer dort erhöht, wo es nicht so
stört (puuh, sollte doch die Brille aufsetzen).

Gruß, Guido

[Blue F. (blueflash)]

Hmm muß ich wohl mal checken, war mir noch nicht aufgefallen. Das soll 
ja so nicht sein...

Hayo

[Torsten W. (wirehead)]

Kann ich ebenfalls so bestätigen, nach dem einschalten ist die FFT 
wieder da aber beim verlassen hab ich 2 kanäle mehr...

[Blue F. (blueflash)]

Mensch, seid doch froh, meldet sich das Oszi dann auch als W2024A ;-)

Ich werde da mal einen Fix in den nächsten Tagen rausbringen.

Hayo

[Blue F. (blueflash)]

Also zum Thema Default Setup:

Definitiv werden DAC-Offset und ADC-Offset nicht dadurch verstellt! Ich 
habe mehrere Tests gemacht und es funktioniert wie es soll!!!


Folgende Situation habe ich bei mir aber öfters mal gehabt:

Nach einem Flashvorgang mit einer neuen Version hingen die Signale 
völlig schief, danach ein Default Setup und alles ist wieder gut. 
Allerdings waren da jedesmal die Kalibrierungen hinüber. Das liegt dann 
aber nicht am Default Setup, sondern an der Startup-Routine, die nach 
dem Laden einer neuen Firmware das Flash neu initialisiert, um bei 
geänderter Flashkonfiguration die Werte neu zu belegen und das Gerät 
nicht ins Nirwana zu schicken.

Hayo

[Guido (Gast)]

Hmmh, ob ich den Junge zu grob anfasse? Ich habe vorhin wieder
das ganze Programm durchgezogen. Auch unter Utility->more->Hardware
hatte er alles vergessen.

Wir werden es rausfinden!

Gruß, Guido

[Blue F. (blueflash)]

Hallo, einen schönen 1. Mai wünsche ich,

ich überarbeite gerade die Initialisierungsroutine um das mal entgültig 
zu stabilisieren.

Nächste Version kommt in Kürze...

Hayo

[Guido (Gast)]

Hallo Hayo,

wäre es möglich in der FFT das Grid horizontal auf 10 Div zu ändern?
Es muss ja nur das Grid und die Anzeige/div angepasst werden. Die
8 Divs treiben einen beim Kopfrechnen in den Wahnsinn. ;-)

Gruß, Guido

[Blue F. (blueflash)]

Guido schrieb:
> Hallo Hayo,
>
> wäre es möglich in der FFT das Grid horizontal auf 10 Div zu ändern?
> Es muss ja nur das Grid und die Anzeige/div angepasst werden. Die
> 8 Divs treiben einen beim Kopfrechnen in den Wahnsinn. ;-)

Tja, wie Du Dir denken kannst, hab ich das nicht ohne Grund gemacht. Und 
der Grund ist nicht, dass ich Euer Kopfrechnen auf Vordermann bringen 
will, sondern, dass das Grid 512 Punkte breit ist - was ja direkt mit 
der Breite der FFT-Abtastung zusammenhängt die ja nur Werte zur Basis 2 
zuläßt und nicht zur Basis 10.

Teil mal 512 durch 10 - und jetzt kommst Du...


Hayo

[Guido (Gast)]

... auf 51, Rest 2. Sieht doch unproblematisch aus? Achso,
ist vom Array aus betrachtet, nicht in Pixeln.

512 MHz durch 8 wäre ja auch schon besser, würde dir aber
sicher mehr Probleme bereiten. Bleiben wohl doch nur die
zähen Cursor übrig. :-(

[Guido (Gast)]

Nö, gleich nochmal. Jetzt hast du mich geblufft.

Es geht doch nur um die graphische Darstellung. Alles bleibt,
nur das Grid wird verändert. Was übersehe ich da?

[Blue F. (blueflash)]

Also,

Du kannst eine Gridlinie immer nur auf einem vollen Pixel malen. Bei 512 
Pixeln müßtest Du aber bei einer Zehnerteilung die Linie auf dem jeweils 
51,2ten Pixel malen....ist etwas schwierig :-)

Hayo

[Guido (Gast)]

Nö, ist einfach. Eine Gridlinie alle 51 Pixel, hinten bleiben
2 Pixel übrig. Ich fände es noch nicht einmal störend, wenn
die horizontalen Linien über die 11. vertikale hinausragen.

Gruß, Guido

[Blue F. (blueflash)]

Ich überleg mir da mal was, vielleicht kann ich Dir da doch was 
anbieten.

Hayo

[Blue F. (blueflash)]

Kurzer Zwischenbericht von der Firmwarefront.


Auf der Suche nach den Ursachen der Auffälligkeiten die Ihr gemeldet 
hattet, bin ich auf diverse Bugs in den Flash-Routinen gestoßen. Der 
Grund für die komischen Effekte war einfach, dass die Daten nicht 
richtig gespeichert wurden, und er dann völlig verwurstete Daten beim 
Start geladen hat (oder auch beim Rückkehren von der FFT).

Das wundert mich ja nicht wirklich, da es die einzigen Routinen sind 
(außer den USB-Routinen) die ich noch nicht korrigiert habe. Ich hatte 
ja gehofft das der Kerl wenigstens etwas fehlerfrei hingekriegt hätte - 
aber wie der Lateiner sagt: Spes saepe fallit! (die Hoffnung trügt oft).

Zur Zeit lerne ich gerade das Datenblatt von AMD auswendig und probiere 
an der Löschroutine rum.

Auch das kriegen wir hin...

Gruß Hayo

[Blue F. (blueflash)]

Na hat Euch die Frühjahrsmüdigkeit überwältigt?

Dann hier der richtige Wachmacher! Nach einer Woche rumtüfteln hat sich 
eine Menge getan. Die Highlights sind:

- Startup-Sequenz stabilisiert
- Flashroutinen gefixt/verbessert
- diverse Bugs in FFT und Channel-Switching gefixed
- neue Flash Backuplogik

Das neue Flash-Sektormapping findet Ihr in den aktuellen Memorymaps.

Und für Guido ist auch was dabei:

- neue FFT-Grid Frequenzteilung, umschaltbar durch mehrfaches Drücken 
des Grid Switch im Displaymenü.

Ansonsten viele kleine Änderungen damit alles rund läuft.

Die stabilste Version die ich je rausgegeben habe!

Please pay attention to the changelog for detailed information.

Schönes Wochenende / Nice Weekend

Hayo

[Michael D. (mike0815)]

...ui, zufällig war ich mal der Erste der frohen Botschaft!

Hi Hayo, habe gestern den Winzling ICS511 (200MHz) bekommen!
Hast du in dieser Richtung schonmal was gemacht?
Guido, wie war denn dein weiterkommen mit dem ICS501? Da war doch was?

Ich weiß, gehört in die HW...

Gruß Michael

[Blue F. (blueflash)]

Hi Michael,

nein ich war rein firmwareseitig eingespannt, das aber dafür gründlich. 
Da ich da jetzt etwas Ruhe ausstrahlen kann werde ich mich mal an die 
Hardware machen, z.B. 32 kleine Kühlkörper zurechtsägen um dem W2014A 
auch zu der thermischen Stabilität wie dem W2022A zu verhelfen. Oder 
auch das Zusammenbraten der Generatorerweiterung.

Ihr werdet auf jeden Fall von mir hören, ansonsten bin ich gespannt auf 
das Echo zur neuen Version.

Gruß Hayo

[Blue F. (blueflash)]

Äh, sorry meinte natürlich 16 Kühlkörperchen, sind aber auch schon 
genug...

Hayo

[Guido (Gast)]

@ Hayo: FRÜHJAHRSMÜDIGKEIT, wo ist denn Frühling? Solange ich morgens
zum Radfahren Handschuhe brauche ist das ne fette Winterdepri!

Nene, du kennst sicher den Stress, wenn man den Brückentag für einen
Kurzurlaub nutzen möchte. :-)) Da sieht es natürlich auch mit Testen
schlecht aus, hole ich aber nach.

@ Michael: Schau mal im Hardwarethread, der 502 funktioniert und
erste Messergebnisse liegen vor. Die Dinger sind eigentlich sehr
anspruchslos, brauchen nur 100 nF von Vcc zu GND. Denke aber an
einen 50-Ohm-Ausgang mit Abschluss am Oszi. Sonst misst du bei
den Frequenzen nur Fahrkarten. Ich habe einfach einen bedrahteten
51-Ohm-Widerstand in den Ausgang eingefügt. Ein SMD-Widerstand hier
trägt das schwere Koaxkabel nicht.

Grüße, Guido

[egberto (Gast)]

Hallo Hayo,

hab sie eben aufgespielt, sieht gut aus - vielen Dank für die Mühe!!
Habe (wie immer) nur wenig Zeit zum testen, denn es  ist Heringszeit!!!

Wir ziehen hier jeden Tag mehrere Kilo Hering raus und danach kommt der 
Hornfisch (Hornhecht, Arbeiteraal).

Gibt's das eigentlich in HH auch so extrem?

Viele Grüße,

egberto

PS: Das Angebot mit dem Griechen steht!!

[Blue F. (blueflash)]

Hier gibts nur Backfisch ;-)

Gruß Hayo

[Gyppe (Gast)]

Hi Hayo, point out some bugs for the new version:

-The ultra-slow timebase not function again.
-The switch on-time FFT is very slow
-In normal wound-there are freeze the track.
-Sometimes the button switches the display grid on the menu freezes the 
entire system and a reboot does not always happen and I did not 
understand what causes it.


Bye Gyppe.

[Blue F. (blueflash)]

Gyppe schrieb:
> Hi Hayo, point out some bugs for the new version:

thanks for Your report

> -The ultra-slow timebase not function again.

I'm sorry about that, it is because of the new flash routine which 
causes a little confusion on timer 2 (USTB-Timer). I fixed it.

> -The switch on-time FFT is very slow

the new config save routine needs a little bit more time now because of 
the double writing strategy, but works much more save than before.

> -In normal wound-there are freeze the track.

I didn't understand that

> -Sometimes the button switches the display grid on the menu freezes the
> entire system and a reboot does not always happen and I did not
> understand what causes it.

I changed the logic and hope it is stable now.


The new 1.2.BF.1.4 with all fixes will be available this evening here!

Hayo

[Blue F. (blueflash)]

Ok Jungs (Mädels sind, glaube ich, keine hier online oder?),

für die, die nicht so gerne englisch lesen - die neue Version mit den 
Fixes gibt es heute Abend hier.

Hayo

[Gyppe (Gast)]

Sorry :) i used the traslator whitout checking the result..

I meant:
-In normal use have random freeze of track view.



Thanks again for the great job you do, hello:)

[Blue F. (blueflash)]

Ok Leute hier ist sie, hab noch einige Kleinigkeiten optimiert.

Hayo

[Luc (Gast)]

Oh boys, really a good job!
Hayo you are truly tireless, you work for free even on weekends!
I think many others would have expected at least Monday to release the 
new bug free version, so really very well Hayo, thank You very much!!!
Vielen Dank!:-)

Luc

[Gyppe (Gast)]

Hayo my god! You are our benefactor:)

Thanks, this version is very stable, now the menu fft and display is a 
jewel!

[Luc (Gast)]

Hi Hayo and guys, have You a good Sunday.
I tried the 1.2.BF.1.4 new release and it work like a charm, thank You 
very much Hayo!
I do not want to ruin your Sunday and your rest but I noticed something 
so I say them to You: if You want to take a look at them, please wait at 
least Monday, enjoy your well deserved rest now!
Here what I noticed.
Sometimes with some functions by setting a value, two items are checked 
in the same time (i.e. pressing MODE/COUPLING button and setting the 
MODE parameter, sometimes AUTO and COMBI or other are checked in the 
same time and is no possible to fix the problem), I hope to be 
understood.
As You can see it is a little importance thing.
Another thing which is not a problem but a suggestion.
Pressing AUTO-SCALE then the MODE parameter in MODE/COUPLING change to 
AUTO if it is not already so, is not better that the current settings 
are maintained?
However I repeat that this is not a real problem because there is still 
the UNDO AUTOSCALE function.
Vielen Dank!:-)

Luc

[Gyppe (Gast)]

My impression for new flash routines, is that the calibration values are 
not keep in memory, is it possible? When you turn the zero is wrong. 
That's because even cold?
Now ask the friends of my forum for more feeds, you'll know.

Gyppe.

[Gyppe (Gast)]

Excuse me false alarm, the problem was simply the dso cold after a few 
minutes back ok.

[Michael D. (mike0815)]

Hi Gyppe,

i noticed, that you got your own Forum about the Welec DSO's?
Is it possible to set a link in here, so maybe we can take a look at it?

Greetings, Michael

[Gyppe (Gast)]

Yes, we are Italians, thanks to your fine work they have to buy so many.

See here:

http://forum.roboitalia.com/showthread.php?t=5530

[Luc (Gast)]

Luc schrieb:

>Here what I noticed.
>Sometimes with some functions by setting a value, two items are checked
>in the same time (i.e. pressing MODE/COUPLING button and setting the
>MODE parameter, sometimes AUTO and COMBI or other are checked in the
>same time and is no possible to fix the problem), I hope to be
>understood.
>As You can see it is a little importance thing.
>Another thing which is not a problem but a suggestion.
>Pressing AUTO-SCALE then the MODE parameter in MODE/COUPLING change to
>AUTO if it is not already so, is not better that the current settings
>are maintained?
>However I repeat that this is not a real problem because there is still
>the UNDO AUTOSCALE function.

Sorry Hayo and all, really sorry...
Now I understand so please do as if I had never written anything.
Sometimes I do not know where I got my head, really sorry again!
Vielen Dank!

Luc

[Blue F. (blueflash)]

Hallo allerseits,

zu der neuen Configschreibroutine noch eine Anmerkung. Es handelt sich 
hier um einen ersten Wurf. Ich bin noch dabei hier am Timing zu 
optimieren, damit die "Gedenksekunde" nicht so lang ausfällt.

For our Italian friends and all the other not german guys here: the new 
config write routine is a first try. I'm working on a timing 
optimization to minimize the short signal acquisition interrupt while 
writing to flash.

Desweiteren habe ich eine neue Overlay Funktion im Save/Recall Menu in 
Planung, den Button kann man schon sehen, aber er ist noch inaktiv.

Dahinter steckt die vor längerem mal erwähnte Möglichkeit das 
gespeicherte Signal über das aktuelle Signal zu legen um direkt 
vergleichen zu können.

Gruß Hayo

[Paolo (Gast)]

Hi, first of all a great thanks to Hayo and all the open source staff 
that are continuously improving our cheap instrument....
Then, today while playing with my DSO in XY mode, i notice an artifact 
when displaying lissajous figures through two 2 KHz (and 20 KHz) sinus 
as you can see in the screenshot.
I do not own anymore my Tek 465 so i cannot compare the figures...

Firmware is the last BF version, ADC mode is in HF Filter and gain is 
1,25.

Hope it will help to improve further...

Thanks to all and best regards..

Paolo

[Blue F. (blueflash)]

Hi Paolo,

thanks for the hint. It's not unknown! I think it is the first or the 
last value in one sample line which has zeroline value. I will check 
this in the next time.

By the way, for I noticed, that many users don't know this function - 
pressing the Quick Print Button twice (in short time) the screenshot 
starts without changing the menu.

Hayo

[Gyppe (Gast)]

Thanks for this tip.  I don't know, I say immediately on our forum:)

[Paolo (Gast)]

Nice tip.....thanks again!!

Regards

Paolo

[Blue F. (blueflash)]

Hallo Leute, auch wenn es still ist geht es dennoch weiter. Ich habe 
gerade von unseren italienischen Kollegen Unterstützung in Sachen FFT 
angeboten bekommen und wurde auch noch darauf hingewiesen, dass die 
RMS-Berechnung im Quick Measure Betrieb nur für Sinussignale richtig 
ist. Das ist auch schon in Arbeit.

In der nächsten Woche bin ich erstmal nicht online, da ich (wie wohl 
viele) im Urlaub bin. Ich melde mich dann sobald ich wieder da bin.

For our multi language listeners: Developing is going on. Thanks to 
Alessandro for the tip with the RMS-calculation and his offer to help us 
with the FFT functions. The next week I'm on holiday in 'bella Italia' 
and therefore not online here.

Hayo

[Michael H. (Gast)]

Ich komme immer nur dazu, mal kurz in die neuen Versionen reinzuschauen, 
finde es wirklich aber klasse, was sich momentan alles tut. Hayo das 
Energiebündel - einfach wahnsinn.
Aber auch branadic und Walter's Arbeit verfolge ich gespannt.

Und Alex, der FPGA-Gott: Konntest du in letzter Zeit noch was an deinem 
Design weiterentwickeln? Tut mir leid, dass ich noch nichts beitragen 
konnte, aber ich komme im Gegensatz zu Hayo in letzter Zeit immer recht 
geschafft nach Hause.
Wenn die aktuelle Firmware als ausgereizt angesehen werden kann (und das 
wird bald so weit sein, scheint mir) und Hayo sich der Firmware für den 
Leon zuwendet, dann könnte ich mir vorstellen, dass auch dort 
einsatzbereite Versionen nicht mehr allzu weit weg sind...


@Italia

Voi dove avete comprato l'oscilloscopio? Se non riuscite a capire 
qualcoso che sta scritto qua sul sito chiedetemi che ve lo traduco o lo 
spiego. Siccome sono piuttosto occupato al momento dovreste essere un 
po' pazienti comunque.
Mi piace che cominciate a partecipare alla migliorazione del Welec - 
benvenuti!

Michael

[Tony T. (i2tzk)]

Hello Hayo
thanks a million for the time you're dedicating to improve the W20xx, 
you're doing an excellent job.

I would like to use the dso as a data collection device connected to the 
pc.
I saw the original W2000A.exe from Welec but it seems not able (when it 
works !!! hihihi) to real time acquire a data stream from the dso.

I read the command list available from the serial interface, so I've a 
couple of stupid questions:

1. do you have any doc about the command: "Shift+u" and "shift+p" ?
2. does exist a command to obtain a contiuous sample data stream from a 
channel ?
3. are those commands available also from the USB interface?

Thank you from your Italian friend, ciao Tony

[Gyppe (Gast)]

Ok Hayo happy holidays:)

Thanks for the welcome Hayo and Michael:)

Hello, Gyppe.

[Blue F. (blueflash)]

Tony Tony schrieb:
> Hello Hayo
> thanks a million for the time you're dedicating to improve the W20xx,
> you're doing an excellent job

:-)

> I would like to use the dso as a data collection device connected to the
> pc.

There are available the screenshot function which allows you to send 
ascii data via RS232 and the FFT-screener - infos on our Source Forge 
Net project page

> I saw the original W2000A.exe from Welec but it seems not able (when it
> works !!! hihihi) to real time acquire a data stream from the dso.

original WELEC software is not compatible to the open source versions!

> I read the command list available from the serial interface, so I've a
> couple of stupid questions:
>
> 1. do you have any doc about the command: "Shift+u" and "shift+p" ?

No, but I will check this inthe next time...

> 2. does exist a command to obtain a contiuous sample data stream from a
> channel ?

Not at this time, but maybe in future
> 3. are those commands available also from the USB interface?

At this time there is no USB support because of not existing 
PC-Applications which support USB.

> Thank you from your Italian friend, ciao Tony

Kind regards from Merano in Italy

Hayo

p.s. cool, WLAN is for free on this camping place

[Michael D. (mike0815)]

...ha, der Hayo macht Camping...bei dem schönen Wetter.

Ich hätte da mal einen Vorschlag zu machen:
Wie wäre es denn mal eine schicke bebilderte Betriebsanleitung für die 
Welec DSO's zu basteln?
Ich denke da an eine deutsche sowie englische Version.
Als Anfang ein paar grobe Entwürfe und dann mal sehen, wie es sich 
gestalten lässt...

Damit der Thread hier nicht völlig überläuft, könnte man extra dafür 
einen Neuen auf machen, wäre das eine Idee???

Gruß Michael

[egberto (Gast)]

Gute Idee - wie wärs mit einem Wiki, da könnten alle leicht mithelfen??

Viele Grüße,

egberto

[Michael D. (mike0815)]

das ist eine gute Idee, wenn das Ding fertig ist, könnte man noch eine 
schicke PDF draus machen!
Für den Anfang, wie es im SF schon beschrieben ist, die technischen 
Daten, Funktionsumfang, Belegung der Softkeys, Knoppfunktionen und die 
Einstellmöglichekeiten, Tastköpfe und deren Abgleich, Modding, 
Modifizierungsmöglichkeiten der Hard-und Software etc...
au man, ist schon jede Menge Zeug!
Gruß Michael

[Cra Z. (crazor)]

Moin Leute,
moin Guido,

ich bin durch Google mal wieder hier gelandet, weil ich auf der Suche 
nach einer Part-Definition für UrJTAG bin für den EP2C35.
Du scheinst da was gebastelt zu haben, Guido, ist das irgendwo abrufbar? 
Würde mich sonst über eine Mail mit der Datei freuen.

Grüße

Daniel

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Hallo,

Für alle die nur diesen SW-Thread lesen...

Ein HW-Umbau-Anleitung für Akku-Betrieb
Beitrag "Wittig(welec) DSO W20xxA Umbau Akku-Betrieb"

Wäre es nicht sinnvoll einen Artikel zu machen wo man die aktuellen 
Funktionen/Links/Stand usw. zusammenfasst. Diese Threads durchzuackern 
ist doch recht mühsam.

Grüße Markus.

[alex008 (Gast)]

Hallo!

Eine Dokumentation ist beim Leon3-Design sicher absolut nötig!
Es wird sicher noch ein weilchen Dauern bis ich damit anfange, weil ich 
ungern Dinge dokumentiere, die ich noch nicht getestet habe.

Genauso wichtig wie die Dokumentation ist die Umstrukturierung der 
Verzeichnisstruktur von der Software, die Daniel federführend 
vorantreibt, da ich die Oszilloskop-Firmware anfangs nicht für eine GUI 
schrieb, sondern nur um mein FPGA-Design zu debuggen.

Mittlerweile läuft der neue SRAM-Controller relativ zur 
Taktgeschwindigkeit 3x beim Lesen schneller und 3/2 beim 32 Bit 
schreiben und 3/4 so schnell mit read modify write schreiben (16 und 8 
Bit).

Im Moment kümmere ich mich um den 16 Bit Mode, mit dem sehr kleine 
Signale bei niedriger Abtastrate mit eingeschaltenen HW-Filter zu sehen 
werden sollten. Ob man dann vorallem interne Störsignale sieht oder 
nicht, wird sich weisen. In der Software habe ich mal 10µV/div 
vorgesehen.

MfG
Alexander

[Tony T. (i2tzk)]

Hayo, thanks for the answer
I'm studing to write a gui to command the dso from the pc.
This is the reason I need some doc, the "Remote Control Protocol" or 
"USB protocol" page on sourge forge seem to be not updated and commands 
like "shift+p" etc. are not listed there.
So if you have some preliminary doc please pvm to me.
No problem abt the RS232 or USB from the pc point of view it is just 
matter to properly select the port also if the speed can be quite 
different.

I'm very interested in using the FFT analysis, is it possible to add a 
"center" function as it was listed int the original welec user manual, 
so we can simulate the "center" & "span" commands of an analogic 
spectrun analyzer?

I'll keep you informed.
ciao,Tony

[Rolf W. (rowue)]

Tony Tony schrieb:
> Hello Hayo
> [...]
>
> 1. do you have any doc about the command: "Shift+u" and "shift+p" ?
> 2. does exist a command to obtain a contiuous sample data stream from a
> channel ?

At least in the OS series of the firmware there was an
possibility using an "extended command"

This was issued sending 0x02 and 'E' to the scope. Perhaps
it also has found it's way into the BF-Series. For further
information you may look at the fft-screener which uses this
feature AFAIR

> 3. are those commands available also from the USB interface?
>
> Thank you from your Italian friend, ciao Tony

Kind reg's,

  rowue

[Rolf W. (rowue)]

Tony Tony schrieb:
> Hayo, thanks for the answer
> I'm studing to write a gui to command the dso from the pc.
> This is the reason I need some doc, the "Remote Control Protocol" or
> "USB protocol" page on sourge forge seem to be not updated and commands
> like "shift+p" etc. are not listed there.

Hi Tony,

you might take an look at the FFT-Screener or try to contact
"brunowoe" - he has already done some work on this issue....

> [...]
>
> I'll keep you informed.
> ciao,Tony


Kind reg's,

    rowue

[Guido (Gast)]

Hallo,

back from Italy, wie sieht es bei dir aus Hayo?

@ crazor: Hier ein Link.

http://bsdl.info/view.htm?id=941

Grüße, Guido

[Antonio (Gast)]

Hi,
Only like information.
After of the FFT's intensive use I noticed with my equipment (W2012A 
with 1.2.BF.1.4) if I return in normal view the DSO do reset (all LED 
bright and after show logo screen).
After this there are no track on the display and is necessary to switch 
OFF and ON to fix so the track are visible again.
The setting seems no be lost, only the tracks appears to be a bit out of 
zero, all settings appear to have been maintained.
Sometimes the FFT function does not work then reset occurs on return to 
normal operation.
Thanks in advance.

[Blue F. (blueflash)]

Rolf W. schrieb:
> Tony Tony schrieb:
>> Hello Hayo
>> [...]
>>
>> 1. do you have any doc about the command: "Shift+u" and "shift+p" ?
>> 2. does exist a command to obtain a contiuous sample data stream from a
>> channel ?
>
> At least in the OS series of the firmware there was an
> possibility using an "extended command"
>
> This was issued sending 0x02 and 'E' to the scope. Perhaps
> it also has found it's way into the BF-Series. For further
> information you may look at the fft-screener which uses this
> feature AFAIR


In the actual BF.1.4 the remote interface should work as in the 
OS-version - but I did not test it. So You have to check out if it is 
working as it should. Let me know if it does!

Kind regards from Merano

Hayo

[Blue F. (blueflash)]

Antonio schrieb:
> Hi,
> Only like information.
> After of the FFT's intensive use I noticed with my equipment (W2012A
> with 1.2.BF.1.4) if I return in normal view the DSO do reset (all LED
> bright and after show logo screen).
> After this there are no track on the display and is necessary to switch
> OFF and ON to fix so the track are visible again.

Hmm, I never had this problem. Is it a special sequence of actions which 
force the reset? Is it reproducible?


> The setting seems no be lost, only the tracks appears to be a bit out of
> zero, all settings appear to have been maintained.
> Sometimes the FFT function does not work then reset occurs on return to
> normal operation.

I will check it after my holidays.

Kind regards Hayo

[Blue F. (blueflash)]

Guido schrieb:
> Hallo,
>
> back from Italy, wie sieht es bei dir aus Hayo?

Hi, bin noch dabei hier in Südtirol meinen Moppedreifen abzufräsen. 
Heute stand die Sella Gruppe auf dem Programm. Bin am Freitag wieder im 
Lande und werde mich dann mal wieder an die Arbeit machen. Geht ja nicht 
an, dass da irgendwas an der FFT klemmt...   ;-)

Gruß Hayo

[Michael H. (Gast)]

Na dann noch einen schönen Urlaub - hoffentlich hast du mehr Glück mit 
dem Wetter als ich es in meinen fünf Tagen gerade hatte!

[Antonio (Gast)]

Hayo W.
Hmm, I never had this problem. Is it a special sequence of actions which
force the reset? Is it reproducible?

Hallo.
The problem is sporadic, seems to occur after using the FFT, if you 
return to normal operation and you change the volts/div sometimes the 
DSO do a reset.
Other sometimes the FFT function does not work and returning to normal 
operation the DSO do a reset also.

Hayo W.
I will check it after my holidays.

Thank you very much!

[Guido (Gast)]

Ohoh Hayo,

bist du auch so ein Typ mit HH, der mit dem Wohnmobil und
hintendrauf gebundenen Motorrad mit 40 km/h über den
Fernpass schleicht und die nachfolgenden Fahrer in den
Wahnsinn treibt? Jedenfalls wünsche ich dir eine gute Fahrt,
nach den Vorhersagen bringst du die Sonne mit: nur immer
zu :-). Ich habe mir durch den Temperatursturz eine fette
Erkältung zugezogen.

Gruß, Guido

[Roberto (Gast)]

Hallo Hayo (Schönen Urlaub noch :-)

Ich habe gerade meinen Logik-Analyser bekommen und wollte mal die Zeiten 
zwischen zwei Flanken vergleichen.
Da ist mir aufgefallen, dass das DSO bei bestimmter Eintellung falsch 
misst!
(Messung mit Cursor-Funktion)

Z.B. Einstellung am DSO:  5MSa/s 50us (Spannung 1V/div)
Flanke zu Flanke sind es 194us.

Wenn ich mit der 50uS-Einstellung messe, stimmen die Zeiten mit dem 
Logik-Analzer überein.
Jetzt kann ich aber am DSO im Stop-Modus, die Zeit mit dem Drehrad noch 
auf 20us verstellen. Hier zeigt es mir dann aber 97us zwischen den 
beiden Flanken an!!! :-(

l.G. Roberto

[Joe (Gast)]

Hi,
ich werde das selbst nie verwirklichen können, aber könnte man nicht 
über die serielle Schnitstelle des Scopes einen komerziellen oder 
selbstgebauten Signalgenerator ansteuern und die Software damit um einen 
VNA zu erweitern?
Grüße und schöne Pfingsten

[Falk (Gast)]

Joe schrieb:
> ich werde das selbst nie verwirklichen können, aber könnte man nicht
> über die serielle Schnitstelle des Scopes einen komerziellen oder
> selbstgebauten Signalgenerator ansteuern und die Software damit um einen
> VNA zu erweitern?

Dazu müßte sichergestellt sein, daß Code von anderen Entwicklern als 
Hayo in das Projekt eingehen kann. Das ist nicht der Fall. Gründe können 
in diesem Thread und seinem Vorgänger nachgelesen werden.

Falk
Kein Zeitraffer: http://www.youtube.com/watch?v=5tb16NtTws0

[Roberto (Gast)]

Hallo Joe
Für einen VNA vielleicht eher sowas.. Kann dann auch höhere Frequenzen .
http://www.pukshofer.com/Privat/Projekte/VNWA/Hauptseite.htm
l.G. Roberto

[Blue F. (blueflash)]

Guido schrieb:
> Ohoh Hayo,
>
> bist du auch so ein Typ mit HH, der mit dem Wohnmobil und
> hintendrauf gebundenen Motorrad mit 40 km/h über den
> Fernpass schleicht und die nachfolgenden Fahrer in den
> Wahnsinn treibt?

Ach Du liebe Zeit nein, das wäre ja die Höchststrafe. Hab mich oft genug 
selbst geärgert. Meine Möhre fährt im Wohnwagen mit (spezielle 
Ausführung zum Transportieren von Motorrädern). Und damit das Ganze auch 
voran geht hängt davor ein S4 Quattro mit 4,2 Liter V8 und 350 PS. Damit 
kommt man auch im 6. Gang noch jede Steigung mit 100 Sachen hoch 
(einfach Tempomat rein...). Also aufatmen für die Mopedfahrer...

Zum Programmieren bin ich heute noch nicht gekommen, es dauert halt doch 
etwas bis alles wieder geordnet läuft.

Hayo

[Blue F. (blueflash)]

Joe schrieb:
> Hi,
> ich werde das selbst nie verwirklichen können, aber könnte man nicht
> über die serielle Schnitstelle des Scopes einen komerziellen oder
> selbstgebauten Signalgenerator ansteuern und die Software damit um einen
> VNA zu erweitern?

Machbar ist das auf jeden Fall. Mir fehlt dazu aber zur Zeit das 
Praxis-Knowhow in Sachen VNA um da jetzt geziehlte Ideen anbieten zu 
können.

Gruß Hayo

[Blue F. (blueflash)]

Falk schrieb:

> Dazu müßte sichergestellt sein, daß Code von anderen Entwicklern als
> Hayo in das Projekt eingehen kann. Das ist nicht der Fall.

Wo ist das Problem? Die OS-Version und auch die aktuelle BF-Version sind 
eine Gemeinschaftsaktion von diversen Entwicklern hier im Thread bzw. im 
SFN. So habe ich seit der BF.0.98 auch Deine Remoteschnittstelle in der 
aktuellen Fassung übernommen oder als anderes Beispiel die neue 
Triggerung von Stefan eingebaut. Das aktuelle Coding stelle ich gerne 
zur Verfügung damit alle daran rumschrauben können, nur wollte ich das 
lieber als eigenen Branch einstellen um nicht die aktuellen 
OS-Entwicklungen durcheinander zu bringen.

Ich bitte die BF-Versionen nicht als Konkurenz zur OS-Version zu sehen, 
sondern als Möglichkeit für mich Einfluß darauf zu nehmen welche 
Änderungen für mich selbst sinnvoll sind oder nicht.

Auch die Rückmeldungen der italienischen Kollegen sehe ich als Chance 
hier gemeinschaftlich weiterzukommen.

Gruß Hayo

[Bert (Gast)]

Hallo Leute,

bei meinem W2024 funktioniert die externe Triggerung nicht.
Firmware: 1.2.BF.1.4.
Bei Ext.-Line-Triggerung bekomme ich bei 100Hz Rechteck ein stehendes 
Bild.
Bei Ext-HF und Ext.-LF erfolgt keine Triggerung, egal bei welchem Pegel, 
auch nicht wenn ich das Rechteck-Signal über einen DC-Pegel verschiebe.
Hat jemand ähnliche Probleme oder einen Vorschlag?

Gruß Bert

[Robert S. (razer)]

Hallo Leute,

auch wenn wir Entwickler hier im Forum nicht so aktiv sind, wir arbeiten 
weiter. Unsere Diskussionsplattform ist Skype - aus dem einfachen Grund, 
dass keine Latenzzeiten wie zB aus dem Forum vorhanden sind!!

Da wie vom Leon Design in letzter Zeit große Probleme mit SVN von 
Sourceforge hatten sind wir auf Git umgezogen. Mit Git ist nun Branching 
und Merging kein Thema mehr - denn das funktioniert perfekt - im 
Gegensatz zu SVN.

Hier das Repository von Crazor: http://github.com/Crazor/welecw2000a

Der neue Speichercontroller von Alex funktioniert sehr gut und hat viele 
Probleme gelöst.

Im Anhang könnt ihr eine Screenshot sehen. Danke der super 
Screenshotroutine von Kurt ist ein Farbscreenshot unter 5 Sekunden 
möglich (bei einer Baudrate von 115k2). Das funktioniert bereits aus der 
Firmware heraus in Kombination mit dem Waverecorder.

Das Leon Design hat auf jeden Fall noch viele Reserven und wir (das Leon 
Team) würden uns freuen neue Entwickler begrüßen zu können.

Grüße und schöne Pfingsten
Robert

[egberto (Gast)]

@Bert (und natürlich Hayo)

kann ich bestätigen, bei mir läuft das Bild auch....
Das Problem trat bei mir auch erst auf, nach dem ich auf Kanal 2 
triggern wollte (triggern auf Kanal 1 war bis dahin ok), dann triggerte 
er auf Kanal 1 auch nicht mehr.... (TTL Rechteck 2 MHz)

Viele Grüße,

egberto

[Michael D. (mike0815)]

Hi Robert,

Ich habe mal den Source auf eurer Seite herunter geladen und habe unter 
Anderem, eine ----W2000A.sof---- ausfindig gemacht(siehe Screenshot)!
Kann diese geflasht werden und brauche ich noch eine sram.bin?

Gruß Michael

EDIT: Jetzt habe ich noch eine sram.bin neueren Datums entdeckt!

...geht da was, mit dem aufspielen(Waverecorder)

noch mal Gruß

[Robert S. (razer)]

Hallo Michael

Michael D. schrieb:
> Ich habe mal den Source auf eurer Seite herunter geladen und habe unter
> Anderem, eine ----W2000A.sof---- ausfindig gemacht(siehe Screenshot)!

Das ist das aktuelle FPGA-Desgin mit dem neuen Speichercontroller.

Eine firmware.bin benötigst du immer noch. Derzeit ist keine aktuelle 
auf der Sourceforgeseite. Weder vom Waverecorder noch der Leon-Firmware.

Ich habe heute eine Anleitung für das Aufsetzen der Toolchain unter 
Windos geschrieben: 
https://sourceforge.net/apps/trac/welecw2000a/wiki/ToolchainWindows

Damit hat sehr schnell ein das ganze aufgesetzt um den Waverecorder als 
auch die Leon Firmware zu erstellen.

Grüße Robert

[Kurt B. (kurt)]

Jetzt sind eine w2000a.bin und der waverecorder.exe auf SF verfügbar.

https://sourceforge.net/apps/trac/welecw2000a/wiki/Leon%20Binaries


W2000A.sof:
http://github.com/Crazor/welecw2000a/raw/master/fpga/leon3/Scope/synW2000A/W2000A.sof

[Blue F. (blueflash)]

@Bert

Die externe Triggerung steht bei mir als einer der nächsten Punkte auf 
der Liste. Zugegebenermaßen habe ich die externe Triggerung noch nie 
ausprobiert. Ich meine aber mich erinnern zu können, dass die noch nie 
funktioniert hat (weder in den original Welec Versionen und zwangsläufig 
auch nicht in den Open Source Versionen die ja von der originalen 1.2 
abstammen).

Alle bisherigen Triggeroptimierungen waren nur für den internen Trigger.

Gruß Hayo

[Michael D. (mike0815)]

Ich habe mal das Batchfile für den Waverecorder angepasst, sonst läuft 
der ja nicht an!

Die ---sram.bin--- heißt hier ---w2000a.bin---

Es müsste nur noch der Comport angepasst werden,
in meinem Fall ist das COM 1 mit 115200 Baut.

Jetzt haben wir hier mehrere Waverecorder mit verschiedenen Dateigrössen 
zur Auswahl
Ich nehme mal an, das die mit 630kb vom 21.05.2010 die Aktuelle ist ?1?

Gruß Michael

[Kurt B. (kurt)]

Hallo Michael,
wenn du die zip Datei vom 22.05.2010 meinst, die ist ziemlich auf dem 
neuesten Stand. Flimmerfrei und mit Screenshot Unterstützung im BMP 
Format.

Mfg,
Kurt

[Michael D. (mike0815)]

Hi Kurt,

ich habe die Files von deinem Link, die da heißt:---22052010.zip---
...da ist auch der Waverecorder drinnen!

Gestern habe ich das neue Leon3 aufgespielt, funzte auch einwandfrei...

...eben hatte ich es noch mal aufgespielt und jetzt hängt sich das DSO 
ständig auf und nix geht mehr!
Kann es sein, das da noch Reste im Ram sind und da Konflikte verursacht?

Ansonsten stellt Kanal 2, trotz selbiger Einstellung wie Kanal 1 
(200mV/Div) das Signal (ProbeComp)nicht korrekt dar, siehe Foto.

Gruß Michael

EDIT: Die Screenshotroutine arbeitet mit dem Waverecorder? Wenn ja, 
wären das die korrekten Parameter für die Batch?

---WaveRecorder -u com1 -b 115200 -n 2 -Capture

[Torsten W. (wirehead)]

Die Drehgeber für scroll, triggerlevel usw sind auch noch etwas 
unentschlossen wenn man daran dreht.
Ansonzten schon ganz nett!

[Michael D. (mike0815)]

Hi,
Betreff Leon3: Kann man die Signale (Nulllinie) nicht verschieben? Beim 
Spannungswechsel sind diese zu weit oben, und Kanal 2 zu weit unten, 
oder ist das noch in der Mache?

Ich bekomme das mit der Screenshotroutine nicht gebacken, der 
Waverecorder geht gleich wieder zu...wie sehen denn die Strings in der 
Batchdatei aus?

WaveRecorder -u com1 -b 115200 -n 2 -p Debugger -c Capture 
--WFile=screenshot001.bmp---

Ich denke mal, das diese nicht korrekt ist!

Ansonsten ist hier eine super Leistung erbracht worden und möchte an 
dieser Stelle mein Lob an die Macher aussprechen!!!

Gruß Michael

[Robert S. (razer)]

Michael D. schrieb:
> Betreff Leon3: Kann man die Signale (Nulllinie) nicht verschieben? Beim
> Spannungswechsel sind diese zu weit oben, und Kanal 2 zu weit unten,
> oder ist das noch in der Mache?

Ist derzeit noch nicht implementiert. Kommt aber noch. Derzeit schauen 
wir gerade, dass der DAC funktioniert.

Michael D. schrieb:
> Ich bekomme das mit der Screenshotroutine nicht gebacken, der
> Waverecorder geht gleich wieder zu...wie sehen denn die Strings in der
> Batchdatei aus?
>
> WaveRecorder -u com1 -b 115200 -n 2 -p Debugger -c Capture
> --WFile=screenshot001.bmp---

Der Aufruf ist leider falsch. Das Screenshotkommando ist leider nicht in 
der Hilfe. Mea Culpa!

Folgender Aufruf ist richtig:
Waverecorder -u com1 -b 115200 -n 2 -p CPU -c Screenshot -f <filename>

Ich bin derzeit gerade dabei den ganzen Waverecorder umzubauen um die 
Bedienung zu erleichten. Dann ist es einfach möglich mit Waverecorder 
--screenshot einen Screenshot zu machen.

Grüße aus Österreich
Robert

[mike0815 (Gast)]

Hallo Robert,

Folgender Aufruf ist richtig:
Waverecorder -u com1 -b 115200 -n 2 -p CPU -c Screenshot -f <filename>

Na klasse, da kann ich ja lange suchen, trotzdem danke!
Werde das mal testen, wenn ich wieder Daheim bin...

Gruß Michael

[mike0815 (Gast)]

ich noch mal,

also ich könnte mit der Stapelverarbeitung leben, wenn alle Commands zur 
Verfügung stehen und funktionieren, ist das auch ok!

Noch mal zum Leon3 !
Bei 200mV/Div ist ja, im Vergleich zur jetzigen Software, das Rauschen 
enorm niedrig.

Kann es sein, das auch noch nicht alle Spannungsbereiche zur Verfügung 
stehen? Geht ja runter bis in den µV/Div Bereich.


Gruß Michael

[Robert S. (razer)]

mike0815 schrieb:
> also ich könnte mit der Stapelverarbeitung leben, wenn alle Commands zur
> Verfügung stehen und funktionieren, ist das auch ok!

Ist schon alles umgebaut. Wird noch getestet. Aber generell wurde es 
verwinfacht. Waren einfach zu viele Parameter für einfache Kommandos.

mike0815 schrieb:
> Noch mal zum Leon3 !
> Bei 200mV/Div ist ja, im Vergleich zur jetzigen Software, das Rauschen
> enorm niedrig.

Danke für die Rosen. Gebührt natürlich Alexander!

mike0815 schrieb:
> Kann es sein, das auch noch nicht alle Spannungsbereiche zur Verfügung
> stehen? Geht ja runter bis in den µV/Div Bereich.

Daran wird gerade gearbeitet. Bei langsamen Signalen wird das Signal auf 
16-Bit hochgesampelt um auch sehr kleine Spannungen messen zu können.

Grüße Robert

[Michael D. (mike0815)]

Hallo Robert,

Robert S. schrieb:
> Ist schon alles umgebaut. Wird noch getestet. Aber generell wurde es
> verwinfacht. Waren einfach zu viele Parameter für einfache Kommandos.

verwinfacht?


Die Screenshotfunktion funzt einwandfrei, man kann immer nur einen Shot 
machen den man jedes mal manuel umbenennen muß sonst wird der nächste 
Shot überschrieben!
Ich habe mal eine Batchroutine gebaut.
Es können damit 10 Shots nacheinander mit fortlaufender Nummer gemacht 
werden!
Die Parameter sind Com1 und 115200 Baut.
Wer einen anderen Comport hat(z.B. Com2 oder 3), muß diesen angleichen!
Ein kleiner Beitrag von mir für dieses Projekt.

Der erste Shot ist ohne Filter, der 2. mit eurem HW-Filter.
Da wurde einiges geleistet, unglaublich was da möglich ist!!!

Anbei noch meine gebaute Batch.

Gruß Michael

[Robert <razer6> (Gast)]

Michael D. schrieb:
> Die Screenshotfunktion funzt einwandfrei, man kann immer nur einen Shot
>
> machen den man jedes mal manuel umbenennen muß sonst wird der nächste
>
> Shot überschrieben!

schon Behoben. Mann kann in Zukunft einfach mit Waverecorder 
--screenshot (defaultname, falls vorhanden wird die nr erhöht) oder mit 
--screnshot <filename> erzeugen.

Gruß Robert

[Michael D. (mike0815)]

Hi Robert,

wie ich sehe, -- http://github.com/Crazor/welecw2000a --

seid ihr weiterhin fleißig am Programmieren vom Leon3.
Wann kann man denn mit einem neuen Testfile rechnen? Für eine Beta ist 
es ja wohl noch zu früh.

Gruß Michael

[Blue F. (blueflash)]

Hi there,

mal wieder was Neues aus der Nios Firmware Ecke. Hier die neue 1.5 mit 
einigen Verbesserungen:

- optimierte Flashsicherung für den Configbereich
- neue RMS Berechnung beim Quick Measure

Die neue Routine ist etwas langsamer als die Alte da sehr viel gerechnet 
wird. Dafür wird jetzt der Effektivwert beliebiger Signalformen 
berechnet
und nicht wie vorher nur für Sinus. Etwas Optimierungspotential in 
Sachen Geschwindigkeit wäre da noch wenn man einige Multiplikationen 
durch Schiebeoperationen ersetzt, hatte ich aber momentan keine Zeit zu.



For our non german speaking friends:

- optimized flash writing for the config data
- new RMS calculation for Quick Measure

The new routine is a little bit slower because of the additional 
calculations. The benefit is that now for every signal form the RMS kann 
be measured and not as before only for sinus. The speed may be increased 
by exchanging the multiplications with shift operations, but I didn't 
had the time for that.

Thanks at this place to Alessandro (Scroky) for the tip with the wrong 
RMS calculation.

The download is also available here:

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


Hayo

[Luc (Gast)]

Hi to all.
Thank you very, very much Hayo!
I run to try your new gem,Hayo you are really very kind and great!!!
Vielen Dank!!!

Luc

[Michael D. (mike0815)]

Hi Hayo,

habe eben mal deine 1.5er aufgesetzt und ein bißchen gespielt.
Hast du da was an der Timebase geschraubt?
Die erste Flanke bleibt immer schick an einer Stelle.
Habe gesehen, das der Browser sich da automatisch mit 
einpendelt...saubere Sache!
War das bei 1.4 schon der Fall?

Gruß´Michael

Ps. ist dein Mikroskrop inzwischen eingetroffen?

[Blue F. (blueflash)]

Hi Michael,

ja nach nur 3 Wochen Wartezeit ist es tatsächlich schon eingetroffen. 
Nach dem Urlaub lag auf einmal eine Benachrichtigung zur Paketabholung 
im Briefkasten. Bei denen geht wohl im Momentalles drunter und drüber 
wegen einer IT-Umstellung.

Aber das Teil an sich ist ganz ok muß ich sagen. Macht echt Spaß damit 
herumzuspielen. Zur Zeit bastel ich gerade an einem alten Mikroskop 
herum und versuche das USB-Mikroskop an das alte Stativ anzubringen um 
den Feintrieb nutzen zu können.

Zur 1.5:

Nein ich hab da soweit ich mich erinnern kann nur an den Flashroutinen 
und der RMS-Geschichte rumgeschraubt. Wer mal in das changelog 
reingesehen hat weiß auch dass ich noch die neue Overlay-Funktion in 
Vorbereitung habe, die ist aber noch nicht aktiv - kommt demnächst.



Gruß Hayo

[Blue F. (blueflash)]

@Luc

I am pleased that You like it - try out the the new RMS function in the 
Quick Measure function and enjoy!!

Hayo

[gyppe (Gast)]

Hayo Thanks again!

Davvero mitico ! :)

For the future version, you can add the ability to maintain the 
configuration of the trigger even after the ladders used or switches to 
USTB?

Bye, Gyppe.

[Michael H. (Gast)]

So jetzt bin ich endlich mal wieder dazugekommen, die aktuelle BF 
Version zu testen. Der letzte Test ist schon einige Versionsnummern her 
und ich muss sagen: seitdem hat sich ordentlich was getan! So gut konnte 
man noch nie mit der Kiste arbeiten, Kompliment und danke an Hayo!
Vor allem die Neuigkeiten im Utility Menü haben machen sich positiv 
bemerkbar, insgesamt fine ich im Moment außer den nervigen Spikes kaum 
etwas auszusetzen.

Viele Grüße
Michael

[Jan F. (jan_f)]

Hi,

I'm new here, my German knowledge is zero.

I am updating the Welec pages at SourceForge.com and I have several 
questions. Is this the right place to post?

[Michael H. (stronzo83)]

I'm sure that your questions will be answered promptly if they are 
related to the opensource firmware.

[Jan F. (jan_f)]

Michael H. schrieb:
> Im sure that your questions will be answered promptly if
> they are related to the opensource firmware.

Hi , well those are actually my first questions, to figure out what 
belongs where. Mentioned on the web site are
GUI
Screenshot
DataExport
Remot Control Protocol
USB protocol

Are these related to the opensource firmware?

[Blue F. (blueflash)]

Hi Jan,

that's correct. The origianal firmware version are not supported by our 
project, because they are so terrible buggy, that it makes no sense to 
spend any time on it. Some guys here around in the forum and on Source 
Forge have developed their own Interface and GUI. The screenshot is 
working well, same as the communication protocol for the RS232.The GUI 
project is still under construction, I think.

Actual I'm developing and testing the USB interface. First success is 
that the WELEC PC-Software now communicates with the 1.2.BF.1.6 version 
which is not released until now.

Kind regards

Hayo

[Blue F. (blueflash)]

Ok Leute,

noch mal auf Deutsch, zur Zeit bin ich gerade an den USB-Routine am 
Rumdengeln. Erster Erfolg: Die Kiste spricht wieder mit der WELEC 
PC-Software. Allerdings sind da noch so viele Bugs drin, dass es wohl 
noch etwas dauert bis ich Euch das zumuten kann. Einige Bugs werde ich 
nicht beseitigen können, da diese auf der Seite der PC-Software liegen. 
Da sich die tolle Software darüber ausschweigt welcher Version sie sich 
angehörig fühlt, weiß ich nichtmal ob meine die Aktuellste ist (Größe 
1168 k).

Desweiteren implementiere ich parallel dazu ein neues USB 
Kommunikationsinterface, auf dem auch die bestehenden Programme wie 
screenshot und GUI aufsetzen können. Beispielprogramme zur Ansteuerung 
lege ich dann bei.

@Michael

Und? ist die Mikroskopsoftware bei Dir angekommen - und läuft sie?

Gruß Hayo

[Jan F. (jan_f)]

Ok, what I am trying to do is to clarify the situation for 
newbies/newcommers: which parts are available and suitable for end 
users, which are in the developers toolboxes.

I think I will make something like a table with three columns, one for 
the original Welec firmware and codes 8for comparison), one for the open 
source firmware (does it have a NAME? the Hayo firmware?) and the third 
being the Leon3 development.

I would try to maintain an overview of what works, what is compatible, 
alpha, beta, buggy, working or whatever. Whatever is considerd ready to 
run by a normal owner with some PC knowledge would be the the top 
priority for me.

Makes sense?

When the 1.2.BF.1.6 has USB support, there is not yet any end user 
software to hook up to that USB on the (PC) side?

[Michael D. (mike0815)]

Hi Hayo,

wenn du die Software von Welec's Seite meinst, das ist die einzige 
Version, die dort existiert!
Die hatte bei mir nur einmal gefunzt, beim nächsten Start, ist die dann 
ständig stehen geblieben, danach hab' ich es gelassen, bevor ich einen 
Hammer in den Bildschirm geschmissen hätte!

Ui, du schraubst am USB? Da bin ich mal gespannt!
Mich würde mal interessieren, was so die Huckepackplatine macht und ob 
der Prototyp schon am laufen ist?!?

Mikrosoftware:
Die habe ich bekommen, hatte dir eine Mail mit einem fetten Dank 
geschickt!
Werde ich evtl. Morgen testen, mußte heute lange Arbeiten.

Gruß Michael

[Jan F. (jan_f)]

One visitor on the SourceForge site wrote about half a year ago a very 
relevant question from a newcommer:

"A lot of files and info here but what does the latest firmware contain? 
Functional FFT? Is the fw fully functional so I can use it instead of 
the original fw?"

Can someone make short summary here that we can also use in the wiki?

[Guido (Gast)]

Hi Jan, it's quite easy: no functinoal firmware is available. :-(

There are two ways at the moment and a half one. Best of all will
be the Leon-Design. But it is still not working for real use, as
far as i know. The developement of firmware for this one is just
starting.

Forget the original firmware of Welec, it is not usable anyway.

The original hardware-design is supportetd by 2 slightly
different firmwares. One ist the BF-version supportetd mainly
through Hayo W (blueflash) and this might be the most
sophisticated version. The last revision of this firmware
should be the starting point for new users.

The second firmware for the original hardware-design is the
so called OS-version at source-forge. But this is somewhat outdated
and seems to be not longer supported. Most of it's developers
can be asked here or at source-forge, they still are online. This
firmware is worth aa try, too.

Kind regards, Guido

[Blue F. (blueflash)]

Jan F. schrieb:
> Ok, what I am trying to do is to clarify the situation for
> newbies/newcommers: which parts are available and suitable for end
> users, which are in the developers toolboxes.

Good idea I think. I thought about an user manual belonging to the open 
source version. But in last time there where too much changes to write a 
valid manual.

> I think I will make something like a table with three columns, one for
> the original Welec firmware and codes 8for comparison), one for the open
> source firmware (does it have a NAME? the Hayo firmware?) and the third
> being the Leon3 development.

The original Firmware is not usable for anything, but nevertheless it 
may be interresting to have a comparison.

> I would try to maintain an overview of what works, what is compatible,
> alpha, beta, buggy, working or whatever. Whatever is considerd ready to
> run by a normal owner with some PC knowledge would be the the top
> priority for me.

The 1.2.OS.0.x versions are basing on older 1.2.BF.0.x versions and 
occasionally where nearly identical because of source exchange between 
both. The versions with the .0.x versions are beta versions, what means, 
that they where better than the original firmware, but there where many 
functions which where still under construction or not tested properly.

While the last OS-version is a little bit older and just in beta status, 
I went on with developing the BF-versions and reached the stable release 
status (BF.1.x) That means that most functions are working well and are 
usable for anyone.

There are still some little bugs and some functions (as USB and FFT) are 
under construction, but I think that's the normal way of software 
developing.

Most important is the support we (the guys here and I) can offer to any 
user who has problems with his DSO. If the problem is solvable it will 
be solved as soon as possible.  And if it is not solvable - it may take 
a little bit longer ;-)

> Makes sense?
indeed
> When the 1.2.BF.1.6 has USB support, there is not yet any end user
> software to hook up to that USB on the (PC) side?

In the first step I try to support the original PC-Software which was 
supplied by WELEC/Wittig and to repair the interface communication which 
is a relic of the WELEC 1.2 Firmware on which all open source 
development bases.

Simultaneous I am developing an own communication protocol for an own 
open USB-Interface. For this I will supply some templates under Linux 
and Windows which can be used by other developers to create new 
applications.


Kind regards

Hayo

[Jan F. (jan_f)]

I started making the overview table at SourceForge. Please send me 
comments and additions! My idea is to place most links that are now 
further down on the page, into the table later.

- Is the 1.2.BF.0.x worth mentioning there?
- Whatever the shortcomings, the latest 1.2.BF.1.X is the "recommended" 
version?
- I am also updating the pages on Screenshot, GUI etc, one at a time....

[Blue F. (blueflash)]

Jan F. schrieb:
> I started making the overview table at SourceForge. Please send me
> comments and additions! My idea is to place most links that are now
> further down on the page, into the table later.

Good idea

> - Is the 1.2.BF.0.x worth mentioning there?

that are the older beta versions. Details can be seen in the change log 
which is supplied with every new version. Those versions are only used 
for comparing when searching for mystery failures in newer versions 
which didn't appear in earlier versions.

> - Whatever the shortcomings, the latest 1.2.BF.1.X is the "recommended"
> version?

At this time I would say yes, but maybe the OS-Version will be brought 
up to date in future...

> - I am also updating the pages on Screenshot, GUI etc, one at a time....

Until now there is nothing new (as far as I know), but be aware that 
there are also existing two screenshot versions with different handling. 
The actual BF-versions are supporting both! The OS-Version is a little 
bit faster, because of an more efficient compression algorithm.

One of the first USB applications I'm planning to create, is an 
USB-screenshot version, which may be much faster than the RS232 
versions.

In the next time I want to experiment on a Visual C++ GUI to use the USB 
Interface. This will be available as template as well.

Kind Regards

Hayo

[Jan F. (jan_f)]

I am now pointing the SF BUTTON to BF.1.6 (as I did not think it was 
appropriate to have developers files there). I saw the stats of 150 
weekly downloads and I do not think all those are developers? I could 
change the text to "Recommended Firmware Version" and let "you guys" 
decide which one this is. I am too much on the outside to have an 
opinion and I do not want to cause any friction or whatever. Just trying 
to help newcomers get moving.

If someone goes to SF, searches, downloads the latest firmware package 
they should imo be helped to the right web pages, to the uploader apps. 
So I'd recommend a readme file with a link to the first page of the wiki 
and to the SF forum. I will make links onward from there. OK?

[Jan F. (jan_f)]

SF repository; somehow I can change everything except the PC-Software 
subdirectory. So I created a new one named PC software and uloaded the 
files there. Can someone please delete the PC-Software library. I do not 
have the rights there...

[Jan F. (jan_f)]

SF: I am updating the Screenshot wiki page. Unfortunately there is no 
review system so I am editing the live version.

Some questions for the wiki page

- There is a firmware softbutton on the scope for BF / OS but with 
1.2.BF.1.5 I only get screenshot 0.91 working with the OS mode? Normal?

- There are four soft buttons on the scope, but it seems ascii / csv and 
bitmap mode are actually controlled by Screenshot? Does the FV actually 
toggle between the four modes and does screenshot handle them all?

- I ran the exe on XP/32 Does it run on other OS too?


(- I know this is an early version but I miss some communication 
verification both from PC and firmware (ie screenshot saying, "Scope 
connected" when started and scope saying "Transferring" when softbuttons 
have been pushed. Now I had some trouble with comms an never new if it 
was dead or alive.)

[Rolf W. (rowue)]

Jan F. schrieb:

Hi Jan,

> SF: I am updating the Screenshot wiki page. Unfortunately there is no
> review system so I am editing the live version.

There is an nice little button which says: "Preview Page" - I think,
you can estimate it's meaning.

>
> Some questions for the wiki page
>
> [BF.1.5]

For your information about the OS series of the firmware:

 in sommer last year branadic discovered, that the DSO produces some
ringing on higher frequencys (a few MHz) and amplitudes. Falk discovered 
that this was caused by an wrong filter setting in the firmware.

This error is only corrected in the OS series of the firmware.

For the screenshot you must have a corresponding version of screenshot 
to the firmware. So screenshot 0.90 will not work with OS 0.91 or 
0.92(a).

(For history: the 0.92a was a bugfix to 0.92)

Kind regards,

    rowue

[Blue F. (blueflash)]

Rolf W. schrieb:
> Jan F. schrieb:
>
> Hi Jan,
>
>
>  in sommer last year branadic discovered, that the DSO produces some
> ringing on higher frequencys (a few MHz) and amplitudes. Falk discovered
> that this was caused by an wrong filter setting in the firmware.
>
> This error is only corrected in the OS series of the firmware.

That's not correct! In the BF-versions You have the option to choose 
between different filter settings -> hardware menu->ADC Setting

Hayo

[Blue F. (blueflash)]

Jan F. schrieb:

> - There is a firmware softbutton on the scope for BF / OS but with
> 1.2.BF.1.5 I only get screenshot 0.91 working with the OS mode? Normal?

Maybe that some interfaces (USB->RS232) may cause some problems with one 
of the versions.

> - There are four soft buttons on the scope, but it seems ascii / csv and
> bitmap mode are actually controlled by Screenshot?

The BF-version is controlled by the scope, so it can be started with few 
parameters. The OS-version is controlled by parameters on the PC-side. 
So the Softbuttons have limited function here.

> - I ran the exe on XP/32 Does it run on other OS too?
Linux is supported as well

> (- I know this is an early version but I miss some communication
> verification both from PC and firmware (ie screenshot saying, "Scope
> connected" when started and scope saying "Transferring" when softbuttons
> have been pushed. Now I had some trouble with comms an never new if it
> was dead or alive.)

The BF-version informs You via console messages when it is receiving a 
screenshot.

Hayo

[Mr. Neumalklug (Gast)]

In der Mai-Ausgabe der Elektronikpraxis, in Teil 3 zu Grundlagenwissen 
Oszilloskop nachzulesen:

Zitat:
"Die beiden Triggermodi

Der Triggermodus bestimmt, ob das Oszilloskop ein Signal auf der 
Grundlage eines Signalzustands darstellt oder nicht. Gängige Triggermodi 
sind:

* Normalmodus: Das Oszilloskop erzeugt nur dann eine Darstellung des 
Signals, wenn das Eingangssignal den Triggerpunkt erreicht. Anderenfalls 
ist der Bildschirm leer oder auf dem zuletzt erfassten Signal 
eingefroren.

* Auto-Modus: Im Auto-Modus stellt das Oszilloskop auch dann ein Signal 
dar, wenn kein Trigger anliegt. Wenn kein Signal vorhanden ist, triggert 
ein Zeitgeber im Oszilloskop die Ablenkung. Dies gewährleistet, dass die 
Anzeige nicht ausgeblendet wird, wenn das Signal keinen Trigger 
auslöst."

Die drei Artikel zum Thema: Grundlagenwissen Oszilloskope

Teil 1:
http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/252618/

Teil 2:
http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/255168/

Teil 3:
http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/258115/

Wollt ich nur beitragen, da es dazu ja mal eine Diskussion gab.

[Blue F. (blueflash)]

Mr. Neumalklug schrieb:

> Wollt ich nur beitragen, da es dazu ja mal eine Diskussion gab.

Klasse, das ist ein guter Tip. Eigentlich könnte man das in ein Manual 
für das WELEC mit aufnehemen. Denn in dieser Preisklasse sind bestimmt 
etliche Neueinsteiger unter den Besitzern.

Gruß Hayo

[Jan F. (jan_f)]

Hayo W. schrieb:
> The BF-version is controlled by the scope, so it can be started with few
> parameters.

I use BF.1.6 and it seems both screenbuttons and commandline works with 
Screenshot 0.91 but it worked with the softbutton set to OS, not when 
setting it to BF (USB-serial cable)

Anyway, the wiki page is updated now. Let me know if additions / changes 
are needed.

[Michael D. (mike0815)]

...wo hat denn der Jan F. die BF 1.6 her, hab' ich da was verpasst???

Gruß Michael

[Jan F. (jan_f)]

Sorry, typo. I have 1.2.BF.1.5

[Jan F. (jan_f)]

Thanks Rolf and others,

What I meant by review was to be able to have you look at a version 
before posting it. I am aware of the Preview.

Is there a relation also between the BF version and screenshot version?
I'm just trying to get rid of the frustrations these things may cause 
for end users. I have added a footnote about versions but will make it 
clearer.

[Blue F. (blueflash)]

Jan F. schrieb:

> Is there a relation also between the BF version and screenshot version?
> I'm just trying to get rid of the frustrations these things may cause
> for end users. I have added a footnote about versions but will make it
> clearer.

to avoid such problems, I distribute the corresponding PC-addons with 
the released versions in one package.

It is recommended to use those versions from the package. Maybe other 
versions are working as well but it is not tested.

@all

noch mal in Deutsch:

Um Kompatibilitätsprobleme zu vermeiden, lege ich die passenden 
PC-Anwendungen immer mit ins freigegebene Downloadpaket. Kann sein, das 
auch andere Versionen funktionieren, aber das habe ich nicht getestet.



Kind regards / Gruß

Hayo

[Roberto (Gast)]

Hallo Hayo (Hallo Leute)

Möchte da mal ein Programm erwähnen, dass ich mir vor kurzem gekauft 
habe (99,-)
Es heißt "ProfiLab-Expert 4.0"  von Abacom
http://abacom-online.de/html/profilab-expert.html

Ich bin echt begeistert davon!!!!

Man kann damit sehr viele Messgeräte an den PC anbinden und dort dann 
darstellen lassen. z.B. Multimeter oder USB-Messkarten und vieles mehr.
Man hat dann eine Grafische Oberfläche mit z.B. Zeigergeräten, 
XY-schreiber u.s.w.
Die einzelnen Funktionen und Abhängigkeiten voneinander kann man einfach 
per Symbole definieren und programmieren.
Das beste ist noch, man kann dieses Programm dann compilieren und hat 
dann eine eigenes Lauffähiges Programm!

Das Programm unterstützt sehr viel Hardware! Eigentlich fast alles was 
über RS232, parallel oder USB geht.

Meine Idee wäre nun die, dass man das Welec-DSO vielleicht auch an 
dieses Programm anbindet.
Es gibt da auch ein Forum:
http://forum.abacom-online.de/phpBB3/
und soweit ich mit gelesen habe, ist diese Firma auch immer bestrebt, 
neue Hardware in Ihr Programm aufzunehmen.
Unterstütze Hardware z.B. hier:
http://abacom-online.de/html/hardware_de.pdf


Nur mal so eine Idee, weil Du schon an der USB bastelst.

Eigentlich war es ja meine Hoffnung, das aus dem DSO vielleicht mal ein 
bisschen ein Digital Analyzer wird. Aber inzwischen habe ich mir einen 
eigenen kleinen gekauft...

Aber man könnte z.B. mit dem Profilab noch immer Messwerte darstellen 
lassen , oder zu frei definierten Zeiten Messwerte abrufen und vieles 
mehr...

Nur mal so eine Anregung :-)

l.G. Roberto

[Guido (Gast)]

Hmmh,

von Linux steht da aber nix. Wäre es nicht die Aufgabe von
abacom für zahlende Kunden das Welec in die Reihe
unterstützter Geräte aufzunehmen?

Gruß, Guido

[Roberto (Gast)]

Hallo Guido
Vermutlich werden sie das Gerät nur aufnehmen können, wenn die 
Schnittelle klar definiert ist.
Mann müsste sich halt da bei Interesse zusammenreden..

Es gibt zwar bei ProfiLab auch eine Serielle Schnittstelle. Mit der 
könnte man vermutlich die Steuerparameter von DSO schon ansprechen?!

Mit Linux habe ich nix am Hut, darum habe ich mich dafür noch nicht 
schlau gemacht.

l.G. Roberto

[Robert S. (razer)]

Hallo Leute,

Der neue Waverecorder ist nun fertig. Es sind nun deutlich weniger 
Argumente beim Aufruf nötig, was die Bedienung deutlich erleichtert.

Ein Screenshot kann nun einfach mit waverecorder --screenshot gestartet 
werden (hier wird ein Defaultdateiname gewählt, wobei bereits vorhandene 
Screenshots nicht überschrieben werden. Es kann auch ein Name angegeben 
werde mit waverecorder --screenshot -f dummyfilename.

Die Kommandos -u (Schnittstelle), -b (Baudrate) und -p (Schnittstelle 
zum Oszi, FPGA oder leon) sind nicht mehr nötig, da sie in der 
Konfigurationsdatei gespeichert werden. -b und -u können angegeben um 
den in der Konfigurationsdatei gespeicherten Wert für den aktuellen 
Aufruf zu überschreiben (um das ganze besser skriptbar zu machen).

Eine Binary für Windows ist unter 
https://sourceforge.net/apps/trac/welecw2000a/attachment/wiki/Leon%20Binaries/ 
zum runterladen.

Derzeit arbeite ich am VHDL-Design um die Encoder in Hardware sicher zu 
machen. Erste Versuche zeigen bereits Erfolge.

Ein schönes, einmal sonniges Wochenende
Grüße Robert

[franco (Gast)]

Hi all,
I'm sorry for my poor english, but  I live in italy and I do not 
understand german.
I have a welec w2012, I'm very interested to collaborate with the 
developement on open source software.

I don't know now if I will have time to write code, but I'm surely 
interested to test new versions and to give suggestions, in both 
hardware and software environments.

I've seen the schematic in http://sourceforge.net/apps/trac/welecw2000a/
and there are some things that I don't understand, I think that  there 
are errors on schematic.

I've tried on EmbDev.net but I'm not able to find any thread on 
welec/wittig.

Finally, if possible, I wish to look source codes of the firmware, I 
haven't find them in the web.

Thanks to all

Franco

[Robert S. (razer)]

Hi franco,

I'm one of the contributors to the alternative leon3 design of Alex. 
Some weeks ago we switched from Sourceforge code hosting to git 
(http://github.com/Crazor/welecw2000a). All our code (fpga design, 
firmware and other necessary stuff related to the leon design is hosted 
there)

We are using Skype as our main communication program. You can add me 
"xxrazer6xx". We do speak English there.

I think the sourcecode of Hayos fimware is published with the download.

Regards from sunny Austria
Robert

[Luc (Gast)]

franco schrieb:
>
>I've seen the schematic in http://sourceforge.net/apps/trac/welecw2000a/
>and there are some things that I don't understand, I think that  there
>are errors on schematic.

Hi Franco and all guys.
Franco what do you think is wrong and where?
Regards,

Luc

[Michael H. (stronzo83)]

Hey Hayo,

sowohl ich als auch die Italiener haben Probleme damit, dass hin und 
wieder das Signal "einfriert", was dann manchmal durch drehen an der 
Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist.
Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr, 
was dabei herauskam...
Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch 
nicht getestet.
Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den 
etwas langsameren Zeitbasen vorzukommen und dann immer nach einem 
Wechsel der Zeitbasis.

Gruß
Michael

P.S.: Bitte fangt jetzt nicht wieder an, mir den Trigger zu erklären, 
ich kann Oszilloskope bestens bedienen

[franco (Gast)]

I do not understand the flow of the input signal in this schematics:

http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment_V3_4.pdf

The signal goes through the input attenuator, then it must reach the 
first amplifier U1.
I see that from the blue point 16 to the blue point 2 (non-inverting 
input of the opa656N) there is no DC coupling.

It seems that the first stage is  the OP1177, but I don't believe it 
beacouse it has a unity-gain bandwith of only 1,3 MHz !!!

So I thik something is wrong!
I think this part of schematic is important to understand where the 
input nise is generated....

And are there news about the new input board?

Thanks
Franco

[Guido (Gast)]

Hi franco,

imho you are wrong. First amplifier is U1. U2 only delivers
DC and DC-offset from the dac. Do you still know
bootstrapping_stages? This is kind of that. I think that the
schematics are pretty good, but there might be some errors
anyway. So never mind to check them.

Kind regards, Guido

[Luc (Gast)]

franco schrieb:
>I do not understand the flow of the input signal in this schematics:
>http://welecw2000a.sourceforge.net/docs/schematics...
>The signal goes through the input attenuator, then it must reach the
>first amplifier U1.
>I see that from the blue point 16 to the blue point 2 (non-inverting
>input of the opa656N) there is no DC coupling.
>It seems that the first stage is  the OP1177, but I don't believe it
>beacouse it has a unity-gain bandwith of only 1,3 MHz !!!
>So I thik something is wrong!
>I think this part of schematic is important to understand where the
>input nise is generated....

Hi Franco and all guys.
Franco try to look at this:

http://welecw2000a.sourceforge.net/docs/Hardware/Improving_Input_Stage_branadic_Part_5.pdf

franco schrieb:
>And are there news about the new input board?

Franco, new news I do not know but try to look here please:

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

Regards,

Luc

[franco (Gast)]

Hi luc,
thank you for the updated links.

Google translator helped me to understand last documents in german.

I think that the choice of LMH6518 is very good, I have some dubt about 
the layout, at hier frequency is very important every millimeter in 
positionig components and wire. But I think that branadic is more or 
less readuy to test the new version of pickaback, and, I think, we all 
are waiting for the results.

Many compliments to all, it is a great work.

Source code: I've find only the "original" welec source, i read them and 
i'm very interested to look the source of new version of Hayo..... :-)

I have some suggestion, due to my experienxe with the welec scope: for 
example I think that is good increase sample frequency at middle and low 
speed timebase. If you must observe small pulse or glitch , a bigger 
sample rate is better.

Regards
Franco

[franco (Gast)]

Hi Guido,
sorry but I seen your message only now, I'm a little confused between 
many messages in many language...

hum...
you say that the dc component of the signal, plus  the dc offset is 
handled from U2, the ac part goes through capactor c9?
may be.

I'm thinking about....

Thank you ,Guido

regards
Franco

[Michael D. (mike0815)]

Hallo Robert,

habe gerade mal deinen neuen Waverecorder herunter geladen und werde ihn 
heute Abend mal testen.
Jetzt ist erstmal die Sonne an der Reihe, soll später ja Gewitter 
geben...

Erst mal ein Lob für dein neues Werk, habe das Teil schon mal 
gestartet...Neugier :)
Im Dosfenster geht gleich die Configuration los, man kann sehr bequem 
die Parameter eintragen, nun meine Frage: im obigen Screenshot stehen 
die unterstützten Gerätschaften---enter Platform:---(W2012, 2022, 
2024...) zur Auswahl, für was steht die ---SBX---???

...noch was, für die Screenshotfunktion muß ich noch eine Batch 
erstellen, oder?

PS. hast du mittlerweile Kontakt mit dem "Forker" auf Github ? 
Vollmars...den kenne ich doch?

Gruß Michael

[Robert S. (razer)]

Hallo Michael,

Michael D. schrieb:
> Jetzt ist erstmal die Sonne an der Reihe, soll später ja Gewitter
> geben...

Ich liege auch im Freien und genieße den Tag ;)

Michael D. schrieb:
> Im Dosfenster geht gleich die Configuration los, man kann sehr bequem
> die Parameter eintragen, nun meine Frage: im obigen Screenshot stehen
> die unterstützten Gerätschaften---enter Platform:---(W2012, 2022,
> 2024...) zur Auswahl, für was steht die ---SBX---???

SBX steht für Sandbox, ein FPGA Board auf dem Design auch lauffähig ist.

Michael D. schrieb:
> ...noch was, für die Screenshotfunktion muß ich noch eine Batch
> erstellen, oder?

Ja kannst du machen wenn du willst. Ein Screenshot ist einfach mit 
--schreenshot möglich. Ist also in der Kommandozeile auch sehr 
komfortabel.

Michael D. schrieb:
> PS. hast du mittlerweile Kontakt mit dem "Forker" auf Github ?
> Vollmars...den kenne ich doch?

Nein habe ich noch nicht.

Michael D. schrieb:
> Erst mal ein Lob für dein neues Werk, habe das Teil schon mal
> gestartet...Neugier :)

Danke für die Blumen.

Gruß aus der sonnigen Steiermark
Robert

[Rolf W. (rowue)]

Hayo W. schrieb:
> Jan F. schrieb:
>
>> [...]
>
> The BF-version is controlled by the scope, so it can be started with few
> parameters. The OS-version is controlled by parameters on the PC-side.

You can even start the OS Version without any further
options (apart from Port) and can use the scope to choose
between the output:
  Color Screenshot
  Black-White Screenshot
  CSV
  Raw-CSV

> So the Softbuttons have limited function here.

Maybe it would be nice to change the dump-output-type
on the scope (ascii/csv) via softbutton - but apart of
this I've used the softbuttons many time to gather
different outputs (take one screenshot before the
(raw) data dump)

(Indeed to change the output from csv to ascii you have
to specify this on the cl ;)

>
>> [...]
>
> The BF-version informs You via console messages when it is receiving a
> screenshot.

AFAIR - the OS Screenshot does this also ;)

>
> Hayo

Kind reg's,

   rowue

[Blue F. (blueflash)]

Michael H. schrieb:
> Hey Hayo,
>
> sowohl ich als auch die Italiener haben Probleme damit, dass hin und
> wieder das Signal "einfriert", was dann manchmal durch drehen an der
> Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist.
> Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr,
> was dabei herauskam...
> Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch
> nicht getestet.
> Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den
> etwas langsameren Zeitbasen vorzukommen und dann immer nach einem
> Wechsel der Zeitbasis.

Hi, also die Italiener sagten dass es bei der FFT auftritt. Bei Dir 
tritt es auch im Zeitbereich auf? Muß ich mal versuchen nachzustellen, 
ist bei mir bislang nicht aufgetreten.

Danke und Gruß

Hayo

[Blue F. (blueflash)]

franco schrieb:

> Source code: I've find only the "original" welec source, i read them and
> i'm very interested to look the source of new version of Hayo..... :-)

The actual versions are without source code, but with the next version I 
will put the source code into the download package.

Hayo

[Blue F. (blueflash)]

Roberto schrieb:
> Hallo Hayo (Hallo Leute)
>
> Möchte da mal ein Programm erwähnen, dass ich mir vor kurzem gekauft
> habe (99,-)
> Es heißt "ProfiLab-Expert 4.0"  von Abacom
> http://abacom-online.de/html/profilab-expert.html
>
> Ich bin echt begeistert davon!!!!

Hallo Roberto,

das hört sich gut an. Ich kann folgendes anbieten:

- mit dem nächsten Release gibt es eine Schnittstellenbeschreibung der 
original WELEC USB-Schnittstelle

- es gibt eine Beschreibung der neuen USB-Schnittstelle die ich 
implementiere

- wenn es eine Beschreibung für ein schon unterstütztes Gerät gibt, kann 
ich dieses Protokoll ebenfalls im WELEC einbauen (hatte ich ja schon mal 
irgendwann vorgeschlagen)

Gruß Hayo

[Bert (Gast)]

Hallo Leute,

Michael H. schrieb:
> Hey Hayo,
> sowohl ich als auch die Italiener haben Probleme damit, dass hin und
> wieder das Signal "einfriert", was dann manchmal durch drehen an der
> Zeitbasis, manchmal nur durch 2x RUN/STOP wieder zu beheben ist.
> Das hatten wir irgendwann schonmal diskutiert, ich weiß aber nicht mehr,
> was dabei herauskam...
> Triggermodus war Combi, bei Normal dasselbe Problem, Auto habe ich noch
> nicht getestet.
> Wann es auftritt, ist schwer zu sagen, es scheint aber vor allem bei den
> etwas langsameren Zeitbasen vorzukommen und dann immer nach einem
> Wechsel der Zeitbasis.
> Gruß
> Michael

Kann ich bestätigen, tritt bei mir sporadisch auch auf.
Durch drehen an den Zeitbasis geht es dann wieder.
Signalform z. B. Pulsfrequenz ca. 20 bis 100Hz, Tastverhältnis ca. 20%, 
5V-Puls. Ich versuche noch genauere Zusammenhänge zu finden.

Gruß Bert

[Blue F. (blueflash)]

Bert schrieb:

> Kann ich bestätigen, tritt bei mir sporadisch auch auf.
> Durch drehen an den Zeitbasis geht es dann wieder.
> Signalform z. B. Pulsfrequenz ca. 20 bis 100Hz, Tastverhältnis ca. 20%,
> 5V-Puls. Ich versuche noch genauere Zusammenhänge zu finden.
>
> Gruß Bert

Hi, am besten wärs wenn man das direkt reproduzieren könnte. Dann käme 
ich der Sache am schnellsten auf die Spur.

Gruß Hayo

[Bert (Gast)]

Hallo Hayo,

ich bekomme das "einfrieren" zu 90% hin, wenn ich an der horizontalen 
Verschiebung drehe, ca. 5 clicks.
Am besten unmittelbar nach der Verstellung der Zeitbasis, die 
horizontale Verschiebung drehen.
Signal ca. 15Hz, 6V Rechteckpuls, Zeitbasis 2ms/Div bis 10ms/Div.

Gruß Bert

[Bert (Gast)]

Hallo Hayo,

das "einfrieren" passiert auch manchmal ohne horizontaler Verstellung.
Signal ca. 6 Hz, Zeitbasis 10ms/Div.
Das Bild friert immer dannn ein, wenn der obere "Trigger"-Balken 
ausgeblendet wird.

Gruß Bert

[Michael D. (mike0815)]

Hallo Bert,

ich hatte wohl dasselbe "Einfrierproblem" bei den niedrigen 
Frequenz-Messungen, Restripple-Messungen bei stab.Netzgeräten z.B.!
Vielleicht schaltest du mal die "Browserfunktion" an, so das der 
"Trigger" -Balken am Display bestehen bleibt, warscheinlich ist das DSO 
mit dem ein u. Ausblenden des Selbigen etwas überfordert, teste das mal!

Gruß Michael

[Niklas O. (nevm)]

Hallo zusammen,

ich melde mich mal nach laengerer Zeit zurueck, diverse
Gruende haben mich vom Basteln abgehalten.

Verzeiht mir, dass ich den langen Thread nur teilweise gelesen
bzw. ueberflogen habe.

Es freut mich, dass die Entwicklung voranschreitet und auch
neue Besitzer hinzu gekommen sind.

Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr
im .zip Archiv mitliefert.  Wenn ich das recht verstehe liegt das
daran, dass im Moment nur Hayo daran arbeitet.

@Hayo:  Es waere schoen wenn Du die Sourcen trotzdem wieder dabei
packst, auch wenn diese nicht "poliert" sind.  So kann mal selbst
nachschauen oder Hand anlegen, wenn was klemmt.  Ich persoenlich
wuerde auch wieder zu den Screenshot und Datendump-Funktionen
beitragen wollen, sofern es meine Zeit zulaesst (im Moment gibt
es ja anscheinend zwei Varianten).

Niklas

[Michael D. (mike0815)]

...ich habe das jetzt noch mal auf die Schnelle getestet und den 
"Browser" eingeschaltet.
Im 1. Foto habe ich eine Wechselspannung 50Hz mit 9,1V Pk-pk (AC) mit 
10ms/Div und im 2. Foto 2ms/Div eine Zeit lang laufen lassen und nix 
friert ein, man sieht auf den Fotos den eingeschalteten "Browser" !

Gruß Michael

[Blue F. (blueflash)]

Niklas O. schrieb:
> Hallo zusammen,
>
> ich melde mich mal nach laengerer Zeit zurueck, diverse
> Gruende haben mich vom Basteln abgehalten.

Hallo Niklas,

welcome back :-)

> Verzeiht mir, dass ich den langen Thread nur teilweise gelesen
> bzw. ueberflogen habe.

Schon klar, ist etwas unübersichtlich...

> Es freut mich, dass die Entwicklung voranschreitet und auch
> neue Besitzer hinzu gekommen sind.

Ja und wir haben auch neue Mitstreiter aus Italien.

> Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr
> im .zip Archiv mitliefert.  Wenn ich das recht verstehe liegt das
> daran, dass im Moment nur Hayo daran arbeitet.

> @Hayo:  Es waere schoen wenn Du die Sourcen trotzdem wieder dabei
> packst, auch wenn diese nicht "poliert" sind.  So kann mal selbst
> nachschauen oder Hand anlegen, wenn was klemmt.

Ja ich wollte da dem Open Source Projekt nicht in die Quere kommen und 
hatte vorgeschlagen einen eigenen Branch für meine Sourcen anzulegen. Da 
aber jetzt schon mehrere danach gefragt haben werden ich die Sourcen bei 
der nächsten Version beilegen.


> Ich persoenlich
> wuerde auch wieder zu den Screenshot und Datendump-Funktionen
> beitragen wollen, sofern es meine Zeit zulaesst (im Moment gibt
> es ja anscheinend zwei Varianten).

Ich arbeite gerade am USB-Interface (siehe weiter oben). Da gäbe es 
Bedarf an einer USB-Screenshot-Variante. Für Linux kann ich schon ein 
USB-Template beisteuern, bei WIN_USB arbeite ich noch daran.

Die neue Version werde ich daher "etwas unfertig" mit den 
USB-Spezifikationen und den Sourcen in den nächsten Tagen rausgeben.

Gruß Hayo

[Bert (Gast)]

Hallo Michael D. und Hayo,

das "Einfrieren" tritt bei mir nur auf, wenn die "Browser"-Funktion 
deaktiviert ist. Das "Einfrier"-Problem scheint mit dem Ausblenden des 
"Browser"-Balkens zusammen zu hängen.

@Hayo:
Wann steht denn die externe Trigger-Funktion bei Dir auf dem Plan?

Gruß Bert

[Blue F. (blueflash)]

Ok, ich hab's jetzt auch geschafft das Signal einzufrieren.

Wie Ihr schon sagtet bei langsamer Timebase (5 ms/Div) und dann im 
Browser langsam hin und her drehen, dann klappt's. Muß ich mal sehen 
woran das liegen kann.

Danke für die Hinweise

Hayo

[Jan F. (jan_f)]

Hayo W. schrieb:
> to avoid such problems, I distribute the corresponding PC-addons with
> the released versions in one package.
> It is recommended to use those versions from the package. Maybe other
> versions are working as well but it is not tested

OK, I was not aware of this. I downloaded them separately. I will add a 
readme file to the downloads section telling about this. ie something 
like "Please use the version available in the firmware download package, 
as this ensures that firmware and application have been tested together. 
Other versions may not be fully compatible"

[Michael D. (mike0815)]

Bert schrieb:
> Hallo Michael D. und Hayo,
>
> das "Einfrieren" tritt bei mir nur auf, wenn die "Browser"-Funktion
> deaktiviert ist. Das "Einfrier"-Problem scheint mit dem Ausblenden des
> "Browser"-Balkens zusammen zu hängen.
>
> Gruß Bert

...ei sag' ich doch, das war aber schon immer so bei dem Teil, egal was 
für eine SW-Ver. da drauf war...
Ich unterstelle mal, das das Ein u. Ausblenden des Browsers etwas zuviel 
Rechenleistung erfordert, da bleibt der Rest vielleicht auf der Strecke!

Hayo meinte mal, das eh' noch einiger Müll beseitigt werden müsse, 
vielleicht liegt's daran...

Gruß Michael

PS. Hayo, ich habe mal eine Schaltung für den ICS511 entworfen, ich 
schicke sie dir mal, schaust du mal drüber?

[Blue F. (blueflash)]

Ha, hab Ihn!

War noch ein Relikt aus alten WELEC-Zeiten. Deshalb trat es auch in 
allen alten Versionen auf. Aber jetzt ist Schluß!

Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der 
steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf 
abgesetzt, der die ADC anhält. Hatte ich glatt übersehen, rechnet aber 
auch keiner mit.

Fix auskommentiert und schon ist alles in Butter...

Gruß Hayo

[Sven K. (svenk)]

Hayo W. schrieb:
> Ha, hab Ihn!
>
> War noch ein Relikt aus alten WELEC-Zeiten. Deshalb trat es auch in
> allen alten Versionen auf. Aber jetzt ist Schluß!
>
> Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der
> steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf
> abgesetzt, der die ADC anhält. Hatte ich glatt übersehen, rechnet aber
> auch keiner mit.
>
> Fix auskommentiert und schon ist alles in Butter...
>

Sehr, sehr geil. Vielen Dank Hayo.

Gruß Sven

[Blue F. (blueflash)]

Ach ja, schon mal vorab zur neuen BF.1.6

Die Zusammenarbeit mit der original WELEC PC-Software klappt ganz gut. 
Leider sind einige Bugs direkt in der PC-Software (war ja nicht anders 
zu erwarten). Aber alle Besitzer eines Zweikanal Gerätes sind fein raus, 
die merken davon nichts, da es nur die Kanäle 3 + 4 betrifft.

Aber für "geschenkt" kann man immerhin einige Funktionen wie 
Messwertexport, FFT und Messwertberechnung (peak-peak etc.)  nutzen.

Gruß Hayo

[Michael D. (mike0815)]

Hayo W. schrieb :
> Da hat der Kerl doch in der Interrupt Service Routine des Timer 3 (der
>
> steuert die Anzeigedauer des Browserfensters) einen Hardwareaufruf
>
> abgesetzt, der die ADC anhält.

unglaublich, man meint, du wärs't mit der Software geboren worden :))

...wieso friert's dann nicht ein, wenn das Browserfenster geöffnet 
bleibt oder war die Interruptanforderung nur für das öffnen u. 
schliesen?

Gruß Michael

PS. Hayo: Was ist, kann ich dir die Schaltung mal schicken?

[Falk (Gast)]

Niklas O. schrieb:
> ich melde mich mal nach laengerer Zeit zurueck, diverse
> Gruende haben mich vom Basteln abgehalten.

Hi, willkommen zurück.

> Was mich etwas gewundert hat ist, dass Hayo die Sourcen nicht mehr
> im .zip Archiv mitliefert.  Wenn ich das recht verstehe liegt das
> daran, dass im Moment nur Hayo daran arbeitet.

Das ist ein Henne-Ei-Problem. Wenn Du in den hiesigen Threads nach "SVN" 
suchst, wirst Du eine Ursache finden.

Gruß,
Falk, der Deine Screenshot-Funktion verschlimmbessert hat ;-)
P.S.: Ich will mich nicht streiten, aber mit NIOS ist das Ende der 
Fahnenstange bzgl. Performance und "Spikes" ungefähr da:
http://www.youtube.com/watch?v=aD_A3JPSxlc
http://www.youtube.com/watch?v=5tb16NtTws0

[Rainer H. (rha)]

Hallo zusammen,
vielen Dank an die fleißigen Hände der Entwicklerfraktion. Ich verfolge 
mit Begeisterung Eure Fortschritte.
Ich habe mal 'ne ganz einfache Frage: Warum verschwinden bei Zeiten > 1s 
die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder 
steckt Absicht dahinter?

Viele Grüße und vielen Dank,
Rainer

[Blue F. (blueflash)]

Rainer Haape schrieb:
> Hallo zusammen,
> vielen Dank an die fleißigen Hände der Entwicklerfraktion. Ich verfolge
> mit Begeisterung Eure Fortschritte.
> Ich habe mal 'ne ganz einfache Frage: Warum verschwinden bei Zeiten > 1s
> die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder
> steckt Absicht dahinter?

Hmm, kann ich momentan nichts zu sagen, da ich in der Firma bin und kein 
Gerät hier habe. Schau ich mir nachher mal an.

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:

> unglaublich, man meint, du wärs't mit der Software geboren worden :))

Zumindest kenne ich sie jetzt schon fast auswendig ;-)

> ...wieso friert's dann nicht ein, wenn das Browserfenster geöffnet
> bleibt oder war die Interruptanforderung nur für das öffnen u.
> schliesen?

Nur für's Schließen. Beim Start des Browserfensters wird der Timer 
gestartet, wenn dann der Timer abgelaufen ist wird die Timer3 ISR 
aufgerufen.

Zu diesem Zeitpunkt ist dann entscheidend ob gerade ein Acquisition-Lauf 
gestartet ist oder nicht. Wenn der nämlich schon durch ist, bleibt der 
Aufruf ohne Auswirkung, wenn er aber gerade läuft, dann erwischt es ihn 
kalt... d.h. das Acquisition_Ready Signal wird nie gesendet (weil der 
Lauf ja abgebrochen wurde) und der weitere Ablauf wartet dann bis 
Start_ADC irgendwann mal wieder aufgerufen wird. Das geschieht aber nur 
bei einigen wenigen Ereignissen, z.B. wenn man an der Timebase dreht 
oder den Stop/Start Knopf drückt.

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:

> PS. Hayo: Was ist, kann ich dir die Schaltung mal schicken?

Ja klar

[Blue F. (blueflash)]

Rainer H. schrieb:
> Warum verschwinden bei Zeiten > 1s
> die 0V Marken? Die Spannung dann einzuschätzen wird schwierig. Oder
> steckt Absicht dahinter?

So hab's mal gecheckt, ja es lag Absicht dahinter, da ja die 
Triggermarken hier keinen Sinn machen hab ich der Einfachheit halber 
alles ausgeblendet. Da ich aber Dein Anliegen gut nachvollziehen kann 
hab ich das jetzt etwas eleganter gelöst und nur die Triggermarken 
ausgeblendet. Die Nulllinien werden jetzt wieder angezeigt.

Gruß Hayo

[Blue F. (blueflash)]

Jupp,

hier ist sie, das USB-Interface ist noch in Arbeit aber es geht schon 
etwas. Die Änderungen stehen wie immer im changelog. Diesmal sind die 
Sourcen dabei und auch ein USB-Template für Linux. Die USB-Spezifikation 
findet Ihr im Programmers Guide, der jetzt die einzelnen Exceldateien 
ersetzt.

Leider wird auf SFN der Upload Link nicht mehr automatisch aktualisiert 
seit Jan das geändert hat.


Und noch mal auf auswärts:

Hi, get here the new 1.2.BF.1.6 - USB-Interface is still under 
construction but some features work. Changes are described in the 
changelog. Sources are in the package and also an USB-template for 
Linux. The USB-specs can be found in the programmers guide which 
replaces the single Excel files.

The upload link on SFN points to the old version because there is no 
automatic update since Jan changed some settings.

Hayo

[moud (Gast)]

Guten Abend,

habe gerade mal die neuste Version installiert. Den folgenden Fehler 
kann icht nicht reproduzieren, er ist beim ändern der Timebase 
aufgetreten nachdem ich CH2 deaktiviert hatte.


Gruß,
moud

PS: Habe ein 2022A
PPS: Nochmal Danke für deine Arbeit! Endlich ist das Oszi sein Geld 
wert!

[Blue F. (blueflash)]

moud schrieb:
> Guten Abend,
>
> habe gerade mal die neuste Version installiert. Den folgenden Fehler
> kann icht nicht reproduzieren, er ist beim ändern der Timebase
> aufgetreten nachdem ich CH2 deaktiviert hatte.

Huch, wie hast Du das denn hingekriegt????? Hattest Du nach dem 
Firmwareupdate einen Reset bzw. Neustart durchgeführt? Sonst läuft das 
DSO eventuel in undefinierten Betriebszuständen.

Gruß Hayo

[Moritz Z. (moud)]

Hayo W. schrieb:
> Huch, wie hast Du das denn hingekriegt????? Hattest Du nach dem
> Firmwareupdate einen Reset bzw. Neustart durchgeführt?

Guten Morgen,

wie gesagt, ich weiß es nicht. DSO war definitiv neu gestartet und ich 
war dabei die sehr komfortable Screenshot-funktion mit dem 2x drücken 
auf "Quick Print" auszuprobieren. Also mach dir mal keinen all zu großen 
Kopf. Wenn ichs nochmal schaffe, melde ich mich.


Gruß
moud

[Blue F. (blueflash)]

Noch ein kleiner Nachtrag zu den original WELEC PC-Anwendungen:

- das Firmwareupload via USB funktioniert zwar, braucht aber sage und 
schreibe 1h20m für den kompletten Upload. Desweiteren habe ich auch nur 
den "Upgrade" von 1.2.BF.1.6 auf WELEC 1.3 getestet. Ob die Open Source 
Versionen geladen werden weiß ich nicht. Es ist ein neues 
USB-Firmwareuploadprogramm geplant.

- das PC-Programm zur Messdatenaufbereitung und Fernsteuerung des DSO 
arbeitet ganz akzeptabel, wenn man davon absieht, das Kanal 3 die 
Zusammenarbeit zum Teil verweigert und Kanal 4 falsch skalierte Werte 
liefert. Bei letzterem kann ich evtl. korrigierend eingreifen, bei Kanal 
3 sieht es nicht so gut aus.


And in english:

- firmware upload via USB with the original WELEC program works, but 
needs incredible 1h20m for the upload. It is tested only the "upgrade" 
of 1.2.BF.1.6 to WELEC 1.3 - other combinations may work or not.

A new USB Frirmware update program is planned in future.

- The PC-program for data export and romote control works partly, 
channel 1 + 2 are ok, channel 3 doesn't have any ambition to work and 
channel 4 has wrong scaled values which might be corrected on DSO-side.

Hayo

[Michael D. (mike0815)]

Hallo Hayo,

folgendes Problem beim Quickprint in der 1.6er Ver. :
Bei ---"Save to BMP"--- bleibt das Oszi stehen und wacht auch nicht mehr 
auf.
Bei 2x ---"Quickprint"--- drücken ist alles Ok, tritt auf bei beiden 
Screenshotver. auf, OS u. BF.

Ich habe die 1.5er noch mal geflasht und dort funzt alles einwandfrei, 
wer hat das mal getestet?

...noch was, hat die BF1.5er Screenshot einen Schluckauf, braucht ja 
ewig, bis die fertig ist mit generieren!

Gruß Michael

PS. Hayo, ich habe gestern den ICS511 mit Quarzen zum laufen gebracht, 
das Ding rennt ja wie der Teufel! Bis 160MHz geht's noch!
Ich werde später mal was im HW-Thread berichten.

[Blue F. (blueflash)]

Oh sorry,

da hatte ich testweise die original WELEC Screenshot Funktion eingebaut 
und vergessen wieder rauszunehmen.

Hier die 2. Compilation mit korrigierter Screenshotfunktion.


Hi, I forgot a testfunction in the screenshot (BMP) Menu which causes a 
crash. Please use the 2. compilation provided here.

Hayo

[Blue F. (blueflash)]

moud schrieb:

> habe gerade mal die neuste Version installiert. Den folgenden Fehler
> kann icht nicht reproduzieren,

> DSO war definitiv neu gestartet und ich
> war dabei die sehr komfortable Screenshot-funktion mit dem 2x drücken
> auf "Quick Print" auszuprobieren.

Da haben wir dann wohl auch die Ursache für Dein merkwürdiges Problem 
gefunden....und gleich gelöst.

Hayo

[Luc (Gast)]

Hi Hayo and all guys thanks for the excellent work!
Really thanks very much to all You!
Vielen Dank!

Luc

[franco (Gast)]

Thank you Hayo!

I've see the source file, Thank you, now I have some reading to do!

:-)


Franco

[Rainer H. (rha)]

Hallo Hayo,
Danke für die Referenzmarken im Rollmodus, da fällt die Orientierung 
doch viel leichter.

Viele Grüße,
Rainer

[Blue F. (blueflash)]

Rainer H. schrieb:
> Hallo Hayo,
> Danke für die Referenzmarken im Rollmodus, da fällt die Orientierung
> doch viel leichter.

Stimmt, aber mir ist noch ein Grund aufgefallen warum ich die 
ausgeblendet hatte - wegen der niedrigen Wiederholrate im USTB-Modus 
"schmieren" die Marken etwas beim Verstellen, aber damit kann man wohl 
leben.

Gruß Hayo

[Bert (Gast)]

Hallo Hayo,

Bert schrieb:
> @Hayo:
> Wann steht denn die externe Trigger-Funktion bei Dir auf dem Plan?

Kannst Du schon was dazu sagen?
Wäre doch schön, wenn solche Grundfunktionen eines Oszi's auch 
funktionieren würden.

Gruß Bert

[Blue F. (blueflash)]

Ich schau mir das mal an. Vielleicht kann ich ja kurzfristig was machen.

Gruß Hayo

[Blue F. (blueflash)]

Hi Bert,

ich habe Schwierigkeiten Deine Probleme nachzuvollziehen. Bei mir 
triggert er extern ohne Probleme in allen Einstellungen (Auto, Normal, 
Combi) und auch bei LF und HF Reject. Holdoff habe ich nicht geprüft -> 
war off.

Einziges Manko war die Skalierung des Levels, die nicht zu stimmen 
scheint.

Was genau funktioniert denn bei Dir nicht?

Gruß Hayo

[Bert (Gast)]

Hallo Hayo,

anbei nochmals die Beiträge.
Weil egberto auch das Problem hat, glaube ich das es nicht an meiner 
Hardware liegt. Ich werde nochmals mit der Vers. 1.6 testen.
Vielleicht könnten ander Besitzer auch mal sagen ob der externe Trigger 
funktioniert oder nicht.

Bert schrieb:
> bei meinem W2024 funktioniert die externe Triggerung nicht.
> Firmware: 1.2.BF.1.4.
> Bei Ext.-Line-Triggerung bekomme ich bei 100Hz Rechteck ein stehendes
> Bild.
> Bei Ext-HF und Ext.-LF erfolgt keine Triggerung, egal bei welchem Pegel,
> auch nicht wenn ich das Rechteck-Signal über einen DC-Pegel verschiebe.
> Hat jemand ähnliche Probleme oder einen Vorschlag?
> Gruß Bert

egberto schrieb:
> @Bert (und natürlich Hayo)
> kann ich bestätigen, bei mir läuft das Bild auch....
> Das Problem trat bei mir auch erst auf, nach dem ich auf Kanal 2
> triggern wollte (triggern auf Kanal 1 war bis dahin ok), dann triggerte
> er auf Kanal 1 auch nicht mehr.... (TTL Rechteck 2 MHz)
> Viele Grüße,
> egberto

Gruß Bert

[Blue F. (blueflash)]

So um vorweg mit allen auf der gleichen Basis zu diskutieren hier 
erstmal etwas Knowhow zum exterrnen Trigger:

• Externe Triggerung: Das Triggersignal wird von außen zugeführt, 
beispielsweise vom Signalgeber selbst.

• line: Dabei wird das Triggersignal nicht aus dem Messsignal, sondern 
aus der 50 Hz Wechselspannung des Netzes gewonnen. Damit bietet sich 
z.B. die Möglichkeit zu testen, ob irgendwelche angezeigten 
Störspannungen als Ursache die 50 Hz Netzspannung haben. (In diesem Fall 
ergibt sich ein stehendes Bild.)

• hf-reject: Bei bestimmten Signalen sollen hochfrequente Anteile des 
Messsignals als Triggerursache ausgeschaltet werden. In diesem Fall wird 
durch hf-reject ein Tiefpass vor den Triggerkomparator geschaltet.

• lf-reject: Im umgekehrten Fall (falls niederfrequente Signale als 
Triggerursache ausscheiden sollen), wird durch lf-reject ein Hochpass 
vor den Komparator geschaltet. Ebenfalls ein Hochpassverhalten zeigt die 
Triggerung bei AC-Kopplung. Die Grenzfrequenz dieses Hochpasses liegt 
aber wesentlich tiefer. Der Trigger kann mit AC oder DC gekoppelt 
werden.


Also, wenn ich auf line triggere (also auf die Netzfrequenz) ergibt sich 
bei 50 Hz ein sauberes Bild. Bei anderen Frequenzen läuft das Signal 
naturgemäß mehr oder weniger schnell durch.

Bei lf-reject steht das Signal nicht so sauber, ja nach Triggerlevel 
steht es dann an irgendeinem Spike am Signal.

Am besten sieht es aus wenn ich mit hf-reject triggere, da dann die 
hochfrequenten (Störanteile) keinen Einfluß haben.

Signal: 100Hz
Vpp:    15V
Ta:     500KSa/s
Tb:     500µs/div
Trigger: Norm
Flanke: rising

Gruß Hayo

[Blue F. (blueflash)]

Potzblitz,

kanntet Ihr das schon? Ich meine die zweite Seite mit den Preisen!

Stellt Euch vor Ihr hättet tatsächlich soviel Geld dafür ausgegeben...

Hayo

[egberto (Gast)]

Hallo Hayo und Bert,

Thema Trigger - funktioniert bei mir (Firmware 1.5) - aber ich kann 
nicht sagen, ob es die Firmware gebracht hat oder ich nur zu blöd zum 
bedienen war.

Schönes WE

egberto

[egberto (Gast)]

Nachtrag - der Triggerlevel für extern wird im Bild aber nicht angezeigt 
(ok, hat mit den Signalen dort ja auch nix zu tun) - könnte man den 
nicht noch irgendwie als Pfeil in einer anderen Farbe dazu malen? Nur so 
als Vorschlag.

[Blue F. (blueflash)]

egberto schrieb:
> Nachtrag - der Triggerlevel für extern wird im Bild aber nicht angezeigt
> (ok, hat mit den Signalen dort ja auch nix zu tun) - könnte man den
> nicht noch irgendwie als Pfeil in einer anderen Farbe dazu malen? Nur so
> als Vorschlag.

Und in Relation zu welcher Nulllinie?

Gruß Hayo

[Bert (Gast)]

Hallo Hayo und egberto,

bitte probiert mal folgendes aus.
Ext. Triggerung mit Darstellung einer halben Periode und dann ein 
bischen an der Frequenz rauf und runter drehen.
Ab 3 Pulse ist es bei mir auch stabil, darunter wird es instabiler.
Frequenz ca. 100Hz oder 1kHz.

Gruß Bert

[egberto (Gast)]

Da ist doch irgendwie der Wurm drin....

1. Indiz - Triggere ich auf Kanal 1, erhöhe ich die Triggerschwelle 
durch drehen im Uhrzeigersinn, schalte ich auf Ext. HF rej. ist es 
plötzlich umgekehrt.
2. Indiz - ich bekomme die Schwelle nur auf max. 2.5 V - geht da nur ttl 
(+- 2.5 V)?

Bei meinen weiteren Versuchen habe auch ich keine externe Triggerung 
mehr hinbekommen.... Anscheinend scheint wirklich der Level irgendwo in 
der Luft zu hängen...

Zum Thema Nulline - da ich ja das externe Triggersignal nicht auf dem 
Schirm sehe (und damit verschieben kann, ist die Nullinie nat. in der 
Mitte - oder?

Grüße,

egberto

[Guido (Gast)]

Hallo,

der Bereich für externe Triggerung ist imho nicht
umschaltbar. Ich sehe da zumindest in der Schaltung
nichts. Könnte also gut sein, dass die Triggerschwelle
hier nur zwischen 0 und z.B 5 V eingestellt werden kann.

Gruß, Guido

[Stefan (Gast)]

Also zumindest bei mir wird beim ext. Trigger oben rechts ein 
Schwellwert angegeben. Es sollte also einstellbar sein.

[egberto (Gast)]

Ich habe mal ins WELEC Handbuch geschaut (die Spezifikationen sollten ja 
wenigstens stimmen ;-))

Der ext. Triggereingang kann 400Vpp ab, es ist ein Abschwächer von 1:1 
bis 1:1000 zuschaltbar, die Levelanzeige von +- 2.5 V ist also doch 
recht obskur.

Viele Grüße,

egberto

[Bert (Gast)]

Hallo Leute,

was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext. 
Trigger?
So wie ich das sehe nur der Triggermode, oder?
Im Combi-Triggermode habe ich bei Triggerung auf Kanal 1 ein stehendes 
Bild. Stelle ich auf ext. Trig. um läuft das Bild (je nach Frequenz).
Stelle ich den Triggermode auf "Normal" steht das Bild auch bei ext. 
Trigger.
Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode.
Frage, muss das so sein?

Gruß Bert

[egberto (Gast)]

bei mir triggert er im normal Modus gar nicht mehr - spricht für meine 
These der in der Luft hängenden Triggerschwelle.

Bei meinem 1. Versuch (wo es ging) hatte ich vorher bei "normaler" 
Triggerung recht viel rumgespielt - kann sein, das dadurch die 
Triggerschwelle für den ext. Trigger auf einem vernünftigen Wert war.

[Bert (Gast)]

ist bei mir auch so.
Drehe ich am Trigger-Level wird es erst instabil und bei weiterer 
Verstellung kommt dann kein Trigger mehr. Der angezeigte Pegel liegt 
aber noch im Signal drin und es triggert nicht mehr.

Noch was zum angezeigten Trigger-Level:
Trigger-Level zunächst erhöhen und dann zurück:
von 600mV -> 800mV -> 900mV -> 1mV -> 1,1V zurück 1V.
Die angezeigten 1mV sind dann wohl 1V.

[Guido (Gast)]

Die einstellbare Abschwächung bezieht sich nur auf den
verwendeten Tastkopf (1:1 bis 1:1000). Das Gerät selbst
hat wohl keine Umschaltung, über den Pegelbreich finde
ich nichts. Ihr müsst halt ausprobieren (AC-Signal mit
Offset), was eingestellt werden kann und ob die Anzeige
hierzu vernünftig ist.

[egberto (Gast)]

heißt das, es wird nur die Bildschirmanzeige für den Triggerlevel 1,6V 
->16V->160V dadurch "umgeschaltet"?

Das bringt ja mehr Verwirrung als Information oder?

Viele Grüße,

egberto

[Guido (Gast)]

So ist es. Das bringt wenig Verwirrung, wenn man daran
denkt(!) es korrekt einzustellen. Passiert mir aber auch
immer mal wieder, dass ich das auch auf den Kanälen falsch
eingestellt habe und dann über dem Fehler grüble.

Gruß, Guido

[egberto (Gast)]

Hallo Guido,
bei den Tek Tastköpfen finde ich das ja ok, wenn das Gerät das auch 
mitbekommt, aber wenn ich selbst dran denken muß, das noch am Gerät 
einzustellen, kann ich auch gleich selbst (in Gedanken)durch 10 (oder 
was auch immer) teilen. Die Einstellerei am Gerät ist doch eigentlich 
nur eine Fehlerquelle!

[egberto (Gast)]

ich meinte natürlich multiplizieren...ist halt schon etwas später, das 
Glas leerer usw....

[Blue F. (blueflash)]

Hi, meine Gläser sind inzwischen auch schon alle leer, aber trotzdem 
hier der letzte Stand der Dinge.

Also der externe Triggerlevel lässt sich in 33 Schritten zwischen ca. 
+9V und -9V einstellen. Bei 9V werden aber nur 2,5V angezeigt (Deshalb 
das Gefühl, dass der Trigger in der Luft hängt). Die Registerwerte und 
die angezeigten Werte sind einander in zwei  Werte-Arrays a 33 Werten 
direkt zugeordnet.

So was habe ich also heute Abend gemacht?

Ich habe den Wertebereich auf 129 Werte aufgeblasen und die Skalierung 
auf die tatsächlichen Werte angepasst, so dass sich das Ganze jetzt 
etwas geschmeidiger bedienen läßt.

Das Ganze gibt es in Kürze in der BF.1.7

So long

Hayo

[Guido (Gast)]

Hallo egberto,

natürlich ist es Geschmackssache, die einfachen Hameg machen
das ja auch nicht, so dass man selbst daran denken muss. Aber
eigentlich machen das heute alle Oszis so, da wird man sich
wohl dran gewöhnen müssen. ;-)

Gruß, Guido

[Michael D. (mike0815)]

...dann machen wir uns ein kleines Zettelchen auf dem steht: Probe 1:1 ? 
1:10 ? umstellen ! Das kleben wir dann auf das Display, ist dann immer 
im Sichtfeld...:)

[Bert (Gast)]

Hallo Hayo,

einige Fragen zum Trigger:

Bert schrieb:
> Noch was zum angezeigten Trigger-Level:
> Trigger-Level zunächst erhöhen und dann zurück:
> von 600mV -> 800mV -> 900mV -> 1mV -> 1,1V zurück 1V.
> Die angezeigten 1mV sind dann wohl 1V.

Ist dieses Problem dann mit BF.1.7 erledigt?

Bert schrieb:
> was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext.
> Trigger?
> So wie ich das sehe nur der Triggermode, oder?
> Im Combi-Triggermode habe ich bei Triggerung auf Kanal 1 ein stehendes
> Bild. Stelle ich auf ext. Trig. um läuft das Bild (je nach Frequenz).
> Stelle ich den Triggermode auf "Normal" steht das Bild auch bei ext.
> Trigger.
> Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode.
> Frage, muss das so sein?

Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert 
und der Combi-Modus nicht stabil funktioniert?

Wirkt die AC/DC-Kopplung auch beim ext. Trigger?

Gilt der TV-Modus nur für Kanal 1 (deshalb dieses Kästchen mit der 1)?

Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf 
"HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt 
ist.

Danke für die Hilfe!

Gruß Bert

[Blue F. (blueflash)]

Bert schrieb:
> Hallo Hayo,
> einige Fragen zum Trigger:

>> Die angezeigten 1mV sind dann wohl 1V.
>
> Ist dieses Problem dann mit BF.1.7 erledigt?

Ja

> Bert schrieb:
>> was gilt von der Trigger-Mode-Anzeige eigentlich auch für den ext.
>> Trigger?
>> So wie ich das sehe nur der Triggermode, oder?

Auto und Normal, die Flanke, der Level, hab ich noch was vergessen?

>> Der ext. Trigger funktioniert scheinbar nur stabil im "Normal"-Mode.
>> Frage, muss das so sein?

Der Automode sorgt halt konstruktionsbedingt dafür, dass auch ohne 
Triggerereignis der Trigger auslöst

> Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert
> und der Combi-Modus nicht stabil funktioniert?

Ja, das ist korrekt, das liegt daran, das der Combi-Trigger zusätzlich 
die Samplewerte eines Signals auswertet. Für den externen Trigger stehen 
aber keine Werte zur Verfügung.

> Wirkt die AC/DC-Kopplung auch beim ext. Trigger?

Das sollte sie auf jeden Fall (siehe oben), aber ob sie es auch wirklich 
tut habe ich noch nicht überprüft.

> Gilt der TV-Modus nur für Kanal 1 (deshalb dieses Kästchen mit der 1)?

Den TV-Modus hab ich noch nicht untersucht, da mir auch das 
Hintergrundwissen zur TV-Triggerung fehlt. Vielleicht kennt sich hier 
jemand damit aus?

> Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf
> "HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt
> ist.

Muß ich mir mal ansehen, vielleicht kann man da was ändern.

Gruß Hayo

[Bert (Gast)]

Hallo Hayo,

danke für die Infos!
Bedienerfreundlicher fände ich die Anzeige der aktuellen Einstellung bei
ext. Trigger und TV-Trigger. Bisher wird nur ein Haken angezeigt.
Bei "Source" wird die Kanalnummer angezeigt, da ist es direkt zu
erkennen.
Vielleicht kann der Haken durch die akt. Einstellung ersetzt werden, das
fände ich übersichtlicher.

Gruß Bert

[Bert (Gast)]

Hallo Hayo,

und noch ein Hinweis.

Hayo W. schrieb:
>> Ist es richtig, das der ext. Trigger nur im Normal-Modus funktioniert
>> und der Combi-Modus nicht stabil funktioniert?
>
> Ja, das ist korrekt, das liegt daran, das der Combi-Trigger zusätzlich
> die Samplewerte eines Signals auswertet. Für den externen Trigger stehen
> aber keine Werte zur Verfügung.

Vielleicht sollte bei Aktivierung des ext. Trigger ein evt. 
eingestellter Combi-Mode automatisch in den Normal-Mode wechseln.
Das war nämlich mein Haupt-Problem mit dem ext. Trigger, das der 
Combi-Mode bei ext. Trigger aktiviert war.

Gruß Bert

[Michael D. (mike0815)]

Hallo Bert,

> Verwirrend finde ich z. B. auch, wenn in der Mode-Anzeige Reject auf
> "HF-Reject" steht, der ext. Trigger aber auf "ext. LF Rej" eingestellt
> ist.

Ich habe das mal getestet und es zeigt alles so an wie es soll...
1.Foto : Externer Trigger steht auf LOW und wird oben rechts korrekt 
angezeigt

2. Foto: Ext. Trigger steht auf HIGH, wird auch korrekt angezeigt.

3. Foto: Ext. Trigger steht auf LINE, auch hier stimmt die Anzeige

 was stimmt da jetzt bei dir nicht?

Gruß Michael


EDIT: ich kann mich dunkel erinnern, das früher die 
EXT-Trigger-Einstellung über den Softbutton, angezeigt wurde.

[Blue F. (blueflash)]

Bert schrieb:

> Vielleicht sollte bei Aktivierung des ext. Trigger ein evt.
> eingestellter Combi-Mode automatisch in den Normal-Mode wechseln.

Das ist eine Idee, werd ich mal einbauen...

Hayo

[Blue F. (blueflash)]

Bert schrieb:

> Vielleicht kann der Haken durch die akt. Einstellung ersetzt werden, das
> fände ich übersichtlicher.

Ich werd mir da mal was überlegen...

Hayo

[egberto (Gast)]

@Michael,

schau dir doch mal die Triggerpunkte in deinen Bildern an, dann siehst 
du, was nicht stimmt (oder hattest du bei dem Screenshot kein stehendes 
Bild?).

Ich habe eben auch noch mal getestet, bei 800 mV hat er auf mein TTL 
Signal auch getriggert, dann habe ich aber am Pretrigger etwas länger 
hin und her gestellt ->Bild fror ein, nix mehr mit Trigger....

Noch ein Vorschlag, diese HF/RF/Line Einstellung nur noch im Edge Menü, 
Ext. Trigger einfach in die Liste der Triggerkanäle aufnehmen (falls das 
von der Systhematik passt).

Schönes WE,

egberto

[Bert (Gast)]

Hallo Leute,

@Michael:
bitte stelle mal den ext. Trigger auf ext. LF Rej.
Dann drückke den Trigger-Mode und unten steht dann z. B. (oder 
einstellen) bei Reject auf HF Reject.
Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der 
ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt.


@Hayo:
Auch noch ein Vorschlag:
Alles was bei ext. Trigger und TV-Trigger keinen Sinn macht z. B. die 
entspr. Softkeys im Mode-Menu deaktivieren und "unsinnige" Einstellungen 
ausblenden.
Beispiel: Reject oder ggf. Coupling (AC/DC) und ggf. Hold off.

Weiß jemand ob der ext. Trigger-Eingang eine Ac/DC-Umschaltung hat?

Gruß Bert

[Bert (Gast)]

Hayo W. schrieb:
> Bert schrieb:
>> Vielleicht sollte bei Aktivierung des ext. Trigger ein evt.
>> eingestellter Combi-Mode automatisch in den Normal-Mode wechseln.
>
> Das ist eine Idee, werd ich mal einbauen...
> Hayo

Danach sollte der Combi-Mode nicht mehr einstellbar sein solange der 
ext. Trigger aktiv ist (Combi-Mode hellgrau wie z. B. inaktive Kanäle 
bei der Source Einstellung).

[egberto (Gast)]

Und noch ein Vorschlag - einige haben doch Zugriff auf "ordentliche" 
Oszis (Tek etc.).
Da könnte man sich doch was die Menüführung betrifft einiges abschauen.

Ich klink mich erst mal aus, bin ab morgen im Urlaub (und ich nehm das 
Teil nicht mit!!;-).


Viele Grüße,

egberto

[Guido (Gast)]

Bert schrieb:
> Weiß jemand ob der ext. Trigger-Eingang eine Ac/DC-Umschaltung hat?

Ja, hat er.

[Torsten W. (wirehead)]

Hallo,
wird ja immer brauchbarer!

Gäbe es die möglichkeit für den TV Trigger einen LineSelector zu 
realisieren?
Sprich das man auchsuchen kann auf welche zeile man Triggert und damit 
immer die gleiche angezeigt wird?

Gruß
Torsten

[Guido (Gast)]

Torsten W. schrieb:
> Gäbe es die möglichkeit für den TV Trigger einen LineSelector zu
> realisieren?

Lohnt sich das denn wirklich noch? Die analoge Videotechnik stirbt
doch aus, oder?

[Michael D. (mike0815)]

Bert schrieb:
> @Michael:
>
> bitte stelle mal den ext. Trigger auf ext. LF Rej.

...hab' ich

> Dann drückke den Trigger-Mode und unten steht dann z. B. (oder
> einstellen) bei Reject auf HF Reject.

...jetzt weiss ich, was du meinst: ---MODE-COUPLING---
Stimmt, die Anzeige ist falsch!

> Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der
> ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt.

Ich habe noch mal ein Screenshot gemacht: Oben rechts steht wohl "XH" 
neben dem Triggermode,
nach drücken der Mode-Coupling Taste steht dann unten "REJECT LF-REJECT"
Das ist ist wohl wiedersprüchlich, entschuldige, konnte das erst nicht 
nachvollziehen, aber jetzt...

Bert, meinst du das, wie es auf dem Screenshot zu sehen ist?

Gruß Michael

[Bert (Gast)]

@Michael:
Korrekt und in umgekehrter Einstellung genau so, auch in "Line" 
Einstellung, dort gibt es vermutlich kein LF-/HF-Reject.
Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext. 
Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was 
bei ext. Trigger und TV-Trigger "unsinnig" ist.

Gruß Bert

[Torsten W. (wirehead)]

Ein Lineselector hat vieleicht auch in der heutigen hdtv welt einen 
gewissen wert da es auch bei hdtv analoge komponentensignale gibt.
Lohnt sich allerdings auch nur wenn der aufwand für die realisierung 
nicht allzugroß ist, da es warscheinlich fast niemand braucht bzw. nur 
im produktionsbereich anwendung findet.

[Bert (Gast)]

Hallo Leute,

egberto schrieb:
> Und noch ein Vorschlag - einige haben doch Zugriff auf "ordentliche"
> Oszis (Tek etc.).
> Da könnte man sich doch was die Menüführung betrifft einiges abschauen.

Anbei das User Guide von der Agilent 6000er Serie.
Von Agilent ist ja das Design für die Welec-DSO's "übernommen" worden.
Von der Bedienung lässt sich sicher auch noch einiges "übernehmen" z. B. 
Trigger-Einstellungen.

Gruß Bert

[Guido (Gast)]

Naja, noch gibt es die Signale, nutzen tut sie kaum
noch jemand.

Ich bin etwas ratlos, wie man das realisieren könnte,
da vermutlich V- und H-Sync zusammengefasst am FPGA
ankommen. Wie kann man die beiden dann unterscheiden?
An der Länge, mit Timer im FPGA? Vielleicht hat Hayo
ja in der Firmware irgendwo schon was dazu gefunden.

Gruß, Guido

[egberto (Gast)]

Danke für das Manual - hier ist es also wirklich so, das im Menü 
Triggerquelle, die Kanäle, Ext und Line auftauchen - den Filter(HF rej 
etc.) wählt man dann im anderen Menü.

(Die anderen Filter wären nat. auch Traumhaft - SPI, I2C...beim 4 
Kanaler technisch bestimmt machbar)


Grüße,

egberto

[wirehead (Gast)]

Nach 
http://welecw2000a.sourceforge.net/docs/schematics/Ext_Syncro_V1.1.pdf
kann man auf Vsync und Composite sync triggern.
Fehlt leider ein einzelnes H-sync was die sache etwas komplizierter 
macht.

[Michael D. (mike0815)]

Bert schrieb:
> @Michael:
>
> Korrekt und in umgekehrter Einstellung genau so, auch in "Line"
> Einstellung, dort gibt es vermutlich kein LF-/HF-Reject.
> Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext.
> Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was
> bei ext. Trigger und TV-Trigger "unsinnig" ist.
>
>
...da haben wir's doch...was eine Geburt. :)
>
ich bin überzeugt davon, das der Hayo das hin bekommt!

> Gruß Bert


Gruß Michael

[Blue F. (blueflash)]

Ich seh schon hier ist richtig was los. Ich bin allerding immer noch 
dabei den Einstellbereich für den ext. Triggerlevel zu justieren. Da ich 
jeden Wert einzeln ausmessen muß dauert das etwas...

Gruß Hayo

[Rainer (Gast)]

Guten Abend zusammen,

wirehead schrieb:
> Nach http://welecw2000a.sourceforge.net/docs/schematics...
> kann man auf Vsync und Composite sync triggern.
> Fehlt leider ein einzelnes H-sync was die sache etwas komplizierter
> macht.

So ein richtig ernstes Problem sehe ich da gar nicht. Auf V-Sync gibt es 
bei jedem Halbbildwechsel eine Flanke und auf C-Sync kommt bei jeder 
Zeile ein Puls. Allenfalls muß man bei der ersten/letzen Zeile 
aufpassen. Grundsätzlich sollte das aber klappen.

Zum Zeilentriggern müßte man
 - erst auf V-Sync Flanke triggern und auf Bildanfang warten
 - bei Trigger-Event mit U26 umschalten auf C-Sync
 - Trigger-Events bis zur gewünschten Zeile zählen
 - Signalaufzeichnung starten (Triggerpointer merken)
 - mit U26 umschalten auf V-Sync
und auf's nächste Bild waren - und immer schön die Triggerflanke 
zwischen den Halbbildern umschalten...

Die Frage ist, wie wichtig das für's praktische Leben und in Relation 
zum Aufwand ist.

Gruß Rainer

[Blue F. (blueflash)]

Rainer schrieb:

> Die Frage ist, wie wichtig das für's praktische Leben und in Relation
> zum Aufwand ist.

Auch ich denke, dass es noch andere Stellen gibt die da erstmal 
angegangen werden sollten, da der Nutzen einfach größer ist. Wenn der 
externe Trigger soweit vernünftig funktioniert, werde ich wieder in 
Richtung USB und Overlay-Funktion weitermachen - es sei denn es gibt 
noch brennende Probleme anderswo.


Gruß Hayo

[egberto (Gast)]

genau, lieber SPI und I2C Trigger ;-)))

Viele Grüße,

egberto

[Guido (Gast)]

Damit hat es sicher keine Eile, wenn es überhaupt möglich
ist. C- und V-Sync sind ja zusätzlich noch ODER-
verknüpft, so dass am FPGA nur die Kombination ankommt.

Was die digitalen Bussignale anbetrifft, halte ich das
eh für Quatsch. Dafür ist die Speichertiefe zu gering.
Wer sowas braucht (wer braucht sowas eigentlich?) kann
sich doch einen MiniLA bauen, der ist dafür viel beser
geeignet als ein Oszilloskop und auch sehr günstig.

Gruß, Guido

[egberto (Gast)]

schon klar, war als nette Zugabe gemeint (praktischer als dieses TV 
Zeugs), erst mal haben aber die Fehlerkorrekturen Vorrang!

Viele Grüße,

egberto

[Michael D. (mike0815)]

hier ist ja so ein Teil, ist mit 100MHz angegeben und LPT-Port, der Link 
dazu ist hier:

http://minila.sourceforge.net/hw/mainboard/hw.php?id=hw&sm=mainboard

Gruß Michael

[Bert (Gast)]

Hallo Hayo,

ich habe noch ein Problem mit der Pre-Trigger-Anzeige.
Firmware: BF 1.4
Zeitbasis: 2ms/Div
Trigger: pos. Edge, Pre-Trigger 2ms => Triggerpunkt nach dem ersten 
Kästchen

Verstellung: Zeitbasis auf 1ms/Div
Nach einer "Weile" springt die Pre-Trigger-Anzeige auf 1,1ms (sollte 1ms 
sein).

Verstellung: Zeitbasis von 2ms/Div auf 5ms/Div
Nach einer "Weile" springt die Pre-Trigger-Anzeige auf 5,5ms (sollte 5ms 
sein).

Jede weitere Verstellung:
Pre-Trigger wird nicht mehr aktualisiert.

Verstellung Edge (pos. Flanke auf neg. Flanke):
Pre-Trigger wird aktualisiert.

Gruß Bert

[Bert (Gast)]

Hallo Hayo,

einige Fragen zum ADC- und DAC-Abgleich:
Lt. Deiner Beschreibung sollen die Eingänge auf Masse gelegt werden
"alle Eingänge von Signalen befreien, oder besser noch alle Eingänge auf 
Ground legen (mit den Tastköpfen oder einem Kurzschlußstecker)".

Ich habe die Eingänge mittels "Coupling" auf Ground gelegt. Funktioniert 
diese Vorgehensweise auch?
Wenn ja, wäre dies einfacher.

Die Kanäle 3 und 4 lassen sich bei mir nicht gut abgleichen.
Kanal 3 ist 1V unter der Nullinie, Kanal 4 ist 1,5V unter der Nullinie
bei Abgleich mit "Coupling" auf Ground.
Lasse ich die Eingänge offen oder mit Kurzschlußbrücke ist es noch 
wesentlich schlechter.
Hast Du eine Idee?

Gruß Bert

[Guido (Gast)]

Bert schrieb:
> Ich habe die Eingänge mittels "Coupling" auf Ground gelegt. Funktioniert
> diese Vorgehensweise auch?

Hallo Bert, das funktioniert imho nicht, da hierbei nur rechnerisch
die Messwerte auf Null gesetzt werden. Wenn ich mich recht entsinne,
ist im Oszi keine Schaltung zum Kurzschluss vorhanden.

Also besser die Eingänge offen lassen.

Gruß, Guido

[Michael D. (mike0815)]

Hallo Bert,
du hast noch die 1.4er Ver., mein Vorschlag wäre, hau dir die 1.6 drauf 
und teste da mal den Abgleich!
Ich lasse die Eingänge immer offen oder schliese diese mit dem 
Tastkopp(1:1) auf Masse.
Des weiteren hast du noch die Möglichkeit unter 'HARDWARE' im 
Utility-Menu, verschiedene Modi für den ADC-Abgleich zu testen, 
vielleicht löst das dein Problem...1V, 1,5V, ist ja gewaltig, geht ja ja 
garnicht.
Widerstände hast du ja keine getauscht, oder?

Gruß Michael

noch was, leg mal alle Kanäle übereinander und calibrier dann mal, bei 
mir waren dann alle Kanäle gleich, allerdings habe ich nur das W2022, 
hatte da aber auch Probleme mit der Nulllinie!

[Bert (Gast)]

Hallo Leute,

das Problem mit dem Abgleich habe ich etwas eingegrenzt.
Die 4 Kanäle gleichen gut ab, wenn die Trigger-Source Kanal 1 oder 2 
ist.

Ist als Trigger-Source der externe Trigger oder der TV-Trigger 
aktiviert, dann gleichen die Kanäle 3 und 4 sehr schlecht ab.

Ist als Trigger-Source der Kanal 3 oder 4 aktiviert, dann gleichen die 
Kanäle 1 und 2 sehr schlecht ab.

Muss ich das jetzt verstehen?

Gruß Bert

[Bert (Gast)]

@Michael:
Michael D. schrieb:
> Widerstände hast du ja keine getauscht, oder?
Alles noch original.

@Hayo:
Kleiner Verbesserungsvorschlag:
Als Abgleichreihenfolge könnte man sich Reihenfolge der Softkeys merken 
von links nach rechts.
Dafür müssten die Softkeys "Calibrate ADC" und "Search Zero Lines"
getauscht werden.

Gruß Bert

[Lukas K. (carrotindustries)]

Ohne euch stören zu wollen, wer braucht in Zeiten von HDMI und DVB 
eigentlich noch diese ganzen TV-Trigger? Bei helmut singer trudeln zur 
Zeit auch gehäuft TV-Messsender und ähnliches ein...

[Michael D. (mike0815)]

Bert schrieb:
> Hallo Leute,
>
> das Problem mit dem Abgleich habe ich etwas eingegrenzt.
> Die 4 Kanäle gleichen gut ab, wenn die Trigger-Source Kanal 1 oder 2
> ist.
>
> Ist als Trigger-Source der externe Trigger oder der TV-Trigger
> aktiviert, dann gleichen die Kanäle 3 und 4 sehr schlecht ab.
>
> Ist als Trigger-Source der Kanal 3 oder 4 aktiviert, dann gleichen die
> Kanäle 1 und 2 sehr schlecht ab.
>
> Muss ich das jetzt verstehen?
>
> Gruß Bert

Was'n jetzt? Nach oder vor der Kalibrierung? Oder was meinst du jetzt?
Kalibrierung erfolgt im Automodus, bzw. Default-Setup drücken, dann 
folgt der Abgleich: Search Zerolines, ADC, DAC...funzt bei 5V/DIV!
Laut Hayo stimmen dann die anderen Spannungen auch, also die 2V, 1V und 
500mV/DIV müssen dann nicht mehr justiert werden.

>@Hayo:
>Kleiner Verbesserungsvorschlag:
>Als Abgleichreihenfolge könnte man sich Reihenfolge der Softkeys merken
>von links nach rechts.
>Dafür müssten die Softkeys "Calibrate ADC" und "Search Zero Lines"
>getauscht werden.

Das verstehe ich jetzt wieder nicht, erst ADC, Search Zero und dann DAC?
...was'n nu?

Gruß Michael

[Blue F. (blueflash)]

Hi, kämpfe noch mit den ext. Trigger Menüs.

-> die Ground-Coupling Einstellung ist nicht für den Abgleich geeignet, 
da (wie Guido schon anmerkte) nur das Ausgabesignal auf Null gezogen 
wird, aber nicht der Eingang.

-> beim Abgleich kann man ruhig auch in der Reihenfolge der Knöpfe 
vorgehen, die Funktion Search Zeroes ist nur für den Grobabgleich. 
Wichtig ist nur, dass die ADC vor dem Feinabgleich der DACs 
synchronisiert werden, da sonst der Feinabgleich für die Tonne ist.

-> und ein Abgleich sollte für alle Bereich ausreichen. Die Abhängigkeit 
zur Triggersource ist mir noch nicht aufgefallen, ich schau mir das mal 
an

Gruß Hayo

[Bert (Gast)]

@Michael:
Die Frage ist, was hat die Kalibrierung mit der Trigger-Source zu tun?
Ich mache einen Default-Setup und verstelle anschl. nur die 
Trigger-Source, sonst nichts. Dann erfolgt die Kalibrierung.

Hayo schreibt in seiner Anleitung "How to calibrate DAC and ADC.txt":
- wenn nicht schon vorher gemacht, jetzt die ADC-Kalibrierung 
durchführen....
- Jetzt kann man den standard DAC-Abgleich durchführen indem man Search 
Zero
  Lines betätigt....
- In der Regel bleiben noch Restoffsets die sich auch durch mehrfaches
  Betätigen nicht beseitigen lassen. Jetzt kommt der neue DAC-Abgleich 
ins
  Spiel. Man stellt also die Kanäle und die Spannungsbereiche ein die 
man
  kalibrieren möchte und betätigt "Calibrate DAC"....

Für mich ist die Reihenfolge wie folgt:
1. Cal. ADC
2. Search Zero Lines
3. Cal. DAC

Als "Eselsbrücke" würde ich die Softkeys in dieser Reihenfolge anordnen.
Es sei denn, die Anleitung ist falsch.

Gruß Bert

[Michael H. (Gast)]

Ne Bert, die Reihenfolge ist von links nach rechts, also nicht "Zero 
Lines" mitten drin drücken, sondern als erstes - ist ja wie bereits 
erklärt wurde der Grobabgleich, auf den der Feinabgleich folgt.

Kontrolliere außerdem mal, ob eine Änderung der Verstärkung im Utility 
Menü etwas ändert.

Gruß
Michael

[Bert (Gast)]

@ Hayo:
Hat es einen besonderen Grund für diese Abgleich-Prozedur?
Oder kann der ganze Ablauf:
- Default-Setup
- Cal. ADC
- Search-Zero-Lines
- Cal. DAC
nich als komplette Sequenz unter einem Softkey ablaufen?
Damit wäre es auch für den DAU "Dümmster anzunehmenden User" sicher.

Gruß Bert

[Michael D. (mike0815)]

...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung!
Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst, 
dann wären alle anderen Einstellungen auch Pfutsch, ausseredem hätte man 
dann nicht mehr die Möglichkeit, die Sachen separat einzustellen!
Macht ja Sinn, wenn ich mehrere Optionen zur Verfügung habe, oder?



Bert,
>- Cal. ADC
>- Search-Zero-Lines
>- Cal. DAC


...die Reihenfolge der Keys ist falsch,
richtig ist Search Zerol., ADC(Grob), DAC(Fein)

Gruß Michael

[Bert (Gast)]

Hallo Miichael,

Michael D. schrieb:
> dann nicht mehr die Möglichkeit, die Sachen separat einzustellen!

Nenn mir mal eine Anwendung warum die Sachen separat auszuführen sind.
Also nur "Search Zero Lines" als Grob-Abgleich.
Oder nur einen "Cal. DAC" als Feinabgleich ohne das andere.
Mir fällt dazu keine Anwendung ein.

Michael D. schrieb:
> ...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung!
> Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst,...

Ich nehme lieber den "zufälligen" Default-Setup in Kauf, als eine 
falsche Kalibrierung mit ungenauen Messwerten.

Michael D. schrieb:
> ...die Reihenfolge der Keys ist falsch,
> richtig ist Search Zerol., ADC(Grob), DAC(Fein)

Dann sollte Hayo seine Anleitung auch entspr. so schreiben (siehe Zitat 
weiter oben).

Gruß Bert

[Guido (Gast)]

Hallo Bert,

was meinst du mit Anwendung? Mein Welec braucht z.B. einige
Zeit zum Warmlaufen, was die Kalibrierung beeinträchtigt. Da
bin ich ganz froh, wenn ich dann nicht das ganze Programm
durchlaufen muss, sondern die DAC-Kalibrierung separat
aufrufen kann und dass dabei die Grundeinstellung nicht
verändert wird.

[Michael D. (mike0815)]

Bert schrieb:
> Hallo Miichael,
>
> Michael D. schrieb:
>> dann nicht mehr die Möglichkeit, die Sachen separat einzustellen!
>
> Nenn mir mal eine Anwendung warum die Sachen separat auszuführen sind.
> Also nur "Search Zero Lines" als Grob-Abgleich.

...könnte man evtl. weglassen, weiß der Hayo aber besser!

> Oder nur einen "Cal. DAC" als Feinabgleich ohne das andere.
> Mir fällt dazu keine Anwendung ein.
>
...genau, manchmal ist es notwendig den DAC-mehrmals zu betätigen ohne 
den ADC, ist schon vorgekommen, das dieser einen "Schluckauf" hatte, 
dann muß man nicht wieder von vorne anfangen.

> Michael D. schrieb:
>> ...bei 'DEFAULT-SETUP' geht das Oszi in die Grundstellung!
>> Würde ein SOFTKEY alles erledigen und du aus Versehen diesen drückst,...
>
> Ich nehme lieber den "zufälligen" Default-Setup in Kauf, als eine
> falsche Kalibrierung mit ungenauen Messwerten.

...wenn der ADC-abgleich i.O. ist, dann bleibt dieser erstmal erhalten, 
auch nach dem Ausschalten. Wenn man schon mal soweit ist, hat man ja die 
halbe Miete und muß nur noch ab u. zu den DAC calibrieren.
>
> Michael D. schrieb:
>> ...die Reihenfolge der Keys ist falsch,
>> richtig ist Search Zerol., ADC(Grob), DAC(Fein)
>
> Dann sollte Hayo seine Anleitung auch entspr. so schreiben (siehe Zitat
> weiter oben).

(Jetzt muß ich Hayo mal ein bißchen in Schutz nehmen:
Der haut hier in die Tasten, das einem schwindlich wird, da bleibt die 
Eine oder Andere Dokumentation eben mal auf der Strecke)
Ich denke, das ist zu entschuldigen!!!
Der Eine o. Andere kann ja weiter helfen, wenn's hakt...

Ich weiß, es hat sich im Laufe der Entwicklung von Hayo's FW heraus 
gestellt , das dies die bessere Methode ist die Nullinien dahin zu 
bekommen, wo sie sein sollen.
Ich muß zugeben, das ich auch erst etwas verwirrt war...habe aber "fast" 
alles, was die FW betrifft, hier mit gelesen, daher weiß ich das jetzt.
Der Thread hier, ist schon wieder Kilometer lang, wenn man da nicht 
regelmässig mit liest, bleibt so Einiges auf der Strecke!!!

Ich hatte mal den Vorschlag gemacht, eine schicke Betriebsanleitung mit 
allem Drum u. Dran zu kreieren, ist leider nicht so einfach, das gäbe 
ein Buch mit unzähligen Seiten und die Änderungen müssten dann auch noch 
eingepflegt werden!
Also alles in Allem ist das nicht ohne, da wäre dann noch die Zeit und 
Geld verdiehnen müssen wir alle noch so nebenher  :)

>
> Gruß Bert

Gruß Michael

[Bert (Gast)]

Hallo Michael,

deine Ausführungen bestätigen nur meinen Vorschlag!
Nicht jeder kennt den Kalibrierablauf auswendig, dieser sollte ja auch 
nur selten notwendig sein.
Das die aktuelle Dokumentation nicht den optimalen Ablauf wiedergibt 
spricht auch für eine einfache "Komplett-Kalibrierung" per Software, 
denn damit hätten wir keine Widersprüche zur Doku.
Das man bei jedem Einschalten den DAC kalibrieren muss, kenne ich von 
anderen DSO's (Tek und Agilent) nicht, ist vielleicht Welec spezifisch.

Je einfacher die Bedienung ist und umso weniger Bedienungsfehler möglich 
sind, desto besser ist das Gerät und umso weniger muss man 
dokumentieren!
Das kann ich nach 25 Jahren Software-Entwicklung für Mikrocontroller 
beurteilen.

Es spricht ja nichts dagegen den Softkey für den Feinabgleich (DAC) noch 
weiterhin "anzubieten". Bei einer guten Hardware sollte er allerdings 
überflüssig sein!

Michael D. schrieb:
> ...genau, manchmal ist es notwendig den DAC-mehrmals zu betätigen ohne
> den ADC, ist schon vorgekommen, das dieser einen "Schluckauf" hatte,
> dann muß man nicht wieder von vorne anfangen.
Das sollte eine "gute" Kalibrier-Software erkennen und automatisch 
korrigieren!

Ich bin mal gespannt was Hayo's Analyse zum Thema "Kalibrierung ist 
abhängig von der Trigger-Source" ergibt.
Diesen Test habe ich absichtlich so durchgeführt und nicht aus Dummheit!
Es würde mich nicht wundern, wenn da noch einige "Ungereimtheiten" in 
der Software zu Tage kommen!

Gruß Bert

[Blue F. (blueflash)]

Bert schrieb:
> @ Hayo:
> Hat es einen besonderen Grund für diese Abgleich-Prozedur?

Hi Bert,

das ist historisch so "gewachsen", da die Search Zeroes Funktion so 
schlecht funktioniert, das ich nach den Ursachen bzw. nach Alternativen 
gesucht habe, die dann erst mal experimentell eingebaut wurden und nach 
und nach verbessert wurden.


> Oder kann der ganze Ablauf:
> - Default-Setup
> - Cal. ADC
> - Search-Zero-Lines
> - Cal. DAC
> nich als komplette Sequenz unter einem Softkey ablaufen?
> Damit wäre es auch für den DAU "Dümmster anzunehmenden User" sicher.

Ja man könnte da einiges Zusammenfassen, aber ich denke flexibler ist 
man wenn man die Möglichkeit hat die Funktionen getrennt zu nutzen. Was 
ich aber auf jeden Fall noch machen wollte ist, die Search Zeroes und 
den DAC-Abgleich zusammenzulegen.

Der ADC-Abgleich kann wahlweise als Erstes oder als Zweites aufgerufen 
werden, da dieser Abgleich nur relative Werte vergleicht und keine 
Absoluten. Der DAC-Abgleich muß aber unbedingt als letztes aufgerufen 
werden, da hier absolute Werte zur Berechnung verwendet werden.

Gruß Hayo

[Michael D. (mike0815)]

morn Bert, morn Hayo,

bei meinem W2022 ist es so, das die ADC-Chips (pro Kanal 4 Stck.)schon 
nach kurzer Zeit gut warm werden, des weiteren lässt der originale 
Lüfter auch etwas zu wünschen übrig.
Also auch ein Faktor, der die Calibrierung beeinflusst.
Eine kleine Abhilfe, haben Kühlkörper auf die ADC's und ein Tausch gegen 
einen 80er Lüfter gebracht, eine Anleitung dafür ist im HW-Thread.
Ich kann mir vorstellen, das bei den 4 Kanal DSO's, die Wärmeentwicklung 
um einiges höher ist.

Gruß Michael

[Blue F. (blueflash)]

Michael D. schrieb:

> Ich kann mir vorstellen, das bei den 4 Kanal DSO's, die Wärmeentwicklung
> um einiges höher ist.

So ist es. Deshalb läuft hier der Lüfter auch mit mehr Spannung und 
lärmt daher auch mehr. Ich habe die Kühlkörper schon in Vorbereitung, da 
ich mir dadurch etwas mehr Temperaturunabhängigkeit verspreche

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> Bert schrieb:
>> @Michael:
>>
>> bitte stelle mal den ext. Trigger auf ext. LF Rej.
>
> ...hab' ich
>
>> Dann drückke den Trigger-Mode und unten steht dann z. B. (oder
>> einstellen) bei Reject auf HF Reject.
>
> ...jetzt weiss ich, was du meinst: ---MODE-COUPLING---
> Stimmt, die Anzeige ist falsch!
>
>> Das sind dann widersprüchliche Anzeigen. Der Reject zeigt HF an, der
>> ext. Trigger ist aber auf LF eingestellt. Das war mein Kritikpunkt.

Jungs Ihr kriegt da was durcheinander! Die Anzeige ist ganz korrekt. Die 
Anzeige oben bezieht sich auf den tatsächlich eingestellten externen 
Trigger. Die Anzeige HF Reject bezieht sich auf den normalen 
Triggermodus des ausgewählten Kanals, welcher aber ja in diesem Moment 
nicht aktiv ist.

Gruß Hayo

[Blue F. (blueflash)]

Und jetzt kommts,

wie ich gerade feststelle hat der Reject Knopf im Mode/Coupling Menu 
keine Funktion. Ist sozusagen überflüssig wie ein Kropf - deshalb werde 
ich ihn ausblenden. Also keine Verwirrung mehr.

Gruß Hayo

[Bert (Gast)]

Hallo Hayo,

Hayo W. schrieb:
> Jungs Ihr kriegt da was durcheinander! ...

Genau das ist ja das verwirrende!
Da kann man am "Reject" was einstellen, das keinerlei Wirkung hat und 
das Gegenteil anzeigt, was gerade für den ext. Trigger eingestellt ist.

Mein Lösungsvorschlag dazu:
Bert schrieb:
> Alles was bei ext. Trigger und TV-Trigger keinen Sinn macht z. B. die
> entspr. Softkeys im Mode-Menu deaktivieren und "unsinnige" Einstellungen
> ausblenden.

Bert schrieb:
> Korrekt und in umgekehrter Einstellung genau so, auch in "Line"
> Einstellung, dort gibt es vermutlich kein LF-/HF-Reject.
> Die Reject-Einstellung im Mode-Menue hat keine Auswirkung auf den ext.
> Trigger und verwirrt nur. Deshalb der Vorschlag, alles auszublenden was
> bei ext. Trigger und TV-Trigger "unsinnig" ist.

Bert schrieb:
> Danach sollte der Combi-Mode nicht mehr einstellbar sein solange der
> ext. Trigger aktiv ist (Combi-Mode hellgrau wie z. B. inaktive Kanäle
> bei der Source Einstellung).


Ich habe eben mit dem Agilent 6054A gearbeitet.
Folgende Dinge sind mir bei der Bedienung positiv aufgefallen.
1. Beim Verschieben des Triggerpegels wird zusätzlich zum Pfeil eine 
Linie
   für den Triggerpegel angezeigt. Die Linie wird nach ca. 1s ab
   "Stillstand" wieder ausgeblendet, das hat mir gut gefallen. Der 
Trigger-
   Pegel ist so genau auf dem Signalverlauf (Kreuzungspunkt) sichtbar.
2. Die horizontale Verschiebung funktioniert so, wie ich es intuitiv
   erwarte, Rechtsdrehung verschiebt das Bild nach rechts, Linksdrehung
   verschiebt das Bild nach links.
3. Auswahl der Trigger-Source mittels Edge->Source. Es können die
   Kanäle "1" bis "4" , "Extern" und "Line" angewählt werden.
   Wenn man das so umsetzt, dann gibt es auch nur ein "Reject"-Softkey 
für
   die Kanäle und "Extern". Den TV-Trig. kann man dann auch noch dort
   unterbringen.

Hayo, bitte vergesse folgende Punkt nicht:
Pre-Trigger: siehe Beitrag #1746189.
Abhängigkeit Kalibrierung und Trigger-Source: siehe Beitrag #1746588.

Gruß Bert

[Michael D. (mike0815)]

Jetzt habe ich mal kurz das Manual des Agilent DSO's überflogen, das 
sieht ja genauso aus, wie das Welec?!?
Die Screenshots haben dieselbe Grafische Oberfläche!
Mich würde mal interessieren, ob die Software von dem Agilent, nicht 
auch auf das Welec passen würde, wenn da noch das FPGA - Design dasselbe 
ist...
Es könnte der Bert doch mal die FW vom Agilent sichern und Hayo schaut 
sich das Ganze mal! Ginge das???

Gruß Michael

[Torsten W. (wirehead)]

:Ich glaube nicht das da die gleiche hardware in dem gehäuse steckt...

Gruß
Torsten

[Michael D. (mike0815)]

...glauben heißt nicht wissen! Da hilft nur auf machen und rein schauen.
Ich nehme mir mal kurz die Zeit und schau mal im I-Net nach eventuellen 
Informationen, noch besser wäre...wer hat denn ein Agilent zur Hand?
Da gibts ja 2 Kanal mit 100MHz und 300MHz, da könnte doch passen...

[Bert (Gast)]

Hallo Leute,

ich sagte ja bereits, Welec hat ordentlich das Design abgekupfert bei 
Agilent. Aber die Preisklasse ist nun mal eine andere!!

http://www.datatec.de/cgi-bin/shop/lshop.cgi?action=showdetail&wkid=26759&ls=d&nc=1276529250-26765&rubnum=&artnum=dso6054a&file=1&gesamt_zeilen=0Tsuche--agilent%206054A

In dieser Preis- und Leistungsklasse gibt es keine Standard FPGA's mehr.
Die sind alle Hersteller spezifisch, die macht Agilent entweder selbst 
oder lässt machen. Das Betriebs-System vom Agilent ist jedenfalls 
Windows, da erscheint das Windows-Logo beim hochfahren.

Die Bedienung hat Welec sich auch dort abgeguckt, ist ziemlich ähnlich.
Die Drehschalter gehen butterweich, aber bei der Preisklasse auch zu 
erwarten.

Gruß Bert

[Bert (Gast)]

Bert schrieb:
> Das Betriebs-System vom Agilent ist jedenfalls
> Windows, da erscheint das Windows-Logo beim hochfahren.

sorry, stimmt nicht, da hab ich was durcheinander gebracht.
Das war der Rohde&Schwarz Spectrum-Analyser mit dem Windows-Logo.

[Robert S. (razer)]

Bert schrieb:
> Bert schrieb:
>
>> Das Betriebs-System vom Agilent ist jedenfalls
>> Windows, da erscheint das Windows-Logo beim hochfahren.
>
> sorry, stimmt nicht, da hab ich was durcheinander gebracht.
> Das war der Rohde&Schwarz Spectrum-Analyser mit dem Windows-Logo.

Ja Agilent Oszis (MSO6000er, MSO7000er) haben kein Windows. Die LeCroy 
Waverunner haben dann wieder Windox XP kotz. Da lob ich mir mein 
Agilent MSO7034.

Grüße Robert

[Michael H. (Gast)]

@ Hayo

habe ich dich richtig verstanden, dass es keinerlei zuschaltbare 
Triggerfilter gibt? Oh Mann. Hältst du es für machbar, welche 
nachzurüsten?

@Bert
Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs 
ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist. 
Vermutlich meintest du ASICs?

Gruß
Michael

[Blue F. (blueflash)]

Michael H. schrieb:
> @ Hayo
>
> habe ich dich richtig verstanden, dass es keinerlei zuschaltbare
> Triggerfilter gibt? Oh Mann. Hältst du es für machbar, welche
> nachzurüsten?

Ich vermute, dass das mal angedacht war, da der Softbutton ja schon da 
war. Beim Setzen der Hardwareregister wird das aber nicht 
berücksichtigt. Ob es da Hardwareseitig schon eine Implementierung gibt 
die man ansteuern könnte kann ich aber so nicht sehen, leider haben wir 
keinerlei Hardware bzw. FPGA Spezifikationen von WELEC bekommen.

Beim externen Trigger wird das über SetSwitches geschaltet, da gibt es 
also Filter auf der Platine die irgendwie angesteuert werden.

Gruß Hayo

[Michael D. (mike0815)]

Hi Robert,

was macht das LEON3, gibt's was neues zu berichten?

Es werden doch bei dem Agilent bestimmt Software updates angeboten, oder 
nicht?
Wenn ja, wird ja vor dem Aufspielen ein Backup gemacht, ist ja wohl bei 
jeder Firmware pflicht!
Wenn Hayo das Backup in die Finger bekommt, könnte er die beiden 
FW-Versionen vergleichen und wenn absolut keine Kompatibilität vorhanden 
ist, kann man das ja immer noch in die Tonne kloppen!
Ich finde, es wäre einnen Versuch wert, oder ?

[Blue F. (blueflash)]

Ist aber ziemlich unwahrscheinlich dass das hinhaut

Hayo

[Bert (Gast)]

Hallo Hayo,

damit Dir nicht langweilig wird, folgendes Problem:
Die Y-Cursor zeigen die Pegel zur Nullinie des ausgewählten Kanals an.
Verschiebe ich einen Y-Cursor wird der Wert sehr (quälend!) langsam 
aktualisiert.
Verschiebe ich die Nullinie des Kanals, werden die Y-Cursor-Werte gar 
nicht aktualisiert. Erst nach einer Cursor-Steuerung, oder 
Zeitbasis-Änderung  werden die aktuellen Y-Cursor-Werte angezeigt.

Schnelleres Drehen der Cursor-Verstellung bringt leider keine 
Cursor-Beschleunigung.Den Cursor von unten nach oben zu drehen ergibt 
Blasen an den Fingern :-)

Wie sieht das denn mit dem ext. Trigger aus, sind da die HF- und LF 
-Einstellungen auch Dummy's?


@Michael H.
Michael H. schrieb:
> Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs
> ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist.
> Vermutlich meintest du ASICs?
Könnte sein. Aber ob die sich während der Entwicklung eines DSO's x-mal 
ein ASCI "backen" lassen, bis alles funktioniert, da bin ich mir auch 
nicht sicher!? Vielleicht deshald der Preis von über 10k€.

Gruß Bert

[Bert (Gast)]

Hallo,

wer möchte, darf die Agilent Firmware analysieren.
Ich glaube allerdings, das ist Zeitverschwendung!!

Anbei folgende Software-Pakete:
5000/6000 Series Oscilloscope System Software, Version 6.00.0004
5000/6000 Series Oscilloscope Library Software, Version 2.24
5000/6000 Series Oscilloscope Graphics Software, Version 2.12

Quelle:
http://www.home.agilent.com/agilent/editorial.jspx?cc=US&lc=eng&ckey=666864&nid=-35802.0.00&id=666864

Gruß Bert

[Michael D. (mike0815)]

...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die 
nicht auf!

Gruß Michael

[Bert (Gast)]

Michael D. schrieb:
> ...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die
> nicht auf!

Ich vermute das ist eine "eigene" Komprimierung, die das Update-Programm 
verwendet.

@ Hayo:
Und noch etwas zur Cursor-Steuerung:
Ich aktiviere gleichzeitig Cursor und Delay.
Im Delay-Bereich werden die Y-Cursor angezeigt, nicht aber die X-Cursor.
Frage ist, ob das so gewollt ist. Ich vermute mal nicht, denn zum 
genauen Zeitmessen wären die X-Cursor im Delay-Fenster hilfreich.

Gruß Bert

[Michael D. (mike0815)]

Bert schrieb :
> Hallo,
>
> wer möchte, darf die Agilent Firmware analysieren.
> Ich glaube allerdings, das ist Zeitverschwendung!!
>
Nun ja, könnte sein...

Es wurde hier schon mehrmals in der Vergangenheit gesagt, das FW u. 
HW-mässig das Ende der Fahnenstange ist...
Plötzlich kam ein 3. Triggermodus, ein funktionierendes FFT, optimierte 
Delay-Funktion und ein simpler Akkubetrieb dazu.
Ein LEON3 von Robert und die Huckepackplatine sind ebenfalls noch in 
Arbeit
...es ist immer noch Potenzial unterwegs!
>
> Gruß Bert

Gruß Michael

[Michael D. (mike0815)]

@ Bert

...die Update-EXE von der 3000er Serie ist über 4MB groß, in der 
Anleitung steht leider nichts von einer Sicherung!
Kannst du deine FW vom Agilent vor dem Update sichern?
(ich suche mal nach dem Kompressor für die jpz)


Vielleicht machst du mal einen Screenshot von deinem Problem...

Hier ist meiner mit "CURSERS" u. "DELAY-MODE"
bei mir sind alle Curser vorhanden!

Noch mal ein Lob an Hayo, den Delay hast du sauber hin gekriegt!!!

Gruß Michael

[Bernd O. (bitshifter)]

Michael D. schrieb:
> ...mit was wurden die Dateien denn komprimiert? Mit 7zip krieg ich die
> nicht auf!
>
> Gruß Michael
Ich hab' mir eine Datei mal angesehen. Ab Byte 240 steht "AGLTZIP". Das 
deutet sehr stark auf eine "Privatimplementierung" durch Agilent hin.

Der Versuch, über die Agilent-Dateien weiterzukommen ist mit Sicherheit 
sinnlos - nicht wegen des Zip-Formates, sondern einfach weil es eine 
andere Hardware ist.

Gruß,
Bernd

[Bert (Gast)]

OK, ich habs, es ist reproduzierbar. (BF 1.4)

Nach einem Default-Setup sind die X-Cursor in beiden Fenstern vorhanden.
Ablauf wie folgt:
1. Default-Setup
2. Zeitbasis auf ca. 500µs.
3. Cursor und Delay aktivieren, Kontrolle ob die X-Cursor in beiden
   Fenstern vorhanden sind.
4. Zurück auf Main-Einstellung (kein Delay, Cursor aktiv).
5. Die X-Cursor gemeinsam (mit X1 X2) bis an den rechten Rand schieben 
und
   die Differenz (ca. 3 Kästchen) kleiner wird.
6. Die X-Cursor gemeinsam (mit X1 X2) in die Mitte schieben.
7. Delay aktivieren, die X-Cursor fehlen im Delay-Fenster.
8. Ab jetz sind die X-Cursor im Delay-Fenster weg bzw. man sieht sie am
   rechten Rand.
9. Oszi aus und wieder einschalten.
10. Cursor und Delay aktivieren, Kontrolle ob die X-Cursor in beiden
   Fenstern vorhanden sind => die X-Cursor im Delay-Fenster sind weg 
bzw.
   man sieht sie am rechten Rand.
   Zurück auf 1.


Nächstes Problem.
Trigger-Mode.
1. Triggermode auf Normal stellen.
2. Zeitbasis erhöhen bis 1s, Triggermode schaltet auf "Auto".
3. Zeitbasis auf zurück auf 500ms,  Triggermode schaltet auf "Normal".
4. Zeitbasis auf 2s, Triggermode schaltet auf "Auto".
5. Zeitbasis auf zurück auf 500ms,  Triggermode schaltet nicht auf
   "Normal".
   Drückt man die Mode-Taste unten, ist der Haken bei "Normal", 
angezeigt
   wird aber "Auto"
6. Zeitbasis veringern, Trigger-Mode bleibt bei "Auto", Haken ist bei
   "Normal".

Gruß Bert

[Michael H. (Gast)]

@ Bert
Du bist ja echt fleißig im Fehler finden, das bringt die Firmware sicher 
auch weiter.

Zum Thema ASIC: Die Entwicklung läuft auf Simulationsbasis und auf FPGAs 
mit VHDL oder Verilog. Wenn alles funktioniert wie es soll, dann kann 
der Code direkt in ein ASIC umgesetzt werden.

Gruß
Michael

[Michael D. (mike0815)]

hallo Bernd,

du konntest das File öffnen? Ich habe mir einen Wolf im I-Net gesucht 
und habe da immer nur was von Puzzels gelesen...

Wenn das Sinnlos ist da weiter zu bohren, nun ja, war ja nur so eine 
Idee, hätte ja sein können, das da was geht.

Gruß Michael

[Blue F. (blueflash)]

Hi,

bin grad vom Griechen zurück. Hier tobt ja das Leben!

Bert findet die Fehler ja schneller als ich sie überprüfen kann...

Ich hab das im Blick, muß das aber nach und nach abarbeiten, da ich 
dummerweise auch noch für Geld SAP-Programme schreiben muß.

Danke für die intensiven Tests und ausführlichen Fehlerberichte

Gruß Hayo

[Blue F. (blueflash)]

Ach ja, hab noch vergessen eins anzumerken.

Die Performance ist gerade bei Quickmeasure oder auch bei einfachen 
Cursoraktionen aufgrund der begrenzten Rechenleistung des 33MHz 
Prozessors natürlich schnell am Ende. Aussicht auf Besserung bietet hier 
eigentlich nur das LEON3-Projekt.

Als Grundregel kann man aber sagen, je weniger Kanäle aktiv sind desto 
schneller geht alles. Also nicht benötigte Kanäle immer abschalten!

Und zum Reject des externen Triggers: Ja hier funktioniert das 
tatsächlich, nur beim normalen Kanaltriggern nicht.

Gruß Hayo

[Michael D. (mike0815)]

ja ja, der Bert heizt hier gut an, da kennt der nix...:))

Hayo W. schrieb :
> Ach ja, hab noch vergessen eins anzumerken.
>
> Die Performance ist gerade bei Quickmeasure oder auch bei einfachen
> Cursoraktionen aufgrund der begrenzten Rechenleistung des 33MHz
> Prozessors natürlich schnell am Ende. Aussicht auf Besserung bietet hier
> eigentlich nur das LEON3-Projekt.
>
oje, 33MHz für 4 Kanäle, bei voller Belastung bleibt ja fast alles 
stehen.
Beim Quickmeasure geht das W2022 auch ganz schön in die Knie...

> Als Grundregel kann man aber sagen, je weniger Kanäle aktiv sind desto
> schneller geht alles. Also nicht benötigte Kanäle immer abschalten!

...das ist ja wohl logisch!
>
Ich habe in der Vergangenheit des öfteren Rechner CPU's übertaktet, so 
das diese gerade noch stabil liefen. Man darf das natürlich nicht 
übertreiben, sonst macht der Rest der perepherie nicht mehr mit!

Könnte man die 33MHz noch ein bißchen hoch takten? So 10-15% müssten 
doch drinnen sein?!?

> Gruß Hayo

Gruß Michael

[Bert (Gast)]

Hi,

konnte schon jemand das X-Cursor-Problem nachvollziehen?
Ich bekommen meine X-Cursor (Delay und Cursor aktiv) nicht mehr 
"sortiert", weder mittels ausschalten und auch nicht mit Default-Setup.
Die X-Cursor im Delay-Fenster erscheinen von der rechten Seite und 
wanden nach links ins Bild, wenn ich beide Cursor gemeinsam immer weiter 
nach links verschiebe. In der oberen Fensterhälfte sind sie dann aber 
bereits aus dem markierten Bereich (Delay-Sichtbereich) heraus.
Diesen Anordnung der X-Cursor bekomme ich nicht mehr "repariert".

Gruß Bert

[Bert (Gast)]

Hi,

um *ASIC*-Klarheit zu schaffen und das Thema Agilent Firmware 
endgültig zu beerdigen:

Bert schrieb:
> @Michael H.
> Michael H. schrieb:
>> Herstellerspezifische FPGAs, jetzt hört's aber auf. Der Sinn von FPGAs
>> ist doch gerade, dass nichts in irgendeiner Weise spezifisch ist.
>> Vermutlich meintest du ASICs?
> Könnte sein. Aber ob die sich während der Entwicklung eines DSO's x-mal
> ein ASCI "backen" lassen, bis alles funktioniert, da bin ich mir auch
> nicht sicher!? Vielleicht deshald der Preis von über 10k€.

Michael H. schrieb:
> Zum Thema ASIC: Die Entwicklung läuft auf Simulationsbasis und auf FPGAs
> mit VHDL oder Verilog. Wenn alles funktioniert wie es soll, dann kann
> der Code direkt in ein ASIC umgesetzt werden.

Auf der linken Seite dieses Vergleichs steht folgendes.
InfiniiVision scopes incorporate acquisition memory
waveform processing and display memory in an advanced
013 μASIC


Gruß Bert

[Steve (Gast)]

@ Bert,

im kaufmännischem Bereich und in der Werbebranche ist der Unterschied 
zwischen ASIC und FPGA nicht wirklich bekannt.

Alle DSOs die ich bisher gesehen habe, darf ich eigentlich niemandem 
erzählen, dass ich schon viele Interesse halber geöffnet habe ;) , 
hatten einen FPGA drin.
Da dieser ein anwendungsspezifisches Hardware-Design erhält spricht man 
schnell von einem ASIC, obwohl die Begrifflichkeit in diesem Fall falsch 
ist, es bleibt trotzdem ein FPGA.

Das einzige echte ASIC das ich in einem DSO bisher gesehen habe, war ein 
von Tektronix und National Semiconductor gemeinschaftlich entwickelter 
ADC für ein DSO, den man nicht bei National ordern kann.

Im Zeitalter von FPGAs und mittlerweile auch Mixed Signal FPGAs lohnt 
sich der Guss von ASICs kaum noch, da viel zu unflexibel und nur bei 
wirklich großen Stückzahlen rentabel (USB- und Ethernet-Controller zum 
Beispiel).

Lasst euch also nicht in die Irre führen.

Die Firmware wird euch dennoch nicht viel nützen, ihr kennt weder das 
Hardware-Design des FPGA im Agilent, noch die Hardware auf der Platine 
etc.

Hier Energie reinzustecken wäre unnötige Liebesmühe.

Grüßle, Steve

[Bert (Gast)]

Hallo Steve.

Steve schrieb:
> Hier Energie reinzustecken wäre unnötige Liebesmühe.
Das sehe ich genauso!

Konzentrieren wir uns lieber auf die Verbesserung der NIOS-Firmware und 
hoffentlich auch bald auf die Leon3-Firmware.

Gruß Bert

[Michael D. (mike0815)]

Bert schrieb:
> Hi,
>
> konnte schon jemand das X-Cursor-Problem nachvollziehen?
> Ich bekommen meine X-Cursor (Delay und Cursor aktiv) nicht mehr
> "sortiert", weder mittels ausschalten und auch nicht mit Default-Setup.
> Die X-Cursor im Delay-Fenster erscheinen von der rechten Seite und
> wanden nach links ins Bild, wenn ich beide Cursor gemeinsam immer weiter
> nach links verschiebe. In der oberen Fensterhälfte sind sie dann aber
> bereits aus dem markierten Bereich (Delay-Sichtbereich) heraus.
> Diesen Anordnung der X-Cursor bekomme ich nicht mehr "repariert".
>
> Gruß Bert

Hallo Bert,
Ich habe heute Mittag einige Einstellungen bezüglich Curser u. Delay 
geteste, bleibt alles hübsch!
Vielleicht solltest du die Firmware noch mal neu aufspielen, evtl. 
behebt das dein Problem?!?
Nach der Aktuallisierung der FW. DEFAULT-SETUP nicht vergessen!

Gruß Michael

[Michael D. (mike0815)]

Jetzt habe ich hier aber ein Problem:
ich bin gerade dabei den Restripple eines symetrischen Netzteils zu 
messen.
Ist eine Einweggleichrichtung, daher die 50Hz.

Einstellungen sind: Kanal 1 AC-Coupling, 100mV/Div, 50kSa/s
Foto 1

jetzt wollte ich auf 50mV/Div, habe ich plötzlich kein Signal mehr!

Ich schalte den 2.Kanal mit 100mV/Div dazu und gehe mit Kanal 1 auf 
50mV/Div, Signal ist wieder da!
Foto 2

Kanal 1 bleibt bei 50mV/Div, Kanal 2 schalte ich ebenfalls auf 50mV/Div, 
beide Kanäle haben kein Signal mehr!
Kanal 1 schalte ich auf 100mV/Div, Kanal 2 bleibt auf den 50mV/Div, 
plötlich habe ich wieder meine Signale und kann auch bis runter auf 
10mV.
Sobald ich einen Kanal weg schalte, tut sich unter 100mV/Div nichts 
mehr...
umgekehrt dasselbe.

Wie kann das sein???

Gruß Michael

EDIT: Jetzt wollte ich testen, ob das auch im Trigger-Automode so ist
Jetzt kann ich den Trigger nur noch zwischen COMBI und NORMAL schalten, 
bei AUTO-Trigger bleibt der Haken bestehen, d.h. ich habe 2 x Haken im 
Coupling-Mode!!!

[Bert (Gast)]

Hallo Michael,

Michael D. schrieb:
> Hallo Bert,
> Ich habe heute Mittag einige Einstellungen bezüglich Curser u. Delay
> geteste, bleibt alles hübsch!
> Vielleicht solltest du die Firmware noch mal neu aufspielen, evtl.
> behebt das dein Problem?!?
> Nach der Aktuallisierung der FW. DEFAULT-SETUP nicht vergessen!

Habe jetzt BF1.6 geflasht, die Cursor im Delay-Fenster funktionieren 
wieder.
Probier bitte mal folgendes aus:
1. Zeitbasis 50ns
2. Cursor aktivieren
3. X-Cursor 2 Kästchen auseinander in der Mitte positionieren.
4. Delay aktivieren, Kontrolle ob die X-Cursor in beiden Fenstern 
vorhanden sind.
5. Delay deaktivieren
6. Zeitbasis 2ms
7. Delay aktivieren
8. Die X-Cursor im Delay-Fenster sind am rechten Bildrand.

Gruß Bert

[Michael D. (mike0815)]

Hallo Bert,

bin gerade dabei...hast du ein Signal(1KHz) am Eingang oder nichts?

Gruß Michael

EDIT: Hast du von meinem Probl. gelesen? Im Gegenzug, teste das doch mal 
bitte!

[Michael D. (mike0815)]

So, habe alles genau nachvollzogen!

Foto 1: Die X1 X2 Curser sind am rechten Bildrand,
sieht das bei dir jetzt genauso aus?


Foto 2: Ich habe die X1 X2 Curser nach links verschoben, sollten die 
nicht so ziemlich in der Mitte sein?

Gruß Michael

[Michael D. (mike0815)]

ich noch mal,

im DELAY-Modus (2mS) ist der Delay 1mS, dann kann man den Delay noch auf 
500µS stellen, dann sin die unteren Curser (X1 X2) in der linken 
Schirmhälfte, hmm...

Damit Jeder weiß, was ich meine, auch hier ein Foto davon!

Gruß Michael

[Bert (Gast)]

Michael D. schrieb:
> bin gerade dabei...hast du ein Signal(1KHz) am Eingang oder nichts?
> EDIT: Hast du von meinem Probl. gelesen? Im Gegenzug, teste das doch mal
> bitte!

Ich habe Dein Signal und Einstellungen alles so eingestellt.
Bei mir tritt das Problem nicht auf. Auch nicht, wenn ich die 
Trigger-Kopplung DC/AC verstelle. Meine Eingangs-Widerstände sind 
allerdings alle noch original, ob daran liegen könnte, keine Ahnung.
Wie ist das im Trigger-Normal-Mode?
Wie ist das, bei Verstellung der Trigger-Pegels?

Cursor:
Am Eingang habe ich bei meinem Cursortest nicht anliegen gehabt.
Ja, das ist das Problem, die oberen X-Cursor sind nicht mehr innerhalb 
der Markierungen für den Display-Ausschnitt. Somit laufen die X-Cursor 
in den beiden Bildschirmhälften nicht mehr synchron.
Bei 2ms bekomme ich allerdings die unteren X-Cursor garnicht mehr ins 
Bild. Erst mit kleineren Zeitbasen klappt das wieder.

Gruß Bert

[Michael D. (mike0815)]

Ich fasses nicht, wie kann das sein, wenn ich eines der beiden Kanäle 
bei 50mV/Div zu schalte, das ich dann erst wieder messen kann? Übrigens 
ist das egal ob ich Kanal 1 oder Kanl 2 verwende.
Mich würde interessieren, ob das jetzt wirklich nur bei mir so ist, wenn 
ja, habe ich einen Hardwarefehler!
Die Widerstände sind in dem Fall alle original, 0 Ohm also.

Vielleicht testet das noch Jemand, damit ich da sicher gehen kann?!?
Bei der W2000er Serie existieren mehrere HW-Versionen,
ich habe das Model: W2022A mit HW-Vers. 8C7.0L
Wer hat denn das gleiche Model?

@Bert
Cursor:
>Am Eingang habe ich bei meinem Cursortest nicht anliegen gehabt.
>Ja, das ist das Problem, die oberen X-Cursor sind nicht mehr innerhalb
>der Markierungen für den Display-Ausschnitt. Somit laufen die X-Cursor
>in den beiden Bildschirmhälften nicht mehr synchron.
>Bei 2ms bekomme ich allerdings die unteren X-Cursor garnicht mehr ins
>Bild. Erst mit kleineren Zeitbasen klappt das wieder.

Da haben wir dasselbe Problem, mit dem Unterschied, das ich meine Curser 
noch nach links rücken kann!

Hayo wird das schon richten, denke ich.

Gruß Michael

[Blue F. (blueflash)]

Hi, ich bin aber erstmal mit dem Trigger beschäftigt. Das Andere muß ich 
mir mal in Ruhe ansehen.

Gruß Hayo

[Bert (Gast)]

Hallo Leute,

hier meine erste Version des Agilent-Erfahrungsberichtes.
Ich würde mich freuen, wenn man sich bei der Firmware daran orientieren 
würde.

Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn!
Linksdrehung verschiebt recht, Rechdrehung verschiebt links.
Keine Verschiebung über den ganzen Bildschirm möglich.
Über den Zweck des Browser-Balkens grüble ich immer noch!
Eure Meinung zu diesem Thema und der gesamten Bedienung ist gefragt!


Michael D. schrieb:
> EDIT: Jetzt wollte ich testen, ob das auch im Trigger-Automode so ist
> Jetzt kann ich den Trigger nur noch zwischen COMBI und NORMAL schalten,
> bei AUTO-Trigger bleibt der Haken bestehen, d.h. ich habe 2 x Haken im
> Coupling-Mode!!!

Das ist bei mir jetzt auch da!
Ich habe allerdings keine Ahnung "wie ich da hin gekommen bin".
Nach einem "Autoscale" war es wieder weg.

Gruß Bert

[Guido (Gast)]

Bert schrieb:
> Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn!

Die Einstellung orientiert sich am Browserbalken, dafür stimmt die
Drehrichtung. Was am meisten fehlt, ist eigentlich eine Taste, mit
der man die hor. Position in die Mitte des dargestellten Bereichs
bekommt. Dafür kurbelt man sich wirklich manchmal den Wolf.

[Michael W. (slackman)]

... ja, ein progressives Verhalten der Drehelemente wäre schön ;-)

irgendwo war hier im Thread jemand, der dem Scope gerne verschiedene 
Protokolle beibringen wollte um es als Logicanalyzer zu nutzen...
Ich habe mir das hier besorgt:
http://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.html?cPath=61_68

Spotbillig und wirklich ein cooooles Teil. O.k., man benötigt immer 
einen Rechner aber dafür wirklich topp!

Michel

[Michael D. (mike0815)]

...was ein lustiger Name:"Logic Sniffer"
man könnte das Teil ja glatt in das Frontpanel mit einbauen.

Gruß Michael

[Michael W. (slackman)]

Dann musst Du aber noch die Kommunikation zwischen dem Scope und dem 
Sniffer bauen, ebenso, wie die Bedienung und die Anzeige.
(Aber cool wär's schon... )

Michel

[Rainer (Gast)]

Bert, das kann ich nur sagen: "dafür"
d.h. Signal sollte der Knopfdrehung folgen

Die Drehrichtung bei der Vertikalempfindlichkeit empfinde ich auch als 
ungewohnt. Bei der Bedienung habe ich immer einen Knopf mit Zeiger vor 
Augen, der auf eine auf dem Gerät aufgedruckte Skala zeigt - Links: hohe 
Empfindlichkeit, Rechts: niedrige Empfindlichkeit.

Andere Meinungen? Wie handhaben das die "Großen" (Tek, Agilent)?

Rainer

Bert schrieb:
> Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn!
> Linksdrehung verschiebt recht, Rechdrehung verschiebt links.

[Michael D. (mike0815)]

Michael W. schrieb :
> Dann musst Du aber noch die Kommunikation zwischen dem Scope und dem
> Sniffer bauen, ebenso, wie die Bedienung und die Anzeige.
> (Aber cool wär's schon... )
>
> Michel

...ist ja beides mit USB ausgestattet, wäre eine Überlegung wert?!?

Könnte man das hier in den HW-Thread schieben? Die Seite hier ist knalle 
voll und der Seitenaufbau geht nur sehr schleppend...

@Bert
Hast du Gestern, wie du den Test nachvollzogen hast
siehe hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"  , 
mit 50 Hz Sägezahn gemessen?
Ich habe das Ganze noch mal mit 1KHz Rechteck getestet, da bleiben die 
Signale komischerweise bestehen, kann auch bis runter auf 10mV/DIV ohne 
zicken, also doch kein HW-Fehler?!?

Gruß Michael

[Rainer (Gast)]

Guido schrieb:
> Bert schrieb:
>> Die horizontale Verschiebung beim Welec bringt mich zum Wahnsinn!
>
> Die Einstellung orientiert sich am Browserbalken, dafür stimmt die
> Drehrichtung.

Um das unter einen Hut zu bekommen, hätte ich folgenden Vorschlag zur 
Bedienphilosophie:
 - der Drehregler "Horizontal" verschiebt das Signal
 - der allgemeine Drehregler "Entry knob" verschiebt das 
Fenster/Balken...

Dann hätte man für jeden Geschmack einen Regler und wäre konsistent zu 
anderen Markierungsfunktionen (z.B. Cursorpositionierung), bei denen die 
Markierungselemente auf dem Schirm in der Richtung immer dem "Entry 
knob" folgen.
Die Frage wäre dann allerdings: Wodurch/wann wird der "Entry knob" in 
seiner Funktion als Fensterverschiebeknopf aktiviert?

Rainer

[Rainer (Gast)]

@Hayo, da du gerade mit dem ext. Trigger beschäftigt bist:
Bei der Bedienung gibt es noch die kleine Unschönheit, dass der Regler 
für den Triggerlevel bei Benutzung des ext. Trigger die falsche 
Drehrichtung hat, d.h. eine Linksdrehung erhöht den Triggerlevel. Beim 
Triggern auf einen Signalkanal ist die Drehrichung andersrum und ok. (FW 
1.2.BF.1.6 C2)

Gruß, Rainer

[Blue F. (blueflash)]

@Rainer

Hab ich schon geändert, hat mich auch gestört.

@all

Beim rumfrickeln hab jetzt die nächste Baustelle gefunden. Bei der 
Pulsweitentriggerung zieht er den Source-Kanal nicht wie er soll sondern 
nimmt den der Flankentriggerung. Bin gerade dabei das zu ändern. 
Außerdem scheint mir beim externen Trigger keine Pulsweitentriggerung 
möglich zu sein. Ich hab zwar die Menüsteuerung dafür gefunden, aber die 
Registeransteuerung läßt vermuten, dass das nur heiße Luft ist.

Da hoffe ich mal auf Eure Mithilfe, da die Testerei doch enorm viel Zeit 
kostet.

Gruß Hayo

[Bert (Gast)]

Hallo Rainer,

Rainer schrieb:
> Die Drehrichtung bei der Vertikalempfindlichkeit empfinde ich auch als
> ungewohnt. Bei der Bedienung habe ich immer einen Knopf mit Zeiger vor
> Augen, der auf eine auf dem Gerät aufgedruckte Skala zeigt - Links: hohe
> Empfindlichkeit, Rechts: niedrige Empfindlichkeit.
> Andere Meinungen? Wie handhaben das die "Großen" (Tek, Agilent)?

Die Einstellung der vert. Empf. ist beim Agilent genauso wie beim Welec.
Das würde ich so lassen, sonst stimmen die Sinus-Symbole auf der 
Frontplatte nicht mehr (grosser Sinus = empfindlicher, kleiner Sinus 
weniger empfindlicher). Ich kenne das aber auch nicht anders, selbst bei 
meinem "uralt" Hameg wird es nach rechts herum immer empfindlicher.
Wenn Du Dir anstatt Empfindlichkeit "Signal-Verstärkung" vorstellst, 
dann passt es wieder. Rechts herum = hohe Verstärkung, wie beim 
Audioverstärker.

Gruß Bert

[Blue F. (blueflash)]

So, damit Ihr auch vernünftig testen könnt hier die BF.1.7

Leider mußte ich wegen einiger Änderungen am Flash die Einstellungen 
zurücksetzen. Ihr müßt also Eure Kalibrierungen und 
Hardwareeinstellungen nochmal machen.

Alle Änderungen sind im Changelog dokumentiert. Sourcen sind auch wieder 
dabei.


Please notice: Because of changes in the flash memory I had to reset the 
Hardwaresettings. You have to calibrate and justify Your settings again.

Find all changes in the changelog. Sources are included.

Hayo

[Bert (Gast)]

@Michael
Michael D. schrieb:
> @Bert
> Hast du Gestern, wie du den Test nachvollzogen hast
> siehe hier:
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"  ,
> mit 50 Hz Sägezahn gemessen?

Ich habe mit 50Hz Sägezahn getestet.
Habe es gerade nochmals versucht.
Dein Problem kann ich nicht reproduzieren.
Gruß Bert

[Rainer (Gast)]

Bert schrieb:
> Die Einstellung der vert. Empf. ist beim Agilent genauso wie beim Welec.
> Das würde ich so lassen, sonst stimmen die Sinus-Symbole ... nicht

Ok, überzeugt. Dann hat nur mein Multimeter die andere Drehrichtung.

Rainer

[Bert (Gast)]

Hallo Hayo,

erster Test 1.2.BF.1.7:
- Nach einem "Default-Setup" sollte der ext. Trigger und der TV-Trigger 
"hellgrau" sein. Ich habe wie blöde auf diesen Softkey gedrückt, bis ich 
gesehen habe, das man den jetzt unter Source anwählt. Nach dem 
Einschalten stimmt es!
- Default-Setup, Oszi-Ausschalten => gleiches Problem.
- Trigger-Kanal anwählen, Softkeys "ext. T." und "TV-T." werden grau, 
Oszi ausschalten => alles OK, Softkeys bleiben grau.

ext. Trigger aktiviert:
- keine Trigger-Level-Verstellung möglich
- keine Triggerung im Normal-Mode
- stehendes Bild bei ext. Line-Triggerung???

Bitte kläre mich mal über USTB auf.

Gruß Bert

[Torsten W. (wirehead)]

Stehendes bild bei Linetrigger und normalmode hat mich auch etwas 
gewundert.
Im Startscreen steht noch 2009 :-)

Gruß
Torsten

[Bert (Gast)]

@Hayo:
Ich fände es gut, wenn Du wenigsten alle Bugs bzgl. Trigger in einer 
Version erledigen würdest. Sonst gibt es zuviele "Versionen" und der 
Testaufwand wird auch nicht weniger.

Noch "offene" Trigger-Bugs:
- Pre-Trigger: Beitrag #1746189
- Triggermode: Beitrag #1747812
- Level-Einstellung: Beitrag #1750082
  Hayo W. schrieb:
  > Hab ich schon geändert, hat mich auch gestört.
  Nicht nur beim ext. Trigger.
  Bei mir ist die Drehrichtung bei Kanal-Triggerung immer noch falsch

Gruß Bert

[Blue F. (blueflash)]

Da hatte sich durch die umfangreichen Änderungen an den Menüs noch ein 
Fehler beim ext. Triggerlevel und bei den Drehrichtungen eingeschlichen.

Hier die zweite Compilation.


A little bug in the external trigger level display has been undetected.

Please use the second compilation

Hayo

[Guido (Gast)]

Hallo Hayo,

die Drehrichtung stimmt jetzt, aber immer noch keine externe
Triggerung und der Pegel ist bei ext.-Trig nicht änderbar.

Gruß, Guido

[Blue F. (blueflash)]

Hi Guido,

das kann ich nicht nachvollziehen, ich hab gerade alles ausprobiert - 
läuft gut (siehe Screenshot).

Ext. Trigger läßt sich gut verstellen, allerdings triggert er am Besten 
im Normal-Modus. Ich kann den Level auch aus dem Signal herausdrehen, 
dann bleibt es stehen.

Gruß Hayo

[Bert (Gast)]

erster Test 1.2.BF.1.7_C2:
- Default-Setup sollte den Triggerlevel vom ext. Trigger auf 0 setzen.
  Der wird auf -8,19V gesetzt.

ext. Trigger aktiviert:
- stehendes Bild bei ext. Line-Triggerung, jetzt aber mit 
Aktualisierung???
- Bei Normal-Mode und LF-Reject bekomme ich keinen Trigger hin.
- Keine "saubere" Triggerung bei Normal-Mode und HF-Reject (Signal 
wackelt hin und her) bei Triggerpegel von ca. halber Rechteck-Amplitude 
(2,09V, 2,29V, 2,5V).

- Die Signalflanke steht nicht auf dem Triggerpunkt, sondern "kommt" 
später (zeitverzögert). Bei Kanal-Trigger stimmt das.

Trigger-Level:
1. Trigger-Kanal 1 einstellen
2. Trigger-Level auf 2V einstellen
3. Kanal 2 aktivieren
4. Trigger-Kanal 2 einstellen => Trigger-Level wird noch von Kanal 1 
angezeigt
5. Drehen des Trigger-Levels, Startwert "war" 0V
Problem: Beim Umschalten der Trigger-Source wird der Trigger-Level des 
aktivierten Kanals nicht angezeigt, erst nach verdrehen des Levels


- Unter 875mV bekomme ich keine Triggerung bei Kanal-Trigger, bei ext. 
Trigger klappt das.


Noch "offene" Trigger-Bugs:
- Pre-Trigger: Beitrag #1746189
- Triggermode: Beitrag #1747812

So, jetzt gucke ich weiter Fußball!
Gruß Bert

[Guido (Gast)]

Ahja, im Normal-Modus bekomme ich es jetzt auch hin, sehr schön.

Was mich noch sehr stört ist die Pretrigger-Einstellung. Wenn da
die Anzeige von µs auf ns umspringt und ich von 999 in
Einerschritten runterkurbeln soll, kriege ich die Krise. Das
passiert aber nicht immer, eine Systematik dahinter habe ich
noch nicht entdeckt. Könnte man das nicht prozentual auf die
Samplingtiefe beziehen, z.B. in 5-%-Schritten? Wenn du da einen
Suchbegriff für die Source hättest, würde ich mir das mal ansehen.

Gruß, Guido

[Rainer (Gast)]

Hayo W. schrieb:
> Ext. Trigger läßt sich gut verstellen, allerdings triggert er am Besten
> im Normal-Modus. Ich kann den Level auch aus dem Signal herausdrehen,
> dann bleibt es stehen.

Einen wunderschönen guten Abend,

mit Sinus 50 Hz 1.5 V ist bei mir extern, normal, hf_rej getriggert kein 
stehendes Bild hinzubekommen. Bei Triggerung auf Line erfolgt gar keine 
Aufzeichnung.

Die von dir, Bert, beschriebenen Probleme mit den X1-X2 Cursorn beim 
Delay-Fenster und das fehlende Update der Triggerlevelanzeige bei 
Wechsel des Triggerkanals treten bei mir auch auf. Die Anzeige vom 
Triggerlevel wird auch aktualisiert, wenn man die Auswahlliste für den 
Triggerkanal noch mal öffnet (ohne den Kanal zu ändern).

Rainer

[Michael D. (mike0815)]

Hallo Bert,

zu deinen Verweisen:

>Noch "offene" Trigger-Bugs:
>- Pre-Trigger: Beitrag #1746189
>- Triggermode: Beitrag #1747812
>- Level-Einstellung: Beitrag #1750082

...damit kann man schlecht was anfangen!

Wenn du den Curser über den Orangen Text hälst und mit der rechten 
Maustaste den Link (vom Topic)in deinen Beitrag kopierst, gelangt man zu 
dem Beitrag den du meinst, mit den Beitragsnummern kann das hier Keiner 
nachvollziehen.
...danke schon mal!

Gruß Michael

[Moritz Z. (moud)]

Michael D. schrieb:
> ...damit kann man schlecht was anfangen!

Jetzt kann ich auch was positives Beitragen ;-)
Einfach die Beitragsnummer hinter die URL kopieren, dann kommst du zum 
richtigen.

Hier die direkten Links:
Pre-Trigger: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Triggermode: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Level-Einstellung: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

Schönen Abend noch,
Gruß,
Moritz

[Rainer (Gast)]

Um etwas Klarheit in die unterschiedlichen Befunden mit dem externen 
Trigger zu bringen, habe ich noch mal probiert:

  Signal:    Rechteck mit +/- 400 mV, 1kHz (ProbeComp),
  Ablenkung: vert hor. 200 us/div
  Trigger:   extern, Norm., HF rej.

Triggerlevel
  < -350 mV:      stabiler Trigger, immer fallende Flanke,
Flankenwahl wird aber ignoriert
  -350 .. 300 mV: mehr oder weniger instabiler Trigger
  >= 500 mV:      kein Trigger

Muß man das verstehen? Mit Trigger auf Auto ist gar nichts anzufangen.

Außerdem ist
1. bei den Rastwerten für den ext. Triggerlevel treten viele krumme 
Werte und eine Unsymmetrie um die 0 auf (in mV: ..., -550, -350, -100, 
0, 100, 300, 500 ..., 1.29, ...).

2. nach "Default Setup" und Umschaltung auf ext. Trigger, Norm wird
oben rechts nicht der aktuelle Level angezeigt (Updateproblem s.o.) und 
der Wert sollte auf Default 0.0 gesetzt werden (nicht -8,19 V, s. Bert)

3. die fallende Signalflanke kommt, unabhängig von der 
Horizontaleinstellung, anscheinend immer etwa 15 Pixel hinter der 
Triggermarke.

4. Cursor: Beim Verschieben des Cursors wird der Zahlenwert bei mir
  erst endlose 5 s später aktualisiert. Vorschlag: 1 s

@Hayo: Ganz großes Lob für die engagierte Arbeit!!! Wo nimmst du bloß 
die Zeit her?

Rainer

[Blue F. (blueflash)]

Rainer schrieb:

> Muß man das verstehen? Mit Trigger auf Auto ist gar nichts anzufangen.

Ja, das hab ich auch schon festgestellt, aber vermutlich läßt sich das 
auch nicht ändern, da das eine Hardwaresache zu sein scheint. Ich werde 
aber trotzdem nochmal forschen ob da was machbar ist.

> Außerdem ist
> 1. bei den Rastwerten für den ext. Triggerlevel treten viele krumme
> Werte und eine Unsymmetrie um die 0 auf (in mV: ..., -550, -350, -100,
> 0, 100, 300, 500 ..., 1.29, ...).

Das liegt daran (siehe oben) dass ich jeden einzelnen!!!! Wert des jetzt 
statt 32 auf 112 Werte vergrößerten Werte-Arrays mit dem Multimeter 
ausgemessen habe, und die Registerwerte weggelassen habe die nicht 
funktionierten. Das sind die Werte direkt um Null, da lief das Signal 
einfach durch, und die Werte ganz oben im positiven Bereich, da hing das 
Sgnal dann komplett und es ging nix mehr.

> 2. nach "Default Setup" und Umschaltung auf ext. Trigger, Norm wird
> oben rechts nicht der aktuelle Level angezeigt (Updateproblem s.o.)

ist in Arbeit

> und der Wert sollte auf Default 0.0 gesetzt werden
> (nicht -8,19 V, s. Bert)

schon geändert

> 3. die fallende Signalflanke kommt, unabhängig von der
> Horizontaleinstellung, anscheinend immer etwa 15 Pixel hinter der
> Triggermarke.

bin ich gerade dabei, sieht schon ganz gut aus...

> 4. Cursor: Beim Verschieben des Cursors wird der Zahlenwert bei mir
>   erst endlose 5 s später aktualisiert. Vorschlag: 1 s

Meinst du den Timeout für das Browserfenster?? Soll ich den 
runtersetzen? Aber 5s sind das doch nicht.

> @Hayo: Ganz großes Lob für die engagierte Arbeit!!! Wo nimmst du bloß
> die Zeit her?
...frag mal meine Frau, die sieht mich kaum noch.

Gruß Hayo

[Michael D. (mike0815)]

Hi Hayo,

Hayo W. schrieb :
> Meinst du den Timeout für das Browserfenster?? Soll ich den
>
> runtersetzen? Aber 5s sind das doch nicht.

Nein, nicht das "Browserfenser", das ist ja i.O. so!

Rainer mein den "Curser-Modus", verschiebst du da die "X1, X2 und oder 
Y1,Y2, braucht das eine kleine Ewigkeit, bis unten die Werte angezeigt 
werden (Frequenz und Spannungs-Aktualisierung)

Gruß Michael

Edit: Jetzt hat sich wieder dieser dämliche Prob-Pinöfkel bei mir 
verabschiedet, jetzt hab' ich noch eine BNC-Buchse eingebaut und das 
Teil da angeschlossen...

[Bert (Gast)]

Hallo Leute,

hier meine zweite und letzte Version des Agilent-Erfahrungsberichtes.
Das Thema "Bedienung", schein hier kein besonderes Interesse zu finden.

Gruß Bert

[Stefan (Gast)]

Den Browserbalken finde ich durchaus nützlich zur Orientierung.

[Blue F. (blueflash)]

Michael D. schrieb:

> Rainer mein den "Curser-Modus", verschiebst du da die "X1, X2 und oder
> Y1,Y2, braucht das eine kleine Ewigkeit, bis unten die Werte angezeigt
> werden (Frequenz und Spannungs-Aktualisierung)

Ja ich weiß, das ist etwas nervig, aber da kann ich leider nichts 
machen, denn das dauert so lange, weil ein ganzer 
Hauptschleifendurchlauf abgearbeitet wird und dann noch die Werte 
berechnet werden. Einzige Abhilfe ist hier möglichst nur einen Kanal 
aktiv zu haben.

Gruß Hayo

[Rainer W. (rawi)]

Bert schrieb:
> Das Thema "Bedienung", scheint hier kein besonderes Interesse zu finden.

Wie kommst du da drauf? Ich finde, dass der Trigger gerade große 
Fortschritte macht und genug Baustellen offen sind, zumal Hayo das alles 
im Code umsetzen muß.

zu 1. Reaktion auf Drehregler läßt beim Welec noch Wünsche offen...
zu 2. Triggerlevel als temporäre Linie finde ich sehr gut
zu 3. Drehrichtung Hor.-Position: ändern, d.h. als Signalverschieber 
lesen
      Browserbalken: finde ich praktisch wegen Visualisierung PreTrigger

Das Agilent kennt wahrscheinlich gar keine PreTrigger Einstellung 
sondern steuert alles über den Fangpunkt, oder? Hört sich überlegenswert 
an.

zu 4. Run/Stop: Agilent absolut überzeugend, "dafür"

zu 5. X1-X2 Limit-Konzept ist sinnvoll. Beim Welec ist die Veränderung 
des Intervalls, nur weil man mal gegen den Rand gestoßen ist, unmöglich.
Die Fehlermeldung "Limit..." halte ich fast für entbehrlich.

zu 6. Das Delay-Fenster beim Welec kommt mir wie das Digital-Zoom bei 
Kameras vor (keine echte 2.te Zeitbasis, sondern gestreckte Anzeige 
ohnehin vorhandener Samples oder täusche ich mich da?).

Noch was anderes
X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die 
Position auf den Bildschirm bezieht. Eigentlich ist doch die 
Triggerposition das Maß der Dinge. Wie macht das Agilent?

So, dass mag erstmal genug sein. Gruß Rainer

[Michael D. (mike0815)]

Hi Rainer, dich gibt's ja noch!

>Noch was anderes
>X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die
>Position auf den Bildschirm bezieht. Eigentlich ist doch die
>Triggerposition das Maß der Dinge. Wie macht das Agilent?

Wie willst du das denn umsetzen?
Das Grid fängt ja links bei "0" an, wenn du mitten drinnen bist...dann 
müsste z.B. der X1 Curser immer auf "0" stehen, das wäre natürlich sehr 
Praktisch!
Nur müsste das Grid-Raster dann immer mit ziehen, so das X1 immer auf 
"0" sitzt.
Vielleicht kann Hayo das ja umsetzen!
... ich kann mir vorstellen, das das eine Menge Arbeit ist, da sieht ihn 
seine Frau noch weniger...:)))


Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen 
und hatte ein unmögliches Bild!
Jetzt kommt's: Verschiebe ich den Sinus nach rechts (Browser ist 
sichtbart)
Wird das Signal plötzlich sauber, schiebe ich das Ganze wieder nach 
links, habe ich wieder überall Knicke drin. Kann das Jemand bestätigen?
Rainer, du hast doch da einen HF-Generator, kannst du das mal nach 
meiner Beschreibung testen?

Gruß Michael

[Guido (Gast)]

Michael D. schrieb:
> Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen
> und hatte ein unmögliches Bild!

Der ICS511 kann doch garkeinen Sinus. Mit einem 100-MHz-Rechteck sind
Probleme doch normal.

Gruß, Guido

[Rainer W. (rawi)]

Michael D.:
>>X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die
>>Position auf den Bildschirm bezieht. Eigentlich ist doch die
>>Triggerposition das Maß der Dinge. Wie macht das Agilent?
>
> Wie willst du das denn umsetzen?

Gar nicht so kompliziert. Der Zahlenwert soll einfach die Zeitdifferenz 
zwischen Cursor und Trigger angeben, d.h. Cursor links vom Trigger -> 
negativer Wert, auf Trigger -> 0.0, rechts vom Trigger -> positiver Wert

> Apropos "Bowser" ...ich bin mit dem ICS511 mal auf 100MHz Sinus gegangen
> und hatte ein unmögliches Bild!
> Jetzt kommt's: Verschiebe ich den Sinus nach rechts (Browser ist
> sichtbart)
> Wird das Signal plötzlich sauber, schiebe ich das Ganze wieder nach
> links, habe ich wieder überall Knicke drin.

Das kann ich so bestätigen. Sobald die Triggermarke deutlich links 
außerhalb liegt, wird's unsauber. Bei mir passiert das, wenn das Noise 
Filter eingeschaltet ist. Das verferkelte Signal sieht aus, als ob das 
Filter plötzlich aus ist.

Rainer

[Michael D. (mike0815)]

Hi Guido,

jetzt bin ich aber etwas überrascht, was ist dann das hier?

Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
siehe Bild 2

@Rainer

...mal schauen, was der Hayo dazu meint, der wird's schon richten...

Gruß Michael

[Bert (Gast)]

Hallo Rainer,
Rainer W. schrieb:
> Das Agilent kennt wahrscheinlich gar keine PreTrigger Einstellung
> sondern steuert alles über den Fangpunkt, oder? Hört sich überlegenswert
> an.

Agilent hat keinen Pretrigger!
Es gibt die Timereferenz mit folgendem Zweck:
1. Schnelle "weite" Verschiebung (um 4 und 8 Kästchen) des Bildes ohne 
Triggerverstellung und ohne "Kurbelei" an der hor. Verschiebung. Das 
geht blitzschnell mittels Drehknopf und Timereferenz-Verstellung 
"Left", "Center", "Right"!

2. Direkte Zeitanzeige Trigger zur Timereferenz. Durch hor. Verschiebung 
des Triggerpunktes hat man immer eine direkte Zeitanzeige zu einer 
beliebigen Stelle, die man auf die Timereferenz positioniert.

3. Beim hor. Verschieben ist die Timereferenz ein "Fangpunkt".
Das "Fangen" dient nur zum einfacheren Positionieren des Triggerpunktes 
auf die Timereferenz.

Wenn ich das richtig kapiert habe, dient beim Welec der Pretrigger zum 
Verschieben des Triggerpunktes.
Da gefällt mir die Agilent-Bedienung wesentlich besser! Bei Anzeige der 
Timereferenz, Triggerpunkt und Zeitanzeige brauche ich keinen Browser.

Rainer W. schrieb:
> Noch was anderes
> X-Cursor: Ich finde es unpraktisch, dass sich der Zahlenwert für die
> Position auf den Bildschirm bezieht. Eigentlich ist doch die
> Triggerposition das Maß der Dinge. Wie macht das Agilent?

Beim Agilent sind die X1- und X2-Zeiten die Zeit zum Trigger-Punkt!
Bei Cursor-Aktivierung und Haken bei X wird dann folgendes angezeigt:
X1-Zeit im Softkey, X2-Zeit im Softkey, Delta X, 1/Delta X (Frequenz) 
und Delta Y.

Gut gefällt mir beim Agilent auch, das die Y-Cursor sich beim 
Verschieben der Signal-Nullinie automatisch mitbewegen!

Es ist sicher kein Fehler sich an Agilent (bzw. ehemals HP) zu 
orientieren.
Die bauen Oszis schon wesentlich länger als Welec und wissen genug über 
"Bedienkomfort"! Auch wegen dem fast identischem Design, Beschriftung 
und Bedienelementen macht das schon Sinn.

Gruß Bert

[Michael D. (mike0815)]

Hi Bert,

>Gut gefällt mir beim Agilent auch, das die Y-Cursor sich beim
>Verschieben der Signal-Nullinie automatisch mitbewegen!

Wie sieht es denn da mit den X-Cursern aus, gehen die beim horizontalen 
verschieben auch mit?
Beim Welec muß ja immmer alles manuell nach gerückt werden.
Ab 2mS orientieren sich diese am Gridraster, finde ich jetzt bei hohen 
Frequenzen ein bißchen grob.

@Guido
Ich nehme an, das du den ICL501 (nicht ICS) extern ansteuerst, da kommt 
natürlich immer ein Rechteck raus, egal was du ihm zu Füttern gibst.
Ich habe die Schaltung so ausgelegt, das ich extern einspeisen kann und 
als Standalone mit whlweiser Quarzbestücken betreiben kann.
Bei der Quarz-Variante, haut der nur Sinus raus, wie im HW-Thread 
bebildert.
Ich setze dort mal das Layout rein, schau's dir mal an.

Gruß Michael

[Bert (Gast)]

Hi Michael,

nein, bei Y-Verschiebung bleibt in X-Richtug alles so wie es ist.
Übrigens: Bei Y-Verschiebung gibt es auch eine "Fangfunktion" in der 
horizontalen Bildschirm-Mitte. Ist echt klasse zu Bedienen das Agilent, 
liegt aber auch ander hohen Anzahl Rastungen pro Umdrehungen der 
Drehschalter.

Gruß Bert

[Stefan V. (vollmars)]

Hi Michael,

der Chip heißt ICS501 oder ICS511 und produziert immer Rechteck.
Wenn du was anderes gemessen hast, sind das Artefakte.

Gruß Stefan

[Michael D. (mike0815)]

Stefan V. schrieb:
> Hi Michael,
>
> der Chip heißt ICS501 oder ICS511 und produziert immer Rechteck.
> Wenn du was anderes gemessen hast, sind das Artefakte.
>
> Gruß Stefan

Hi Stefan,

du hast natürlich Recht, ich weiß auch nicht, wie ich auf ICL kommme!

Ok, das 1. Foto zeigt Input 1MHz. und Output ICS511 4MHz.

2. Foto ist mit Quarz bestückt als Standalone und 6fach 112MHz, das sind 
jetzt Artefakte?

Gruß Michael

[Stefan V. (vollmars)]

Hi Michael,

wie du auf deinem ersten Foto sehen kannst, hat das Outputsignal des 
ICS511 eine große Anstiegszeiten, d.h. hohe Frequenzen werden stark 
gedämpft.
Entsprechend ist das 112MHz Signal auch viel schwächer. Die erste und 
einzige messbare (nach Abtasttheorem) Oberwelle bei 336MHz ist noch mehr 
gedämpft. Daher kommt das Signal einem Sinus sehr nahe.

Gruß Stefan

[Michael D. (mike0815)]

na toll, was eine Blamage!

[Rainer W. (rawi)]

'n schönen guten Abend,

ein echter 100 MHz Sinus sieht bei mir so aus:
(Noise Filter immer eingeschaltet)

Bild 1: Triggerposition mittig, alles ok
Bild 2: Triggerposition ordentlich nach links rausgeschoben, kaputt

Trotz vernünftig eingestelltem Trigger zappelt das Signal heftig, aber 
das könnte wohl eher ein Hardwareproblem sein (Bandbreite 
Triggerelektronik).

@Michael: Oder bekommst du ein sauber stehendes Bild?

Rainer

[Rainer W. (rawi)]

Noch ein Nachtrag zu dem kaputten Sinus:

Ich hatte gerade den Effekt, dass auf dem Bildschirm ein Teil des 
Signals noise-gefiltert (links) und ein anderer Teil (rechts) 
ungefiltert dargestellt wird. Die Grenze läßt sich mit dem Regler 
H-Position verschieben. Es sieht aus, als ob das Noise-Filter nicht auf 
alle Samples angewandt wird.
Hayo, vielleicht gibt dir das eine Idee für die Ursache.

Rainer

[Michael D. (mike0815)]

Jetzt haben wir hier 6 Seiten? Sehr Gute Idee, jetzt kann man hier 
endlich ohne Zicken schreiben!!!

Hi Rainer,
Bei mir ist das genau dasselbe wie bei dir!
Das Signal bleibt aber Horizontal einigermaßen ruhig, es schwingt in der 
Vertikalen ein wenig!

Ausserdem, hat Guido und Stefan recht, mein 100MHz Sinus ist in 
Wirklichkeit ein veranztes Rechteck!!! Schön blamiert, hab' ich mich 
da...

Ich habe wenigstens 8 MHz Output (Input 1MHz mit ICS511)gut hin 
bekommen.
Es ist unglaublich, was eine Tastkopp-Justage(1:10) alles bewirkt!
Ausser dem Trimmer am Kopf sollte man noch ein wenig an den 2 Potis am 
BNC-Stecker kurbeln, ich war überrascht, was da noch ging!
Ich glaube, das die originalen Tastk. nicht so optimal sind!

Gruß Michael

[Rainer W. (rawi)]

Hi Michael,

Das Anheben von hohen Frequenzen mit den Trimmern am Tastkopf ist kein 
Problem, aber sieht ein Rechteck dann auch noch ok aus oder hast du dir 
damit kräftige Überschwinger eingehandel?

Gibt es eigentlich eine Abgleichanleitung zu den Original-Tastköpfen?

Gruß Rainer

Michael D. schrieb:
> Es ist unglaublich, was eine Tastkopp-Justage(1:10) alles bewirkt!

[Michael D. (mike0815)]

Hi Rainer,
Hast ja ein Sinus wie gemalt...

Rainer W. schrieb:
> Hi Michael,
>
> Das Anheben von hohen Frequenzen mit den Trimmern am Tastkopf ist kein
> Problem, aber sieht ein Rechteck dann auch noch ok aus oder hast du dir
> damit kräftige Überschwinger eingehandel?

Wie du oben in den Fotos siehst, hatte ich die ja voher!
2Std. hab' ich da rum gemacht, bis ich endlich ein paar Steile Flanken 
in das Rechteck bekommen habe!

Siehe 1. Foto nach der Justage
      2. Foto vor der Justage

>
> Gibt es eigentlich eine Abgleichanleitung zu den Original-Tastköpfen?

Ja die gibt's, ist aber sehr dürftig beschrieben: Prob 1KHz Rechteck 
dann solange am Kopf (Kondensator-Trimmer) drehen bis die Spikes oben 
und unten verschwinden, das war's !
Mit den 2 Potis am BNC-Stecker, geht noch mehr, ist in der Anleitung 
aber  nicht beschrieben! Ich selber, muß da noch ein wenig 
experimentieren...
>
> Gruß Rainer
>
> Michael D. schrieb:
>> Es ist unglaublich, was eine Tastkopp-Justage(1:10) alles bewirkt!

Das mit der horizontalen Verschiebung ist ja eine böse Falle! Wenn man 
das nicht weiß, könnte man denken, das der FG im Eimer ist.
Im Delay-Modus ist das auch, da kommt von Rechts der ganze Müll an und 
zappelt sich einen ab!

Gruß Michael

[Guido (Gast)]

Hallo Rainer und Michael,

seid mir nicht böse, aber ein wenig Grundlagenwissen würde viele
eurer Probleme zum Verschwinden bringen. Ich bin mir nicht sicher,
ob dieser Thread so geeignet ist Anfängerfragen zur Bedienung
von  Oszilloskopen oder den Grundlagen der Signaltheorie zu
erörtern.

Grüße, Guido

[Bert (Gast)]

Hallo,
Rainer W. schrieb:
> ein echter 100 MHz Sinus sieht bei mir so aus:
> (Noise Filter immer eingeschaltet)
> Bild 1: Triggerposition mittig, alles ok
> Bild 2: Triggerposition ordentlich nach links rausgeschoben, kaputt

Ich habe ein ähnliches Problem:
Wenn ich den Anzeigebereich im Browserbalken ganz nach rechts 
verschiebe, befinden sich am rechten Bildrand fehlerhafte Abtastwerte. 
Das passiert mit und ohne Noise-Filter.
Ich kann mich erinnern, das dieses oder ein ähnliches Problem 
(Abtastfehler am Speicher-Ende) schon mal diskutiert wurde. Ich weiß 
aber nicht mehr, ob das Problem behoben wurde, oder ob es ein 
Hardware-Problem ist.

Gruß Bert

[Bert (Gast)]

Und noch einige Bilder, weil sie so "schön" sind.

[Bert (Gast)]

So, jetzt habe ich Kaffee getrunken und bin wach!
Nun die Bilder im richtigen Bildformat!

[Bert (Gast)]

Hallo,

mit ein bischen "Spielerei" an der Zeitbasis bekommt man tolle Bilder 
hin!
Anmerkung: Das sind keine Singleshots, sondern die Ansicht bei laufender 
Triggerung ???
Kanal 1 ist Sinussignal
Kanal 4 ist der Synch.-Ausgang meine Funktionsgenerators.

Gruß Bert

[Bert (Gast)]

Screenshot_0016 oben ist zu gering abgetastet, da würde ich die 
Darstellung noch als korrekt bewerten.

Screenshot_0019:
Kanal 1 ist ein ca. 5400 Hz Sinus, parallel mit Analog-Oszi 
kontrolliert.
Es werden nur noch ca. 3 Kästchen des Bildes aktualisiert, der Rest 
steht still.

[Bert (Gast)]

Default-Setup ausgeführt, Trigger-Source auf 4 gestellt, ein bischen an 
der Zeitbasis gedreht und dann dieses Ergebnis:
Screenshot_0020.
Hier wird das ganze Bild aktualisiert.

Auf dem Analog-Oszi sieht alles noch bestens aus!

[Bert (Gast)]

kleiner Hinweis:
Man achte im Screenshot_0020 und manchen anderen Bildern auf das rechte 
"T", das außerhalb des Browser-Balkens steht!!
Das Problem könnte was mit dem Browser-Balken tun haben!!

[Bert (Gast)]

Ich bekomme das Problem relativ oft hin, wenn ich die Zeitbasis 
schnell um mehrere Stufen in Richtung kleinere Zeitbasis verstelle.

[Blue F. (blueflash)]

Rainer W. schrieb:
> Noch ein Nachtrag zu dem kaputten Sinus:
>
> Ich hatte gerade den Effekt, dass auf dem Bildschirm ein Teil des
> Signals noise-gefiltert (links) und ein anderer Teil (rechts)
> ungefiltert dargestellt wird. Die Grenze läßt sich mit dem Regler
> H-Position verschieben. Es sieht aus, als ob das Noise-Filter nicht auf
> alle Samples angewandt wird.
> Hayo, vielleicht gibt dir das eine Idee für die Ursache.

Interessanter Hinweis, leider komme ich im Augenblick wegen des 
Gefrickels am Trigger nicht dazu die Sachen nachzustellen. Hole ich aber 
nach.



@Bert

Nochmal der Hinweis zum Screenshot: Den Quickprint-Button zweimal kurz 
hintereinander drücken, dann kann man auch das aktuelle Menü im 
Screenshot sehen, was bei den meisten Sachverhalten ganz hilfreich ist.

Gruß Hayo

[Rainer W. (rawi)]

Hallo

@Hayo: Lass dich nicht stören, der Trigger ist wichtig!

Bei der Einstellung des PreTriggers bin ich noch auf ein Bedienproblem 
gestoßen: Wenn man die Zeit immer weiter erhöht, springt der Wert 
irgendwann zyklisch vom Maximalwert auf 0 zurück. Dann geht die Kurbelei 
von vorne los. Besser wäre IMO wenn er oben hängen bliebe, zumal man 
durch Drehung nach links von der 0 nicht zu den hohen Werten kommt.

@Guido: Sorry für den Exkurs. Zurück zu Abtastjitter, ADC Interleave 
Phase und Ausbügelung durch das Noise-Filter (auf dem ganzen Signal).

@Bert: Deine sporadischen Spikes
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
waren, soweit ich mich erinnere, auf unsauberes Timing im FPGA geschoben 
worden. Die neuen: sehr mysteriös.

Nun habe ich noch einen Bug mit systematisch falschen Daten: 
(samples01,02)
Gerade bin ich mal wieder auf die systematisch falschen Daten am Ende 
jedes (?) aufgezeichneten Signals gestoßen. Die letzten Pixel hängen auf 
im Signal nicht vorhandenen Werten. Meist rauschen sie um eine feste 
Bildschirmposition (samples01), manchmal aber auch ohne Rauschen ganz am 
unteren Rand (samples02). Wenn man das Signal vertikal verschiebt oder 
die Höhe des Signals ändert, bleiben diese Pixel trotzdem auf der 
gleichen Bildschirmhöhe und trotzdem rauschen sie munter vor sich hin. 
Als Signal liegt das Rechteck vom Probe Comp an, unten ist das Signal 
übers Delay-Fenster vergrößert, ganz rechts jeweils die bösen Pixel.

Gruß Rainer

[Jürgen (Gast)]

Hallo Hayo,

erstmal Respekt und vielen Dank für Deine gute Arbeit an der Firmware!

Ich teste hier an der Extern Synchro herum und meine, daß die Belegung 
der "SwitchesTB" im Vergleich zu den Hardwareplänen falsch ist. Es 
sollte sein:

LF Reject : SwitchesTB = 0xC0;
HF Reject :            = 0x80;
Line      :            = 0x40;
TV        :            = 0x00; ( siehe hardware_t.cpp ab zeile 2299 )

Ausserdem muss beim Umschalten auf Line der "Trigger_Pos_CHE" ebenfalls 
auf 64 resetet werden!

Kannst Du das mal prüfen?

Testmöglichkeit in der BF 1.7.C2: Wenn bei "Line" ein Signal zu sehen 
ist, muß beim Abziehen des Kabels von der Externen Buchse das Signal 
unverändert zu sehen sein. Macht die Version aber nicht:-(

Gruß,
Jürgen

[Blue F. (blueflash)]

Ok Jürgen -> checke ich mal durch.

Gruß Hayo

[Blue F. (blueflash)]

@Jürgen

Ich hab das mal so nach Deinen Vorgaben eingebaut. Scheint ganz gut zu 
funktionieren. Line geht schon mal ganz anständig, ob HF und LF jetzt 
richtigrum sind konnte ich nicht rausfinden. Da ist dann der Rest 
unseres Teams hier gefragt.

Der Nullpunkt bei Default Setup stimmt jetzt auch.

@all

Möchtet Ihr den aktuellen Stand als nächste Version schon haben, oder 
soll
ich lieber (wie weiter oben angemerkt wurde) sparsamer mit den Versionen 
umgehen und noch warten?



Gruß Hayo

[Jürgen (Gast)]

Hayo W. schrieb:
> Ich hab das mal so nach Deinen Vorgaben eingebaut. Scheint ganz gut zu
> funktionieren. Line geht schon mal ganz anständig, ob HF und LF jetzt
> richtigrum sind konnte ich nicht rausfinden. Da ist dann der Rest
> unseres Teams hier gefragt.

Na super!Wenn "Line" funktioniert, passt auch der Rest. C34 und R42 ist 
ein Hochpass.Was dahinter abgeht,ist somit LF Reject.

> Der Nullpunkt bei Default Setup stimmt jetzt auch.

Falls Du den Nullpunkt des Triggereingangs nach der PWM meinst: Der 
sollte auch bei "Line" auf ca. 0V gesetzt werden, da der andere Eingang 
von U6 dann über R44 ebenfalls auf GND liegt. Deshalb nicht nur beim 
Default Setup.

> Möchtet Ihr den aktuellen Stand als nächste Version schon haben,...

Jo,natürlich!Kannst ja nur mal die Source zippen und unter markantem 
Namen hier einstellen.

Grüße

[Jürgen (Gast)]

Noch ein Gedanke zur Bedienung:

Guido schrieb:
> Was mich noch sehr stört ist die Pretrigger-Einstellung. Wenn da
> die Anzeige von µs auf ns umspringt und ich von 999 in
> Einerschritten runterkurbeln soll, kriege ich die Krise.

Das ist wirklich lästig!
Bei "Pulse With" kann man aber durch mehrfaches Drücken der 
Funktionstaste den Wert in Zehnerpotenzen verstellen und danach durch 
drehen am Rad in Einerschritten weiter machen.Dadurch ist man schnell im 
richtigen Bereich und kann trotzdem fein genug einstellen.
Wäre das nicht eine Methode für die Pretrigger Einstellung?

Gruß Jürgen

[Bert (Gast)]

@Jürgen:
Jürgen schrieb:
> Na super!Wenn "Line" funktioniert, passt auch der Rest. C34 und R42 ist
> ein Hochpass.Was dahinter abgeht,ist somit LF Reject.

Bis hier konnte ich folgen.

Aber wo ist der Tiefpaß für HF-Reject?
Den habe ich noch nicht ausfindig gemacht.

Gruß Bert

[Jürgen (Gast)]

Bert schrieb:
> Aber wo ist der Tiefpaß für HF-Reject?
> Den habe ich noch nicht ausfindig gemacht.

Ich auch nicht!
Auf dem Foto ist nunmal zu sehen, daß da eine direkte Verbindung vom OPV 
Ausgang 1 zum Analogschalter Eingang 4 ist. Bleibt noch der FPGA....


Gruß Jürgen

[Blue F. (blueflash)]

Egal, das könnt Ihr jetzt testen. Hier die BF.1.8

Ich hab noch einige Sachen überprüft, daher erst jetzt.


Gruß Hayo

[Rainer W. (rawi)]

Hayo W. schrieb:
> Egal, das könnt Ihr jetzt testen. Hier die BF.1.8

Hallo Hayo,

ich habe mir den externen Trigger angesehen, leider scheint da immer 
noch der Wurm drin zu sein.
Mit Trigger Einstellung "Normal", "Line" läuft ein an CH1 anliegendes 50 
Hz Netzsignal munter durch. Die Änderung der SwitchesTB-Werte hat 
immerhin schon mal dazu geführt, dass jetzt auch ohne Signal an "Extern" 
gesampled wird; aber das Bild synchronisiert nicht. Mit LF rej. wird 
zwar synchronisiert, aber die Phase folgt nicht dem Triggerlevel und das 
Bild steht zeitlich nicht sauber. Bei HF rej. ist es eigentlich gar 
nicht zum Stehen zu bekommen. Wahrscheinlich bin ich zu blöd ????
Zur Not müßte man mal ansehen, was an U18 Pin 12 (Ext_Syncro_V1.1) so 
los ist.

Der Trigger auf Signallevel Ch1..Ch4 läuft sauber.

Gruß Rainer

[Blue F. (blueflash)]

Hallo Rainer,

interessant wären noch ein paar Details zu Deinen Messungen (z.B. via 
Screenshot oder auch hier als Text) und zwar die Signalform, Frequenz, 
Messbereich und Signallevel/Triggerlevel.

So habe ich z.B. den Eindruck dass es besser geht bei Rechtecksignalen 
und Frequenzen < 5 MHz und schlechter bei Sinus und F > 5 MHz. Aber das 
habe ich noch nicht bis ins Detail getestet.

Der Line Trigger hat bei mir ein stehendes Signal (Rechteck, Vpp 15V) 
bei genau 47,5 Hz erzeugt. Das kommt also eigentlich ganz gut hin.

Witzigerweise kann man den Line Trigger auch erzeugen wenn man auf HF 
Reject mit Tr.Level 0V triggert.

Grundsätzlich möglichst den Triggerlevel ungleich 0V wählen, z.B. 2,5V 
-> dann geht es meistens besser.

Gruß Hayo

[Blue F. (blueflash)]

Übrigens,

der Link

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

ist jetzt wieder aktuell. Der "Download Now" Button verweist wieder auf 
die aktuellste Datei.

Gruß Hayo

[Rainer W. (rawi)]

Hayo W. schrieb:
> interessant wären noch ein paar Details zu Deinen Messungen (z.B. via
> Screenshot oder auch hier als Text) und zwar die Signalform, Frequenz,
> Messbereich und Signallevel/Triggerlevel.

Das Signal sieht nicht weiter spannend aus, halt 50 Hz Netzsinus aus 
einem Steckernetzteil mit nominell 9V AC. Bei Trigger "Line" sollte das 
Bild damit eigentlich automatisch stehen - tut es aber nicht.

Was wird bei "Line" eigentlich als Triggerlevel (Ausgang U16) gesetzt?

Rainer

[Blue F. (blueflash)]

Rainer W. schrieb:

> Was wird bei "Line" eigentlich als Triggerlevel (Ausgang U16) gesetzt?

0.00V - bzw. der Registerwert 0x80

Ich prüfe das nochmal mit der Line Triggerung.


Gruß Hayo

[Jürgen (Gast)]

Hayo W. schrieb:
> Egal, das könnt Ihr jetzt testen. Hier die BF.1.8

Hallo Hayo,

habe leider gerade zu wenig Zeit, um tiefer zu testen. Deshalb nur ein 
paar Beobachtungen und Bemerkungen:

1. Leider kann ich die beiliegende TomCat.flash nicht aus den Sourcen 
1.8 compilieren. Es gibt sehr viele Abweichungen zur beiliegenden 
TomCat.flash aus dem Archiv! Gibt es verschiedene Versionen des 
Compilers? Welche Version nutzt Du? Kannst Du mal das Makefile posten? 
Vielleicht liegt es an Optimierungen? Ich compiliere unter WinXP.

2. Mein Compilat läuft aber auch. Kann Rainers Beobachtungen nicht 
komplett bestätigen. Das "Durchlaufen" bei "Norm + Line" sieht eher aus 
wie vier verschiedene Startpunkte für die Displaydarstellung. Die Kurve 
wird nacheinander offenbar um 1 Pixel versetzt gezeichnet und dann 
wieder vom Startpunkt. ( Ch1 und Extern mit Signal belegt )

3. Habe beim Externen Trigger wieder mal das Problem, daß die Kanäle 3 
und 4 nur bei jeder 1. Displayrunde gezeichnet werden. D.h. es wird bei 
jeder 2. Runde nur eine exakt gerade, horizontale Linie für Kanal 3+4 
dargestellt. ( ohne Signal an 3+4 ! ) Ich erinnere mich dunkel, das es 
dieses Problem schon mal gab und Du es behoben hast! Es tritt im 
Ch-Trigger bei Ch1 -  Ch4 nicht auf!

Gruß Jürgen

[Jürgen (Gast)]

Hab den alten Beitrag zu Extern und Ch3+4 eben gefunden:

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


Gruß Jürgen

[Blue F. (blueflash)]

Ok,

ich hab einiges getestet. Auf den Bildern sieht man ein Sinussignal vom 
Funktionsgenerator. Bei beiden Frequenzen steht das Bild auch im Normal 
Mode. Wie ich aber festgestellt habe ist das auch noch von der 
Einstellung des Gerätes abhängig.

Mit dem echten Netzsignal (das exakt 50 Hz hat)  bekomme ich auch ein 
stehendes Bild, aber nur wenn ich die anderen Kanäle ausschalte und 
Quickmeasure aktiviere. Sobald ich das ändere fängt es mehr oder weniger 
stark an durchzulaufen - sehr merkwürdig. Leider weiß ich nicht ob da 
tatsächlich intern das Netzsignal für den Trigger genutzt wird, oder nur 
ein generiertes 50Hz Signal. Müßte man mal hardwareseitig prüfen.


@Jürgen

Ich nutze die Linux Entwicklungsumgebung, aber mit der CygWin geht es 
auch.

Gruß Hayo

[Rainer W. (rawi)]

Hallo Jürgen und Hayo,

Jürgen schrieb:
> 2. .... Kann Rainers Beobachtungen nicht
> komplett bestätigen. Das "Durchlaufen" bei "Norm + Line" sieht eher aus
> wie vier verschiedene Startpunkte für die Displaydarstellung. Die Kurve
> wird nacheinander offenbar um 1 Pixel versetzt gezeichnet und dann
> wieder vom Startpunkt. ( Ch1 und Extern mit Signal belegt )

Bei mir läuft das 50Hz  Netzsignal eindeutig gleichmäßig durch. Mit 
Display auf "Persist" wird der Schirm gleichmäßig gefüllt.

Das Problem mit Kanal 3+4 habe ich auch: Es wird abwechseln das Signal 
und eine horizontale Linie in unterschiedlicher Höhe geschrieben, auch 
bei "Single"-Aufzeichnung. Das Signal hat relativ häufig einen Kinken 
drin (Signal_34). Das Signal auf 1+2 bzw. 3+4 sind jeweils synchron, 
aber 1+2 ist gegen 3+4 verschoben (Signal_12_34)

Rainer

[Rainer W. (rawi)]

2.ter Versuch
Signal_34:
50 Hz Netz auf Ch4 mit Kinken (dto. bei Ch3)

Signal_12_34:
50 Hz Netz auf Ch1..4, Verschiebung 12 gegen 34, Kinken in 3,4

Rainer

[Blue F. (blueflash)]

Jürgen schrieb:

> 3. Habe beim Externen Trigger wieder mal das Problem, daß die Kanäle 3
> und 4 nur bei jeder 1. Displayrunde gezeichnet werden. D.h. es wird bei
> jeder 2. Runde nur eine exakt gerade, horizontale Linie für Kanal 3+4
> dargestellt. ( ohne Signal an 3+4 ! ) Ich erinnere mich dunkel, das es
> dieses Problem schon mal gab und Du es behoben hast!

Ok, hast recht. Das Problem haben wir schon länger. Ich erinnere mich. 
Aber gelöst hatten wir das bislang noch nicht, da war ich irgendwie von 
ab gekommen. Inzwischen hab ich auch schon die Stelle gefunden die es 
verursacht und den Fehler behoben. War wie vermutet wieder eine 
WELEC-Altlast.

Gruß Hayo

[Rainer W. (rawi)]

Hayo W. schrieb:
> .... Leider weiß ich nicht ob da
> tatsächlich intern das Netzsignal für den Trigger genutzt wird, oder nur
> ein generiertes 50Hz Signal. Müßte man mal hardwareseitig prüfen.

Das Signal an PowerConn Pin 23, dass in den Line-Trigger geht, sieht 
nicht toll aus, sollte aber irgendwie seinen Zweck erfüllen. Ich habe 
aber nicht nachgemessen, ob das wirklich zum Netz synchron läuft. Wenn 
der Triggermode irgendeinen Sinn machen soll, muß dass aber aus dem Netz 
abgeleitet sein.

Rainer

[Blue F. (blueflash)]

Tja das es Sinn macht ist klar, aber wie wir wissen waren die 
Gedankengänge des Entwicklers und bei WELEC allgemein etwas sonderbar...

Hier schon mal vorab die 1.9 Preview mit der Korrektur. Allerdings 
scheint das beim Verstellen der Nulllinie noch aufzutreten, mal sehen.


Hayo

[Blue F. (blueflash)]

Oh ich muß nochmal zurückrudern, leider tritt es beim Normal Trigger 
immer noch auf - blöde Sache, bin aber dran.

Hayo

[Blue F. (blueflash)]

Ok,

Ihr wolltet es nicht anders - hier ist sie. Die Anzahl der Dateien ist 
im Gegensatz zur Source sehr übersichtlich.

Besonders erheiternd ist der einleitende Kommentar in der tc_classes.cpp

Viel Spaß

Hayo

[Blue F. (blueflash)]

Noch eine kleine Anmerkung:

Das sind über 42000 Zeilen mit fast keinen Kommentaren drin. Vergleicht 
jetzt mal die aktuellen Sourcen damit!

Hayo

[Egberto (Gast)]

Hallo Hajo,

Verstehe ich jetzt irgendwie nicht - allen ist (denke ich) klar, das die 
originale Software sch.... Ist und alle sind (bin ich mir sicher) sehr 
glücklich, mit dem was du hier leistest!!!

oder hab ich was verpasst??

Viele Grüße,

Egberto

PS: Mein erstes Posting mit dem iPad - wider Erwarten ein super Teil - 
wo ist das Welec- App ;-) !!

[Egberto (Gast)]

Ok, habe eben in den Hardware-Fred geschaut-jetzt ist die Ursache für 
das Posting klarer.

Guts Nächtle!!

[Blue F. (blueflash)]

Wie ich sehe haben sich doch schon etliche Interessierte die Sourcen 
runtergeladen.

Hier eine kleine Demoaufgabe:

Sucht die Zeichenroutine, die die Signale auf das Display zeichnet und 
vergleicht mal alt und neu. Man muß nicht unbedingt programmieren können 
um zu verstehen was ich meine.

Hayo

p.s. da die Suche in der Source recht schwierig ist hier noch ein Tip:
     -> DrawSignals()

[Moritz Z. (moud)]

Das nicht der gesammte Quelltext in einer einzigen Zeile geschrieben 
wurde wundert mich... da findet man ja NIX drin!

[Blue F. (blueflash)]

Ist natürlich auch eine Methode sich bei einer Firma unentbehrlich zu 
machen, hat aber den Nachteil, dass man selbst auch irgentwann den 
Überblick verliert (wie man gesehen hat) und dann ist man eben doch 
entbehrlich (wie man ebenfalls gesehen hat)

Hayo

[Roberto (Gast)]

Hallo
Im Hardware Thread ist wieder der Satz vom langen Thread gefallen...
Sollten wir hier vielleicht mal wieder eine neue Seite anfangen ? (Teil3 
?)
l.G. Roberto

[Thomas (kosmos)]

ja als GPRS-Modem Nutzer würde mir das wieder einen schnelleren 
Seitenaufbau ermöglichen.

[Michael H. (stronzo83)]

Ich wüsste nicht warum - inzwischen ist der Thread doch schön in Seiten 
gegliedert.

[Michael D. (mike0815)]

...stimmt, steht gleich nach "E-Mail-Benachrichtigung ein oder 
abschalten"

"Seitenaufteilung ein oder abschalten"

Gruß Michael

[Blue F. (blueflash)]

Hi, kurze Info zum externen Trigger und dem "Blinksignal" auf Kanal 3 + 
4. Ich bin immer noch am forschen, aber es kristallisiert sich so 
langsam heraus, dass es sich um einen Hardware bzw. FPGA-Fehler handelt.

Ob ich dann dafür einen Workaround finde ist noch offen.

Gruß Hayo

[Blue F. (blueflash)]

Michael D. schrieb:
> ...stimmt, steht gleich nach "E-Mail-Benachrichtigung ein oder
> abschalten"
>
> "Seitenaufteilung ein oder abschalten"

Wo das denn? Bei mir ist da nichts. Hängt das evtl. am Browser? Ich 
nutze Opera.

Hayo

[A. F. (frankalicious)]

Hayo W. schrieb:
> Michael D. schrieb:
>> ...stimmt, steht gleich nach "E-Mail-Benachrichtigung ein oder
>> abschalten"
>>
>> "Seitenaufteilung ein oder abschalten"
>
> Wo das denn? Bei mir ist da nichts. Hängt das evtl. am Browser? Ich
> nutze Opera.
>
> Hayo

Geht hier auch mit Opera.
Befindet sich zwischen dem letzten Beitrag und zwischen dem Rahmen 
'Antwort schreiben'.

[Michael D. (mike0815)]

Hi Hayo,

Im Bild oben, habe ich es nochmal rot eingerahmt!
So müsste das bei dir aussehen!!!

Der Seitenaufbau, geht dadurch um einiges schneller...

by the way,
im "cgi/ebay", gibt es doch noch Welec's, allerdings nur die 
100MHz-Variante!
Vertreiber sind immer noch die Wittig-Brüder.
Ich bezweifle, das es da ein Unterschied zwischen den 100MHz u. den 
200MHz Geräten gibt.

Gruß Michael

[Blue F. (blueflash)]

Oh, tatsächlich - ich hatte nach einer Checkbox zum anhaken gesucht. Ja 
wirklich ganz praktisch mit der Seitenaufteilung, gefällt mir.

Gruß Hayo

[Michael D. (mike0815)]

hohoho, 23 Downloads von dem Anhang, schön das ich helfen konnte...;)))

Gruß Michael

[Peter M. (none)]

Hallo allseits,

bin jetzt im Besitz eines W2012A.

Ich wuerde gerne am WE Hayo's Software aufspielen. In der Doku schreibt 
er leider nicht (oder ich habe es nicht gefunden), ob seine SW mit einer 
bestimmten Hardware Version am besten funktioniert. Meine ist 8C7.0E 
(siehe Bild).
Beim Lesen hier bin ich noch ueber 8C7.00, 8C7.0F, 8C7.0G, 8C7.0H und 
8C7.0L gestolpert.
Welche davon passt am besten zu Hayo's SW? Oder ist das egal?

Schade, das sich die einzelnen Entwicklergruppen nicht alle unter 
Sourceforge austauschen. Dann koennte man die Suchfunktion in diesem 
einen Forum bestens nutzen.

Wird der Leon3-Ansatz noch weiterverfolgt? Gibt es dazu ein aktuelles 
Forum? Ich habe leider noch nie Skype benutzt 8-(

Weiss jemand, wie man branadic erreichen kann? Ich wuerde gerne ein 
Abschirmblech erwerben, falls er noch welche hat.

Hoffentlich habe ich nicht zu viel Dummes gefragt ;-)

Gruss, Peter

[Jürgen (Gast)]

Roberto schrieb:
> Hallo
> Im Hardware Thread ist wieder der Satz vom langen Thread gefallen...
> Sollten wir hier vielleicht mal wieder eine neue Seite anfangen ? (Teil3
> ?)
> l.G. Roberto

Mach es einfach!!! Es kommt dann auch uns Gästen zugute :-)

l.G. Jürgen

[Roberto (Gast)]

Hallo

Kannte diese neue Funktion, mit den Seiten, auch noch nicht.
Wollte diese gleich probieren, aber anscheinend geht das nur mit 
Registrierten Nutzern...... Schade!

Habe jetzt mal eine neue Seite (Teil3) aufgeschlagen.
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"

Ich weis, jetzt gehen wieder die Diskussionen los...
Wenn Du dich nicht mal anmelden willst u.s.w....
Aber wenn es ohne geht, warum nicht... ist viel ungezwungener und man 
muss sich ja so schon, viel zu viele Passwörter merken.
Und anscheinend gibt es auch andere Gäste, die scheinbar gleich 
denken...

Lange Rede, kurzer Sinn ;-), schließlich wird es an Hayo liegen, wo er 
hingeht.. :-)

l.G. Robert

[Rolf W. (rowue)]

Peter M. schrieb:
> Hallo allseits,
>

Nabend Peter ;)

> bin jetzt im Besitz eines W2012A.

Ahh - dann warst Du einer der beiden anderen, die letzte
Woche geboten haben - haben wir ja im Vergleich noch
"günstig" (soweit mensch ~160-190E für das DSO "günstig"
nennen kann) abgeschlossen ;)

>
> Ich wuerde gerne am WE Hayo's Software aufspielen. In der Doku schreibt
> er leider nicht (oder ich habe es nicht gefunden), ob seine SW mit einer
> bestimmten Hardware Version am besten funktioniert. Meine ist 8C7.0E
> (siehe Bild).
> Beim Lesen hier bin ich noch ueber 8C7.00, 8C7.0F, 8C7.0G, 8C7.0H und
> 8C7.0L gestolpert.
> Welche davon passt am besten zu Hayo's SW? Oder ist das egal?

Generell sollte - egel ob BF oder OS die Hardware-Version egal
sein. Auf alle Fälle würde ich Dir aber raten, vorher ein Backup
Deines Gerätes zu machen. In der Vergangenheit gab es z.B. mit der
.0L ab und zu Probleme, auch, da zwischenzeitlich ein "Standard-Wert"
nicht aus dem Flash geladen wurde, sondern von der FW direkt geschrieben
wurde (und dann auch in's Flash ... ) - der war auf der .0L bloß nicht
Standard und hat für einige Probleme mit den Geräten gesorgt.

Aber: wenn Du am Anfang einmal das Komplett-Backup ziehst, kannst
Du Dein Gerät immer wieder in den Ausgangszustand versetzen ;)

>
> Schade, das sich die einzelnen Entwicklergruppen nicht alle unter
> Sourceforge austauschen. Dann koennte man die Suchfunktion in diesem
> einen Forum bestens nutzen.

SF ist leider nicht bei allen beliebt ;)

>
> Wird der Leon3-Ansatz noch weiterverfolgt? Gibt es dazu ein aktuelles
> Forum? Ich habe leider noch nie Skype benutzt 8-(

Ich denke schon ;)

>
> Weiss jemand, wie man branadic erreichen kann? Ich wuerde gerne ein
> Abschirmblech erwerben, falls er noch welche hat.

Vielleicht wird er sich bei Dir melden ;)
>
> Hoffentlich habe ich nicht zu viel Dummes gefragt ;-)
>
> Gruss, Peter

Grüße,

   rowue

[Rolf W. (rowue)]

Michael D. schrieb:
> [...]
>
> by the way,
> im "cgi/ebay", gibt es doch noch Welec's, allerdings nur die
> 100MHz-Variante!
> Vertreiber sind immer noch die Wittig-Brüder.
> Ich bezweifle, das es da ein Unterschied zwischen den 100MHz u. den
> 200MHz Geräten gibt.

Ich tippe mal drauf, dass die Bestückung gleich ist, sich aber
gewisse Bandbreiteneffekte durch Geräte- und Fertigungstoleranzen
ergeben. Als ich mal beide Varianten zum Testen auf dem Tisch
hatte, gab es da schon einen leichten Unterschied bei der
Signalwiedergabe.

Halt genauso, wie die Geräte ohne Math-Modus vertickt werden, weil
da eine Leiterbahn 'nen Kurzen hat (was durch OS/BF schnell
behoben wurde ;)

>
> Gruß Michael

Grüße,

   rowue

[Michael D. (mike0815)]

moin Rolf,

Das erklärt natürlich so Einiges.
Ich glaube brunowe war's, der mit seinem W2010 beim experimentieren mit 
den Eingangswiderständen, weit über die 150MHz gekommen ist...

...was verstehst du denn unter "leichten" Unterschied ?

Einen Kurzen in der Leiterbahn???
Oha, wurde der denn mal ausfindig gemacht oder war das jetzt nur 
symbolisch gemeint?


@Roberto

Kleiner Vorschlag am Rande: Da wir ja jetzt mit der FW in die 
Realease-Version gelangt sind, könnte man doch die neue Seite als solche 
bennen?!?

Vielleicht DSO W20xx Open Source Firmware REALEASE (Teil3)

Die Seiteneinteilung geht auch im ausgeloggten Zustand, habe das eben 
mal getestet!

Gruß Michael

[Peter M. (none)]

Rolf W. schrieb:
> Hallo rowue,

> Ahh - dann warst Du einer der beiden anderen, die letzte...

(sorry, ich muss die Zitate kuerzen, sonst mosert die ForenSW)

Leider nein 8(

Mein altes TEK453 hat allerdings keinen Tauch mehr, zumal es in letzter 
Zeit ueber H durchlaeuft, also ein neues Scope.
Den Preis finde ich einen absoluten Schnapper fuer die Hardware die man 
kauft (der arme Herr W. zahlt drauf) und dann noch ein Open Source 
Projekt, also ideal.

Es gab 3 Auktionsschuebe, die ich verfolgt habe.

Am 16. Jun.
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190404199361&ssPageName=STRK:MEWAX:IT
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190404199527&ssPageName=STRK:MEWAX:IT
250-260 Teuro
Am 23. Jun.
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190406363547&ssPageName=STRK:MEWAX:IT
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190406363383&ssPageName=STRK:MEWAX:IT
220 Teuro
und dann wie von dir erwaehmt am 26. Jun.
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190408330905&ssPageName=STRK:MEWAX:IT
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190408330742&ssPageName=STRK:MEWAX:IT
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=190408330484&ssPageName=STRK:MEWAX:IT
160-190 Teuro

Ich war leider in der Mitte dabei, also Glueckwunsch an dich.

Ansonsten zahlt man 295 Teuro.

Ich hatte eine Mail an tek4you_eu geschickt mit dem Angebot ein W2012A 
fuer 250 Teuro zu erwerben.
Keine Antwort. Der Auktionshandel mit Herrn Wittig lief aber sehr rund.

> Generell sollte - egel ob BF oder OS die Hardware-Version egal...

Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-)

> Aber: wenn Du am Anfang einmal das Komplett-Backup ziehst, kannst
> Du Dein Gerät immer wieder in den Ausgangszustand versetzen ;)

Unbedingt!

> SF ist leider nicht bei allen beliebt ;)

Sehr schade! Ich frag mich nur warum? Nur wegen der Anmelderei?

> Ich denke schon ;)

Prima, Hayo hat ja wohl die Vermutung, dass in der Signalverarbeitung im 
FPGA auch der Wurm drin ist.

> Vielleicht wird er (branadic) sich bei Dir melden ;)

Das ware schoen.


Vielen Dank fuer deine Antworten.

Gruss, Peter

PS: Falls jemand Bilder vom Innenleben meines W2012A zum Vergleichen 
wuenscht, kann ich sie im Hardware-Thread posten. Ich musste das Ding 
natuerlich erst mal zerlegen. Einzig negativ vielen mir die Iverterkabel 
zum Display auf. Zu sehr verdrillt und spannten deshalb ein wenig.

[Rolf W. (rowue)]

Peter M. schrieb:
> Rolf W. schrieb:
>> Hallo rowue,
>
>> Ahh - dann warst Du einer der beiden anderen, die letzte...
>
> (sorry, ich muss die Zitate kuerzen, sonst mosert die ForenSW)
>
> Leider nein 8(
>
> [...]
>
> Ich war leider in der Mitte dabei, also Glueckwunsch an dich.

Nein, ich war der erste - mit den 184 ;) - hätten wir uns mal
absprechen sollen ;)
>
> Ansonsten zahlt man 295 Teuro.

Das ist eher eine Preisdeckelung - warum mehr als 295,- bieten ;)

>
> Ich hatte eine Mail an tek4you_eu geschickt mit dem Angebot ein W2012A
> fuer 250 Teuro zu erwerben.
> Keine Antwort. Der Auktionshandel mit Herrn Wittig lief aber sehr rund.

Naja, etwas auf die Lauer legen und Du hast eins für 250 und weniger ;)

>
>> Generell sollte - egel ob BF oder OS die Hardware-Version egal...
>
> Vielen Dank, danach habe ich gesucht 8))) Dann bleibt 8C7.0E drauf ;-)

Etwas anders als Du denkst ;) - aber Backup von der alten,
OS/BF Fw drauf und gut ist ;)

>
>> Aber: wenn Du am Anfang einmal das Komplett-Backup ziehst, kannst
>> Du Dein Gerät immer wieder in den Ausgangszustand versetzen ;)
>
> Unbedingt!
>
>> SF ist leider nicht bei allen beliebt ;)
>
> Sehr schade! Ich frag mich nur warum? Nur wegen der Anmelderei?

Weiß ich nicht - ich nutze das SVN dort ;)

>
>> Ich denke schon ;)
>
> Prima, Hayo hat ja wohl die Vermutung, dass in der Signalverarbeitung im
> FPGA auch der Wurm drin ist.

Da braucht Hayo keine Vermutung zu haben - dass ist Gewissheit!!!

a) Haben wir letztes Jahr 'nen Filter abgeschaltet, der für
Schwingungen gesorgt hat - in der OS bleibt der (wahrscheinlich)
abgeschaltet, in der BF ist er per Default eingeschaltet, kann
aber übers Menue abgeschaltet werden ;)
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=21

b) Sind die Signale bei 250/500MSa/s extrem verwürfelt, siehe:
http://sourceforge.net/apps/trac/welecw2000a/ticket/44
Das ist gerade mit in dem Schwung, den ich mache und nach dessen
Abschluß wohl eine OS 0.93 ansteht (wenn keiner schreit ;)

c) Sind die Samples bei 1GSa/s nicht äquistiant, siehe:
http://sourceforge.net/apps/trac/welecw2000a/ticket/53

a), b) und c) wurden hier (inkl. Thread eins) schon veröffentlicht
und nachgewiesen - da braucht keiner zu vermuten ;)

Zur Beseitigung der Fehler habe ich "gerade" (März) einen Umzug
von Hamburg nach Freiburg hinter mir und muß mich hier auch erstmal
an eine neue Umgebung und einen neuen Tätigkeitsbereich gewöhnen ...

Wen Du mir beim Arbeiten über die Schulter schauen möchtest, meine
Änderungen pflege ich im branch "rowue-signal" in's svn auf Sourceforge
ein. Allerdings möchte ich davon abraten, den Source zu verwenden,
bevor ich ihn in den trunk gemerged (eingefügt) habe, auch wenn
ich vor dem Commit teste, sind das noch einige offene Baustellen.
>
>> [...]
>
>
> Vielen Dank fuer deine Antworten.
>
> Gruss, Peter

Beste Grüße,

    rowue
>
> [...]

[Rolf W. (rowue)]

Michael D. schrieb:
> moin Rolf,

Moin Michael,
>
> Das erklärt natürlich so Einiges.
> Ich glaube brunowe war's, der mit seinem W2010 beim experimentieren mit
> den Eingangswiderständen, weit über die 150MHz gekommen ist...
>
> ...was verstehst du denn unter "leichten" Unterschied ?

Ich habe damals (glaube ich) keine Screenshots gemacht, aber es
war deutlich zu sehen, dass bei einem "Delta-Impuls" auf den
2022A höhere Fourier-Koeffizienten übertragen wurden, als auf
dem 2014A (sprich: höhere Bandbreite)
>
> Einen Kurzen in der Leiterbahn???
> Oha, wurde der denn mal ausfindig gemacht oder war das jetzt nur
> symbolisch gemeint?

Sitzt bei den Schaltern. Wir haben einfach die Abfrage umgedreht
und seit dem machen auch die nicht Mathe-Modus fähigen Geräte
den Mathe-Modus - ist in beiden Versionen drin (und sollte es auch
bleiben ;)
>
>
> [...]
>
> Gruß Michael

Grüße,

   rowue

[Roberto (Gast)]

Michael D

>Die Seiteneinteilung geht auch im ausgeloggten Zustand, habe das eben
>mal getestet!

mmmhh.. bei mir nicht.
Da kommt immer eine Login-Seite und ohne eMail und Passwort geht es 
nicht weiter..
l.G. Roberto

[Egbert O. (horace)]

Roberto hat gerade Teil drei dieses Freds aufgemacht-macht doch bitte da 
weiter!!

Viele Grüße,

Egberto

[Roberto (Gast)]

Hallo
Hier nochmals der Link zum nächsten Teil (Teil3) dieses Threads:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"
l.G. Roberto

[Kurt B. (kurt)]

Dann wäre es schon wenn ein Moderator hier mal dicht machen würde, bevor 
der Link zu Teil 3 irgendwo untergeht...