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


von Roberto (Gast)


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
von Jürgen (Gast)


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

von Ingo M. (ingom)


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

von alex008_ (Gast)


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

von Kurt B. (kurt)


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.

von Anonymer Poster (Gast)


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

von Kurt B. (kurt)


Angehängte Dateien:

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.

von Bruno W. (brunowe) Benutzerseite


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

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

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

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

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

Gruß, brunowe

von Kurt B. (kurt)


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

von Bruno W. (brunowe) Benutzerseite


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?

von Michael D. (mike0815)


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

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

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

Gruß Michael

von Blue F. (blueflash)


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

von Blue F. (blueflash)


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

von Rolf W. (rowue)


Angehängte Dateien:

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

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

Grüße,

   rowue

von Michael D. (mike0815)


Lesenswert?

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

Gruß Michael

von Rolf W. (rowue)


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

von Rolf W. (rowue)


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

von Rolf W. (rowue)


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

von Michael D. (mike0815)


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

von Michael D. (mike0815)


Lesenswert?

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

Gruß Michael

von Default U. (shyguy)


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

von Blue F. (blueflash)


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

von Default U. (shyguy)


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

von Blue F. (blueflash)


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

von Blue F. (blueflash)


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

von Default U. (shyguy)


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

von Guido (Gast)


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

von Blue F. (blueflash)


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

von Blue F. (blueflash)


Lesenswert?

@Guido

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

Gruß Hayo

von Default U. (shyguy)


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

von Michael H. (stronzo83)


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

von Blue F. (blueflash)


Angehängte Dateien:

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

von Guido (Gast)


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

von Blue F. (blueflash)


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

von Michael H. (stronzo83)


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

von Michael H. (stronzo83)


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

von Michael H. (stronzo83)


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

von Default U. (shyguy)


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

von Jürgen (Gast)


Angehängte Dateien:

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

von Default U. (shyguy)


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

von Odic (Gast)


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

von Michael H. (stronzo83)


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

von Default U. (shyguy)


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 ?

von Blue F. (blueflash)


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

von Default U. (shyguy)


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

von Guido (Gast)


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

von Default U. (shyguy)


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.

von Michael H. (stronzo83)


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

von Michael H. (stronzo83)


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.

von Michael H. (stronzo83)


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.

von Guido (Gast)


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?

von Blue F. (blueflash)


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

von Default U. (shyguy)


Lesenswert?

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

von Guido (Gast)


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

von Blue F. (blueflash)


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

von Guido (Gast)


Lesenswert?

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

Gruß, Guido

von Michael H. (stronzo83)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

@ Michael H.

Also ich sehe deine Posts...

von Guido (Gast)


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

von Jürgen (Gast)


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

von Michael H. (stronzo83)


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

von Blue F. (blueflash)


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

von Stefan E. (stefan_e)


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.

von Jürgen (Gast)


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

von Blue F. (blueflash)


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

von Marius W. (mw1987)


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.

von Jürgen (Gast)


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

von Blue F. (blueflash)


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

von Michael W. (slackman)


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

von Blue F. (blueflash)


Lesenswert?

@Jürgen

Sach ich doch! Idealisierte Darstellung ;-)

Hayo

von Blue F. (blueflash)


Lesenswert?

@Michael

Default setup hast Du gemacht?

Hayo

von Michael W. (slackman)


Lesenswert?

@ Hayo,

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

Michel

von Michael D. (mike0815)


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

von Blue F. (blueflash)


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

von Michael D. (mike0815)


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

von Blue F. (blueflash)


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

von Michael D. (mike0815)


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

von Jürgen (Gast)


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

von Michael D. (mike0815)


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

von Marius W. (mw1987)


Angehängte Dateien:

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

von Michael D. (mike0815)


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

von Blue F. (blueflash)


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

von Guido (Gast)


Lesenswert?

Und noch meine 2 Cents:

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

Gruß, Guido

von Marius W. (mw1987)


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

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

Falk

von branadic (Gast)


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

von Blue F. (blueflash)


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

von Blue F. (blueflash)


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

von branadic (Gast)


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

von Guido (Gast)


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

von Falk W. (dl3daz) Benutzerseite


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

von Stefan V. (svaudio)


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

von Guido (Gast)


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

von Stefan V. (svaudio)


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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

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/viewtopic.php?f=20&t=40 
einverstanden ist, kann auf Anfrage von mir einen Download link 
erhalten.
Noch ist nicht ansatzweise alles verwirklicht was ich mir vorgenommen 
habe, denke aber das ich über die kalten Wintermonate noch einiges 
fertig bekomme.
Besonders da der Programmumfang inzwischen so umfangreich ist, das die 
"Testerei" mehr Zeit in Anspruch nimmt, als das Programmieren, hoffe ich 
auf diese Weise auf umfangreiche Rückmeldungen und 
Verbesserungsvorschläge.
Der Leistungsumfang ändert sich täglich, deshalb macht es auch nicht 
viel Sinn hier eine komplette Leistungsbeschreibung zu posten. Das 
Programm sollte mit den FW Versionen 0.91 OS und, nachdem Hayo den 
Remote Befehlssatz übernommen hat, auch mit der 0.97 HE arbeiten.

Gruß, brunowe

von Michael D. (Gast)


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

von alex008_ (Gast)


Angehängte Dateien:

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

von Falk W. (dl3daz) Benutzerseite


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

von Jörg H. (idc-dragon)


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

von Mike B. (Gast)


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

von Ingo M. (ingom)


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)

von Michael (Gast)


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

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Michael schrieb:
> Ist das Oszi eigentlich Fernsteuerbar?

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

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

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

Evtl ist

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


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

von Falk W. (dl3daz) Benutzerseite


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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

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

Falk

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


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

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


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

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


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

von Michael D. (mike0815)


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?

von Falk W. (dl3daz) Benutzerseite


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

von branadic (Gast)


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

von Kurt B. (kurt)


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

von Michael D. (mike0815)


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

von Rolf W. (rowue)


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

von Odic (Gast)


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

von Guido (Gast)


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

von Guido (Gast)


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

von Bruno W. (brunowe) Benutzerseite


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

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

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

Gruß, brunowe

von Falk W. (dl3daz) Benutzerseite


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

von Falk W. (dl3daz) Benutzerseite


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.

von Guido (Gast)


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

von Jürgen (Gast)


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

von branadic (Gast)


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

von Falk W. (dl3daz) Benutzerseite


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

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

BTW: Revision 245 ist mit "Merged FW1.2.BF.0.96HE with SVN" kommentiert: 
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a?view=rev&revision=172

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

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

von Falk W. (dl3daz) Benutzerseite


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

von Holger M. (nezaya)


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

von Falk W. (dl3daz) Benutzerseite


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)

von Michael D. (mike0815)


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

von Falk W. (dl3daz) Benutzerseite


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

Da liegt alles sauber geordnet.

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

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

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

Das ist das Problem.

Falk

von Michael D. (mike0815)


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/viewforum.php?f=14
>
> Da liegt alles sauber geordnet.
>
...keine Frage, ich meine die FW-Versionen: Ein Teil liegt hier, das 
andere in Google-Groups und der Rest im SFN
Könnte man nicht ALLE FW-Versionen (ob beta oder release) die bisher 
erschienen sind mit Beschreibung auf eine Seite setzen?

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

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

Gruß Michael

von Jürgen (Gast)


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!

von Rolf W. (rowue)


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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

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

von Guido (Gast)


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

von Michael H. (stronzo83)


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

von Kurt B. (kurt)


Lesenswert?

Nochmal die Frage direkt an Falk:

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

Mfg,
Kurt

von Falk W. (dl3daz) Benutzerseite


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

von Kurt B. (kurt)


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.

von Falk W. (dl3daz) Benutzerseite


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

von Jürgen (Gast)


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

von Torsten W. (wirehead)


Lesenswert?

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

Gruß
Torsten

von Odic (Gast)


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

von Falk W. (dl3daz) Benutzerseite


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

von branadic (Gast)


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

von Guido (Gast)


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

von Holger M. (nezaya)


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

von Kurt B. (kurt)


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

von Stefan E. (stefan_e)


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.

von Falk W. (dl3daz) Benutzerseite


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

von Blue F. (blueflash)


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

von Falk W. (dl3daz) Benutzerseite


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

von Stefan E. (stefan_e)


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

von Kurt B. (kurt)


Lesenswert?

1
C:\welec\firmware>make
2
# 2009.10.25.13:04:13 --- (Note: to make for Nios 16, try "make clean all M=16")
3
4
# 2009.10.25.13:04:13 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc -I .
5
./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 -DBUILDBY
6
=" - 20091025" -D_Debug_ src/TomCat.cpp -o obj/TomCat.cpp.o
7
/bin/sh: nios-elf-gcc: command not found
8
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?

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Kurt Bohnen schrieb:
1
...
2
> /bin/sh: nios-elf-gcc: command not found
3
> make: *** [obj/TomCat.cpp.o] Error 127
4
>

...

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

Kein Pfad nach nios-elf-gcc.

Falk

von Kurt B. (kurt)


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.

von Kurt B. (kurt)


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

von Guido (Gast)


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

von Rolf W. (rowue)


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

von Falk W. (dl3daz) Benutzerseite


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

von Falk W. (dl3daz) Benutzerseite


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/RemoteControlAPI
Die Funktion kann man mit "hterm" benutzen oder über das kleine tool 
"misc-tools/setvars/setvar.pl".

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

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

Falk

von Guido (Gast)


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

von Rolf W. (rowue)


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

von Falk W. (dl3daz) Benutzerseite


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

von Odic (Gast)


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

von Jörg H. (idc-dragon)


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

von Guido (Gast)


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

von Rolf W. (rowue)


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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

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

von Rolf W. (rowue)


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

von Kurt B. (kurt)


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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

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

von Michael H. (stronzo83)


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

von Michael H. (stronzo83)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


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

von alex008_ (Gast)


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

von Rolf W. (rowue)


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

von Michael D. (mike0815)


Lesenswert?

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

Gruß Michael

von Michael D. (mike0815)


Lesenswert?

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

Gruß Michael

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Ja

von Stefan E. (stefan_e)


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.

von Falk W. (dl3daz) Benutzerseite


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

von Stefan E. (stefan_e)


Angehängte Dateien:

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.

von Falk W. (dl3daz) Benutzerseite


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

von Stefan E. (stefan_e)


Lesenswert?

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

von Rolf W. (rowue)


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

von Rolf W. (rowue)


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

von Michael D. (mike0815)


Angehängte Dateien:

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

von Stefan E. (stefan_e)


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.

von Michael D. (mike0815)


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

von Stefan E. (stefan_e)


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.

von Rolf W. (rowue)


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

von Rolf W. (rowue)


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

von Stefan E. (stefan_e)


Lesenswert?

Hallo Rolf,

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

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.