Announcement: there is an English version of this forum on 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
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
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
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
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.
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
Angehängte Dateien:
-
umleitungsfehler.png
7,2 KB
Beim Versuch ein neues Thema bei Sourceforge zu erstellen bekomme ich einen Umleitungsfehler. Verwendet wird Firefox unter WinXP SP3. Beim Internet Explorer funktioniert es hingegen.
Hallo Kurt, mir ist nicht ganz klar was du mit neues Thema genau meinst. Hast du das gelesen: http://sourceforge.net/apps/phpbb/welecw2000a/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
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
Hallo Kurt, also ich hab meinen o.a. Topic mit Firefox (3.5.3) erstellt und hatte keine Probleme. Mag evtl. nur ein kurzfristiges Problem mit dem SF Server gewesen sein?
Bruno We schrieb: > Hallo Kurt, > > also ich hab meinen o.a. Topic mit Firefox (3.5.3) erstellt und hatte > keine Probleme. Mag evtl. nur ein kurzfristiges Problem mit dem SF > Server gewesen sein? Ich habe den IE8 mit WinXP da funktionert das sehr wohl, ein neues Topic zu eröffnen(wenn man registriert ist)z.B. https://sourceforge.net/apps/phpbb/welecw2000a/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
Jürgen schrieb: > Stefan E. schrieb: > >>@Hayo > >>Es wäre schön wenn das Strecken und Verschieben des Signals im >>Stop-Modus wieder ginge ... > > Ebenso! > > Gruß Jürgen Hab ich bei mir (BF.0.97) schon nach Euren Wünschen geändert, ebenso wie ich den Bug im Autoscale inzwischen gefixed habe. Muß mich aber noch mit dem SVN anfreunden um es in die OS-Version einpflegen zu können. Gebe zu dass ich das irgendwie vor mir herschiebe, da ich mit allen möglichen Ideen rund um die Firmware beschäftigt bin. Aktuelles Projekt bei mir ist gerade der Timebase-Controller. Meine bisherigen Tests mit verschiedenen Registerwerten lassen vermuten, dass das FPGA-Design anscheinend tatsächlich so vergurkt ist, dass die Timebases 100MSa/s und 50MSa/s nicht vorgesehen sind. Zur Zeit bereite ich gerade eine komplett neu designte Timebasesteuerung vor, bei der zwar auch die beiden Timebases fehlen, aber bei der die Aufteilung etwas sinniger und homogener ist. Gruß Hayo
alex008_ schrieb: > Beispielsweise habe ich schon ca. 17000 Codezeilen für das Projekt > geschrieben, ohne dass dies den meisten die die myC Threads lesen, > bewusst ist oder von mir viel gehört haben. > > Jeden Version von Hayo und Slogs Pläne sind bestens bekannt, jedoch > gehen die beachtlichen Leistungen aller anderen unter. Das liegt leider > in der Natur der Sache, dass Neuentwicklungen anfangs für sehr lange > Zeit für Anwender nichts vorzuweisen haben. Diese Eigenschaft verzerrt > zusätzlich das Bild, welches die Masse von den einzelnen Entwicklern > bekommen. > Dieses führt dazu, dass viele den bekannteren Entwicklern mehr > vertrauen, als den unbekannteren, welches in einigen Fällen sehr > nachteilig wirkt. Hi Alex, wie Du schon sagtest ist es halt so dass das primäre Interesse erstmal den direkt nutzbaren Ergebnissen gilt. Ist ja auch verständlich. Deine Entwicklung (und auch die der anderen FPGA-Entwickler) sind aber durchaus nicht unbemerkt geblieben an der Softwarefront. Die Bestrebungen auf der Firmwareseite gehen ja nicht nur in Richtung Fehlerfreiheit und neuer Funktionen, sondern auch in Richtung Portierbarkeit auf andere FPGA-Designs. Ich für meinen Teil warte schon seit einiger Zeit gespannt darauf, dass eines der neuen Designs einen Status erreicht, der eine Portierung möglich macht. Wenn ich das richtig mitbekommen habe ist Deine Arbeit zur Zeit die einzige die noch konkret vorangetrieben wird. Wie ist denn Deine Einschätzung wie lange es ungefähr dauern wird bis eine Portierung auf Dein neues Design möglich sein wird? > Um einen Portalwechsel oder eine interne Abwerbung für einen > Entwicklungszweig zu erreichen, muss man sehr leicht verständliche > und sehr gute Gründe vorweisen können. Also meine Gründe hier weiterhin zu posten sind folgende: - SFN ist teilweise extrem langsam mit den Antwortzeiten bzw. Ladezeiten der Seiten, teilweise ist es auch mal überhaupt nicht zu erreichen - ich hatte mehrfach das Problem, dass ich mit drei unterschiedlichen Browsern arbeiten musste um auf den unterschiedlichen Seiten alle Funktionen zur Verfügung zu haben - in diesem Forum kommen die meisten Anfragen zur Firmware, daher gebe ich hier natürlich auch die meisten Kommentare ab Trotz alledem finde ich die SFN-Projektseite wirklich gut und versuche auch diese Plattform mit zu nutzen. Es ist ja eigentlich auch kein echtes Problem auf beiden Plattformen präsent zu sein. Gruß Hayo
Nabend .... ich habe mal die Verstärkungsfaktoren von 1.25, 2, 4 auf 1, 2.5, 5 angepasst (hatte Guido auch schon mal) und die Darstellung entsprechend geändert. Der Patch kann in http://sourceforge.net/apps/trac/welecw2000a/ticket/42 eingesehen werden, ebenso wie weitere Messungen zu dem Thema. Als Diskussionsthread habe ich bei SFN http://sourceforge.net/apps/phpbb/welecw2000a/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
Hallo Rolf, hast das imgage 2x im Anhang, sind beide unterschiedlich oder...war das ein Versehen??? Gruß Michael
Hayo W. schrieb: > Jürgen schrieb: >> Stefan E. schrieb: >> >>>@Hayo >> >>>Es wäre schön wenn das Strecken und Verschieben des Signals im >>>Stop-Modus wieder ginge ... >> >> Ebenso! >> >> Gruß Jürgen > > [...] > > Aktuelles Projekt bei mir ist gerade der Timebase-Controller. Meine > bisherigen Tests mit verschiedenen Registerwerten lassen vermuten, dass > das FPGA-Design anscheinend tatsächlich so vergurkt ist, dass die > Timebases 100MSa/s und 50MSa/s nicht vorgesehen sind. Also: André hat da mal einige Dinge ausgerechnet: http://sourceforge.net/apps/trac/welecw2000a/wiki/Timebases ich bin über "Stopp", Timebase verstellen (von 25MSa/s aufsteigend) mal in den Bereich 50 und 100 gekommen - also scheint da was möglich angedacht zu sein ;) > > Zur Zeit bereite ich gerade eine komplett neu designte Timebasesteuerung > vor, bei der zwar auch die beiden Timebases fehlen, aber bei der die > Aufteilung etwas sinniger und homogener ist. Wäre schon mal einiges ;) > > Gruß Hayo Grüße, rowue PS: aber gerade weil Du so gute Ideen hast, solltest Du Dich mit dem svn anfreunden ;) - Es beißt nicht und geht schnell ;)
Michael D. schrieb: > Hallo Rolf, > hast das imgage 2x im Anhang, sind beide unterschiedlich oder...war das > ein Versehen??? Tja, einmal mit Virus, einmal ohne ;) Scherz beiseite: war ein Versehen .... btw: Das ram-Image fusst auf dem aktuellen svn-Stand > > Gruß Michael Grüße, rowue
Ingo M. schrieb: > Hallo, > > [...] > > - Skype > > - Welec- und #Welec-IRC-Chat auf conference.jabber.ccc.de Es gibt einmal #welec (IRC) auf irc.freenode.net und einmal welec@conference.jabber.ccc.de als Groupchat innerhalb Jabber (xmpp) auf conference.jabber.ccc.de (aka jabber.ccc.de) bevor sich über letzteres jmd. wundert, jabber.ccc.de ist ein sog. "freier" Server, auf den sich jeder eintragen kann und wo auch so ziemlich jeder einen Groupchat/Chatroom aufmachen kann ;) > > - ... > > [...] > > Gruß Ingo Grüße, rowue
...man, müsste längst im Bett sein... ich bekomme das gezappel vom Rechtecksignal nicht weg, erst wenn ich Kanal 2 anschliese, habe ich bei beiden ein ruhiges Signal, ziehe ich K2 wieder ab, bleibt K1 ruhig stehen! Ziehe ich K1 ab, zappelt K2 wieder, ein Tauschen der Tastköppe bringt nichts. Ich hab das Image mit dem Virus erwischt...(auch Scherz) Gruß Michael
...vergesst es, hatte da was übersehen!!! Gruß Michael
Hallo ! Ich würde mich gern von meinem W2024A trennen. Ich hab's jetzt ~ 6 Monate, Firmware-Updates sind eingespielt, das Abschirmblech aus dem Hardware-Thread liegt bei. Das Scope ist in makellosem Zustand, der Bildschirm fehlerfrei - Nichtraucher - 1A Zustand. Natürlich einschließlich aller 4 Tastköpfe ! Bekomme ich ein realistisches Angebot ? Gruß, Stefan
Rolf Würdemann schrieb: > Also: André hat da mal einige Dinge ausgerechnet: > > http://sourceforge.net/apps/trac/welecw2000a/wiki/Timebases > > ich bin über "Stopp", Timebase verstellen (von 25MSa/s aufsteigend) > mal in den Bereich 50 und 100 gekommen - also scheint da was > möglich angedacht zu sein ;) Die Gedanken von André habe ich mir in ähnlicher Form auch schon gemacht, hier handelt es sich aber um wünschenswerte Aufteilungen. Im Gegensatz dazu stehen aber die tatsächlich möglichen Aufteilungen des bestehenden FPGA-Designs. Ich habe schon diverse Registerwerte getestet, diese führen aber zu verzerrten Signalen. D.h. wie schon geschrieben habe ich bislang noch keine Registereinstellung gefunden die tatsächlich die TB 100/50 MSa/s hergeben. Wenn Du zufällig mal auf diese TB gestoßen bist, versuche das doch mal nachzustellen und teile mir mal die Registewerte mit (kann man sich im Terminal mit >,< anzeigen lassen) > PS: aber gerade weil Du so gute Ideen hast, solltest Du Dich mit dem > svn anfreunden ;) - Es beißt nicht und geht schnell ;) Klar, ist wahrscheinlich kein großes Ding, aber wenn ich von der Arbeit nach Hause komme und nicht gerade für Trivialaufgaben wie Gartenarbeit etc. herangezogen werde, schwirren mir meist schon irgendwelche Ideen im Kopf rum. Da setzt man sich natürlich lieber hin und probiert das aus anstatt sich mit SVN auseinanderzusetzen. Ok ich gebe zu ich bin schwach und undiszipliniert ;-) Aber da es sich um ein Hobby handelt und es kein Geld dafür gibt nehme ich mir diese Freiheit einfach mal raus. Immerhin hab ich SVN schon installiert, das ist doch schon mal ein Schritt in die richtige Richtung! Gruß Hayo
Bevor noch weitere fragen, und da ich das Ganze auch transparent halten möchte: Ich mag das Scope wirklich sehr. Bildschirm ist prima, Software hier und da etwas hakelig, aber im Großen und Ganzen viel Gegenwert für's Geld. Ich möchte es jedoch nicht mehr verwenden, da der Trigger einfach immer noch nicht zuverlässig arbeitet und andere Baustellen anscheinend eine höhere Priorität haben - versteht mich bitte nicht falsch; ich habe keinen Anspruch, dass etwas für mich priorisiert wird; aber wozu braucht denn ein Scope eine Screenshot-Funktion, Auto-Meassure, Store-Restore u.s.w., wenn die eigentliche (!) Funktion, das Darstellen von Signalverläufen, nicht einwandfrei funktioniert !? Ich habe z.B. einen Ausschnitt einer digitalen Kommunikation; jetzt interessiert mich der Bereich, der gerade so nicht mehr angezeigt wird; weil der Bildschirmbereich nun einmal endlich ist. Drehe ich die Timebase einen runter, ist alles FLAT, kein Trigger, nichts. Timebase noch einen runter und das Signal wird wieder angezeigt - links an den Rand gequetscht, denn so weit wollte ich mit der Timebase ja eigentlich nicht runter gehen :( Regelmäßig bleibt das Signal auch einfach stehen (Normal-Modus, Ticket vorhanden) - obwohl definitiv ein triggerfähiges Signal anliegt. Man muss dann wieder auf Auto und zurück zu Normal wechseln, um den Trigger erneut zu motivieren. Das ist Mist und da ich nicht erkennen kann, dass das zeitnah gefixed wird, habe ich mich zum Verkauf entschieden. Wenn man mit den Einschränkungen leben kann, wird man nirgends mehr für sein Geld bekommen - ich denke, da sind wir uns alle einig. Stefan
Noch ein kleiner Nachschlag zu den Ausführungen von André. Letzendlich gilt es einen Kompromiss zu finden zwischen einem möglichst großen Scrollbereich und der Anzahl der verfügbaren Delayed-Zeitbasen, die ohne Interpolation darstellbar sind. Das eine Extrem ist der Faktor 1 wie bei der Zeitbasis 50nS/Div, hier stehen nur interpolierte Delayed-Zeitbasen zur Verfügung, aber dafür ein maximaler Scrollbereich. Das Gegenextrem ist der Faktor 25 wie bei der Zeitbasis 5µS/Div, hier steht ein minimaler Scrollbereich der Möglichkeit gegenüber 4 nicht interpolierte Delayed-Zeitbasen zu nutzen. Der optimale Kompromiss liegt meines Erachtens bei Faktor 4 und 5 (Zeitbasen 10µS - 500mS). Hier hat man einen recht anständigen Scrollbereich und trotzdem zwei nicht interpolierte Delayed-Zeitbasen. Meine Bestrebungen gehen daher auch in die Richtung möglichst homogen bei den meisten Zeitbasen den Faktor 4 und 5 zu verwenden und nur ausnahmsweise davon abzuweichen. Gruß Hayo
Default User schrieb: > Das ist Mist und da ich nicht erkennen kann, dass > das zeitnah gefixed wird, habe ich mich zum Verkauf entschieden. Wenn > man mit den Einschränkungen leben kann, wird man nirgends mehr für sein > Geld bekommen - ich denke, da sind wir uns alle einig. > > Stefan Hallo Stefan, in der Tat weiß auch ich nie genau wann ich welchen Fehler fixen werde. Oft ist es so, dass ich im Rahmen einer Idee die ich umsetze auf Fehler in anderen Bereichen stoße, die ich dann fixe. So auch jetzt bei meinen vorbereitenden Änderungen zum neuen Timebasecontroller. Hier habe ich mehr als die Hälfte der Zeit bis jetzt aufgewendet um Bugs zu fixen (im Rotary Interface, beim Zeichnen der Zero-Zeichen etc.). Eines ist aber definitiv sicher: Die FW wird sukzessive besser und für so kleines Geld gibt es nirgends solche Technik mit mittlerweile so breitem Open Source Support. Was ich mich dabei frage ist, was Du denn als Alternative vorgesehen hast. Wenn ich mir so die ganze Low-Budget Konkurenz aus Asien ansehe, wäre das für mich auf keinen Fall eine Alternative. Da käme bei mir dann nur ein (recht teures) Marken-DSO in Frage. Dieses Budget steht aber Vielen im Hobbybereich nicht zur Verfügung. > da der Trigger einfach immer > noch nicht zuverlässig arbeitet und andere Baustellen anscheinend eine > höhere Priorität haben - versteht mich bitte nicht falsch; ich habe > keinen Anspruch, dass etwas für mich priorisiert wird; aber wozu braucht > denn ein Scope eine Screenshot-Funktion, Auto-Meassure, Store-Restore > u.s.w., wenn die eigentliche (!) Funktion, das Darstellen von > Signalverläufen, nicht einwandfrei funktioniert !? Also die Baustellen an denen die unterschiedlichen Entwickler arbeiten haben keine direkte Priorisierung, sondern richten sich eher nach den Neigungen und Interessen der jeweiligen Entwickler. Die Screenshot-Funktion erlaubt zum Beispiel den Testern die einfache Dokumentation von Fehlern - sehr Hilfreich! Ebenso einfach ist dadurch das Erstelllen von Anleitungen. Bei mir gehen die Prioritäten vom Grundsätzlichen zum Detail. Das heißt, wenn das Coding im Großen und Ganzen verwurstet ist, dann bringe ich da erstmal Ordnung rein, bevor ich mich auf Details stürze. Und die Darstellung von Signalverläufen hängt hier von diversen Einflüssen verschiedener Programmabläufe ab. Wenn es also Probleme gibt die einem auffallen, bzw. die einen massiv stören, sollte man sie erstmal melden (Ticket und evtl. Forumsdiskussion). Je nach Schwere des Problems ist dann die Wahrscheinlichkeit recht groß, dass es in absehbarer Zeit eine Lösung gibt. Zumindest habe ich bei meinen Entwicklungen immer ein waches Auge bezüglich bereits bekannter Probleme. Gruß Hayo
Hallo Hayo, vielen Dank für Deine aufmunternden Worte. Ich habe nicht wirklich eine Alternative im Auge; d.h. die neuen 4-Ch von Rigol für €900 sind mir schon aufgefallen, ab das ist eben auch schon mal eine Hausnummer. Ich habe noch ein zweites Scope von OWON; nichts worüber man ins Schwärmen gerät, aber es triggert zuverlässig und stellt -im Rahmen seiner Möglichkeiten- soweit alles dar. Ich kann auch durchaus nachvollziehen, dass man bei einer verfrickelten Firmware schnell vom Hundertstel ins Tausendstel kommt, auch dass sich bei jedem Beteiligten Vorlieben ausprägen ist absolut nachvollziehbar; aber auch wenn ich dieses und jenes prima finden würde und manche Dinge (Screenshot) sehr hilfreich sind - nützt doch das alles nichts, wenn die Grundfunktionalität nicht einwandfrei abgebildet ist ! Im Grunde genommen, möchte man doch erst einmal MESSEN und braucht dafür einen funktionierenden, verlässlichen Trigger - ohne Anzeige des Signals, kein Auto-Measure und auch keinen Screenshot oder was sonst noch alles... Wie gesagt, Vorlieben sind nachvollziehbar - das geht mir nicht anders ;) Aber wenn ein Auto immer wieder nach Belieben stehen bleibt und manche Strecken überhaupt nicht fahren will, freut man sich doch nicht darüber, dass man jetzt den Intervall der Scheibenwischer einstellen kann, oder ? Ich mag den Gedanken eines Open-Source-Scopes sehr - nur stehe ich mit dem unzuverlässigen Trigger einfach zu oft im Regen... Wenn das Signal dann einfach wieder völlig unmotiviert stehen bleibt (Ticket) während man gerade aufwändig eine bestimmte Situation herbeigeführt hat oder versucht, den Tastkopf an einer kniffligen Stelle ruhig zu halten kann man schon mal ausflippen :-\ Wenn zusätzlich bestimmte Details ums Verrecken nicht darstellbar sind, weil der Trigger in der erforderlichen Timebase einfach nicht läuft, nach ja, ich spar' mir besser die Worte :( Letztendlich - was meinst Du denn, wird das mit dem Trigger noch etwas (?) ist das eine Firmware-Angelegenheit oder hängt da zu viel vom FPGA-Design ab ? Gruß, Stefan
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
@Stefan > Ich habe noch ein zweites Scope von OWON; Interessant! Da würde mich ja der direkte Vergleich interessieren. Ist da die Firmware einigermaßen ausgereift oder wird man da auch von etlichen Bugs geplagt, gibt es FW-Updates? Wäre es eine ernstzunehmende Alternative? > Im Grunde genommen, möchte man doch erst einmal MESSEN und > braucht dafür einen funktionierenden, verlässlichen Trigger Ja da hast Du natürlich recht. Aber das was für den Anwender die Grundfunktionen sind, sind für den Entwickler oft komplexe Detailfunktionen bei denen es (aus Entwicklersicht) eher Sinn macht an anderer Stelle anzufangen um sich dann zum Detail vorzuarbeiten. Was den Trigger angeht finde ich eigentlich das sich die Benutzbarkeit doch schon extrem verbessert hat. Hast Du den mal mit der original FW ausprobiert? Dagegen ist das doch schon echt gut. Die Probleme die Du da schilderst sind mir noch nicht so aufgefallen, was aber auch daran liegt, dass ich als Entwickler nicht immer so praxisbezogen teste wie die eigentlichen Anwender. D.h. meistens habe ich am 50 Ohm Abschluß ein Signal aus dem Signalgenerator (oft Rechteck) das sich ganz gut triggern läßt. > Letztendlich - was meinst Du denn, wird das mit dem Trigger noch etwas > (?) ist das eine Firmware-Angelegenheit oder hängt da zu viel vom > FPGA-Design ab ? Das ist allerdings keine leichte Frage. Die Triggerung setzt sich ja aus einem Hardwareanteil und einem Softwareanteil zusammen. Da ich mich nur zwischendurch mal mit der Triggerung beschäftigt habe kann ich das nicht mit Sicherheit beantworten. Meine Einschätzung ist aber, dass hier auf Softwareseite sicherlich Optimierungspotenzial vorhanden ist. Gruß Hayo
@Guido Stimmt den NORM-Modus verwende ich eigentlich auch nie. Vielleicht ist mir deshalb nichts aufgefallen. Gruß Hayo
Jetzt macht mich nicht unruhig (!) der Auto-Modus des Owon funktioniert genau so, wie er soll: kann der Trigger einrasten, macht er's - wenn nicht, läuft das Signal durch, ganz so, als wäre kein Trigger aktiviert. Beim Wittig triggert er im Auto-Modus nie; darum nutze ich ihn auch nicht. Ein triggerfähiges Signal (nahezu perfekte Flanken) liegt an und blitzt von Zeit zu Zeit auch mal auf ?!? Das OWON hat einen -etwas blassen- VGA Bildschirm mit eindrucksvoller Größe. Es ist in den unteren Spannungsbereichen nicht sonderlich rauscharm - befindet sich aber damit beim Welec in guter Gesellschaft. Die Darstellung in den oberen Spannungsbereichen ist dagegen einwandfrei. Die Firmware ist völlig ohne Auffälligkeiten; wenn auch stellenweise etwas lieblos implementiert. Möchtest Du durch den Speicher scrollen, oder sonst irgend etwas an den Drehreglern einstellen, geht das nur 1:1. Also keine Erhöhung der Schrittweite bei schnellem Drehen oder so. Im Grunde genommen ein echter 68er VW Käfer. Fair im Preis; aber eben Basisausstattung ohne Spielereien. Was gehen soll, geht - darüber hinaus keine Extras. Die Tasten funktionieren im Prinzip, sind aber so schwergängig, dass sie das -zugegeben sehr leichte- Scope wegschieben. Also immer die Finger oben auf das Gehäuse und mit dem Daumen die Tasten drücken. Mache ich beim Welec aber mittlerweile auch so :) Erzählt doch mal, warum der Auto-Modus bei Euch einrastet !? Stefan
Das mit dem Trigger ist wirklich ein Problem - das erwähnte Ticket stammt von mir. Im Auto Modus triggert er zuverlässig, aber nur wenn eine ausreichende Zahl Signalperioden dargestellt werden (ich glaube ab 5 oder so klappt es). Wenn man das ganze größer braucht, um Details zu untersuchen, hilft nur der Normal-Trigger. Und der spinnt, wie ich schonmal ausführlich erklärt habe. Zwischendurch bleibt alles einfach stehen, obwohl nach wie vor triggerfähige Flanken anliegen. Aber das habe ich wie gesagt ja schon im Forum und im Ticket beschrieben. Gruß, Michael
Habe mal versucht das nachzustellen. Bei mir triggert er ohne Probleme sobald eine Flanke vorhanden ist, selbst wenn der Rest der Periode nicht mehr auf dem Bildschirm zu sehen ist. Das Ganze auch mit verschiedenen Signalformen (Rechteck, Sinus, Dreieck, Rampe links, Rampe rechts). Und zwar auch genau am Pretriggerpunkt. Mehr kann man eigentlich nicht verlangen. Welche Firmware, bei welcher Timebase, welche Spannungseinstellung, welche Signalform? Anbei die aktuelle 0.97 beta, würde mich interessieren ob es da auch auftritt. Gruß Hayo
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
So habe nochmal etwas rumexperimentiert, bei 500 MSa/S konnte ich auch eine leichte Triggerschwäche bei abnehmender Anzahl Flanken auf dem Screen feststellen. Anscheinend triggert das Gerät bei 1 GSa/S am zuverlässigsten. Allerdings war diese leichte Schwäche nicht so gravierend wie von Stefan beschrieben. Gruß Hayo
Ich habe mir deine neue Version mal geholt - jippie der Cursor geht wieder im Stopmode und Zoomen auch! Der Trigger spinnt aber nach wie vor. Test erfolgte mit I2C Bus, wie im Ticket beschrieben. Zunächst bei 50us timebase => alles ok. Umgeschaltet auf 20us => keine Reaktion mehr, auf Zweitoszi bei gleicher timebase alles bestens. Umgeschaltet auf 10us => geht wieder. Wieder auf 20us => geht erst, bleibt dann wieder stecken. Keine Ahnung, ob das lediglich bei dieser timebase geschieht, es nervt aber tierisch. Abhilfe bei Steckenbleiben: Run/Stop zweimal drücken oder an timebase drehen. Wahrscheinlich nur eine Kleinigkeit? Gruß Michael
Das "Herumhüpfen", wie Guido es nennt, ist durchaus nicht normal. Bei meinem Zweitgerät, das nur eine Billiggurke ist, gibt es nichts dergleichen. Eins der dadurch verursachten Probleme ist, dass der Average Mode meiner Ansicht nach nur Müll liefert...wie könnte es auch anders sein, bei dem Gehüpfe? Beim andren Oszi führt das Averaging zu einem Lehrbuch-Signal.... Gruß, Michael
Beim Zoomen läuft hier gerade auch einiges schief: wenn ich im stopmode von 20us auf 5us drehe, zoome ich heraus statt herein! Gruß Michael
Also, ich hab' jetzt die 097 drauf und -hätte mich jetzt auch gewundert- im AutoModus kein Trigger bei wirklich erstklassigen Signalen. Es werden völlig unmotiviert Signale eingeblittet - von Triggern kann in keiner Timebase die Rede sein. Im EdgeMenü ist alles einwandfrei eingestellt und funktioniert ja nach Umstellung auf den NormalModus einwandfrei. Trigger bei 250k perfekt - FLAT bei Reduktion auf 100k - erneuter Trigger bei 50k - jedoch Darstellung Mist ! Also alles wie gehabt :(
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
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...
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
Uff bin ich froh, dass ich da Rückenwind bekomme - mein Ticket und meine Postings dazu fanden leider keine Resonanz aber je mehr Leute das Problem melden, desto wahrscheinlicher ist es doch, dass ein barmherziger Entwickler sich der Sache annimmt... Was haltet ihr denn davon, elektor auf das Projekt OpenSource Oszi hinzuweisen? Eine Kurzmeldung würde bestimmt die Aufmerksamkeit einer Menge Leute darauf lenken und vielleicht auch Zuwachs im Entwicklerteam bringen. Wenn ich das richtig mitbekommen habe, könnte ja gerade die VHDL Front noch Verstärkung vertragen. Gruß Michael
Macht mal bitte jemand bei mir ein Update bzgl. des AutoModus; den Ihr ja wohl größtenteils benutzt. Warum funktioniert der Trigger bei mir nur im NormalModus ?
Ich nehme an dass Du Default Setup schon mal gedrückt hast oder? Im Automodus triggert das Gerät definitiv überhaupt nicht? Auch nicht in der 50 nS Timebase? Wenn dem so ist muß ja irgendein Defekt vorliegen. Als einzige Maßnahme fällt mir momentan nur ein Flash-Restore ein. Wenn Du selbst ein Backup gemacht hast kannst Du das ja einspielen, ansonsten würde ich mir mal die angezeigte Hardwarerevision notieren, dann kannst Du auch ein Backup von jemandem hier bekommen (z.B. von mir). Gruß Hayo
Ein Default-Setup habe ich jetzt noch einmal durchgeführt. Bleibt alles wie gehabt - Tigger im NormalMode, frei laufend im AutoMode. Wobei der NormalMode -ebenfalls wie gehabt- eher launisch ist; gern mal stehen bleibt und in mancher TB einfach stehen bleibt. Nachdem Normal funktioniert und Auto nicht, halte einen Hardwaredefekt für ausgeschlossen. Gruß, Stefan
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
Also bei mir geht's im Wesentlichen meist ebenfalls um digitale -in diesem Fall serielle- Daten. Da verliert man schon den Glauben, wenn man liest, was Guido so schreibt :( Was soll ich da schreiben (?) Serielle Daten 14-28 kBps, ~5VDC, TB zwischen 50k und 250k.
Was mir beim Trigger auffält, ist, dass man den Triggerlevel bei einem Rechteck relativ weit oben an der Flanke ansetzen muss, wenn man sich nahe an der unteren Rechteckspannung bewegt, streikt er gern. Bei 5v/div (da 3 Kanälge gleichzeitig dargestellt werden) muss ich bis auf ca. 45% der Amplitude hoch, bevor sich der Trigger regt (20us/div). Bei 2V/div sieht es besser aus, aber >15% muss der Trigger immer noch stehen. Meine Triggerprobleme habe ich übrigens immer mit Kanal 4 gehabt, vor allem bei 20us will er sich oft nur schwer überreden lassen. Dabei habe ich eine interessante Beobachtung gemacht: nach einem Triggerereignis, dass die Kiste gekonnt ignoriert hat (konkret löse ich per Hand eine I2C Übertragung aus), drücke ich Stop und wie durch ein Wunder zeigt er auf einmal doch das Signal. Scheinbar nur mit der Darstellung, das triggern im Hintergrund scheint zu funktionieren. Gruß Michael
Oh da wollte ich eigentlich ein Verb spendieren.... es hapert mit der Darstellung, sollte das heißen. Und "dass" sollte natürlich "das" heißen.
Irgendwie stimmt da noch was nicht mit der Umschaltung der Zeitbasen. Bei Umschaltung von 10us auf 5us war es gerade wieder so, dass sich der Zeitausschnitt vergrößert hat (Darstellung wie 20us), erst nach Schalten auf 2us und wieder zurück nach 5us stimmte das Ganze.
O.k. Stefan, aber das sind ja nichtperiodische Signale. Wie versuchst du die zu triggern, bzw. wie machst du das mit einem anderen Oszi?
So bin gerade wieder eingestiegen, - wie Guido eben anmerkt ist der Trigger für periodische Signale gedacht. Ein serieller Datenstrom ist aber mitnichten periodisch! D.h. hier kann man eigentlich nur per Single-Shot Momentaufnahmen machen, sonst sieht es nämlich so aus als würde der Trigger durchlaufen, da ja bei jedem Triggerevent das dargestellte Signal anders aussieht. Und schon haben wir die Erklärung. Probier mal ein periodisches Signal (Siganlgenerator, Quarzoszillator etc.) dann sollte es doch wohl klappen. Gruß Hayo
Also, es kommt ein Impulspaket, dann lange nichts mehr, dann ein Impulspaket. Der NormalModus triggert doch auch !?
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
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
@ Hayo: Guter Tip, das werde ich mal probieren. Gruß, Guido
Manchmal habe ich den Eindruck, dass meine posts unsichtbar sind...
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
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
Ich habe jetzt nochmal Vergleichstests mit Kanal 1 durchgeführt - hier scheint alles so zu laufen wie es soll. Kanal 4 zeigt dagegen die genannten Schwierigkeiten. Wenn ich Kanal 1 und 4 beide an SDA des I2C Busses hänge und auf Kanal 1 triggere, erscheinen die beiden Signale meistens gleichzeitig (wie es sein soltle), manchmal vergeht aber fast eine Sekunde, bis Kanal 4 auch aktualisiert wurde! Dies ist nach Zeitbasiswechsel der Fall und tritt dann ein- bis zweimal auf, danach passt wieder alles. Gruß Michael, der glücklicherweise wohl doch nicht unsichtbar ist
Jürgen schrieb: > Mahlzeit zusammen! > > Warum nutzten wir nicht einfach das Handbuch? > > http://www.welec.de/data4download/W2000A/W2000AOMen6C8.pdf > > Dort ist alles ( Run/Stop/Single/Autotrigger/Normaltrigger usw. > S.2-2,S.4-14) sehr gut und genau beschrieben und sollte am Ende auch > genau so funktionieren! Die Funktionen sind zwar nett erklärt, entsprechen aber nicht ganz der tatsächlichen Funktionalität. Es gibt mitnichten einen Pretriggerbuffer oder eine Postriggerbuffer, die separat befüllt werden. Auch an anderen Stellen handelt es sich eher um idealisierte Annahmen. Gruß Hayo
>Ich habe jetzt nochmal Vergleichstests mit Kanal 1 durchgeführt - hier >scheint alles so zu laufen wie es soll. >Kanal 4 zeigt dagegen die genannten Schwierigkeiten. Das ist doch schon mal ein Hinweis. Vielleicht wäre es sehr hilfreich, mal für alle Register die die Bedeutung der einzelnen Bits zu ermitteln. Ich finde das derzeit sehr unübersichtlich. Zusätzlich wird zum löschen der Bits die invertierte Darstellung verwendet.
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
@Jürgen Es gibt keinen expliziten Pretriggerbuffer, sondern nur einen Buffer für den gesamten Signalverlauf (16384 Byte). Der Pretrigger bestimmt nur zusammen mit dem Memory-Window und dem Zoomfaktor welcher Ausschnitt im Screen dargestellt wird. By the way -> bei meinen Vorbereitungen zum neuen Timebase Controller stelle ich gerade die Tabellen für Zoomfaktoren und Signallängen um. Dabei bin ich auf diverse falsch berechnete Werte bei den interpolierten Zeitbasen gestoßen. Beispielsweise berechnet der Kollege von WELEC 600/2.5 = 300 und 600/1.25 = 150. Da wundern einen natürlich einige Werte und Effekte nicht. Dabei sind diese Fehler durch die verschwurbelte Tabellenzugriffslogik um drei Ecken nicht auf den ersten Blick erkennbar. Die Umstellung auf neue Tabellen schafft hier deutlich mehr Transparenz. Gruß Hayo
Hallo, ich hoffe jemand kann mir hier helfen. Ich habe nach einem misslungenen Firmware-Update riesen Probleme mit meinem Welec W2012A. Ich kann das Oszi zwar flashen, aber es bootet die Firmware einfach nicht. Der Bildschirm bleibt schwarz. Ich habe nur noch Zugriff auf den Bootloader. Gruß Marius EDIT: Die Firmware ins RAM laden geht irgendwie. Aber die Seriennummer ist weg. Ich habe vor dem Einspielen der Firmware einen kompletten Dump meiner Original-Firmware gemacht. Aber das Einspielen schlägt auch fehl, irgendwann bricht es einfach ab.
@ 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
Marius Wensing schrieb: > Hallo, > > ich hoffe jemand kann mir hier helfen. Ich habe nach einem misslungenen > Firmware-Update riesen Probleme mit meinem Welec W2012A. Zunächst mal - don't panic! Bei einem mißlungenen Update kann schon mal das restliche Flash einen Ditsch abkriegen. Dann muß man das neu einspielen, ist aber kein Ding. Wir kriegen das hier schon per online Hilfe wieder hin. Bei mir war das damals das Gleiche. Zunächst müssen wir erstmal wissen wie Du Dein Update gemacht hast: - Betriebssystem (Linux / Win (Version)) - WelecUpdater / Perlskript - Hardwarerevision (Nummer auf dem Startscreen wenn Du die notiert hast) Eventuell ist Dein Backup nicht in Ordnung, dann kannst Du hier eines bekommen. Gruß Hayo
Hi all, ich habe nach dem letzten Flashen das Problem, dass keine Signale mehr angezeigt werden, auch die Testsignale gehen nicht! Ich kann komplett durch alle Screens schalten nur eben mit dem Messen ist's nix. Hatte die 0.97 eingespielt, danach die 0.96 - nichts half. pleaze!! Michel
@Jürgen Sach ich doch! Idealisierte Darstellung ;-) Hayo
@Michael Default setup hast Du gemacht? Hayo
@ Hayo, bin ich mir jetzt nicht sicher... Wo finde ich den Punkt denn? Unter den Utilities? Kann mich nicht erinnern... Michel
Hallo Michel, du gehst in den EDGE-Modus, dann muß über der rechten SOFTKEY-TASTE "DEFAULT SETUP" stehen! Die betätigst du, dann müsste alles wieder hübsch sein! Gruß Michael Hallo Hayo, die Nullinien-Kalibrierung zickt immer noch rum, wenn ich das Scope wieder einschalte, ist sie völlich daneben (nur bei 1V+2V/DIV) Noch ne Frage: Macht es einen Unterschied beim Kalibrieren, wenn der NOIS-FILTER eingeschaltet ist??? Gruß Michael
@Michael W. Du findest Default Setup einmal im Save/Recall Menu und einmal im Edge Menü. @Michael D. Die Kalibrierung war auch erstmal als Abhilfe gedacht. Eine Überarbeitung steht noch an und soll dann eine etwas sicherere genauere Kalibrierung bringen und dann auch für alle Bereiche mit einem Schlag. Kommt aber erst nach der Umstellung des TB-Controllers. Ebenfalls noch unfertig sind die FFT-Funktionen, wobei ich mal sehen muß in welcher Reihenfolge ich das angehe. Der Noise-Filter hat keinerlei Auswirkungen, da die Kalibrierfunktionen komplett eigene Lese und Verarbeitungsroutinen nutzen. Hayo
Hallo Hayo, mal wieder was dazu gelernt... es wäre schön, wenn die Kalibrierung an 1. Stelle wäre, dann müsste man nicht ständig nachhoppeln, da ich mich beim (z.B.PWM-Messung) manchmal frage, warum die Spannungen plötzlich nicht mehr stimmen----alles abziehen, kalibrieren, wieder alles anschliessen, ist dann schon etwas lästig(ich will ja nicht pöpeln)... Gruß Michael
@Michael D. Übrigens habe ich bei mir keine Probleme mit den Nullpunkten, hab eben nochmal geprüft, alle Spannungsbereiche kalibriert, dann ausgeschaltet dann wieder ein, alles ok. Hayo
oh man, hab's jetzt selbst noch mal probiert und ist bei mir genauso, typisch Vorführeffekt, wer weiß, was da manchmal vor sich geht... Gruß Michael
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
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
Angehängte Dateien:
-
IMG_0326.JPG
49 KB -
IMG_0327.JPG
51 KB
Hallo, ich bins nochmal... Ich habe gestern Abend noch etwas weitergehender versucht die Firmware wiederherzustellen. Anscheinend ist mir das auch weitestgehend gelungen. Meine Seriennummer ist wieder da und auch das Oszi startet mit der Holiday Edition. Ob alles wieder so wie vorher ist, kann ich aber noch nicht sagen. Prinzipiell sieht es aber mal nicht schlecht aus. Wenn ich noch Hilfe brauche melde ich mich hier wieder. Allerdings habe ich derzeit in einigen Zeitbasen große Zeichenfehler. Das war aber vor dem FW-Update auch schon so. Ich habe mal ein Foto angehängt, wo das deutlich wird. In einigen Zeitbasen treten Peaks auf, die da definitiv nicht sind. Verschiebe ich das Signal in Y-Richtung, gibt es Stellen, wo die Peaks verschwinden, und dann wieder welche, wo die Peaks da sind. Vielleicht kann mir jemand sagen, ob das normal so ist. MfG Marius
Hallo Marius, das mit den Peaks kann ich bestätigen! Beim verschieben tritt es tatsächlich nur jeden 3. oder 4. Raster der Y-Achse und nur an bestimmten Stellen des Bildschirms auf! fast Dasselbe gilt beim verschieben ohne Signal nur minimaler, mal ist die Nullinie ohne Rauschen, geht man einen Raster weiter, rauscht es wieder u.s.w....hm, an was liegt das denn? Gruß Michael
Die Peaks treten bei meinem W2022A überhaupt nicht auf und bei meinem W2014A nur auf Kanal 4. Da verhalten sie sich dann aber wie von Euch beschrieben. Das kann man aber eigentlich nicht als normal bezeichenn, ich war auch schon mal am Überlegen ob das ein Rückgabegrund ist. Allerdings wurde das bei mir besser als ich den Lüfter modifiziert habe (siehe Hardwarethread). Gruß Hayo
Und noch meine 2 Cents: Ich habe die Peaks gelegentlich auch, aber nach ca. 3 min Warmlaufzeit verschwinden sie dann (W2012A). Gruß, Guido
Ich verstehe nur nicht, warum das nur in bestimmten Zeitbasen auftritt. Ich habe das Problem extrem bei 1 GS/s und 500 MS/s, aber dort auch nicht in allen Zeitbasen wie oben im Bild zu sehen ist. Das verschieben der Signale in Y-Richtung geschieht doch sicherlich rein in Software. Sonst müssten die Peaks doch auftauchen egal wo sich das Signal auf dem Bildschirm befindet. MfG Marius
na toll, Hayo hatte ein thermisches Problem und beim Guido muß es sich erst aufwärmen ---großes Fragezeichen--- Ich werde das mal testen bei offenem Gerät, das wenn der Fall wieder eintritt, schau ich mal ob es mit Kühlung was bringt, wenn nicht, könnte es wirklich ein Softwareproblem, wie Marius beschrieben hat, sein! Gruß Michael
Hayo, kannst Du mal kurz sagen, an welcher Stelle das alte Signal gelöscht wird? Falk
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
Falk Willberg schrieb: > Hayo, kannst Du mal kurz sagen, an welcher Stelle das alte Signal > gelöscht wird? Hi Falk, ich bin mir nicht sicher was Du meinst. Der Signalbuffer wird bei jedem Acquisitionsdurchlauf im ADC-Handler neu beschrieben. Die Grafikausgabe wird nicht gelöscht sondern die Grafiklayer werden in TransferPlanes() einmal pro Schleifendurchlauf neu ausgegeben. Gruß Hayo
Zu den Peaks: Dass diese in unterschiedlichen Zeitbasen unterschiedlich stark ausgeprägt sind hängt mit dem Zoomfaktor zusammen, der ja dafür sorgt dass nur jeweils der 2te, 4te, 5te, 10te, 20te oder 25te Wert dargestellt wird. Bei Faktor 2 bedeutet das, dass nur die Werte von 2 ADCs dargestellt werden, bei Faktor 4 ist es nur ein ADC. Bei den anderen wechseln die ADCs. Wenn jetzt die Spikes von einem ADC verursacht werden, dann hat man bei Faktor 1 (50nS) alle Spikes im Bild. bei Faktor 2 und 4 hängt es jetzt davon ab von wo gestartet wird, im günstigsten Fall verschwinden die Spikes ganz. Bei den nicht durch 4 teilbaren Zeitbasen treten die Spikes dann mit reduzierter Häufigkeit auf. Hier hilft am ehesten der Download als CSV, da hier unabhängig vom Zoomfaktor das ganze Signal zur Verfügung steht Soweit zur Theorie. Ob die Spikes durch den Trigger verursacht werden kann ich ich nicht sagen, möglich wären auch Timingprobleme beim Auslesen des ADC, ein FPGA-Designproblem also. Ich habe auch noch von keinem unserer FPGA-Designer von diesem Peakproblem gehört. Es handelt sich offensichtlich um ein Problem des WELEC-Designs. Dass die Firmware hier verantwortlich ist würde ich eher nicht vermuten, da sonst die Auswirkungen bei allen gleich sein müssten. Gruß Hayo
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
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
Hallo zusammen. Ich habe mal die "Zeitfresser" dingfest gemacht: Hardware::Handle_ADC(): 127ms Display::DrawSignals(): 72ms Hardware::TransferPlanes(): 26ms Basis ist Rev. 260, 200mV/10mV 100µs Trigger: Auto. HTH, Falk
So nun muss ich mich hier auch mahl melden war seither stiller mit Leser (und mit nutzer). Und deswegen vorab danke! an alle fleißigen Entwickler an der Hardware, Software und FPGA Front die das Gerät So langsam brauchbar machen. Macht Bitte weiter so. nun zu meinem Problehm Ich hab vor einigen tagen die Software Version „FW1.2.BF.0.82+beta“ und direkt danach „FW1.2.BF.0.84beta" in mein W2024A geflasht das klappte auch wunderbar und die Software lief Abgesehen von den bekanten Fehlern perfekt. Nun hab ich das Scope zum ersten mahl nach einigen tagen wieder eingeschaltet und es lief nicht mehr hoch. Auch das einspielen meines original Backups (kompletter Speicher Bereich von 0x00040000 bis 0x007FFFFF) brachte keine Verbesserung (gelegentlich werden nun beim Einschalten Fragmente der Startbildschirms angezeigt). hat jemand einen Tipp was man da machen kann. Und Woran das liegt wäre denke ich auch interessant (ich hatte ca. 5 Monate die original Firmware 104 auf dem Gerät die Lief (wen man das bei so vielen Bugs) so nennen darf immer perfekt ach ja zum einspielen und sichern der Software hab ich den WelecUpdater (V0.4BA22)verwändet führ Hilfe wäre ich sehr dankbar MFG Stefan und wenn´s hilft ich habe Spikes auch nur im Warmen zustand auf Kanal Drei
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
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
Angehängte Dateien:
-
FFTscreener1.JPG
250 KB -
FFTscreener2.JPG
100 KB -
FFTscreener3.JPG
150 KB
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
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
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
alex008_ schrieb: > Hallo, > > ich entwickle das LEON3 HW-Design. ... > Bis das ganze aber Benutzertauglich ist, vergeht mindestens noch ein > Jahr! Na, nicht so pessimistisch.... > Ich freue mich natürlich über jede Hilfe (SW+HW)! Da die NIOS-Geschichte offensichtlich eine Ein-Mann-Show bleiben wird und ich da auch kein Potential für entscheidende Verbesserungen mehr sehe, werde ich meinen Einsatz an dieser Stelle reduzieren oder einstellen und mehr an der LEON3 FW arbeiten. Was ich bisher gesehen hab, gefällt mir ganz gut. ZPU liegt ja momentan auf Eis, wenn ich das richtig verstanden habe. Sorgen macht mir, daß auch hier ein Punkt ist, der von einer einzigen Person abhängt. Ich jedenfalls habe keine Ahnung von VHDL. Falk
Das mit dem Leon (und neuer Software) finde ich gut. (Nach dem Wenigen, was ich Neuling bisher weiß... :-) Ich wäre dabei, das bestehende Nios-Design und die Herstellersoftware halte ich auch für eine Sackgasse (nix für ungut). Ich selbst kann praktisch kein VHDL, bin Firmwareentwickler in einer ASIC-Firma, die Hardware machen andere. Bin's aber gewohnt, mit solchen zu arbeiten. ;-) Jörg
Hallo, 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
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)
Ist das Oszi eigentlich Fernsteuerbar? Ich kenne das von den großen Osziherstellern. Die Befehle über IEEE sind fast immer die gleichen. Seriell kann man ja die gleichen Befehle benutzen. Mfg Michael
Michael schrieb: > Ist das Oszi eigentlich Fernsteuerbar? Ich kenne das von den großen > Osziherstellern. Die Befehle über IEEE sind fast immer die gleichen. > Seriell kann man ja die gleichen Befehle benutzen. > > Mfg Michael ...ein Namensvetter, du sprichst das DSO mit der Seriellen Schhnittstelle über ein Telnet-Prog. an! Die Befehle sind z.B. im FW.096HE unter dem Ordner "DOKU" interpretiert! Ansonsten die Schnittst. mit 115 KB einstellen(sonst funzt das net) Telnet mit Schnittltelle COM ebenfalls 115 KB einrichten, dann "H"(help) eintippen, der Rest dürfte ja bekannt sein! ...hab' ich was vergessen? Gruß Michael
Michael schrieb: > Ist das Oszi eigentlich Fernsteuerbar? Teilweise schon: http://sourceforge.net/apps/trac/welecw2000a/wiki/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.
Hey, das schaut ja ganz schön flink aus. Was für eine Zeiteinstellung war das?
Stefan E. schrieb: > Hey, > das schaut ja ganz schön flink aus. Was für eine Zeiteinstellung war > das? 500mS/s Ja, schnell ist das (ca. 50fps), aber dafür fehlt noch einiges an Konvertierungen etc. Falk
Falk Willberg schrieb: > P.S.: Hier das Ergebnis eines ersten Versuchs, NIOS mal richtig flott zu > machen: http://www.consult42.com/NIOS-Schnell-2.avi Und hier zum Ausprobieren: http://consult42.com/W20XXA-prereleases/TomCat-22102009.ram Bitte keine Fehlerberichte. Das ist nicht mehr als eine Studie. Falk
Und hier die Variante mit Vektoren als Video: http://consult42.com/signal2.mpg Könnte sein, daß das etwas wird... Falk
Ich hab's mal ins Ram geladen, also ich muß schon sagen, das geht ja ab wie Schmitt's Katze!!! Hast du einen Turbolader in die FW eingebaut? (lach) Gruß Michael
Michael D. schrieb: > Ich hab's mal ins Ram geladen, also ich muß schon sagen, das geht ja ab > wie Schmitt's Katze!!! > Hast du einen Turbolader in die FW eingebaut? (lach) Nein, eigentlich habe ich eine ganze Menge Zeug übersprungen. In Kurzform: Ich nehme die Werte aus dem ADC-Puffer, skaliere die über eine Tabelle und schreibe direkt in den Framebuffer. Falk
Falk Willberg schrieb: > > Nein, eigentlich habe ich eine ganze Menge Zeug übersprungen. > > In Kurzform: Ich nehme die Werte aus dem ADC-Puffer, skaliere die über > eine Tabelle und schreibe direkt in den Framebuffer. > > Falk ...das war als erstes meine Vermutung, das da einiges übersprungen wird, wollte es nur nicht ansprechen, dachte das ich mich mit dieser Aussage blamiere!!! Es ist schon verblüffend, das die Geschwindigkeit garnicht abnimmt, wenn man noch den 2. Kanal mit einschaltet! Hatte ich mal kurz getestet... Wenn man das noch nach Bedarf switchen könnte, wäre das ne feine Sache! Gruß Michael
Michael D. schrieb: ... > Es ist schon verblüffend, das die Geschwindigkeit garnicht abnimmt, wenn > man noch den 2. Kanal mit einschaltet! Hatte ich mal kurz getestet... > Wenn man das noch nach Bedarf switchen könnte, wäre das ne feine Sache! Das geht: Auf der RS232 'S' tippen (test switch 1).
Falk Willberg schrieb:
> Das geht: Auf der RS232 'S' tippen (test switch 1).
wie sieht's aus, könnte man es in die nächste FW mit einbauen?
Gruß Michael
Michael D. schrieb: > Falk Willberg schrieb: >> Das geht: Auf der RS232 'S' tippen (test switch 1). > > wie sieht's aus, könnte man es in die nächste FW mit einbauen? Wenn es brauchbar ist, könnte eine FW 1.2-OS-0.92 released werden. Hayos FW-releases sind ja inzwischen inkompatibel geworden, wenn ich nicht irre. Falk
au mann, ich denke, das ihr das gemeinsam gestaltet, nein? Jetzt habe ich irgenwie den Faden verloren! Bei der Entwicklung kann ich leider nicht mitwirken, denn was da noch zu lernen wäre, würde warscheinlich mein restliches Leben nicht mehr ausreichen...ich bräuchte sowieso mindestens 3 davon!!! Wie auch immer, hier im Forum haben sich Viele festgebissen, im SF will keiner so recht teilnehmen. Es sind sehr viele Baustellen wo man jetzt so langsam den Überblick verliert! Mühselig muß man sich alles zusammen suchen und findet dann doch nüscht... Also wie soll man hier ünterstützen durch Test's u. Berichten, wenn alles so weit verstreut ist??? Z.B. sollten alle Files, ob Software, Gui's, Nios oder FW's über einen Link von hier erreichbar sein, denke ich. SourceForge wird die File-Seite überhaupt nicht gepflegt! Die letzte FW ist die 091, wir sind jetzt schon bei 097!!! Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine Resonanz bekäme, oder?
Michael D. schrieb: > au mann, ich denke, das ihr das gemeinsam gestaltet, Das wäre besser. ... > SourceForge wird die File-Seite überhaupt nicht gepflegt! Releases gab es da länger nicht, siehe unten. Da ist aber trotzdem viel los: http://sourceforge.net/projects/welecw2000a/develop Fast jede kleine Änderung ist da kommentiert. Die Entwicklung findet praktisch öffentlich statt. > Die letzte FW > ist die 091, wir sind jetzt schon bei 097!!! Da schiebe ich den schwarzen Peter ganz weit von mir. Wenn nix eingepflegt wird, kommt auch nix raus. > Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine > Resonanz bekäme, oder? Ja, das ist schade. Ich kann da aber nichts mehr dran ändern. Falk
Hallo 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
Hallo Leute, zu Sourceforge: Vieleicht haben einige Leute Angst dass ihr Post dort übersehen wird, weil kaum einer in ein fast leeres Forum reinschaut? Mann kann jedoch auch ein ganzes Forum abonnieren. Wählt man z.B. "Board index ‹ Entwicklung (deutsch) ‹ Firmware" erscheint unten auf der Seite ein Feld "Subscribe forum". Damit kann man die mail Benachrichtigung für neue Themen aktivieren. Das gleiche gillt natürlich auch für einen einzelnen Thread zur Firmware: Ich habe mich nochmal neu in die Teile für screenshot und CSV Export eingearbeitet. Die sind ja wirklich übersichtlich geworden! Vor einiger Zeit war mal ein einfaches Handshake Protokoll angedacht. Das Oszi müsste auf Eingaben über RS232 warten können. Wurde das mittlerweile realisiert? Außerdem frage ich mich, warum die Reihenfolge der Daten für den CSV Export geändert wurde. Besser fände ich: Ersten Wert Ch1-Ch4, zweiter Wert Ch1-Ch4... Und nicht Werte 0 bis 16383 von Ch1, dann von Ch2, Ch3 und Ch4. Auf die Reihenfolge der Werte in der CSV Datei hätte das natürlich keine Auswirkung! Mfg, Kurt
Hallo branadic, Danke erstmal für das Blech, ist heute gekommen! Du hast Recht, ich habe das eben noch mal geprüft "OS u. BF! Also "OS" ist von Falk und "BF" von Hayo? Mit den 2 Entwicklungsbäumen habe ich kein Problem und so schlecht finde ich das jetzt auch nicht, wenn man irgentwann vielleicht doch auf eine gemeinsamen Ebene trifft ?!? Wie es zum Spalten gekommen ist, habe ich ja auch mit bekommen, war ja schon fast "Zoff in Beverly Hills"...dachte nur, das ihr euch zwischenzeitlich wieder vertragen hattet...hm! Ich selbst bin mit "kastor7" (mike0815 war schon vergeben) im "SF" angemeldet und stöbere auch regelmässig auf den Seiten. Vieles wird über Skype diskutiert? Gibt es da die Möglichkeit zum chatten oder was? Vielleicht schreibst du mir eine PN in der du mir beschreibst, wie ich dazu stoßen kann?!?
Michael D. schrieb: > au mann, ich denke, das ihr das gemeinsam gestaltet, nein? Jein .... > Jetzt habe ich irgenwie den Faden verloren! > [Entwicklung, Link] > Z.B. sollten alle Files, ob Software, Gui's, Nios oder FW's über einen > Link von hier erreichbar sein, denke ich. Sowas ist bloss mit einem Wiki auf SF.net wesentlich leichter zu pflegen als hier - in diesem Sinne gibt es einen Link: http://sourceforge.net/apps/trac/welecw2000a/wiki > SourceForge wird die File-Seite überhaupt nicht gepflegt! Die letzte FW > ist die 091, wir sind jetzt schon bei 097!!! Tja, die muss dann jmd. hochladen - wobei es halt zwei Versionen gibt: einmal BF - aka Hayo und einmal OS (OpenSource), an welcher mehr Leute mitarbeiten. Da wir letztens die Änderungen von mir bzgl. der Verstärkerstufen eingepflegt haben und (u.a.) Falk jetzt dabei ist, damit die Signalverarbeitung und -darstellung von unten hoch neu aufzuziehen, werden die beiden Versionen jetzt stärker divergieren. > Es wäre dochh schade, wenn die ganze Arbeit die ihr euch macht, keine > Resonanz bekäme, oder? Sagen wir es so: ich empfinde es jetzt erstmal als Schade, dass einige Räder zweimal erfunden werden und Arbeit doppelt gemacht wird - aber wir werden sehen ... Grüße, rowue
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
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
@ 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
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
Odic schrieb: ... > Das einzige, was ich nicht verstehe, ist: warum trefft ihr keine bewußte > Entscheidung und kommuniziert die klar und deutlich? Diese Entscheidung ist vor Monaten gefallen, nur hält sich einer nicht daran. Das kann man alles, wenn man richtig viel zeit hat, hier nachlesen: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware" > Ich denke, jeder hat genug Sinn für Realität um zu wissen, dass ihr die > beiden Versionen entweder JETZT zusammenführt oder NIE. Einmal habe ich Hayos Änderungen mit dem SVN zusammengeführt, ein weiteres Mal jemand anderes. Ich mach das nicht noch mal. Falk
Guido schrieb: ... > Für mich ist dieses hier wichtiger, weil mich auch andere Themen > interessieren und ich daher meist täglich hier vorbeschaue. Im SFN > ist nicht soviel los, dass es sich täglich lohnen würde. Es gibt für alles Mögliche eine eMail-Benachrichtigung. > Außerdem > wird es ausgerechnet von den Leuten protegiert, die hauptsächlich > auf nichtöffentliche Kommunikationswege setzen und die Ergebnisse > ihrer "fruchtbaren Diskussionen" weder hier noch auf SFN > veröffentlichen. Vor wenigen Tagen meldete sich ein "Neuer" im öffentlichen IRC-Kanal #welec bei irc.freenode.net. Der diskutiert jetzt im Skype-Chat mit und hat schon wertvolles zur FW beigetragen. Mit Rowue bespreche ich mich regelmäßig im öffentlichen Jabber-Kanal "welec" bei jabber.ccc.de. Im übrigen will *ich* auch einen Kommunikationskanal haben, in dem sich die Experten austauschen. ... > Was gegen das SVN auf SFN spricht ist die Disziplinlosigkeit der > Nutzer. Da wurden z.T. in 30 minütigem Abstand neue Versionen > eingepflegt, die zum Teil noch nicht einmal durch den Compiler > gelaufen sind. Erzähl mal, welche Du meinst. > Eine Menge Änderungen (ca. 273) wurden durchgeführt, > die wohl alle völlig ungetestet sind. Soso, das ist eine mutige Behauptung. Meine commits sind natürlich getestet. Natürlich nicht in jeder Hinsicht und meistens nur von mir, aber für "reife" Versionen gibt es die Releases. Und 273 Änderungen bedeutet auch, daß keiner sich im stillen Kämmerlein etwas zusammenhäkelt, sondern daß jede Änderung transparent ist. ... > Es ist doch eigentlich nicht so schwer: Die Trunk-Version ist die > stabile Grundlage, in der nur gemeldete Fehler behoben werden. Wenn > jemand etwas Grundsätzliches ändert oder etwas testen möchte, macht > er einen Branch. Um Tester für seinen Branch muss sich dann natürlich > jeder selbst kümmern. Dann mach' doch! Jede Hilfe ist willkommen. Hast Du eine Vorstellung davon, wie groß die Menge der Entwickler der NIOS-FW ist? Falk, der jetzt die SVN-Version weiter brauchbar macht und alle daran teilhaben läßt, indem er soeben Revision 277 eingecheckt hat.
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
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
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
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.
Nachtrag: Leute, beruhigt Euch mal wieder. Die Situation ist doch die: Hayo zieht es vor, seine unbestritten wertvollen Verbesserungen an der FW alleine zu machen. Dagegen ist nichts einzuwenden. Einige andere, u.a. ich selbst, ziehen es vor, das im Team zu machen und alle daran teilhaben zu lassen. Das ist nicht die optimale Lösung, aber wer etwas daran verbessern will, muß sich leider auf seinen Hintern setzen und etwas beitragen. Ich tue das und kann mit der Situation gut leben. Falk
Hallo an alle, jetzt finde ich endlich auch mal die Zeit mich hier zu Wort melden. Dafür jetzt ein längerer Post. Ich verfolge die Bemühungen um das Wellec Scope schon seit Anfang an und habe versucht mich durch mitlesen - hier und auch im Sourceforge - immer wieder auf dem neusten Stand zu halten bzw. zu bringen. Das hat zwar nicht immer geklappt, aber doch meistens. Jetzt habe ich gerade mal etwas Zeit und werde versuchen auch mal was beizutragen. Beitragen könnte ich prinzipiell beim sowohl der Firmware (C), als auch beim FPGA-Redesign (VHDL). Allerdings weiß ich nicht wie sinnvoll esist mich da einzuarbeiten und dann doch nicht die Zeit zu finden kostruktiv mitzuarbeiten. Dort wo es hilft und mir möglich ist werde ich es aber gerne versuchen. Doch fürs erste habe ich überlegt, an einer anderen Baustelle zu beginnen. Korrigiert mich, wenn ich falsch liege. Aber ich denke was vielen - vorallem Neueinsteigern und Leuten die nur selten mitlesen - hier fehlt ist der Überblick. Ein kurzer Leitfaden zum Einstieg. FPGA, Firmware, Versionen, Binaries, .... Was ist was und wo und wie muss ich vorgehen. Wenn ich im Moment die Projektseite https://sourceforge.net/projects/welecw2000a/ öffne, dann sehe ich erstmal außer dem fetten Button zum Download der w2000a-screenshot-0.91.tgz und der Kurzbeschreibung "Firmware development/ improvement for the digital storage oscilloscope "Welec 2000a- series" garnichts. Sourceforge ist da leider sehr unübersichtlich. Klein darunter findet man dann den eigentlich wichtigen Link zur "Website" https://sourceforge.net/apps/trac/welecw2000a/. Hilfreich wäre es an der Stelle wenn in der Kurzbeschreibung auf den Link zur eigentlichen Website (und vielleicht auch zum PHPBB-Forum) hingewiesen würde. Als jemand der Sourceforge kennt findet man den Link zwar selbst, aber aus leidvoller Erfahrung mit Nutzern die sich auf Sourceforge nicht auskennen weiß ich, dass SF nicht wirklich intuitiv und übersichtlich ist. Wenn mann es dann auf die Projektseite im Trac Wiki https://sourceforge.net/apps/trac/welecw2000a/ geschafft hat sieht es ja schon garnicht mal so schlecht aus. Allerdings fehlt auch hier noch eine aussagekräftige Einleitung bzw. ein Überblick für alle die die nicht die ganzen Forendiskussionen im Kopf haben. Und hier würde ich jetzt gerne versuchen anzusetzen und einen Kurzeinstieg zu schreiben die folgenden Themen und Fragen beantwortet. 0.0 Was brauche ich um die Firmware nutzen zu können? -> Windows oder Linux PC, Welec2000 oder Welec2000A Oszilloskop. -> Hinweis: Erster Schritt sollte Firmware backup sein! 0. Wo liegen die Informationen (Foren, Wiki) wo kann ich bei mich bei Fehlern und Problemen melden 1. Ich habe nur ein W2000 ohne A. Kann ich das auch nutzen? ->Hinweis auf Umbauanleitung für W2000 zu W2000A. 2. Wie mache ich ein Firmware Backup? 2.1 Unter Windows 2.2 Unter Linux 3. Wie kann ich eine neue Firmware aufspielen (für original Welec FPGA Design) 3.1 Welche unterschiedlichen Firmware gibt es, wie komme ich dran, wo sind die stabilen Versionen, was sind die Unterschiede zwischen den einzelnen Firmware? -> Firmware im SVN (https://sourceforge.net/apps/trac/welecw2000a/browser) unter fpga/nios. -> "NIOS" ist der original Core für den Altera FPGA des Oszilloskops auf dem die originale Welec Firmware und auch die darauf basierende Open Source Weiterentwicklung läuft. Der NIOS-Core ist nicht frei verfügbar. -> Die Entwicklung finde in fpga/nios/oss/trunk statt. -> Stabile/offizielle? Versionen liegen in /fpga/nios/oss/tags, welche Version ist was, sind die aktuell? -> In fpga/nios/welec liegen die Original Sourcen (alle?, gibts auch Binaries?) 3.2 Firmware aufspielen Windows 3.3 Firmware aufspielen Linux 3.4 Fehler Melden (Trac Ticketsystem) und Foren 4. Gibt es weitere Tools/Software für die Arbeit mit dem Oszilloskop? -> Screenshots, FFTscreener, LabView Treiber ... (hier bin ich nicht auf dem aktuellen Stand) 5. Andere FPGA Designs für das Oszilloskop -> jeweils im entsprechenden Unterordner des FPGA Verzeichnisses -> alles noch in Entwicklung, noch keine voll funktionsfähige Version?! 5.1 leon3 -> fpga/leon3 ? 5.2 t51 -> fpag/t51 ? 5.3 zpu -> fpga/zpu ? Teilweise sind in der Gliederung schon Informationen eingetragen. Korrigiert mich bitte, wenn etwas falsch oder unvollständig sein sollte. Ich werde versuchen obiges auszuformulieren und dann auf der Hautpseite des Trac-Wiki zu Verfügung zu stellen bzw. zu verlinken, wenn gewünscht. Für Unterstützung, Tips oder Mithilfe von anderen hier bin ich gerne offen. Auf Sourceforge bin ich als holgerm registriert. Ich hätte diesen Beitrag auch ins SF PHPBB Forum geschrieben, aber ich war mir nicht sicher wo er da am besten hinpasst, deshalb hier. Ich hoffe mit meinen Äußerungen und Anmerkungen keinem irgendwie auf die Füße getreten zu sein. Alles was ich hier äußere ist als konstruktive Kritik geacht und auf keinen Fall ein Angriff auf irgendjemanden. Danke fürs Lesen des doch sehr langen Posts. Gruß Holger
Holger M. schrieb: ... > Korrigiert mich, wenn ich falsch liege. Aber ich denke was vielen - > vorallem Neueinsteigern und Leuten die nur selten mitlesen - hier fehlt > ist der Überblick. Ein kurzer Leitfaden zum Einstieg. FPGA, Firmware, > Versionen, Binaries, .... Was ist was und wo und wie muss ich vorgehen. http://sourceforge.net/apps/trac/welecw2000a/ Ja, da muß man sich mal durchgraben. Und ich bin so vermessen, daß ich das auch erwarte, wenn sich jemand ernsthaft für das Projekt interessiert. Das ist alles kein Vergleich mit den originalen FW-Sourcen ;-) Sicher gibt es übersichtlichere Möglichkeiten, aber Besseres haben wir nicht und besser als die hiesigen unstrukturierten Monster-Threads ist das auf jeden Fall. ... > Ich hoffe mit meinen Äußerungen und Anmerkungen keinem irgendwie auf die > Füße getreten zu sein. Mir nicht. Ich habe mal gelernt, daß Kritik dem Kritisierten hilft, sich zu verbessern. Falk #welec - irc.freenode.net P.S.: Hier zwei Downloadzahlen: Video zum angucken: 208 (http://consult42.com/W20XXA-prereleases/) TomCat.ram zum selbertesten: 17 (http://consult42.com/signal2.mpg)
Hallo Falk, die Links sind vertauscht, das wird aber Jeder merken, denke ich... ...der Holger spricht mir aus der Seele!!! Ich bin wirklich kein fauler Mensch, suche u. lese, was das Zeug hält! Nur hier etwas Konstruktives beitragen zu können, ist wirklich eine Katastrophe! Deshalb kommen dann auch die einen oder anderen dämlichen Fragen von mir(oder nicht nur von mir), gerade weil alles so verstreut liegt! Z.B. hatte ich garnicht darauf geachtet, das die eine FW "OS" von Falk und die ander FW "BF" NUR von Hayo ist!!! Wie ist das mit den Ver.Nummern? sind die jetzt fortlaufend oder bleibt Falk bei der 092er oder hat Hayo auch eine 092er??? Ich kann nicht programieren und kein FPGA-Design entwickeln, kann aber z.B. flashen über den Welec-Upd. und dem Germsmonitor(obwohl das einrichten garnicht so einfach ist und das auch für Andere, wie die Vergangenheit es zeigte)und eben testen... Ich benutze das DSO hauptsächlich für analoge Messungen, wenn ich dann Spannungen ablese mit einer Differenz von 0,5-1V weil die Nulllinienkalibrierung sich ständig verirrt da könnte ich Kinder kriegen... In keiner Version ist dies in den Griff zu bekommen! Denn stimmt diese nicht, stimmt keine Messung! Gruß Michael
Michael D. schrieb: > Hallo Falk, ... > Deshalb kommen dann auch die einen oder anderen dämlichen Fragen von > mir(oder nicht nur von mir), gerade weil alles so verstreut liegt! http://sourceforge.net/apps/phpbb/welecw2000a/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
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
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!
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" ;)
Angehängte Dateien:
-
Rauschen-weg.gif
7,7 KB
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
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
Sieht gut aus, Falk. Die Widerstände werde ich auf jeden Fall auch bald umbestücken. Ihr solltet euch aber nicht an den 24.9 Ohm aus dem Datenblatt aufhängen, das ist lediglich ein Beispiel. In anderen Datenblättern gibt es üblicherweise eine Grafik dazu wie "recommended serial resistance versus capacitive load". Wenn die Größe der Lastkapazität bekannt ist sucht man sich damit eben den passenden Serienwiderstand. Wer einen Blick in die Application Notes zur AD813x Serie wirft, wird dort auch verschiedene Widerstandswerte je nach Anwendung vorfinden, beispielsweise 2x 49.9 Ohm beim Treiben eines ADCs von Analog Devices. Gruß Michael
Nochmal die Frage direkt an Falk: gibt es in der Firmware eine Möglichkeit auf RS232 Eingaben zu warten? Zwecks Handshake. Mfg, Kurt
Kurt Bohnen schrieb: > Nochmal die Frage direkt an Falk: > > gibt es in der Firmware eine Möglichkeit auf RS232 Eingaben zu warten? > Zwecks Handshake. Das kann man natürlich machen. Was schwebt Dir denn vor? Falk
Die Daten für Screenshot und CSV Export Blockweise übertragen. Für erste Tests 128 Byte, später bis zu 3kByte. Vor dem Senden eines Blocks soll das Oszi auf ein Clear-to-send vom Zielsystem (PC oder USB Host) warten.
Kurt Bohnen schrieb: > Die Daten für Screenshot und CSV Export Blockweise übertragen. Für erste > Tests 128 Byte, später bis zu 3kByte. > > Vor dem Senden eines Blocks soll das Oszi auf ein Clear-to-send vom > Zielsystem (PC oder USB Host) warten. Kann man machen. Ich muß mal sehen, wann ich dazu komme. Oder hätte jemand anderes Lust dazu? Falk
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
Offtopic: Verkauft noch jemand einen 2 oder 4 Kanaler? Melde interesse an! torsten-otten ät gmx.de Gruß Torsten
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
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
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
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
So, ich noch mal. Ich hatte implizit vorausgesetzt, dass ich das ganze in Englisch auf das Wiki schreiben würde. Das komplette Wiki ist ja schließlich auch auf englischer Sprache und Doku zu Softwareprojekten schreibe ich persönlich in 90% der Fälle auch in Englisch. Ich wollte auch nicht das Wiki neu erfinden, sondern Informationen zur Klärung an einigen Stellen beitragen. Ich habe nämlich, wie zuvor geschrieben, eine ganze Weile gebraucht, bis ich rausgefunden habe wo welche Sourcen liegen und noch immer keinen rechten Überblick wo welche Binaries zu finden sind, bzw. auf welchem Repository-Stand diese aufbauen. Falk hat zwar oben mal den Link (http://consult42.com/W20XXA-prereleases/) zu irgendwelchen Versionen gepostet, aber der Zusammenhang zwischen Quellen in SF und den Sourcen ist zumindest mir auch noch nicht klar. Ich hatte z.B. gehofft Binaries in den entsprechenden Tags des Repository zu finden. Bevor ich anfange an einem Projekt zu arbeiten, versuche ich zuerst dessen Strukturen zu verstehen, sonst wird das nix mit der Arbeit oder ist sehr mühselig. Das ist aber bei der aktuellen Dokumentation eher mühselig finde ich. Anderen hier scheint es ähnlich zu gehen. Einige scheinen sich in SF nicht wirklich auszukennen bzw. zurecht zu finden, sonst wären ja schon alle dorthin gewechselt, statt hier endlos lange Threads durchzuscrollen. Deshalb hatte ich vorgeschlagen all denen die sich nicht - wie ich jetzt - in mühevoller Kleinarbeit alles immer wieder zusammen suchen wollen etwas zu helfen, indem die Doku etwas klarer wird. Ich dachte mir halt es wäre für das Projekt von Vorteil. Wenn es mehr Leute in kürzerer Zeit einen Einstieg in die Materie finden können, dann gibt es vielleicht auch mehr potentielle Helfer. Und sei's nur das jemand mit nem Welec Oszi mal ein Backup zieht, die OS-FW mal ausprobiert und Bugreports meldet. Wenn es dafür ne "Schritt für Schritt" Anleitung gibt dann ist das doch um so einfacher. Wobei das mit der Einstiegshürde "Ja, da muß man sich mal durchgraben" von Falk natürlich auch ein Argument ist ... das mir die Arbeit ersparen würde den Text für's Wiki zu schreiben. So long Holger
Gibt es irgendwo eine aktuelle,vollständige! Anleitung zum compilieren der Firmware unter Windows? Welche Programme brauche ich, in welcher Reihenfolge werden sie installiert...
Hallo zusammen, ich habe gerade die Posts der letzten Tage gelesen. Dazu möchte ich anmerken, dass ich versucht habe vor vielleicht drei Wochen die Versionen zu mergen. Das Ergebnis war, soweit ich das getestet habe, ganz OK. Allerdings habe ich dabei auch Hayos neue Run/Stop-Logik übernommen. Deshalb war die Version, zumindest für mich persönlich, unbrauchbar, da man keine Signale zoomen konnte. Auf Sourcen mit den Änderungen warte ich bis heute. Deshalb habe ich vorgestern selbst Hand angelegt. Ich kann nur hoffen, dass irgendwann wieder alle an einen Strang ziehen. @Falk: Deine Änderungen sind interessant. Ich hoffe nur, dass diese auch noch so schnell laufen, wenn z.B. die Verbindungslinien gezeichnet werden... Kannst du deine Änderungen vielleicht in einen Branch umziehen? Dann können wir vom Trunk eine OS.092 veröffentlichen.
Guido schrieb: > Hallo, > Ins momentane SVN (sorry) > ferkelt einfach jeder seine wichtigen Änderungen ("added -> in > Comments") ins offizielle Trunk. Dadurch wird dieses früher oder > später automatisch unbrauchbar. Sag mal, (sorry) hast Du noch alle Tassen im Schrank? Ich darf Dir mal kurz sagen, was ich da so 'reingeferkelt habe: Ich habe Niklas' Screendump ist so verbessert, daß ein Screenshot in Farbe in 15s fertig ist. Ich habe eine Fernsteuerung (für RS232) eingebaut, die es u.a. erlaubt, das RAM auszulesen, Variablen zu setzen etc. Damit habe ich bspw. das Bit gefunden, das das Scope für >50MHz unbrauchbar gemacht hatte. Und momentan bin ich dabei, die Darstellungsgeschwindigkeit etwa um den Faktor 5-10 zu verbessern. > Aber klar, das sind Anfangsprobleme, > die aber bitte nicht einfach ignoriert werden sollten. Das Anfangsproblem ist, daß wir die Wohnung eines Messies renovieren müssen. Wir sind jetzt noch in der Phase, daß wir mit Radladern Müll 'rausschaffen. Da bringt es noch nicht viel, sich über coding Style oder die Farbe der Wasserhähne Gedanken zu machen. Falk
Alter Schwede was ist das hier für ein rumgezicke! Ich denke ich muß mal einige klare Worte sagen. Also erstmal trotz des gezickes sind die Fortschritte in allen Bereichen nicht übel. Bei mir war in letzter Zeit viel los (Trauerfall ind er Familie, Beruf) so dass mir nur wenig Zeit blieb für unser Projekt. Zu den Versionen: Ich entwickle keine zweite Linie! Die einzige offizielle Version ist die OS-Version. Der Grund warum ich ab und an eine BF.0.XX rausgetan habe ist, dass ich eine Rückmeldung zu einigen Änderungen brauchte die ich neu eingebaut hatte. Zu diesem Zweck werde ich auch in Zukunft weitere Test oder Demoversionen rausgeben. (@Stefan - Du hattest leider meine Version unvollständig gemerged, daher einige Ungereimtheiten bei Start/Stop). Ich benutze eine eigene Entwicklungsbasis um etwas die Übersicht über die Änderungen zu behalten und nicht alles ungetestet übernehmen zu müssen. Grundsätzlich übernehme ich aber die Änderungen aus der OS-Version und baue meine Änderungen nach ausgiebigen Tests und Rückmeldungen in die OS-Version ein. Mittlerweile habe ich mich mit SVN etwas angefreundet und hoffe ich zerschieße nichts bei meinen ersten Versuchen etwas zu committen. Zu den Kommentaren im Coding: Grundsätzlich kann man sagen, je mehr und ausführlicher kommentiert wird was man macht, umso besser ist der Code wartbar. Eine Kennzeichnung mit dem Entwicklerkürzel vereinfacht eventuelle Nachfragen. Sicherlich sind mir auch schon Programmteile durchgerutscht die nicht so gut kommentiert oder gekennzeichnet waren. Das sollte aber eher die Ausnahme bleiben. Grundsätzlich ist das als Empfehlung (an den gesunden Menschenverstand)zu sehen um allen das Leben etwas leichter zu machen. Gruß Hayo
Stefan E. schrieb: > Hallo zusammen, > > ich habe gerade die Posts der letzten Tage gelesen. Dazu möchte ich > anmerken, dass ich versucht habe vor vielleicht drei Wochen die > Versionen zu mergen. ... > Deshalb habe ich vorgestern selbst Hand > angelegt. Zur Information derjenigen, die SVN noch weniger kennen, als ich: Ich bekam eine Mail, daß Stefan eine Änderung committed hatte. In der gleichen Datei hatte ich reichlich "herumgeferkelt". Wie löst man das? Mit SVN so: svn update; svn commit Und schwupps, waren beide Änderungen berücksichtigt. > @Falk: Deine Änderungen sind interessant. Ich hoffe nur, dass diese auch > noch so schnell laufen, wenn z.B. die Verbindungslinien gezeichnet > werden... Tut es: http://consult42.com/signal3.mpg > Kannst du deine Änderungen vielleicht in einen Branch umziehen? Ok, ich lerne dann mal SVN Lektion III ;) > Dann können wir vom Trunk eine OS.092 veröffentlichen. Gute Idee! So machen wir das. Falk
@Hayo Ja war mir klar, dass ich da was falsch gebaut habe. Das ganze war sehr umfangreich. Allerdings hat das bei deiner Ausgabe bei mir auch nicht funktioniert. Deshalb bin ich davon ausgegangen, dass auch in deinen Sourcen irgendwo ein Fehler steckt. Nachdem ich von dir einige Zeit nichts mehr gehört hatte, musste ich einfach selber eine Lösung finden um überhaupt mal wieder weitermachen zu können. ;-) Und wegen SVN: DU kannst NICHTS zerschießen! Alles kann rückgängig gemacht werden. Ich habe am Anfang auch Mist gebaut und Kopien erstellt, die ich nicht mehr löschen konnte. Probiere es einfach. Ansonsten einfach in Skype anklopfen. Dort bekommst du eine sicherlich kompetente Hilfe bei den ersten Schritten. Mir persönlich ist es egal, wieviele commits an einem Tag gemacht werden. Hauptsache es werden in regelmäßigen Abständen welche gemacht. Das mit den Entwicklerkürzeln in Kommentaren versuche ich zu übernehmen. Leider vergesse ich es noch oft. @Falk Yeah! @all Ich werde mal versuchen (in einem branch natürlich ;-)) einen neuen Trigger zu implementieren, der die Vorteile von Auto- und Normal-Trigger vereint. Hoffentlich klappts :-)
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?
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
Und wo wird der Pfad eingetragen. Makefile oder Systemvariablen? Müssen die Systemvariablen (oder sind es Benutzervariablen?) einen bestimmten Namen haben? Wert ist klar.
Problem gelöst: Die Pfade müssen in der Systemvariablen "Path" eingetragen werden. Die einzelnen Einträge sind mit einem Semikolon zu trennen. @Falk, danke für den Hinweis! Mfg, Kurt
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
Guido schrieb: > Hallo Falk, Hi Guido, > > mit den Ferkeleien meine ich ausdrücklich nicht deine > Änderungen und Erweiterungen im Screenshot usw. Die > wurden in dieser Version eingeführt und werden dort > gepflegt, das ist selbstverständlich. ACK ... > > Das mit den neuen Zeichenroutinen ist zum Glück schon > geklärt (ander finden vllt. die passenderen Worte als > ich). > > Auch die Vertikaleinstellungen hätten in einem Branch > geändert werden sollen, solche Sachen führen schnell > dazu, das Inkompatibilitäten resultieren. Jein - ich hatte die Änderungen hier sehr ausführlich getestet und dann noch mal als Patch (mit Werzen) veröffentlicht bevor ich sie (ein bis zwei Wochen später und nach Rücksprache mit Falk) committet habe. Der Sinn eines Branches besteht ja auch darin, seine Änderungen unabhängig vom trunk durchzuführen (um sich auf diese Aufgabe konzentrieren zu können) und das Endergebniss nachher einzupflegen. Die Aufteilung in "branches", "tags" und "trunk" und ihre entsprechende Verwendung in eine Empfehlung und kein Gesetz und selbst "Gesetze" dürch nicht ignoriert aber gebrochen werden. Es gibt auch Gruppen, welche ganz ohne "branch" arbeiten, auch wenn es sicher sinnvoll gewesen wäre, die Vertikal-Ablenkung und aus ihr resultierende Änderungen in einem branch abzuhandeln. Zur Inkompatibilität: diese stellt sich mit dem mergen des branches in den trunk ein - und dieser Schritt wird immer gegangen werden müssen, wenn ein Feature eingepflegt wird. > > SVN kann nicht zaubern, und bei fast 300 diffs ist es > faktisch unmöglich einen definierten Zustand > wiederherzustellen. Kommt auf die Aussagekraft der commit-messages an ;) Generell könnte ich auch jetzt noch den Code entfernen - allerdings fussen z.B. auch Falks Tabellen jetzt darauf, dass es einen Aussteuerbereich des ADC's und nicht mehr zwei gibt. > > Hayo sollte seine HE auch als Branch anlegen und aus > mehreren Branches ein neues Trunk erstellen, das kann > SVN nun wirklich (bis auf die Konflikte, die dann von > Hand geköst werden müssen). Sicher? > > Gruß, Guido Grüße, rowue
Rolf Würdemann schrieb: > Guido schrieb: >> Auch die Vertikaleinstellungen hätten in einem Branch >> geändert werden sollen, solche Sachen führen schnell >> dazu, das Inkompatibilitäten resultieren. > > Jein - ich hatte die Änderungen hier sehr ausführlich > getestet und dann noch mal als Patch (mit Werzen) > veröffentlicht bevor ich sie (ein bis zwei Wochen später > und nach Rücksprache mit Falk) committet habe. Genau. Nach etlichen Tests war klar, daß diese neuen Faktoren nur Vorteile haben würden. Und, Guido, an welcher Stelle hat Dich diese Änderung bei der FW-Entwicklung gestört? Falk
Es ist ja außerordentlich mühselig, wegen jeder kleinen Änderung an Variablen wie bspw. "adc_change12_reg" eine neue FW einzuspielen. Deswegen gibt es (seit längerem) die Möglichkeit, einige Variablen per RS232 zu ändern. Dokumentiert ist das in http://sourceforge.net/apps/trac/welecw2000a/wiki/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
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
Guido schrieb: > Hallo Falk und Rolf, Hi Guido, > > mit der Vertikaleinstellung ist halt das Problem, dass > hayos Version nicht kompatibel ist, mich stört es nicht, > ich habe ja schon vor langer Zeit damit experimentiert. Jein - die Änderung der Vertikaleinstellung ist vom Grundsatz her kompatibel mit Hayos Version. Es werden (bis auf die Hinzunahme einer weiteren Schiebeoperation in der Anzeige) nur Registerwerte und Faktoren geändert. Den meisten Algorithmen ist es egal, ob da nur mit 2.04; 3.25 oder 2.575 gearbeitet wird. Problematischer sieht es mit den Optimierungen aus, welche nun als Konsequenz aus der Änderung folgen. Hier werden Algorithmen geändert und ausgetauscht ... > > Ich will keine Prinzipien reiten, mir geht es um das > Praktische. Wenn 6 Entwickler an einem Trunk Änderungen > (nicht Bugfixes o.ä.) vornehmen und nach 4 Wochen stellt > jemand fest, dass etwas nicht mehr funktioniert, dann wird > es schwer den Fehler zu finden. Haben wir dagegen 6 Branches, > sagen in dem Fall 5 Entwickler "bei mir geht es noch". Naja, Du musst ja auch bedenken, dass hier mehr als ein Entwickler zur gleichen Zeit am gleichen Punkt arbeiten. Sie Dir als Beispiel nur Jörg und Falk an, welche gerade die Auslese- und Darstellungsroutinen "überarbeiten". Der Vorteil beim Branch ist hier m.E., dass diese Arbeit nicht von Änderungen am trunk beeinflusst wird (warum sehen meine Werte auf einmal anders aus) und sich z.B. auch "conflicts" eher vermeiden lassen. Man arbeitet in der Zeit halt enkoppelt vom trunk (und ich muss gestehen, dass ich am Anfang kurz überlegt habe, 'nen branch dafür aufzumachen ;) Der Preis dafür ist, dass wir auch beim Mergen des branches Fehler einführen können (was ja schon passiert ist, als Hayos Änderungen eingepflegt wurden). Zur Inkompatibilität mit Hayos Version (dem ich an dieser Stelle mein Beileid aussprechen möchte), so stellt sich dann eher die Frage, ob und wie Hayo diese Änderung übernehmen möchte. Die Angebote bzgl. svn stehen noch immer. > > Grüße, Guido Grüße, rowue
Hier mal eine Herausforderung an die eher künstlerisch Begabten: Wie wäre es, wenn mal jemand ein neues Logo für den Startbildschirm entwerfen würde? Ideal wäre Vektorgrafik, die dann auch gerne animiert sein darf. Es gibt 640x480 Pixel und die Farben, die man auf dem Display sehen kann. Ideal wäre eine Beschränkung auf Gelb, Grün, Rot und Blau. Um dieses Thema hier herauszuhalten, habe ich mal einen neuen Fred aufgemacht: Beitrag "Wittig(welec) DSO W20xxA - Neues Logo" Viel Spaß, Falk
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
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
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
Kurz zur Info... in der OS.0.92 hat sich ein kleiner Fehler eingeschlichen, der die Besitzer der W20X4 betrifft und heute Abend behoben wurde. (https://sourceforge.net/apps/trac/welecw2000a/ticket/43) Ein entsprechender Tag auf eine Version 0.92a wurde schon gesetzt, die entsprechende Version wird bald zum Download (Falk?) zur Verfügung stehen. Grüße, rowue
Rolf Würdemann schrieb: > Kurz zur Info... > > in der OS.0.92 hat sich ein kleiner Fehler eingeschlichen, der > die Besitzer der W20X4 betrifft und heute Abend behoben > wurde. (https://sourceforge.net/apps/trac/welecw2000a/ticket/43) > > Ein entsprechender Tag auf eine Version 0.92a wurde schon gesetzt, > die entsprechende Version wird bald zum Download (Falk?) zur Verfügung > stehen. Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht... Darum noch eine Kopie hierhin. Falk
Falk Willberg schrieb: > Rolf Würdemann schrieb: >> Kurz zur Info... >> >> [OS 0.92a] > > Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht... > > Darum noch eine Kopie hierhin. Liegt immer noch nicht da, nachher noch mal schauen .... Aber: Ich bin heute morgen mal durch die Tickets gegangen und habe erledigte Tickets abgeschlossen. Viel ist da nicht mehr. Diverse von den Bugs hat btw. Hayo erlegt. Darum meine Bitte an *alle*: Jeder möge sich die aktuelle Version der von ihm präferierten Firmware ansehen und schauen, ob er/sie noch unbekannte Bugs findet. Wenn ja: bitte in's Ticket-System damit. > > Falk Grüße, rowue
Frage zum Screenshot Programm: Ist der Umweg über fun_hdr(), fun_data() und fun_ftr() auf die Funktionen csv_hdr(), csv_data() und csv_ftr() wirklich nötig oder von Vorteil? Oder kann man csv_ftr() mit in receive_trace() einbauen. Ich werde mal den CSV Export so umbauen das ihr seht was ich mit blockweiser Übertragung meine. Mfg, Kurt
Angehängte Dateien:
-
screenshot-0000.gif
12 KB
Hier mal ein Bild von ca. 1h Persist mit dem Probe-Generator. Was auffällt ist, daß die Impulse nur an bestimmten Stellen auftreten und den gleichen Wert haben. Vielleicht hat ja noch jemand eine Idee... Falk
Ich habe mich gerade wie gewünscht auf Käfer-Suche begeben. QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei der Murks diesmal vermutlich einfach daran liegt, dass die neuen Skalierungsfaktoren hier nicht berücksichtigt werden? Lohnt sich ein Ticket oder wisst ihr auch so, was Sache ist? Kurz gesagt stimmen da die Werte überhaupt nicht mehr, wirklich abenteuerlichst was da rauskommt. Michael
@ Falk: ehrlich gesagt kann ich dein Bild nicht ganz nachvollziehen, was hast du da genau getrieben?
Michael H. schrieb: > @ Falk: ehrlich gesagt kann ich dein Bild nicht ganz nachvollziehen, was > hast du da genau getrieben? Eine Stunde lang im Persist-Mode das Rechteck des Generators anzeigen lassen. Die Nadelimpulse snd die berüchtigten "Glitches". Falk
Ich habe mich kaum mit der originalen Software beschäftigt, konnte aber so aus den Beiträgen herauslesen, dass die Triggerung in Kombination von Software und Hardware geschieht und das Pretrigger nur für den dargestellten Bereich existiert, und somit kein HW Pretrigger ist. In der Signaldatenerfassung müssen pro 125-MHz-Takt 8 Werte gleichzeitig oder vielleicht auch Phasenverschoben im internen FPGA-Ram abgespeichert werden. Dies bedeutet, falls der Trigger Bugs hat (einige Messdaten werden am Begin oder Ende überschrieben oder nicht aufgezeichnet), dass deren Probleme mit einem kleinsten Intervall von 8 Werten auftreten. MfG Alexander
Rolf Würdemann schrieb: > Falk Willberg schrieb: >> Rolf Würdemann schrieb: >>> Kurz zur Info... >>> >>> [OS 0.92a] >> >> Die habe ich um 22:21 hochgeladen, man sieht sie aber noch nicht... >> >> Darum noch eine Kopie hierhin. > > Liegt immer noch nicht da, nachher noch mal schauen .... > > [...] die OS 0.92a ist jetzt auf SFN verfügbar. Alle Nutzer, die sich die OS 0.92 (ohne a) geflasht haben: bitte updaten. Grüße, rowue
...ist die von hier nochmal modiefiziert??? Gruß Michael
...scheint doch dieselbe zu sein! Der Screenshot geht nicht??? Gruß Michael
>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei >der Murks diesmal vermutlich einfach daran liegt, dass die neuen >Skalierungsfaktoren hier nicht berücksichtigt werden? Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf Zeitbasen kleiner 50ns. Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade andere Sachen mehr stören. Außerdem hängt das natürlich auch von der neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt.
Stefan E. schrieb: >>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei >>der Murks diesmal vermutlich einfach daran liegt, dass die neuen >>Skalierungsfaktoren hier nicht berücksichtigt werden? > > Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf > Zeitbasen kleiner 50ns. Da passieren auch schlimme Dinge ;) > Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade > andere Sachen mehr stören. Außerdem hängt das natürlich auch von der > neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt. Was hälst Du davon, wenn wir eine zweite Skalierungstabelle generieren, die immer die richtige Abbildung (u_char)ADC-Wert->(long)Spannung in mV enthält? Die entsprechenden Flags, die eine Generierung solcher Tabellen auslöst, setzen wir sowieso. Du kannst Dich ja melden, wenn Du nochmal das QM angehst. Falk
Hallo, hab mal einen dritten Trigger nach meinen Vorstellungen eingebaut. Er verwendet normalerweise den Normal-Modus. Kommt für 500ms kein Trigger-Ereignis schaltet er auf Auto um. Wird der Triggerwert irgendwann überfahren, dann geht es wieder in den Normal-Modus. Das ganze heißt derzeit Standard-Trigger. Wer einen besseren Namen hat, kann sich melden ;-) Das ganze klappt derzeit nur, wenn die Timebase nicht zu lange eingestellt ist. Da muss noch eine Fallabfrage rein ;-) Bei mir klappt das ganze ganz gut.
Stefan E. schrieb: > Hallo, > > hab mal einen dritten Trigger nach meinen Vorstellungen eingebaut. > Er verwendet normalerweise den Normal-Modus. Kommt für 500ms kein > Trigger-Ereignis schaltet er auf Auto um. Wird der Triggerwert > irgendwann überfahren, dann geht es wieder in den Normal-Modus. Sehr angenehm! So werde ich den wahrscheinlich immer einstellen... > Bei mir klappt das ganze ganz gut. Ich mußte nach Einspielen der TomCat.ram den Trigger-Modus einmal von "Standard" auf "Standard" (Kein Tippfehler) umschalten. Falk
Ja, der Fehler ist bekannt. Nur steige ich beim Menü nicht ganz durch g
Stefan E. schrieb: >>QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei >>der Murks diesmal vermutlich einfach daran liegt, dass die neuen >>Skalierungsfaktoren hier nicht berücksichtigt werden? > > Also bis jetzt hat bei mir Quickmeasure gut funktioniert, bis auf > Zeitbasen kleiner 50ns. > > Die Korrektur dafür möchte ich noch etwas aufschieben, weil mich gerade > andere Sachen mehr stören. Außerdem hängt das natürlich auch von der > neuen Skalierung ab, wenn die steht, wird das dann in QM eingepflegt. Also ich habe QM mit der umgesetzten Skalierung geprüft - sah soweit gut aus Grüße, rowue
Michael H. schrieb: > Ich habe mich gerade wie gewünscht auf Käfer-Suche begeben. > QuickMeasure scheint mir ein immer größeres Sorgenkind zu werden, wobei > der Murks diesmal vermutlich einfach daran liegt, dass die neuen > Skalierungsfaktoren hier nicht berücksichtigt werden? > Lohnt sich ein Ticket oder wisst ihr auch so, was Sache ist? Kurz gesagt > stimmen da die Werte überhaupt nicht mehr, wirklich abenteuerlichst was > da rauskommt. In Zeitbasen < 50ns? - Das ist ein anderes Problem. Bei grösseren Zeitbasen habe ich das getestet und die Werte haben den Erwartungen entsprochen. > > Michael Grüße, rowue
Angehängte Dateien:
-
screenshot-0001.png
3,7 KB -
screenshot-0003.png
3,4 KB -
screenshot-0002.png
2,7 KB
Hallo Stefan, ich habe deine Mod-Version mal ins Ram geladen und war so begeistert, das ich die 092er danach geflasht habe!!! Ich kann jetzt das erste Mal triggern ohne gezappel (nur ein wenig am Triggerlevel drehen) bis zum erbrechen! Jetzt macht das ganze mehr Spass!!! An dieser Stelle, ein Lob von meiner Seite für diese tolle Arbeit, ich bin begeistert. Ich habe mal den Screenshot getestet, die 041er Ver. reagiert garnicht! Habe es dann mal mit der 091er Ver. versucht, hat erst die Bytes raufgezählt ist dann aber abgestürtzt (Screenshot hat ein Prob. festgest.) Nach mehrmaligen Versuchen, konnte ich dann 3 x Bitmap-Shots (2x Farbe, 1x Monochrom) machen die sich sehen lassen konnten, wie man sieht! Vielleicht könnte ja Jemand ein bißchen daran schrauben? Gruß Michael
Hey Michael, Danke für das Lob. Ein paar Probleme sind mir noch aufgefallen. Aber die versuche ich auch noch auszubessern. Das ganze ist noch im Experimentierstadium ;-) Wegen dem Screenshot weiß ich jetzt auch nicht. Hast du meine Version drinnen? Oder die aus dem Trunk? Nicht das ich da wieder was zerlegt habe beim mergen ;-) Kriegen wir alles in den Griff. Der Falk ist nur gerade ausgelastet mit den neuen Leseroutinen. Auf die warte ich schon ganz gespannt. Da hängt der Trigger noch etwas verschoben und es gibt noch keinen Noise-Filter. Sonst aber schon echt klasse.
Hallo Stefan, ich habe deine Ver.(OS.092 Alpha) drinnen, bis jetzt habe ich nicht's zu beanstanden, auch die Nullinien-Calibrierung hat sich etwas gebessert (habt ihr daran geschraubt?) Wenn ich jetzt das DSO wieder einschalte bleibt die Calibrierung, wo sie vor dem Ausschalten war, erhalten! Also dein Nois-Filter funzt. Vielleicht brate ich später noch die 50 Ohm Wiederstände rein, wie sieht es mit der SW-Anpassung für diese aus, geht da was? Gruß Michael
Hallo Michael, also ich habe nichts an der Nulllinienkalibrierung gemacht. Jedenfalls nicht absichtlich. Probiere doch mal die Version im Trunk. Vielleicht ist damit der Fehler vom Screenshot behoben. Auf den neuen Trigger brauchst du damit auch nicht mehr verzichten. Der ist mittlerweile eingepflegt. Zusammen mit ein paar Fixes. Mir ist jetzt kein gröberer Fehler mehr aufgefallen. Vielleicht magst du ja nochmal testen. 50 Ohm-Anpassung dürfte mit Falks Routinen kein Problem sein, wenn Sie denn mal funktionieren.
Michael D. schrieb: > Hallo Stefan, > > [...] > Vielleicht brate ich später noch die 50 Ohm Wiederstände rein, wie sieht > es mit der SW-Anpassung für diese aus, geht da was? Du meinst im Bezug auf die Pegel/Aussteuerung? Morgen kommen Widerstände hier an, dann schaue ich mir mal an, ob und wie sich da was ändert (ich hoffe/denke, wir werden nicht viel anpassen müssen ;) > > Gruß Michael Grüße, rowue
Michael D. schrieb: > Hallo Stefan, > > [screenshot] hmmm - also ich habe den screenshot ohne grosse Probleme mit der OS 0.92 am laufen - wobei meiner aus dem Trunk sein dürfte - haben wir vielleicht vergessen 'ne neue Version in's Netz zu stellen? ;) > > Gruß Michael Grüße, rowue
Hallo Rolf, er hatte meine Branch-Version drauf, die noch einem älteren Stand war. Ich vermute da liegt der Fehler.
Thread beobachten
Seitenaufteilung abschalten
