mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)


Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Gesperrt durch Moderator
Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex008_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anonymer Poster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kurt,

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

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

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

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

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

Gruß, brunowe

Autor: Kurt Bohnen (kurt)
Datum:

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

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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael D. (mike0815)
Datum:

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

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

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

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

Gruß Michael

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nabend ....

ich habe mal die Verstärkungsfaktoren von

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

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

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

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

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

Grüße,

   rowue

Autor: Michael D. (mike0815)
Datum:

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

Gruß Michael

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

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

Es gibt einmal

   #welec (IRC) auf irc.freenode.net

und einmal

   welec@conference.jabber.ccc.de

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

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


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

Grüße,

   rowue

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...vergesst es, hatte da was übersehen!!!

Gruß Michael

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Guido

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

Gruß Hayo

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: Jürgen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Odic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
O.k. Stefan,

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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Default User (shyguy)
Datum:

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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hayo: Guter Tip, das werde ich mal probieren.

Gruß, Guido

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manchmal habe ich den Eindruck, dass meine posts unsichtbar sind...

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael H.

Also ich sehe deine Posts...

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jürgen

Sach ich doch! Idealisierte Darstellung ;-)

Hayo

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

Default setup hast Du gemacht?

Hayo

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hayo,

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

Michel

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marius Wensing (mw1987)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch meine 2 Cents:

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

Gruß, Guido

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

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

Falk

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan V. (svaudio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan V. (svaudio)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Welec Gemeinde,

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

Gruß, brunowe

Autor: Michael D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex008_ (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mike B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Ist das Oszi eigentlich Fernsteuerbar?

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

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

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

Evtl ist

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

Autor: Stefan E. (stefan_e)
Datum:

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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

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

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

Falk

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!?

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Odic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

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

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

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

Gruß, brunowe

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen schrieb:
> Hallo,

...

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

Wann hat Hayo das "festgelegt"?

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

Das macht Subverion automatisch beim Einchecken.

> 2. Kommentare sind einzufügen

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

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

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

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

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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger M. (nezaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael D. schrieb:
> Hallo Falk,

...

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

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

Da liegt alles sauber geordnet.

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

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

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

Das ist das Problem.

Falk

Autor: Michael D. (mike0815)
Datum:

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

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

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

Gruß Michael

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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" ;)

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal die Frage direkt an Falk:

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

Mfg,
Kurt

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Torsten W. (wirehead)
Datum:

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

Gruß
Torsten

Autor: Odic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger M. (nezaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

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

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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wo wird der Pfad eingetragen. Makefile oder Systemvariablen?

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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

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

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

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

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

Falk

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Odic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex008_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ist die von hier nochmal modiefiziert???

Gruß Michael

Autor: Michael D. (mike0815)
Datum:

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

Gruß Michael

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rolf,

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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

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

Autor: Michael D. (mike0815)
Datum:

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

Gruß Michael

Autor: Stefan E. (stefan_e)
Datum:

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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer W. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer W. (rawi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Torsten W. (wirehead)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
      }
  }
}

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marius Wensing (mw1987)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Chris (Gast)
Datum:

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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten W. (wirehead)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

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

Autor: Torsten W. (wirehead)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kurt,
gerade probiert, dann ist das problem auch ohne ausschalten 
reproduzierbar.

Gruß
Torsten

Autor: Kurt Bohnen (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten W. (wirehead)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt Bohnen (kurt)
Datum:

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

Was sagen die anderen dazu?

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/ticke...

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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@rowue

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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan E. (stefan_e)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf W. (rowue)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rainer W. (rawi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: