Announcement: there is an English version of this forum on Entschuldigt, hab mich etwas unklar ausgedrückt... Da SVN zu meinen täglichen Arbeitswerkzeugen gehört, ist die Bedienung des Clients nicht das Problem. Vielmehr verweigert mir das Repository den Zugriff, zumindest wenn ich mich mit meinem SF-Account zu authentisieren versuche. Wer ist denn für die Vergabe der Zugriffsrechte zuständig? Beste Grüße, odic PS: Prinzipiell halte ich den Vorschlag von Rolf für eine sehr sinnvolle Lösung. Allerdings würde ich so eine Einschränkung immer erst einführen, wenn die Disziplin der beteiligten Entwickler nicht ausreicht oder es zu Missbrauch kommt. Wo m.E. allerdings die Rechte ganz eindeutig auf wenige Personen begrenzt gehören, ist bei der Erstellung von tags.
Ups... hat sich überschnitten. odic ist und bleibt odic.... auch unter SF. ;-)
Hallo allerseits, war leider eine ganze Zeit nicht online, daher die Funkstille. Allerdings war ich nicht untätig. Ich bin mit der neuen Aufteilung von Falk nicht so recht glücklich, da diese einerseits etwas unübersichtlich und andererseits nicht konsequent genug ist. Also hab ich mich einige Stunden hingesetzt und hab das nochmal neu aufgeteilt, und zwar nicht nur die Dateien, sondern auch auf neue Klassen. Basis ist die 0.86. Zusätzlich habe ich in der Tomcat.cpp die Objektaufrufen in statische Aufrufe geändert. Seht Euch das mal an und überlegt mal ob Ihr das so übernehmen wollt. Gruß Hayo
Hayo W. schrieb: > Hallo allerseits, Hallo, > war leider eine ganze Zeit nicht online, daher die Funkstille. > Allerdings war ich nicht untätig. > > Ich bin mit der neuen Aufteilung von Falk nicht so recht glücklich, da > diese einerseits etwas unübersichtlich und andererseits nicht konsequent > genug ist. Mein Ziel war zunächst mal, diese riesigen Klötze von Dateien aufzuteilen. Ich mag keine Dateien bearbeiten, die etliche tausend Zeilen lang sind. Ich kenne SVN noch nicht so gut, aber ich denke, daß es eine gute Idee ist, wenn wir vermeiden können, daß mehrere Personen an der gleichen Datei arbeiten. > Also hab ich mich einige Stunden hingesetzt und hab das > nochmal neu aufgeteilt, und zwar nicht nur die Dateien, sondern auch auf > neue Klassen. Die Aufteilung in Klassen ist gut! > Basis ist die 0.86. Zusätzlich habe ich in der Tomcat.cpp die > Objektaufrufen in statische Aufrufe geändert. > > Seht Euch das mal an und überlegt mal ob Ihr das so übernehmen wollt. Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN einpflegen? Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja, welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein .zip-File veröffentlichen führt zu Durcheinander. Es ist schon abzusehen... Falk
Und vor allem sollten zwei Releases mit der selben Versionsnummer vermieden werden, da diese immer ein-eindeutig sein sollten. Notfalls lieber mit RCs oder weiteren Versionsnummern arbeiten.... Ich glaube ich warte mit dem Umbenennen und Verschieben von Dateien noch, bis die gröbsten Aufteilungen feststehen. Beste Grüße, odic
Falk Willberg schrieb: > > Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN > einpflegen? > > Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja, > welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein > .zip-File veröffentlichen führt zu Durcheinander. Es ist schon > abzusehen... Hi Falk, pfleg doch Deine Änderungen da manuell ein und übernimm es dann ins SFN, dann ist doch alles paletti. Die eigentlichen Methoden haben sich ja nicht geändert, sondern sind nur in anderen Klassen. Das ist doch noch überschaubar. Durch die neue Klassenstruktur ist das Coding auch besser lesbar, da die Funktionalität besser zuzuordnen ist. Gruß Hayo
Hayo W. schrieb: > Falk Willberg schrieb: > >> >> Leider sind meine Änderungen da nicht drin. Wie willst Du das ins SVN >> einpflegen? >> >> Wir sollten uns darauf einigen, ob wir mit SVN arbeiten oder.... ja, >> welche Alternative gibt es dazu? Lokale Kopien bearbeiten und ein >> .zip-File veröffentlichen führt zu Durcheinander. Es ist schon >> abzusehen... > > Hi Falk, pfleg doch Deine Änderungen da manuell ein und übernimm es dann > ins SFN, dann ist doch alles paletti. Bis hier die nächste Release als zip-file auftaucht. Ich schlage vor, daß wir uns zunächst auf ein Werkzeug einigen, daß es mehreren Leuten ermöglicht, gleichzeitig an den Sourcen zu arbeiten. Ich bin für Subversion (SVN). Wenn eine Alternative (die unter Linux nutzbar ist) bevorzugt wird, bin ich gerne dabei. Wenn wir uns geeinigt haben, kann jemand, der Subversion besser beherrscht als ich, Deine Version mit dem aktuellen Release zusammenführen und ggfs. in ein anderes Format überführen. Falk
Angehängte Dateien:
-
screenshot-0000.gif
14 KB
Bernd O. schrieb: ... > Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt > ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der > Wert "1" gemerkt/übertragen. ... > Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi > dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf > ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1 > pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden > müssen. Das habe ich eben ausprobiert: Farbiger Screenshot in 14s. Ich habe allerdings auch die Memory-Planes weggelassen. Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein Pixel in irgendeiner Plane gesetzt ist, übertragen werden. Wie man sieht, muß noch an der Reihenfolge der Planes gearbeitet werden. ... > Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben, > aber schnelle Screenshots sind noch schöner. Sehe ich auch so. Falk
Nabend ;) Zur Versionsverwaltung kenne ich vier Systeme: * cvs (Krampf im Gesäß) * subversion * git * mercury CVS ist das älteste System und an einigen Stellen etwas unfreundlich zu bedienen. Subversion besticht durch seine einfache Bedienung und eine hohe Anzahl von Clients, hat aber die Nachteile, dass immer zwei Kopien des Checkouts auf der Platte sind (10MB Source-Code benötigen also ca. 20MB Plattenplatz) und dass für Check-In's eine zentrale Stelle definiert ist (lokale Platte oder zentraler Server). git und mercury sind dezentrale Versionskontroll-Systeme, git wird z.B. auch für den Linux-Kernel verwendet, bei Mercury soll der Übergang von Subversion zu Mercury eher einfach ist. Mein Voting wäre hier Subversion. Zur der Frage der parallel bearbeiteten Dateien: Es ist möglich mittels SVN auch Dateien gegen den schreibenden Zugriff zu sperren (svn lock, svn unlock). Wg. des Schreibzugriffs auf das Repository: diesen würde ich auch die "Haupt-Entwickler" (+ggf einige "Helfer") beschränken. Dies mit dem Hintergrund, dass diese auch die Auswirkungen kleinerer Patches (welche von anderen Leuten eingebracht werden können) einschätzen können. (Sprich: wenn jmd. sich besser mit dem Code auskennt, kann er auch direkt schreiben, sonst über den Umweg des Diffs und eines Tickets) Sonst könnte es irgendwann viel Spass bei der Fehlersuche geben. Grüße, rowue PS: vielleicht schaffe ich die Tage den Append zum "ReadMe" ;)
Falk Willberg schrieb: > Ich bin für Subversion (SVN). > > Wenn eine Alternative (die unter Linux nutzbar ist) bevorzugt wird, bin > ich gerne dabei. > > Wenn wir uns geeinigt haben, kann jemand, der Subversion besser > beherrscht als ich, Deine Version mit dem aktuellen Release > zusammenführen und ggfs. in ein anderes Format überführen. > > Falk Hi, ja ich bin auch für SVN nach allem was ich bislang gehört habe. Da ich mich aber jetzt erst einarbeite, möchte ich nur ungern an der Struktur im SFN rumfuhrwerken, da wäre es mir lieber dass das jemand macht der sich schon etwas auskennt. Ist denn die Struktur die ich vorgeschlagen habe soweit in Ordnung oder gibt es noch Änderungswünsche? Hayo
Rolf Würdemann schrieb: > Zur der Frage der parallel bearbeiteten Dateien: Es ist möglich mittels > SVN auch Dateien gegen den schreibenden Zugriff zu sperren (svn lock, > svn unlock). Meine Erfahrung zeigt dass das meistens nicht notwendig ist. Wenn wirklich umfangreiche Änderungen anstehen, wie z.B. die aktuelle Neuaufteilung des Codes, dann reicht es, sich zu koordinieren. Nur wenn die Entwicklergruppe groß genug ist, dass nicht alle solche Absprachen zeitnah entdecken, sollte man locken, es sei denn es betrifft wirklich den kompletten Source und jegliche Änderungen anderer Leute wären komplett sinnlos. Also lieber 3x überlegen ob man locked und vorallem nur in Absprache, sonst sind die anderen recht schnell genervt ;) Auch ohne Locks kann man mit mehreren Leuten problemlos in einer Datei arbeiten. Solange die Edits sich nicht zeilenweise überschneiden, merged SVN die Änderungen fehlerfrei (das erkennt man an einem G vor der Datei beim Updaten). Überschneiden sich Änderungen (oder kommen sich so nahe, als dass diff nicht mehr einwandfrei zuordnen könnte, wie alles zusammenpasst), dann bekommt man einen Konflikt (C vor der Datei) und drei Versionen der konfliktbehafteten Datei. Einmal die *.mine mit den eigenen Änderungen, dann die *.r??? mit der Version aus dem Repository und die eigentliche Datei, die Konfliktmarker enthält. Einfach so eine Datei nach "<<<<<" oder ">>>>>" oder "=====" durchsuchen, wenn man mal einen Konflikt hat, dann wird schnell klar wie das gemeint ist. Wenn man die Datei dann manuell gemerged hat, einmal svn resolved auf der datei aufrufen und dem Commit steht nix im Weg. Ist eigentlich total simpel und hält (im Gegensatz zu Locks) niemanden von der Arbeit ab =)
Hallo zusammen, ich sehe das Ganze ähnlich wie rowue. Subversion wäre optimal. Es gibt viele Clients, für alle möglichen Betriebssysteme. So kommt sich niemand ausgeschlossen vor. Außerdem gibt's viele Infos und HowTos dazu im Netz. Damit sollte wirklich jeder zumindest einen Checkout hinbekommen. Bzgl. der Menge an Schreibberechtigten wäre ich auch eher für einen kleinen Kreis. Ich habe schon bei mehreren OpenSource Projekten Patches eingereicht. Einige wurden akzeptiert, andere nicht (Nebenwirkungen, nicht gut genug, etc.). Hatte nie ein Problem damit, meine Änderungen in ein Diff zu packen, zu erklären und an ein Ticket anzuhängen. Ich denke das hier einige "Gurus" - die genau wissen was sie tun und was der Code im Detail macht - die Patches prüfen sollten, bevor zu viele Leute schreibrechte haben und am Schluss jedes zweite Build in die Hose geht. Entscheiden müssen dass aber diejenigen die hier die Arbeit machen... wofür ich an dieser Stelle auch mal Danke sagen möchte. Gruß Daniel
Hayo W. schrieb: ... > Hi, ja ich bin auch für SVN nach allem was ich bislang gehört habe. Da > ich mich aber jetzt erst einarbeite, möchte ich nur ungern an der > Struktur im SFN rumfuhrwerken, da wäre es mir lieber dass das jemand > macht der sich schon etwas auskennt. Nur Mut ;-) Ich habe Dir ein Repository eingerichtet, in dem Du Dich unabhängig von SFN austoben kannst: http://falk-willberg.de/svn/repos/ Zugangsdaten zum Schreiben hast Du per Mail bekommen. > Ist denn die Struktur die ich > vorgeschlagen habe soweit in Ordnung oder gibt es noch Änderungswünsche? Wie gesagt, ich bin ein Freund kleiner Dateien... Falk
Falk Willberg schrieb: > > Wie gesagt, ich bin ein Freund kleiner Dateien... > Da habe ich versucht zwischen Dateigröße und logischem Zusammenhang einen Kompromiss zu finden. Dazu kommt, dass man sonst bei Entwicklungen die in mehrere Bereiche fallen, so viele Datein gleichzeitig offen hat, dass man da schnell den Überblick verliert. Thematisch fiel mir auch weiter keine sinnvolle aufteilung mehr ein. Die größten Brocken sind auch wie schon gehabt weiterhin die Displayklasse und die Hardwareklasse. Die anderen Klassen würde ich eher als schlank bezeichnen. > Nur Mut ;-) Ich habe Dir ein Repository eingerichtet, in dem Du Dich > unabhängig von SFN austoben kannst: http://falk-willberg.de/svn/repos/ Das ist eine gute Idee, da kann ich mal ausprobieren obs richtig hinhaut. Es ist auch eher weniger eine Mutfrage als vielmehr eine Zeitfrage. Ich denke ich werde mal mit KDE-SVN meine ersten Versuche starten. Obwohl ich als Urgestein hier mit der Kommandozeile groß geworden bin, habe ich doch die GUI-Bedienung schätzen gelernt (den guten alten Atari Mega ST hab ich noch!). Die Lochkarten fristen bei mir mittlerweile ein Dasein als Lesezeichen und Kommandozeilenarien gehören, wenn möglich, auch der Vergangenheit an, bin halt bequem geworden ;-) Gruß Hayo
Hayo, nur als Anmerkung und Tipp, wenn es Klassen wie "Display" gibt, die einfach zu groß sind. Dann wäre es vielleicht überlegenswert das mit Unterklassen und einem Unterverzeichnis aufzuteilen.
Hallo zusammen nachdem heute mein Scope endlich angekommen ist habe ich erstmal eine Weile mit der originalen 1.4er Firmware gespielt und dann zum Vergleich eure 0.86 beta geladen. Ein großes Kompliment und ein noch größeres Dankeschön an die Entwicklergemeinde! Ohne eure Arbeit hätte ich das Ding auf jeden Fall zurückgeschickt - schon allein aufgrund des schrecklichen DAC Abgleichs, der mehrere Divs danebengehaut hat. So ist es für das Geld schon jetzt ein wirklich nettes Gerät und wenn ihr so weiter macht kann es sich sogar noch mit etablierten Marken messen. Klasse! Ich hoffe, dass ich in Zukunft in irgendeiner Form etwas zur Entwicklung beitragen kann. Viele Grüße Michael
Na denn, willkommen in der Gemeinde und viel Spaß mit dem neuen Spielzeug. Gruß Hayo
Hallo, ein paar Kleinigkeiten habe ich schon für die lange Liste: - wenn ich einen Screenshot mache (klappt super, tolle Sache!) ist danach immer QickMeasure eingeschaltet auch wenn es vorher aus war - wenn ich bei QuickMeasure Duty Cycle wähle, steht die Schrift bei Select und Measure über die Buttons raus - wenn man einen Kanal wählt und dort den Teilerfaktor des Tastkopfes wählt leuchtet nicht mehr wie in der Original Firmware die LED beim Drehknopf Sagt mir bitte gleich wenn ich euch mit solchen Lappalien nerve, ansonsten poste ich halt alles was mir so auffällt... Gruß Michael
Hallo zusammen, ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum wird es sonst wohl schnell unübersichtlich. Im übrigen überlege ich gerade, ob eine Art Auto-Updater für die Scopes interessant wäre. Das Programm könnte alle verfügbaren Firmware-Dateien aus dem Internet ziehen und per Mausklick im Ram oder Flash einspielen. Ich würde das Ganze in C# schreiben. Dann wäre es über mono auch multi-plattform. Besteht Bedarf/Interesse an einem solchen Tool. Oder kann ich mich anders nützlich machen? Gruß Daniel
@Michael Testberichte und Fehlermeldungen sind völlig ok und erwünscht, allerdings sollten wir tatsächlich bei dem jetzt entstandenen Umfang der ganzen Sache überlegen wie wir solche Meldungen zentral erfassen (Tickets etc.). @Daniel Hört sich echt gut an. Da sind mit Sicherheit auch die Anderen dran interessiert. Gruß Hayo
Angehängte Dateien:
-
screenshot-0000.png
4,1 KB
Hallo schon wieder, ist schon jemandem aufgefallen, dass der "Denoise" Modus nicht mit QuickMeasure kompatibel ist? Wenn ich (Kanal 1, 500mV/div, 500us/div) das Kompensationsrechtecksignal darstelle, kriege ich teilweise am rechten Bildschirmrand eine komische Linie, die so gar nicht stimmen kann - siehe Screenshot. Mit dem Screenshot habe ich auch Probleme wie ihr sehen könnt, auf dem Scope sah das jedenfalls nicht so aus: der Ausreißer sollte am rechten Bildschirmrand sein usw. Hat jemand eine Idee was da los ist? Vorhin waren die Shots noch ok, das einzige was ich geändert habe ist die Horizontalposition. Gruß, Michael
Hallo Michael H., das ist korrekt. Nach Änderung der Horizontalposition sieht der Screenshot bescheiden aus. Anbei das Bilder vorher. Gruß Jürgen
Angehängte Dateien:
-
screenshot-0002.png
3,9 KB
So, ich habe den Ordner des Screenshot Tools gelöscht und nochmal neu entpackt und jetzt funktioniert es wieder. Der korrekte Screenshot zum beschriebenen Fehler ist im Anhang. Keine Sorge, heute werde ich euch nicht weiter in Anspruch nehmen und morgen bin ich mit zwei Prüfungen gut beschäftigt :) Gruß Michael
Nabend ;) anbei das Diff für das Readme zum NIOS zum Reinpatchen in den trunk und committen ;) Oder soll ich dies als Ticket im Trac eintüten? (Zumindest bekomme ich nach dem Login auf dem SF trac mit der Ticket-Maske angezeigt) Vorschlag bzgl. der informationskanalisierung: Anregungen/Bug-Reports: Trac-Tickets Allg./Spezielle Infos: Trac-Wiki Bei der Verwendung von Trac-Tickets können wir dies sehr gut einem Komponenten (nios-firmware?) und Meilensteinen zuordnen ;) (Trac und SVN spielen sehr gut miteinander - incl. Verweisen in der Commit-Message auf ein entsprechendes Ticket und vis-versa ;) Grüße, rowue PS: Könnte der Committer das Keyword "Id" auf das File setzen?
Angehängte Dateien:
-
screenshot.png
321 Bytes
guten abend, wollte euch mal loben, ihr macht echt gute arbeit! ohne euch hät ich das oszi wieder zurück geschickt! ich denk ihr seid eine große hilfe für viele leute! ich hab mir auch gleich mal die BlueFlash_Build_0_86 firmware drauf getan. als ich die das screenshot(0.3) programm testen wollte(hab übrigens windows), hat es nie wirklich geklappt. ich öffne ganz normal das prog, drücke im oszi auf save to csv (oder auch pgm, pgm bw) dann läd es auch die daten runter, aber wenn ich mir dann die bilder anschaue, kommt entweder nur ein komplett schwarzes bild oder ein schwarzer hintergrund mit grauen linien bzw balken. was mach ich falsch? hoff ihr hab die lösung für mich ;-) großes dankeschön an euch!
Du musst einfach zweimal kurz hintereinander Quickprint drücken, dann sollte es klappen. Gruß Michael
mhh, dann kommen nur noch schwarze bilder raus, ohne graue balken.
Amazz schrieb: > guten abend, > wollte euch mal loben, ihr macht echt gute arbeit! ohne euch hät ich das > oszi wieder zurück geschickt! ich denk ihr seid eine große hilfe für > viele leute! > > ich hab mir auch gleich mal die BlueFlash_Build_0_86 firmware drauf > getan. als ich die das screenshot(0.3) programm testen wollte(hab > übrigens windows), hat es nie wirklich geklappt. Die Firmware-Version muß zum Screenshot-Tool passen. Am besten ist es, die tags aus Sourceforge zu nehmen: https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios Falk
tip top, hab gedacht, dass version 0.3 vom screenshot schon die neueste is aber es gibt ja schon neuere. jetzt funktionierts vielen vielen dank!
Falk Willberg schrieb: > Bernd O. schrieb: > ... >> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt >> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der >> Wert "1" gemerkt/übertragen. > > ... > >> Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi >> dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf >> ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1 >> pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden >> müssen. > > Das habe ich eben ausprobiert: Farbiger Screenshot in 14s. > Ich habe allerdings auch die Memory-Planes weggelassen. Faktor 2 - nicht schlecht! > Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein > Pixel in irgendeiner Plane gesetzt ist, übertragen werden. Eigentlich müssten es 15 Planes + "leer" sein, da mit den 2^4 Bits ja 16 Zustände dargestellt werden können, also beispielsweise 0 = "leer", 1 = Plane_1, 2=Plane_2, ... 15=Plane_15. Ich hab' mir die bisher implementierte RLE nicht angesehen, aber wenn man der "sagt", dass die Symbole nun 4 Bits breit sind anstatt wie früher 1 Bit oder sie gar selbst nach der optimalen Symbollänge suchen muß (was aber wohl aufgrund der begrenzten Rechenleistung nicht der Fall sein dürfte), dann ist hier noch einiges an Potential drin. Wenn beispielsweise 20 Pixel der Plane 1 hintereinander kommen und Plane 1 den Wert 1, also binär 0001 hat, dann wird die RLE mit Symbollänge 4 Bits erkennen, dass 20x 0b0001 übertragen werden soll und optimalerweise nicht viel mehr als die Anzahl, also 20 und den Wert, also "1" übertragen, macht (geschätzte) 2-3 Bytes. Wenn die RLE von 1 Bit ausgeht, wird so etwas wie 3 x "0", 1 x "1", 3 x "0", 1 x "1", 3 x "0" übertragen - und mit diesen (geschätzten) 6 Bytes sind erst die ersten drei der 20 Pixel aus dem Beispiel übertragen. Vielleicht lässt sich so die 10-Sekunden-Marke noch knacken? Gruß, Bernd
Bernd O. schrieb: ... >> Mit diesem Verfahren können nur 14 Planes plus die Information, daß kein >> Pixel in irgendeiner Plane gesetzt ist, übertragen werden. > Eigentlich müssten es 15 Planes + "leer" sein, da mit den 2^4 Bits ja 16 > Zustände dargestellt werden können, also beispielsweise 0 = "leer", 1 = > Plane_1, 2=Plane_2, ... 15=Plane_15. Stimmt.... > Ich hab' mir die bisher implementierte RLE nicht angesehen, aber wenn > man der "sagt", dass die Symbole nun 4 Bits breit sind anstatt wie > früher 1 Bit oder sie gar selbst nach der optimalen Symbollänge suchen > muß (was aber wohl aufgrund der begrenzten Rechenleistung nicht der Fall > sein dürfte), dann ist hier noch einiges an Potential drin. Die Rechenleistung ist das Problem. [Vorschlag] > Vielleicht lässt sich so die 10-Sekunden-Marke noch knacken? Ich habe gerade die Version committed. Sieh Dir das doch mal an, vielleicht sind meine Kommentare ja verständlich ;-) Leider kämpfe ich noch mit einem seltsamen HW-Problem bei meinem Scope, deswegen kann ich im Moment nichts testen. Falk
Daniel G. schrieb: > ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell > deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es > eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum > wird es sonst wohl schnell unübersichtlich. Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden! Edit: Kann in der 0.87 keine Tomcat.flash finden... =(
Daniel H. schrieb: > Daniel G. schrieb: >> ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell >> deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es >> eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum >> wird es sonst wohl schnell unübersichtlich. > > Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden! > > Edit: Kann in der 0.87 keine Tomcat.flash finden... =( https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta/TomCat.flash.gz Was erlaube komprimieren die Flash ;-)
Nabend zusammen, mal ne kurze Frage: Warum gibt es die 0.87 nicht als zip-Archiv? Hängt das mit der Umstrukturierung zusammen? Beste Grüße, branadic
Falk Willberg schrieb: > https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta/TomCat.flash.gz > > Was erlaube komprimieren die Flash ;-) Haha ;) Aber ich bezog mich tatsächlich auf das ZIP weiter oben hier im Thread... Aber gut zu wissen, dass es auch bei euch Kompilate im SVN gibt ;) @andré: mitdembrückenpfeilerwink
Daniel H. schrieb: > Daniel G. schrieb: >> ich hab gerade mal auf SF nachgesehen, dort ist der Bug-Tracker aktuell >> deaktiviert. Würde es nicht Sinn ergeben, diesen zu aktivieren, damit es >> eine zentrale Sammlung der aktuell offenen Probleme gibt? Hier im Forum >> wird es sonst wohl schnell unübersichtlich. > > Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden! Bitte vorher * diese Firmware als "Component" anlegen * entsprechende Versionsnummern (für Bugs) anlegen * entsprechende Milestones (für Planungen) anlegen Das kann nur jmd. der entsprechende (Admin-) Rechte beim Trac hat, wir sollten das aber jetzt machen, sonst gibt das irgendwann Probleme mit dem FPGA-Design resp. anderen Teilprojekten ;) > > Edit: Kann in der 0.87 keine Tomcat.flash finden... =(
Daniel H. schrieb: > Wie rowue erwähnte, bitte die Ticket-Funktion vom Trac verwenden! > > Edit: Kann in der 0.87 keine Tomcat.flash finden... =( Alles klar, danke für den Hinweis. Das hatte ich überlesen.
Die 0.87 enthält (fast) keine funktionalen Veränderungen, sondern war nur als Vorschlag für eine neue Source-Struktur gedacht. Daher auch keine .flash files. Natürlich kann man sie in der Cygwin-Umgebung oder unter Linux CDK compilieren. Für Cygwin kann ich übrigens die Version von Ben empfehlen die er freundlicherweise bei einem Freehoster zur Verfügung gestellt hat (siehe weiter oben). Läuft bei mir problemlos auf dem USB-Stick. Cygwin mag allerdings keine Ordner mit Space im Namen. Die nächsten Versionen werde ich aber wieder wie gewohnt als Komplettpaket zur Verfügung stellen, damit sich nicht immer alle die Einzelteile zusammensammeln müssen. @Michael > Wenn ich (Kanal 1, 500mV/div, 500us/div) das Kompensations- > Rechtecksignal darstelle, kriege ich teilweise am rechten > Bildschirmrand eine komische Linie, die so gar nicht > stimmen kann - siehe Screenshot. Danke für den Tip. Da stimmt wohl die Berechnungslänge nicht ganz. Ist in Arbeit! Hayo
Ach ja, noch einer, wenn ich das richtig mitbekommen habe, dann hat sich das Screenshotprogramm geändert. Kann jemand ein aktuelles Windows-exe kompilieren und zur Verfügung stellen? Hayo
Hallo Hayo, Anbei aktuelles Kompilat fuer Win32 fuer das Screenshot-Programm, ungetestet. (BTW: Ich bin noch da, hab' aber ein paar Privatprojekte angenommen/ angefangen ;)) Ich muss mal schauen ob ich die naechsten Tage einen Nightly-Build (wie ich das schonmal angedeutet habe) eingerichtet bekomme. Niklas
Hayo W. schrieb: ... > Die nächsten Versionen werde ich aber wieder wie gewohnt als > Komplettpaket zur Verfügung stellen, Auf welcher Basis wird die entstehen? Werden die Änderungen an den Screenshot-Routinen enthalten sein? Entschuldige, daß ich so mit Subversion nerve, aber das sich abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen: - SVN, - hiesige ZIP-files, - ein SDK inclusive Sourcen mir unbekannter Herkunft... > damit sich nicht immer alle die Einzelteile zusammensammeln müssen. Muß jetzt schon niemand: https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/ https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/ Falk
Falk Willberg schrieb: > Auf welcher Basis wird die entstehen? Werden die Änderungen an den > Screenshot-Routinen enthalten sein? Die habe ich gerade eben mal mit in meine Sourcen eingepflegt, da ich aber gerade in der Firma bin kann ich nur kompilieren aber nicht testen. > Entschuldige, daß ich so mit Subversion nerve, aber das sich > abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen: > - SVN, > - hiesige ZIP-files, Ich kann die Sourcen sonst auch weglassen, da sie ja eine andere Aufteilung haben. > - ein SDK inclusive Sourcen mir unbekannter Herkunft... Ich vermute Du meinst das Cygwin-Paket von Ben. Die Sourcen dieses SDKs sind nur als Template zu sehen und sollten entsprechend ausgetauscht werden. Enenso wie das Makefile angepasst werden muß. Aber das SDK funktioniert wirklich gut. >> damit sich nicht immer alle die Einzelteile zusammensammeln müssen. > > Muß jetzt schon niemand: > https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/ > https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/ Die Links kannte ich noch nicht. - Sind die auch über die SFN-Page erreichbar? - Wer kompiliert denn die FW-Pakete und wann bei welchem Zwischenstand? - Wenn die FW nicht von mir kompiliert wurde ist es vieleicht besser statt des BF in der Bezeichnung die des Kompilierers zu verwenden. Also in diesem Fall vermutlich 1.2.FW.0.87, dann läßt sich die Herkunft besser zuordnen. Hayo
Also ich sehe hier überhaupt nicht mehr durch......... Meine Bitte: wenn ihr das entflochten habt, dann a) gebt hier bitte die richtigen Links bekannt und b) kennzeichnet alles alte bitte als ungültig/unbenutzbar/obsolet oder was auch immer Aber ich denke auch, diese Umstrukturierung musste irgendwann mal sein.. LG, egberto
Hayo W. schrieb: > Falk Willberg schrieb: ... >> Entschuldige, daß ich so mit Subversion nerve, aber das sich >> abzeichnende Sammelsurium an Quellen will mir einfach nicht gefallen: >> - SVN, >> - hiesige ZIP-files, > > Ich kann die Sourcen sonst auch weglassen, da sie ja eine andere > Aufteilung haben. Das halte ich für eine gute Idee... >> - ein SDK inclusive Sourcen mir unbekannter Herkunft... > > Ich vermute Du meinst das Cygwin-Paket von Ben. Genau. > Die Sourcen dieses SDKs sind nur als Template zu sehen und sollten > entsprechend ausgetauscht werden. Ich hoffe, das beherzigen alle... >>> damit sich nicht immer alle die Einzelteile zusammensammeln müssen. >> >> Muß jetzt schon niemand: >> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/ >> https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/ > > Die Links kannte ich noch nicht. > - Sind die auch über die SFN-Page erreichbar? > - Wer kompiliert denn die FW-Pakete und wann bei welchem Zwischenstand? Wer auch immer ins repository schreiben darf. > - Wenn die FW nicht von mir kompiliert wurde ist es vieleicht besser > statt des BF in der Bezeichnung die des Kompilierers zu verwenden. Na, ich nehme doch nicht einfach den Namen desjenigen heraus, der mit Abstand am meisten beigetragen hat. > Also in diesem Fall vermutlich 1.2.FW.0.87, dann läßt sich die Herkunft > besser zuordnen. Die Herkunft ist da immer aus Sourceforge. Wer's kompiliert hat, ist ja egal. Ich schlage den Namen FW-W20xxA-1.2-XX vor. Die Release ergibt sich ja aus Subversion. > Hayo Gruß, Falk
Hallo, bei Gelegenheit wäre es gut, wenn jemand das mit den Tickets kurz erläutern könnte. Ich möchte jedenfalls gern gefundene Fehler melden bzw. Vorschläge einbringen, hatte aber noch nie Kontakt mit euren Entwicklungshilfen und dementsprechend keine Ahnung wie das läuft. Gruß Michael
Hallo, ich lese ja regelmäßig diesen Thread und wundere mich, daß ihr die langen response Zeiten hier auf eure Posts nicht langsam satt habt?! Ich kann euch, den aktiven 4-5 FW Entwicklern, wirklich nur empfehlen sich sich auf dem kurzen Weg via skype oder einen ähnlichen Dienst auszutauschen. Auf dem HW und dem VHDL Sektor läuft das, mit inzwischen bis zu 8 Leuten, absolut problem- und vor allem verzugslos! gruß, brunowe
Hallo Michael, > bei Gelegenheit wäre es gut, wenn jemand das mit den Tickets kurz > erläutern könnte. Ich möchte jedenfalls gern gefundene Fehler melden > bzw. Vorschläge einbringen, hatte aber noch nie Kontakt mit euren > Entwicklungshilfen und dementsprechend keine Ahnung wie das läuft. ist egtl. ziemlich einfach und funktioniert auch ohne Sourceforge Account. Da fuer unser Welec Projekt der Bug-Tracker leider noch deaktiviert ist kann ich Dir das leider nur anhand eines anderen Projekts zeigen. Wenn Du auf einer Projektseite den Reiter "Develop" anklickst erscheinen nun weitere Reiter daneben. Wenn das Bug-Tracking System aktiviert ist gibt es einen Reiter "Tracker". Wenn Du mit der Maus drueber "hoverst" erscheint ein Menue mit verschiedenen Optionen, u.a. Bugs, Feature Requests und Search. Klickt man z.B. Bugs an, koennte das so aussehen: http://sourceforge.net/tracker/?group_id=145591&atid=762476 Mit "Add new" (oben unter Summary bei mir) kannst Du einen neuen Bug eintragen. Es gibt ein Feld Summary und ein Feld Description und man kann noch ein paar weitere Optionen auswaehlen sowie Dateien anhaengen. Nicht viel anders als hier im Forum. Auf Seite der Admins und Developer koennen die Bugs einem Developer zugewiesen und Stati geaendert werden (ueblicherweise sind das "Open", "Closed", "Nofix", "Duplicate" usw., egtl. selbsterklaerend). So kannst Du dann auch sehen was mit Deinem Bug passiert. Zudem koennen andere Nutzer (oder auch Devels) Kommentare hinzufuegen, wenn bei denen z.B. das Problem nicht reproduzierbar ist oder noch weitere Informationen benoetigt werden. Vergleichbar mit einem Forumsthread. Schau Dich einfach mal ein wenig um unter der URL oben. Niklas
Bruno We schrieb: > Hallo, > > ich lese ja regelmäßig diesen Thread und wundere mich, daß ihr die > langen response Zeiten hier auf eure Posts nicht langsam satt habt?! > Ich kann euch, den aktiven 4-5 FW Entwicklern, wirklich nur empfehlen > sich sich auf dem kurzen Weg via skype oder einen ähnlichen Dienst > auszutauschen. Den Gedanken hatte ich auch schon. Ich lausche jetzt mal auf irc.freenode.org:6667, Kanal #welec. Wenn jemand eine andere Idee hat.... Falk
Habe heute einen "Bug" bei der 0.85 gefunden. Drückt man, während das Oszi im Roll-Mode ist (z.B. Zeitbasis 1sec.), auf >>Autoscale<<, dann schlägt das jedesmal schief. Offenbar wird hier der Rollmode nicht wieder deaktiviert. Deaktiviert man den Rollmode vorher (z.B. Zeitbasis 200ms) geht's dann wieder problemlos. Gruß, Michael
Niklas O. schrieb: > Da fuer unser Welec Projekt der Bug-Tracker leider > noch deaktiviert ist kann ich Dir das leider nur anhand eines > anderen Projekts zeigen. Ich hätte schwören können, dass ich die Tage schonmal geschrieben habe: Bitte benutzt die Ticket-Funktion vom Trac. Die ist viel besser mit dem Trac-Codebrowser, dem Wiki, der Timeline, der Roadmap und eigentlich allem anderen integriert.
Hallo Daniel, sorry, ich merke erst gerade das Trac was ganz anderes ist als die Standard-Oberflaeche und verstehe nun erst richtig was Du und rowue meinen... (Falls ich nicht der einzige bin der zu daemlich ist das richtige Ticketsystem zu finden: http://sourceforge.net/apps/trac/welecw2000a/report ) Koennt ihr das so schalten das man neue Eintraege ins Trac-Ticketsystem auch als unangemeldeter User bei SF erstellen kann? Abgesehen davon: bitte Kurzbeschreibung wie wir Tickets mit SVN verbinden sollen. Niklas
Niklas O. schrieb: > Koennt ihr das so schalten das man neue Eintraege ins > Trac-Ticketsystem auch als unangemeldeter User bei SF > erstellen kann? Also prinzipiell geht das natürlich, aber zwei Punkte sprechen für eine (sehr einfache, schmerzfreie) Registrierung (man bekommt auch keinen Spam von SF.net oder so, sind ja keine bösen Jungs): 1) Spam wird vermieden und 2) Man kann mit den Ticket-Erstellern kommunizieren. Punkt 2 ist unmöglich, wenn alle Leute ihre Tickets anonym posten... > Abgesehen davon: bitte Kurzbeschreibung wie wir Tickets > mit SVN verbinden sollen. Ich empfehle die Lektüre von https://sourceforge.net/apps/trac/welecw2000a/wiki/TracGuide Da steht eigentlich alles drin, was man über Trac wissen muss. Prinzipiell greifen z.B. in Commit-Nachrichten viele der Wiki-Formatierungen von Trac, so auch die Referenzierung von Tickets (mittels #Ticketnummer). Umgekehrt kann man im Trac-Wiki und in Tickets (und überall anders) mit "rNUMMER" Revisionen referenzieren, die dann direkt zum Code Browser verlinkt werden usw. Siehe auch unter https://sourceforge.net/apps/trac/welecw2000a/wiki/WikiFormatting (Abschnitt Trac Links)
Hallo Daniel, kann es sein, dass die Möglichkeit, Bugs etc über Tickets einzutragen momentan deaktiviert ist? "Error - The Tracker has been disabled for this group" Gruß, Michael
Michael H. schrieb: > Hallo Daniel, > kann es sein, dass die Möglichkeit, Bugs etc über Tickets einzutragen > momentan deaktiviert ist? > > "Error - The Tracker has been disabled for this group" > > Gruß, > Michael Das ist der SF.net tracker. Der ist deaktiviert, weil doch das Trac verwendet werden soll. Die SF.net Apps sind alle ziemlich schlecht. https://sourceforge.net/apps/trac/welecw2000a/newticket https://sourceforge.net/apps/trac/welecw2000a/report
Angehängte Dateien:
-
screenshot-0000.png
5,1 KB
Guten Morgen. Ok das mit den Tickets verstehe ich jetzt soweit, denke ich. Wer war denn nochmal der Screenshot-Guru? Da keine Reaktion kam, wurde mein Post oben vielleicht übersehen? Das klappt ja eigentlich sehr gut aber wenn man die Horizontalposition verstellt, fliegt alles durcheinander - hier nochmal ein Shot dazu. Es ist dann ziemlich schwierig, das wieder zurückzudrehen und natürlich wäre es schön, wenn man in jeder Position Screenshots machen könnte. Gruß, Michael
Michael H. schrieb: > Guten Morgen. > Ok das mit den Tickets verstehe ich jetzt soweit, denke ich. > Wer war denn nochmal der Screenshot-Guru? Der Niklas ;-) > Da keine Reaktion kam, wurde mein Post oben vielleicht übersehen? Leider kann ich gerade nichts ausprobieren :-( Falk
Hallo, ich habe gerade ein wenig mit den Messfunktionen gespielt und hätte eine Frage. Wenn man ein Rechtecksignal vermisst wird bei RMS schön ein Vielfaches der Periode betrachtet, bei Average allerdings immer X,5 Perioden, also hinten noch eine halbe dran. Da sich das Ergebnis auch deutlich von meinem anderen Oszi unterscheidet nehme ich an, dass das ein Bug ist? Alle anderen bisher getesteten Messfunktionen liefern tadellose Ergebnisse - wenn ich mich richtig entsinne, muss man einen Stefan dafür loben? Wer auch immer: gut gemacht! Gruß, Michael
Nabend ;)
a) Anbei noch mal der diff mit der Bitte zum Reinpatchen in den
Trunk ;)
b) Zum Thema trac:
i) bitte die Tickets in Englisch abfassen - dann können das auch
Leute lesen, die nicht deutsch sprechen ;)
ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac
entsprechende Bezeichnungen für "Component", "Version" und ggf.
Milestone (vorher absprechen?) einrichtet - sonst wird es
irgendwann etwas unübersichtlich ;)
Grüße,
rowue
Rolf Würdemann schrieb: > ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac > entsprechende Bezeichnungen für "Component", "Version" und ggf. > Milestone (vorher absprechen?) einrichtet - sonst wird es > irgendwann etwas unübersichtlich ;) Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum Ticket-Admin berufen? =)
Hallo Hayo, ich hätte einen Punkt für die Wishlist: Eine Kombination aus Roll und Shiftmode. Das Ganze läuft wie folgt ab: Am Anfang wird der Bildschirm von links her mit neuen Daten beschrieben, also genau so, wie aktuell der Rollmode am Welec auch funktioniert. Ist der Bildschirm komplett gefüllt, dann wechselt das Ganze in einen Shiftmode und die neuen Daten werden von rechts her in das Display geschoben. Bei Tek heißt eben diese Kombination gerade Rollmode. :) Beste Grüße, branadic (der sein TDS5104B immer mehr zu schätzen lernt)
Hallo, ich bin ja immer noch dabei, nach und nach alles am neuen Oszi durchzuprobieren. Heute habe ich mal die I2C Kommunikation eines Bastelprojektes betrachtet und dabei festgestellt, dass es noch ein paar Probleme mit dem Trigger gibt. Der stand auf normal und ich habe ein wenig an der Zeitbasis gedreht während SDA dargestellt wurde. Dabei kam es immer wieder vor, dass der Trigger nicht mehr reagierte, erst nach zweimal Run/Stop drücken lief die Sache wieder. Komischerweise passiert es nicht immer, aber doch recht oft, wie gesagt immer beim Wechseln der Zeitbasis. Achja, wenn man nochmal weiter an der Zeitbasis dreht, reagiert der Trigger teilweise auch wieder. 2V/div, Kanal 4, Acquire=Normal waren meine Einstellungen falls es jemand nachstellen möchte. Irgendwie ist es hier erschreckend still geworden...hoffentlich ändert sich das wieder. Naja, liegt wohl an der ganzen Umstellerei. Gruß, Michael
Daniel H. schrieb: > Rolf Würdemann schrieb: >> ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac >> entsprechende Bezeichnungen für "Component", "Version" und ggf. >> Milestone (vorher absprechen?) einrichtet - sonst wird es >> irgendwann etwas unübersichtlich ;) > > Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum > Ticket-Admin berufen? =) Ach, ich bin ganz froh, wenn das jmd. anderes macht ;) - Zu viele Projekte verderben den Brei ;) Vorschläge: Component: firmware-nios pc-screenshot Version: ab 0.80Beta die veröffentlichten Versionen. Am besten bei/kurz nach der Veröffentlichung. Milestone: 1.0 (1.1 / oder 2.0) alternativ: schöne Codenamen für die "endgültigen" (nicht Beta) Releases ;)
Angehängte Dateien:
-
Signalvergleich.png
8,1 KB
Guten Abend/Morgen, mir ist heute eine seltsame Geschichte beim Messen von einem Signal aufgefallen. Ich hab dieses Problem dann anhand eines 2MHz-Rechtecksignales nachgestellt und möchte davon berichten, weil ich nicht weiß, ob das bekannt ist und vielleicht ein weiterer Hinweis zu den berühmten Schwingungen ist. Gemessen wurde mit dem Tastkopf 10:1 und weiterhin ist BW für eine bessere Beurteilung des Unterschiedes angeschaltet. Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit 1GS/s bei 100ns/div. Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die Samplerate von 500MS/s bei 100ns/div erhalten. Bis hierhin nicht unbedingt verwunderlich. Nun habe ich aber das 2MHz-Rechtecksignal erneut aufgenommen, mit besagten 500MS/s (siehe Bild oben rechts). Was auffällt: Der Trigger triggert statt von steigender plötzlich auf fallende Flanke und man erkennt auf einmal seltsame Schwingungen, die da nicht hingehören. Ist das einfach nur ein Problem in der Ausgabereihenfolge der Daten oder steckt hier ein Indiz für ein Problem im Downsampler/FPGA allgemein? Beste Grüße, branadic
Vielleicht noch ein kleiner Nachtrag. Ich habe die Daten zur besseren Analyse im CSV-Format abgespeichert, es ist aber zu spät, als dass ich noch die Ursache für diese Problematik finde. Eine geringere Samplerate bei gleicher Timebase sollte eigentlich eine Tiefpasswirkung haben, eigentlich. Bei Interesse für eine genauere Analyse stelle ich die Daten auch gern zur Verfügung. Hab sie mir mal mit Octave angeschaut. Dabei ist mir auch ins Gesicht gestochen, dass nur ein Bruchteil der tatsächlich im Datenspeicher befindlichen Daten auf dem Bildschirm angezeigt wird. Vielleicht doch eine Möglichkeit der DPO-Implementierung? :) Grüße und gute Nacht, branadic
Angehängte Dateien:
-
alle_Samples.PNG
51 KB
Hallo Zusammen, auch auf die Gefahr hin, dass das hier ein Monolog wird, ich habe heute noch mal ein wenig mit den exportierten CSV-Dateien der gestern gezeigten Bilder gespielt. Dabei ist mir noch etwas aufgefallen. Zunächst einmal ein Bild der komplett gespeicherten Daten, die im Samplespeicher liegen, einmal mit 1GS/s aufgezeichnet und einmal mit 500MS/s.
Angehängte Dateien:
-
250_Samples.PNG
15 KB
Geht man nun her und lässt sich die ersten 250 Samples beider Aufzeichnungen plotten, dann sieht man ein Schwingen innerhalb der ersten 25 Samples. Kann sich das jemand erklären? Ist doch auch irgendwie seltsam oder? Gruß, branadic
branadic schrieb: > Geht man nun her und lässt sich die ersten 250 Samples beider > Aufzeichnungen plotten, dann sieht man ein Schwingen innerhalb der > ersten 25 Samples. > Kann sich das jemand erklären? Ist doch auch irgendwie seltsam oder? > > Gruß, branadic Sieht mir aus wie das "Zerrissene-Flanke-Phänomen", das wir hier schonmal diskutiert haben. Sind wir da eigentlich auf eine Ursache gestoßen?
Wenn man sich die Bilder genau anschaut, dann sieht man im unteren Bild, also mit 500MS/s, dass sich dieses Schwingen nach einer Weile wiederholt, nämlich auf der Flanke. Dort ist es jedoch eine Überlagerung zusammen mit der fallenden Flanke. Kann das mal irgend jemand nachstellen, um herauszufinden ob das nur bei mir so ist? Vielleicht ist dieser Effekt auch Hardware-Version abhängig? Gruß, branadic
Hallo. Ich habe mich noch ein wenig mit der Screenshot Problematik beschäftigt: die einzige Möglichkeit, wieder einen sauberen Screenshot zu erhalten, nachdem man etwas verstellt hat, scheint zu sein den Ordner des Screenshot Programmes zu löschen und neu aus dem beta Archiv zu entpacken. Dabei ist das seltsame, dass ich keine Datei entdecke, die sich von den jungfräulichen aus dem Archiv unterscheidet - versteht das jemand? Gruß, Michael
Hallo branadic, das sieht doch wieder nach einem Schwingen des Eingangsverstärkers aus. Ich habe dem letzten Videoverstärker ja 2 mal 22 Ohm nachgesetzt, damit wurde es besser aber das Problem nicht gelöst. Ich wollte noch einen abschlusswiderstand an die A/D-Wandler setzen, das ist bei mir aber in Vergessenheit geraten, weil dann das Phänomen der Schwebung auftrat, das ja auch noch nicht geklärt ist. Ich fürchte, dass wir hier nicht ein Problem haben, sondern mehrere zusammenkommen. Gru0, Guido
Angehängte Dateien:
-
Sinus_3kHz_BW.PNG
15 KB
Hallo Guido, durchaus möglich, dass die Schwinger tatsächlich schon vor den ADC anliegen und Bruno sie seinerzeit nur nicht messen konnte. Ich hab jetzt mal ein 3kHz Sinussignal mit BW und 500MS/s aufgezeichnet. Interessant ist, dass auch hier zumindest der erste Schwinger innerhalb der ersten 25 Samples wieder auftaucht. Ich werde noch weitere Signalformen testen, vielleicht findet sich ein Zusammenhang. Das bringt uns letztlich wieder darauf zurück, dass man das Ausgangssignal der Eingangsstufe noch einmal genauer untersuchen sollte. Klar ist, dass bei einem Rechtecksignal natürlich recht hohe Frequenzen auftreten. Vielleicht liegt hier wirklich das Problem. Gruß, branadic
Hallo branadic, Guido, Ich glaube nicht dass es sich da um ein Schwingen in analogen teil des DSO handelt. (sonst waehre das Schwingen auch bei 1Gs sichtbar). Vielmehr vermute ich ein Problem im FPGA code (Zum Beispiel eine falsche phasenlage der 4 PLL's). branadic: Hast du den effekt auf allen kanaelen? Und tritt das immer auf oder nur in einer speziellen sequenz? Ich kann leider das Problem erst Montags nach stellen. Martin
Hallo Martin, meine Befürchtung ist halt, dass mehrere Fehler vorhanden sind. Das Schwingen ist im Eingang ganz sicher da. Ich habe das im Hardware-Thread schon mit Bildern gezeigt. Du findest das dort, wenn du nach "22 ohm" suchst. Gruß, Guido
Angehängte Dateien:
-
Dreieck_3kHz_BW.PNG
15 KB
So, schon wieder ich. Es scheint ganz egal zu sein, was ich für ein Signal anlege, in den ersten 25 Samples stecken immer diese Schwinger drin. Jedoch zeigt sich, dass scheinbar wirklich nur bei Rechtecksignalen diese Schwinger dann immer wieder an den Flanken auftreten. Das macht aber für mich keinen richtigen Sinn, denn angenommen es ist wirklich die Eingangsstufe, woher kommt dann der erste Schwinger, egal welches Signal ich anlege? Denn der sieht bei Rechtecksignalen an den Flanken von der Form her genauso aus. Da ist guter Rat teuer. Jemand eine Idee? Gruß, branadic
Hallo Martin, ja, das Problem taucht so auf allen Kanälen auf. Und richtig, bei 1GS/s scheint es diese Effekte, bis auf diesen seltsamen Schwinger innerhalb der ersten 25 Samples, nicht zu geben. Damit liegt der Verdacht nahe, dass es nicht die Eingangsstufe sein kann und es sich um ein Problem ab dem ADC handeln muss. Gruß, branadic
Naja vllt. kommt der Dezimator im FPGA mit starken Amplitudenhüben (und damit natürlich mit hohen Frequenzen) nicht klar. Bei Dreieck bzw. Sinussignal sind die übergänge von einem zum nächsten Sample ja eher gering. Außer natürlich am Anfang wenn das erste Sample kommt. Ich weiß nicht wie genau der Dezimator im FPGA läuft, ob dieser ständig läuft oder bei jedem Speicher befüllen neu initialisiert wird. Jedoch könnte ich mir durchaus dort den Fehler vorstellen. Vllt sollte man mal nachschauen ob bei Rechtecksignalen mit minimalem Spannungshub auch die beobachteten Schwingung auftauchen. Just my 2 cent... Gruß Sebastian
Angehängte Dateien:
-
Sinus_2MHz.PNG
46 KB
Um das Problem weiter einzugrenzen: Mit 200ns/div lässt sich ein Signal mit 250MS/s, 500MS/s und 1GS/s wunderbar aufzeichnen. Das hab ich im obigen Bild mal gemacht und die ersten 1000 Samples geplottet. Man möchte eigentlich annehmen, dass das Rauschen kleiner werden sollte, also das Signal immer glatter. Dem ist aber offensichtlich nicht so. Man erkennt aber eindeutig einen systematischen Fehler bei 500MS/s und noch besser bei 250MS/s im Bild. Ganz nebenbei ist mir aufgefallen, dass mit der Screenshot0.4.exe leider nur Kanal 1 als CSV ausgegeben wird. Das Drucken in eine Bilddatei funktioniert dagegen bei mir bisher tadellos für alle Kanäle. Vielleicht kann man dieses Manko in der Screenshot0.5 beseitigen? Beste Grüße, branadic
Ich denke mal etwas laut... Kann es sein, dass uns hier ein digitales Filter im FPGA o.ä. zum Nachteil wird? Falls ja, bestünde die Möglichkeit dieses abzuschalten? Gruß, branadic
Hallo branadic, Also meiner Meinung nach ist da nur die Reihenfolge der Samples von den 4 AD-Convertern vertauscht! (siehe http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument) Wenn ich richtig zaehle sind das immer 25 zacken alle 100 Messwerte (1/4). Martin
Nein Martin, dem stimme ich so nicht zu. Ich denke und hoffe, dass bei 250MS/s nur noch ein ADC aktiv ist und dann dürfte das nicht so auftauchen. Beste Grüße, branadic
Hallo branadic, suche mal im Hardwarethread nach Schwebung. Damit müsstest du meine damalige Tomcat.ram finden, mit der nur ein Wandler ausgewertet wird. Screenshot ging damals halt noch nicht, aber du kannst vergleichen. Gruß, Guido
Hallo Guido, läuft denn diese TomCat denn mit der aktuellen Screenshot.exe? Gruß, branadic
Nö, da war die Basis die 0.68 wenn ich mich recht entsinne. Gruß, Guido
Hallo Guido, ich hab dein RAM-File jetzt mal reingeladen. Was ich mich gerade frage, bei 500MS/s laufen da noch zwei ADC oder sind das noch vier? Woran erkenne ich, welche ADC wirklich arbeitet? Muss ich dir da einfach blind vertrauen? Bei 250MS/s, sicher dass da nur noch ein ADC arbeitet? Wenn ich mir das so anschaue, dann scheint da auch irgendein Quark zu passieren. Ich versuch das mal irgendwie festzuhalten, damit jeder sehen kann, was ich meine. Ein wenig schade, dass sich in Moment so wenige Leute beteiligen. Beste Grüße, branadic
So, ich hab mal zwei Video's gemacht, damit man sehen kann, worauf ich hinaus will. Das Signal ist wieder mein 2MHz-Sinus, im ersten Video hab ich mehrfach Singleshot gedrückt, ich zweiten dann eine kurze, kontinuierliche Aufnahme. Diese Effekte der Treppchenbildung kommt mir etwas seltsam vor. Zumal sie mal auftaucht und mal nicht. Wie wäre es, um dem Problem mal genauer auf die Schliche zu kommen, wenn man in die Firmware die Reihenfolge der ADC-Werte in einem Untermenu verstellen könnte, meinetwegen auch via RS232 einstellbar? Nur damit ein für alle mal geklärt wäre, ob die ADC-Reihenfolge vertauscht ist oder nicht. Irgendwie fehlt es in der Beta an Umstellmöglichkeiten, um den Problemen besser auf die Schliche kommen zu können. Gruß, branadic
Hier mal noch ein paar Bilder verschiedener Aufnahmezeitpunkte mit 250MS/s. Unterstellt man den Bildern mit Treppenstufe eine falsche ADC-Reihenfolge und vertauscht immer zwei Samples, dann würde das Signal stimmen. Welcher Effekt könnte jedoch dafür sorgen, dass die Sample-Reihenfolge mal stimmt und mal nicht? Gruß, branadic
Hm. Clockjitter? Was könnte denn sonst noch dazu führen, dass sich das ständig gegeneinander verschiebt? Übrigens finde ich dein Engagement hier Klasse - Hayos Arbeit hat für jeden unmittelbaren Nutzen aber deine "Grundlagenforschung" wird das Welec vielleicht noch auf ein ganz anderes Niveau heben. Gruß, Michael
Hey Guido, wäre es dir möglich auf Basis der aktuellen FW-Version noch einmal eine Sonderversion zu schreiben, bei der man absolut sicher sein kann, dass bei 250MS/s auch wirklich nur ein ADC läuft und bei 500MS/s nur zwei? Warum? Ganz einfach, auf dem Bildschirm sehe ich nur einen Bruchteil der Samples einer Periode, alle Aussagen die ich treffe sind also eher spekulativer Natur. Wenn man die Daten nun aber exportieren könnte (CSV) und dann komplett analysieren würde, dann ließe sich vielleicht eher ein Zusammenhang erkennen. Wenn es deine Zeit also hergeben würde, dann wäre es großartig eine solche Sonderversion mal zu testen. Beste Grüße, branadic
Hallo Michael, danke für die Blumen, aber hier sei mal erwähnt, dass erst die Arbeiten an der Screenshot-Funktion und damit der Export der Daten dazu geführt haben, dass man nun die Daten auf Plausibilität hin untersuchen kann. Denn wie schon erwähnt, was auf dem Bildschirm angezeigt wird ist das Eine, was tatsächlich noch an Samples zwischen zwei Angezeigten vorhanden ist und wie die aussehen ist uns bislang ja verborgen geblieben. Daher muss an dieser Stelle das Lob an die entsprechenden Leute geleitet werden, ohne die diese Untersuchungen überhaupt erst möglich werden. Beste Grüße, branadic
sorry... Daher muss an dieser Stelle das Lob an die entsprechenden Leute geleitet werden, DURCH die diese Untersuchungen überhaupt erst möglich werden. Beste Grüße, branadic
Ach Mist du hattest dich ja extra auf einen ADC beschränkt, da fällt es allerdings schwer, sich eine Ursache für einen eventuellen Sampledreher zu denken der nicht permanent auftritt.
Hallo branadic, zur alten .ram: Da wird unabhängug vom Sampling immer 4 mal hintereinander der Wert des 1. ADC auf dem Schirm abgebildet. Allerdings nur in den schnellen Bereichen. Mit der neuen Firmware will ich das schon noch machen, bin aber bei der schnellen Entwicklung in letzter Zeit kaum noch mit dem Downloaden nachgekommen :-(. Es wir etwas mehr Arbeit, ich schau mal, wann ich dazu komme. Jetzt sehe ich mir erst mal deine Aufnahmen an. Gruß, Guido
Ah branadic, jetzt sehe ich, dass du in den langsamen Bereichen misst. Da habe ich mich noch garnicht darum gekümmert und habe keine Ahnung wieviele ADCs jeweils verwendet werden. Ich probiere mal das rauszufinden und eine Testversion zu kompilieren. Vor heute Abend werde ich aber nicht dazu kommen. Gruß, Guido
Und nochmal ich: @ branadic: In diesen Bereichen solltest du das eigentlich auch mit der aktuellen Beta sehen können. Nach meiner Vermutung samplen da alle 4 ADCs. Die Daten werden dann umgeschaufelt, so dass nur die Werte von ADC0 angezeigt werden. Das ergibt 4 kBytes. Wenn per Screenshot 16 kBytes übertragen werden, findest du die Daten von ADC1 im 2. 4-kB-Block, die von ADC2 im 3. und die von ADC3 im vierten Block. Das ist bei einer Timebase kleiner 5 µs/div so. In den schnelleren Bereichen geht es mit meiner alten .ram. Ich probiere es heute abend mit der Aktualisierung.
Hey Guido, mein Wunsch wäre im Prinzip eine (Sonder-)Firmware auf Basis der aktuelle FW mit folgenden Funktionen: - umschaltbare Samplingrate in den verschiedenen Zeitbasen, wobei wirklich nur echte Samples angezeigt werden sollten und nicht ein und dasselbe Sample mehrfach - verstellbare ADC-Reihenfolge, wobei hier geklärt/untersucht werden müsste, ob die Samples auch wirklich vom korrekten ADC kommen - die Möglichkeit bei 250MS/s, wo ja nur ein ADC laufen sollte, zwischen einem der vier ADC manuell wählen zu können, dessen Daten zur Anzeige kommen sollen - die Möglichkeit bei 500MS/s, wo ja zwei ADC laufen sollten, zwischen zwei der vier ADC manuell wählen zu können, deren Daten zur Anzeige kommen sollen. Vielleicht werden hier ja momentan die falschen ADC verwendet? Wie gesagt, dass alles auf der aktuellen FW-Basis um die Daten exportieren und analysieren zu können. Nur dann kann man wirklich echte Aussagen zu den tatsächlichen Samples treffen. Was auf dem TFT angezeigt wird ist dann noch mal eine ganz andere Geschichte. Solange aber schon Müll im Speicher liegt, brauchen wir nicht neue Funktionen implementieren und verbessern. Die Devise lautet also, erst einmal an der Wurzel zu schauen, bevor wir dem Bäumchen Blätter verpassen :) Beste Grüße, branadic
@ Guido, also wenn ich mir die CSV anschaue, dann sehe ich wie du sagst vier Blöcke, jedoch mit jeweils 16k und nicht 4k. Vielleicht kann uns Niklas mal sagen, in welcher Reihenfolge da was exportiert wird? Gruß, branadic
branadic schrieb: > @ Guido, > > also wenn ich mir die CSV anschaue, dann sehe ich wie du sagst vier > Blöcke, jedoch mit jeweils 16k und nicht 4k. > Vielleicht kann uns Niklas mal sagen, in welcher Reihenfolge da was > exportiert wird? Ganz einfach: Es wird der Datenbuffer von 0 aufsteigend ausgelesen:
1 | for (idx = 0; idx < 16384; idx++) { |
2 | putchar(SIGNAL1[idx]); |
3 | putchar(SIGNAL2[idx]); |
4 | putchar(SIGNAL3[idx]); |
5 | putchar(SIGNAL4[idx]); } |
Könnte es sein, daß die N ADC nicht in der Reihenfolge 1-2-3-4 schreiben, sondern 4-3-2-1 oder sowas? Falk P.S.: Ich nehme mir jetzt mal die Aufteilung der Sourcen von Hayo vor und sehe mal, wie ich das in SVN eingebaut bekomme. Und wenn dann nächste Woche mein Scope wieder da ist, kann es weitergehen....
Hallo branadic,
das wird unendlich kompliziert, ist aber doch auf dem PC mit den
gesendeten Daten leicht zu realisieren.
Schau mal in Hayos Programming-Maps: bis 250 MS/s werden immer alle
vier ADCs verwendet, nur bei der Anzeige auf dem Dispaly werden
Werte übersprungen ("Faktor"), wodurch die SamplingTiefe immer
kleiner wird. Die Anordnung der Daten im Speicher ist dann:
ADC0, ADC1, ADC2, ADC3, ADC0 ..., und so müsste sie doch die
Screenshotfunktion auch senden, oder? Dann kannst du die
Daten ja auf dem PC nach Belieben umsortieren, filtern, ...
Ab 25 MS/s werden die Daten aller vier ADCs gesampled und dann
umgeschaufelt, wie oben beschrieben.
Gruß, Guido
Hallo Falk, also ist es tatsächlich so, dass ich die Daten in der Form: Kanal 1; Kanal 2; Kanal 3; Kanal 4; Kanal 1; Kanal 2; Kanal 3; Kanal 4; Kanal 1; Kanal 2; Kanal 3; Kanal 4; Kanal 1; Kanal 2; Kanal 3; Kanal 4; sehe? Je nach Samplerate sind das dann die Daten von: --> 1GS/s Reihe 1: ADC0 Reihe 2: ADC1 Reihe 3: ADC2 Reihe 4: ADC3 --> 500MS/s (hier wäre zu prüfen ob das wirklich so ist!!!) Reihe 1: ADC0 Reihe 2: ADC2 bzw. Reihe 1: ADC1 Reihe 2: ADC3 --> 250MS/s (hier wäre zu prüfen ob das wirklich so ist!!!) Reihe 1: ADC0 oder ADC1 oder ADC2 oder ADC3 Ist das so korrekt? Gruß, branadic
Hey Guido, pass auf, ich stelle mal meine CSV-Daten zur Verfügung, dann kann jeder nach Belieben damit herumexperimentieren, wir haben aber alle die gleiche Ausgangssituation. Schaue ich mir die Daten an, dann ist kein systematisches Vertauschen erkennbar, denn dann müssten immer vier Werte eine Systematik bilden! Aber schaut doch einfach mal selbst. Beste Grüße, branadic
@ Falk Ich glaube es müssen immer 8 Byte auf einmal weggeschrieben werden, da der FPGA <8ns Zugriffzeit hat. D.h. es gibt mehr als 4 Möglichkeiten bei einem Dreher in der Reihenfolge. Jürgen
Hallo branadic, ich glaube nicht dass es so korrekt ist. Die Kanalzuordnung stimmt aber es müssten im CSV auch bei 500 MS/s und 250 MS/s alle vier ADCs abwechselnd sein. Wie kommst du auf die Idee, dass da ADCs abgeschaltet sind, steht das irgendwo? Ja, stell mal Daten ein und schreib dazu wie du die visualisierst. Gruß, Guido
Hey Guido, siehe meinen Beitrag oben, da sind die Daten mit den drei verschiedenen Sampleraten. Ich importiere die Daten in Octave/Matlab und plotte sie mir dann einfach. Meinetwegen die ersten 1000 Samples oder so. Beim Import erhalte ich eine 16384x1 Matrix. In dieser steht dann immer der erste Wert einer jeden Zeile. Octave ignoriert bei mir alle Werte die nach dem ";" kommen. Daher wäre ein Export mit "Komma" statt "Semicolon" wohl korrekter. Immerhin heißt es ja Comma-Separated Values und nicht Semicolon-Separated Values. ;) Gruß, branadic
Ganz einfach Guido, schau dir die drei Dateien an. Du wirst feststellen, dass vier Blöcke à 16k vorhanden sind. Plottest du nun den ersten Block mit den drei unterschiedlichen Sampleraten, dann wirst du feststellen, dass du bei 250MS/s x Signalperioden hast, bei 500MS/s sind es 2*x Signalperioden und bei 1GS/s sind es 4*x Signalperioden. Es können also unmöglich die Werte aller vier ADC sein. Gruß, branadic
Ganz einfach Guido, schau dir die drei Dateien an. Du wirst feststellen, dass vier Blöcke à 16k vorhanden sind. Plottest du nun den ersten Block mit den drei unterschiedlichen Sampleraten, dann wirst du feststellen, dass du bei 250MS/s x Signalperioden hast, bei 500MS/s sind es 2*x Signalperioden und bei 1GS/s sind es 4*x Signalperioden. Es können also unmöglich immer die Werte aller vier ADC sein, egal welche Samplerate ich einstelle. Gruß, branadic
Wenn ich mir die 250MSa/s und 500MSa/s Daten ansehe, dann ist ja auffällig, dass die Ausreißer eine Periode von 8 Samples haben. Das kann ich mir mit einem einfachen Vertauschen von Samples eigentlich nicht erklären aber bis jetzt kann ich leider auch noch kein vernünftiges Muster erkennen. Es sieht so aus, als würden von 8 Samples jeweils drei saftig danebenliegen. An der steigenden Flanke sind es immer 2 Ausreißer nach oben, einer nach unten, an der fallenden Flanke sieht es genau andersrum aus, also 2 nach unten und einer nach oben. Das kann man auch so sehen: vier Samples passen, von den nächsten vieren hauen drei daneben, die nächsten vier passen wieder. Sieht jemand ein Muster, dessen Ursache man sich erklären könnte? Gruß, Michael
Mir ist gerade noch eine Idee gekommen. Ob und wie sie sich umsetzen lässt ist mal ein anderer Punkt. Angenommen man zeichnet mit Kanal 1 ein Signal mit 1GS/s im Singleshot-Modus auf und speichert diese Daten im Speicher. Nun nimmt man die Daten und tut so, als hätte man diese Daten auf Kanal 2 mit 500MS/s aufgezeichnet und speichert die Daten entsprechend im Speicher für Kanal 2. Dann führt man das gleiche für 250MS/s ebenfalls durch und speichert die Daten auf Kanal 3. Das hätte den Vorteil, dass man genau schauen könnte, was mit den Daten im FPGA/ in der FW passiert, weil sich die Daten direkt miteinander vergleichen ließen. Wäre soetwas realisierbar? Selbst wenn das mit einigem Aufwand verbunden wäre, so ließen sich daraus doch sehr wertvolle Erkenntnisse gewinnen und die Ursache für die seltsamen Werte extrahieren. Meinungen von den FW-Experten sind gefragt. Beste Grüße, branadic (der sich schon wie ein Monolog führender Epiker vorkommt :D )
Guido schrieb: > ich glaube nicht dass es so korrekt ist. Die Kanalzuordnung > stimmt aber es müssten im CSV auch bei 500 MS/s und 250 MS/s > alle vier ADCs abwechselnd sein. Wie kommst du auf die Idee, > dass da ADCs abgeschaltet sind, steht das irgendwo? Um das Sampling äquidistant zu halten, muss es so sein wie André sagt. Bei 1GSa/s sind die Samples in der Reihenfolge: 1-2-3-4-1-2-3-4-, bei 500MSa/s in: 1---3---1---3--- und bei 250MSa/s: 1-------1------- Zusätzlich zu diesem 1, 2, 4-Downsampler gibts noch eine zweite Downsampling-Stage, die die Teilungen 1, 10, 100, 1000... ermöglicht, indem sie den Output des ersten Downsamplers als Input verwendet. Alles in allem sollte bei allen sampling rates <250MSa/s nur noch ein ADC aktiv sein.
Richtig Daniel, das zeigen ja auch die Bilder weiter oben: http://www.mikrocontroller.net/attachment/54967/Signalvergleich.png Hier ist links das Signal mit 1GS/s dargestellt gewesen und rechts mit 500MS/s, wie sie auf dem TFT dargestellt werden. http://www.mikrocontroller.net/attachment/54980/alle_Samples.PNG Hier sind die Daten, die tatsächlich im Speicher liegen ausgeplottet. Man erkennt, dass bei 500MS/s doppelt soviele Signalperioden bei gleichem Eingangssignal vorhanden sind. Gruß, branadic
Angehängte Dateien:
-
2MHz-Sinus.PNG
12 KB
So, ich möchte noch ein wenig mehr zu Verwirrung beitragen. Ich hatte ja oben meine CSV-Daten zur Verfügung gestellt. Plottet man bei 1GS/s jeden 16. Wert, bei 500MS/s jeden 8. Wert und bei 250MS/s jeden 4. Wert, dann sehen sich die drei Kurven sehr ähnlich, um nicht zu sagen sie passen sauber überein. Führt man den gleichen Plot nun mit jedem 8. Wert vom 1GS-Signal, jeden 4. Wert vom 500MS-Signal und jeden 2. Wert vom 250MS-Signal durch, dann bekommt man wieder ein mysteriöses Schwingen, das mit kleiner werdender Samplerate steigt. Doch eine Systematik?
Hier sind mal noch weitere 8 Plots mit verschiedenen Ploteinstellungen und jeweils 1000 Werten. Plot 1-4 zeigen, was passiert, wenn ich von 1GS jeden 16. Wert nehme, bei 500MS jeden 8. Wert und bei 250MS jeden 4. Wert beginnend von 1. Sample, 2. Sample, 3. Sample und 4. Sample. Plot 5-8 zeigen, was passiert, wenn ich von 1GS jeden 8. Wert nehme, bei 500MS jeden 4. Wert und bei 250MS jeden 2. Wert beginnend von 1. Sample, 2. Sample, 3. Sample und 4. Sample. Die Darstellung passt nur für die Verwendung 16 8 und auch nur, wenn ich mit dem ersten Sample beginne. Sieht darin irgend jemand einen Zusammenhang? Insbesondere in Verbindung mit dem FW-Code? Gruß, branadic
branadic schrieb: > Guten Abend/Morgen, > > [...] > > Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit > 1GS/s bei 100ns/div. > Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns > zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die > Samplerate von 500MS/s bei 100ns/div erhalten. Bis hierhin nicht > unbedingt verwunderlich. [...] Naja, für mich klingt das eher so, als würde die Sample-Rate bei einer Umschaltung während die Stop-Taste gedrückt ist, nicht angepasst. Das riecht für mich nach einem Bug. Wenn es dann noch zwei Variablen sind, die da geändert werden müssen und nur eine geändert wird, dürfte es nette Effekte geben. > > Beste Grüße, branadic Grüße, rowue
Rolf Würdemann schrieb: > Daniel H. schrieb: >> Rolf Würdemann schrieb: >>> ii) Es wäre sehr hilfreich, wenn jmd. mit "Admin"-Rechten im Trac >>> entsprechende Bezeichnungen für "Component", "Version" und ggf. >>> Milestone (vorher absprechen?) einrichtet - sonst wird es >>> irgendwann etwas unübersichtlich ;) >> >> Für Vorschläge bin ich ganz Ohr -- oder fühlt sich jemand zum >> Ticket-Admin berufen? =) > > Ach, ich bin ganz froh, wenn das jmd. anderes macht ;) - Zu viele > Projekte verderben den Brei ;) > > Vorschläge: > > Component: > > firmware-nios > pc-screenshot > > Version: > ab 0.80Beta die veröffentlichten Versionen. > Am besten bei/kurz nach der Veröffentlichung. > > Milestone: > 1.0 > (1.1 / oder 2.0) > > alternativ: schöne Codenamen für die > "endgültigen" (nicht Beta) Releases ;) +Type: Feature-Request (Um ein "Enhancement" im Sinne eines Patches von einer Bitte um ein weiteres Feature abzugrenzen ;) Daniel: Ich habe hier einige Bugs (+Feature-Requests), die ich gerne mal filen würden ;) - hättest Du Lust, die Vorschläge oben zu übernehmen, oder möchtest Du noch andere Vorschläge abwarten? - Die Umstellung auf das Trac-Ticket-System würde da m.E. einiges übersichtlicher machen ;) Grüße, rowue
@branadic Mich würden mal die dazugehörigen ADC Offsets interessieren, könnte es sein dass da bei der Zuordnung zu den ADCs was durcheinander gerät, wenn nicht alle vier benutzt werden? Im Prinzip könnten solche Zacken dann schon zustandekommen, auch die Periodizität wäre dann denkbar...
Hallo branadic, ich fange mal mit Spekulationen an; bei 500 MS/s ist die Sache klar. Mit jedem 4, Wert nimmst du abwechselnd Daten von ADC1 und ADC3 und da keine Offsetkorrektur stattfindet (?) schwanken die Werte etwas. Bei 250 MS/s gibt es nach Daniels Erklärung keine solche Begründung. Wisst ihr sicher, dass statt Downsampling nicht einfach die Abtastrate runtergesetzt wird (würde ich so machen, hat ja aber nicht viel zu sagen)? Gruß, Guido
Achso, mit der FW hat das garnichts zu tun. Da werden nur die Daten im FIFO abgeholt und im RAM abgelegt.
@ Rolf Also, ich habe mir jetzt noch mal für alle Sampleraten die Daten exportiert. Soll heißen, 1µs/div mit 1GS/s, 2µs mit 500MS/s und 5µs mit 250MS/s, eben so wie es original im Oszi auch hinterlegt ist. Am Effekt der auf die Daten wirkt ändert sich aber nichts. Das heißt, meine obigen Messungen sind glaubhaft. Kannst du gern selbst nachprüfen. Das heißt also auch, dass es kein Scheineffekt ist, sondern ein ernstzunehmendes Problem ;) Gruß, branadic
@ Michael Du wirst lachen, aber genau den Gedanken hatte ich vorhin auch schon und hab ihn mit den Jungs in Skype diskutiert. ADC-Korrekturwerte für meinen Kanal 1: ADC1 = 3 ADC2 = 0 ADC3 = 1 ADC4 = 1 Beste Grüße, branadic
@ branadic und Michael: Oops, Michaels Post habe ich übersehen. Aber das ist nach meinem Gefühl absolut korrekt. Ich schau später noch nach, aber nach meiner Erinnerung werden alle Werte so wie sie vom FIFO reinkommen in der Reihenfolge 1-2-3-4 offsetkorrigiert. D.h. so, als ob alle 4 ADCs verwendet werden. Gruß, Guido
Damit sind die Offsets wohl eindeutig zu klein, um die hässlichen Sprünge zu erklären. Schade, aber dem kommen wir schon noch auf die Spur! Ich brauche unbedingt mal einen Signalgenerator, leider sind die Dinger halt auch gebraucht noch ziemlich teuer wenn man auf einen einigermaßen anständigen Sinus Wert legt. Ist es eigentlich eine Tatsache, dass die Anzahl der verwendeten ADCs abhängig von der Timebase variiert, also hat das jemand überprüft? Bei nur einem verwendeten ADC bei 250MSa/s kann ich mir einfach nicht vorstellen, dass sowas dabei rauskommen kann! Gruß Michael
branadic schrieb: > @ Rolf > > Also, ich habe mir jetzt noch mal für alle Sampleraten die Daten > exportiert. Soll heißen, 1µs/div mit 1GS/s, 2µs mit 500MS/s und 5µs mit > 250MS/s, eben so wie es original im Oszi auch hinterlegt ist. > Am Effekt der auf die Daten wirkt ändert sich aber nichts. Das heißt, > meine obigen Messungen sind glaubhaft. Kannst du gern selbst nachprüfen. > Das heißt also auch, dass es kein Scheineffekt ist, sondern ein > ernstzunehmendes Problem ;) Dann könnten wir evtl. zwei Probleme haben: a) Das Problem mit den Rückschalten der Sample-Rate (Siehe z.B. auch das Quick-Measurement-Problem nach dem Quick-Print (habe hier noch zwei weitere in der Queue ;) b) Das Abtast-Problem - aus Deinen Datenfiles würde ich schon schliessen, dass da beim Auslesen der ADC's was vertauscht ist. > > Gruß, branadic Grüße, rowue
So, ich habe eben Revision 172 commited. Die enthält die neue Aufteilung der Dateien und Klassen von Hayo und meine schonmal committeten Änderungen am screenshot. Meine Pöbelei im Log auf deutsch: "Das hat mich jetzt drei Stunden gekostet. Wenn nochmal jemand, SVN ignorierend, aus einer lokalen Kopie ein Release baut, tue ich mir diese Überflüssige Arbeit nicht nochmal an. Dann haben wir eben eine Release im SVN, die Screenshots und GUI-Fernbedienung unterstützt und eine, die irgendetwas anderes kann. Es sei denn, jemand anderes popelt das zusammen." Gruß, Falk
1 | svn co https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/ |
Hallo Falk, das ist schön. Ist jetzt also das SVN soweit fertig? Vorher mache ich an der Firmware nichts mehr (mir gehen mit jeder neuen Version halt alle Bookmarks flöten...). @ branadic: Ich habe noch mal in die Sourcen geschaut. Es wird in allen Bereichen so korrigiert, als ob im FIFO die Daten in der Reihenfolge ADC0, ADC1, ADC2 und ADC3 ankommen. Das kann natürlich falsch sein, aber gibt es mehr als den Verdacht, was darauf schließen lässt, dass nicht alle ADCs verwendet werden? Dass die Firmware hinterher nicht alle vorhandenen Daten auswertet ist klar. Gruß, Guido
Hallo Rolf, ein Vertauschen der ADC-Werte möchte ich nicht ausschließen. Nur wurde das bisher anhand der auf dem Display dargestellten Werte beurteilt, der Datenexport dagegen bringt hier eher Aufschluss über die korrekte Reihenfolge. Bei der Darstellung auf dem Display müssen dann ja noch einmal Werte weggeschmissen werden, immerhin stehen nur 600px zur Darstellung zur Verfügung. Das heißt, wenn die Darstellung auf dem Display scheinbar stimmt, muss das für die Samples im Speicher noch lange nicht gelten. Wie wird dieses zweite Downsampling überhaupt realisiert? Welche Werte in welcher Reihenfolge werden hier weggeschmissen? Gruß, branadic
Guido schrieb: > Hallo Falk, > > das ist schön. Ist jetzt also das SVN soweit fertig? Fertig? Mhhhh.... Es sind jetzt alle mir bekannten Versionen eingepflegt. Da ich gerade kein Scope habe, weiß ich nicht, ob das alles funktioniert. > Vorher mache > ich an der Firmware nichts mehr Nach meinem Verständnis sind im SVN jetzt die aktuellen Versionen von: - Firmware aus Hayos BlueFlash_Build_0_87.zip - Letzte Änderungen am Screenshot (Farbe 14s), kompatibel zur aktuellen Version von w2000a-screenshot - Dito für das (sehr rudimentäre) w2000a-qtgui > (mir gehen mit jeder neuen Version halt alle Bookmarks flöten...). Bookmarks? Falk
Hallo Guido, irgendwie muss ja das erste Downsampling realisiert worden sein, da stimmen wir sicher beide überein. Das erste Downsampling ist jenes, welches dafür sorgt, dass bei 1GS alle Daten in den Speicher wandern, bei 500MS nur noch jeder zweite Wert (doppelte Anzahl Signalperioden), bei 250MS jeder vierte Wert (vierfache Anzahl Signalperioden) usw. und so fort. Jetzt stellt sich natürlich die Frage, ob die Werte die in den FIFO wandern auch alle äquidistant sind. Äquidistanz wäre nur gegeben, wenn bei 500MS die Werte von ADC0 und ADC2 verwendet werden. Bei 250MS entsprechend nur noch die Werte von ADC0. Sollte hier schon Unfug passieren, dann wären die Samples nicht mehr plausibel, weil das Eingangssignal nicht in gleichen Zeitabständen abgetastet würde, sondern irgendwie. Das wäre der GAU! Jetzt ist nur die Frage, wie wir die Frage beantworten können, ohne einen Blick auf das FPGA-Design von Welec werfen zu können. Gruß, branadic
Hallo branadic, was meinst du jetzt mit Downsampling? Für die Firmware kannst du das Hayos Programming-Maps entnehmen. Z.B. werden bei 250 MS/s 16 kB Daten gesampled und davon jeder 25. Wert (Faktor=25) angezeigt. Macht für die Darstellung insgesamt 655 Werte (Sample-Depth=25). @ Falk: Die Lesezeichen in Kate, die mir den Weg durch tausende Programmzeilen bahnen. ;-) Gruß, Guido
Guido schrieb: ... > @ Falk: Die Lesezeichen in Kate, die mir den Weg durch > tausende Programmzeilen bahnen. ;-) Oh, die kannst Du wohl wieder wegschmeißen. Ich wollte ja viele kleine Dateien haben..... Naja, das läßt sich vielleicht Zug um Zug umsetzen. Es war zwar ein Stück Arbeit, das zusammenzubauen, aber angesichts der Tatsache, daß Hayo einen überragenden Anteil an der Arbeit hat, das W20xx brauchbar zu machen - und alle anderen sich gedrückt haben ;-) - war es das wert. Wollte ich auch mal gesagt haben. Falk
Okay, noch mal langsam Guido. Mit dem ersten Downsampling meine ich jene Daten, die im 16k-Speicher landen. Wie du diesem Bild hier: http://www.mikrocontroller.net/attachment/54980/alle_Samples.PNG entnehmen kannst, habe ich den kompletten Speicher bei 1GS / 500MS und 250MS mit der Screenshot.exe ausgelesen. Wie du auch siehst, sind es jeweils 16k Datenpunkte und man erkennt, dass bei 1GS 33 Signalperioden zu sehen sind, bei 500MS sogar 66 Signalperioden und bei 250MS sind es dann sogar 132 Signalperioden. Das führt uns zur Erkenntnis, dass bei 500MS die Werte von 2 ADCs weggeschmissen werden müssen, bevor sie überhaupt im Speicher landen, sonst würde das mit der doppelten Anzahl an Signalperioden aufgrund des 16k-Speichers ja nicht funktionieren. Soweit klar? Bei 250MS habe ich nun die vierfache Anzahl an Signalperioden gegenüber 1GS. Also müssen die Werte von 3 ADC weggeschmissen werden, sonst könnt ich nicht die vierfache Anzahl Signalperioden im Speicher haben. Jetzt klar? Gruß, branadic
Hallo branadic, nö, immer noch nicht klar. Was wäre denn, wenn die Samplerate der Wandler jeweils halbiert würde? Kannst du das ausschließen. Das ist es, was ich meine ich würde so vorgehen, denn den Takt im FPGA zu halbieren ist ja kein Hexenwerk. Gruß, Guido
Hallo, also ich habe ein altes W2012 ohne A. Ich verfolge die Diskussionen hier schon lange. Leider hat mir Wittig nie geantwortet. Nun ja, ich hab nun mal ein Update gewagt (die neuere Firmware 1.10.03 oder so) lief ja bei mir nicht, man konnte nur Min und Max auswählen. Also, ich habe die Datei W2022A.JIC per JTAG in den Config-Flash geschrieben. Danach ein Update mit der Firmware 1.2.BF.0.86beta gemacht. Schien alles gut zu laufen. Das Firmwareupdate läuft soweit durch. Das Gerät startet neu, im Updater steht allerding noch "Programmierung .. bitte warten" und es kommt dann dort ein Timeout. Wie gesagt, Gerät läuft und lässt sich auch bedienen. Nur sind die ADC-Values (Konsole) immer auf 255. Die Traces bleiben auch nach Kalibrierung am unteren Bildschirmrand. So ganz stimmt dann wohl doch was nicht? Hat jemand eine Idee? Morgen probier ich nochmal die alte Firmware, um zu sehen, obs am FPGA-Core liegt, mir war aber so, als ging es dann noch.
Hallo Remo, > ADC-Values (Konsole) immer auf 255. Die Traces bleiben auch nach > Kalibrierung am unteren Bildschirmrand. So ganz stimmt dann wohl doch > was nicht? Hat jemand eine Idee? Schau doch mal hier: http://forum.ixbt.com/topic.cgi?id=48:8586 Schauen geht ja noch. Lesen ist allerdings viel schwieriger : -) Soweit ich das verstehe, haben sie dort ein Upgrade geschafft. Gruß Jürgen
Hallo Guido, das wäre prinzipiell natürlich machbar, aber die Wahrscheinlichkeit für dieses Vorgehen dürfte eher gering sein, wenn nicht sogar ganz ausgeschlossen werden. Die einfachste Möglichkeit ist einfach ein Downsampling, sprich Werte werden schlichtweg weggeschmissen. Das man eine Takthalbierung vorgesehen hat traue ich dann noch nicht einmal Wittig zu. Der sinnvollste Weg wäre eigentlich, mit so wenig ADCs wie möglich zu arbeiten, also genauso wie ich das schon die ganze Zeit schreibe: 1GS - vierfach interleaved 500MS - 2fach interleaved 250MS - gar nicht mehr interleaved Was aber können wir machen für den Fall, dass der Downsampler von Wittig nicht korrekt funktioniert? Ich meine, dass uns dann nur die Möglichkeit bleibt mit den vollen 1GS/s in allen Zeitbasen zu arbeiten, die 16k Speicher zu füllen und dann die richtigen Samples via FW herauszupicken. Das ändert die erzielbare Speichertiefe im Oszi insgesamt gewaltig und dürfte auch die Performance gewaltig nach unten treiben. Beste Grüße, branadic
Hallo, also folgende Situation: altes W2012 ohne A mit FPGA-Core für W2022A (slogs *.JIC Datei) führt dazu, dass die Relais nicht mehr angesteuert werden. Deswegen gehen die Analogeingänge dann auch nicht mehr. Taster und Encoder funkitonieren. Hat sich da doch was an der Schaltung verändert? Wie kann ich dies überprüfen? Wo kann ich im FPGA-Design die Pin-Belegung für die Relais-Steuerung finden bzw. ändern? In welchem Thread ist diese Anfrage besser aufgehoben? Gruß, Remo.
Remo schrieb: > Hallo, > > also folgende Situation: > > altes W2012 ohne A mit FPGA-Core für W2022A (slogs *.JIC Datei) führt > dazu, ... > In welchem Thread ist diese Anfrage besser aufgehoben? Entweder im Hardwarethread Beitrag "Wittig(welec) DSO W20xxA Hardware" oder gleich da, wo mehr Leute mitlesen: https://sourceforge.net/apps/phpbb/welecw2000a/ Gruß, Falk P.S.: Im Übrigen bin ich der Ansicht, daß dieses Forum für diese Art der Kommunikation ziemlich ungeeignet ist.
Hallo branadic, guido, Um die Diskussion um den Downsampler etwas zu kaeren habe ich mal den clock an den AD-Convertern bei verschieden Sample raten gemessen. Der Clock ist immer 250Mhz. Damit ist klar das das FPGA Design ein (schlechtes) Downsampling macht. Leider wissen wir nicht ob das irgendwie via SW beeinflusst werden kann. N.B. Der Fehler tritt auch bei der Original FW 1.3 auf. Martin
Martin H. schrieb: > Um die Diskussion um den Downsampler etwas zu kaeren habe ich mal den > clock an den AD-Convertern bei verschieden Sample raten gemessen. Der > Clock ist immer 250Mhz. Damit ist klar das das FPGA Design ein > (schlechtes) Downsampling macht. Leider wissen wir nicht ob das > irgendwie via SW beeinflusst werden kann. > N.B. Der Fehler tritt auch bei der Original FW 1.3 auf. Man hätte drauf kommen können, das zu tun =D Naja aber gut dass das jetzt geklärt ist. Das wichtigste Argument für das Downsampling (statt einer Reduzierung der Samplerate) ist übrigens, dass man so schnell wie möglich vom Interleaving mehrerer ADC wegmöchte, weil dadurch ja doch einiges an Fehler auf's Signal kommt (durch Clock Jitter, unterschiedliche Signallaufzeiten, ... -- da gab's mal so ein PDF von Agilent(?), in dem gut gezeigt wurde, was das Interleaving so für Effekte hat). Edit: Habe das Ticketsystem im Trac nach euren Wünschen eingestellt. Sorry, hatte das total verpennt am WE.
Angehängte Dateien:
-
screenshot-0001.png
4,2 KB
Hallo, über das ADC Timing hatten wir schon ausführlich im HW Thread diskutiert. Jeder der 4 ADC (pro CH) wird von einem eigenen Clocksignal angesteuert. Dieses Clocksignal wird von den 4 PLL's im FPGA direkt erzeugt (25MHz input vom Quarz *10). Das Timing der einzelnen PLL zueinander lässt sich in weiten Grenzen ändern, also eine konstante Phasenverschiebnung zw. den einzelnen Clocks um z.B. Laufzeitunterschiede zu den ADC auszugleichen. Allerdings findet die Clockerzeugung und Festlegung einer evtl. Phasenverschiebung in VHDL statt und lässt sich somit nachträglich nicht mehr korrigieren (ohne ein neues VHDL- Design aufzuspielen) > Aufgenommen habe ich (siehe Bild oben links) ein 2MHz Rechtecksignal mit > 1GS/s bei 100ns/div. > Danach habe ich dann auf 2µs/div gestellt, Stopp gedrückt, auf 100ns > zurück gestellt und eine erneute Messung durchgeführt. Dabei bleibt die > Samplerate von 500MS/s bei 100ns/div erhalten. Vielleicht sollten wir erstmal diesen Fehler fixen??? Da ich ja bereits vor vielen Monaten von eigenartigen Schwingungen (bei höheren Freq.) berichtet habe, wollte ich heute einmal ein Signal mit 60MHz als csv abspeichern. Im Prinzip geht es darum diesen Effekt näher zu untersuchen und mit dem jetzt festgestellten Fehler zu vergleichen. Das Ergebnis hat mich dann doch etwas überrascht. Sollte diese Datei nicht so aufgebaut sein das in Jeder Zeile die Werte des ADC0;ADC1;ADC2;ADC3 stehen, in der nächsten Zeile dann entsprechend u.s.w.? Also Anlage einmal ein Screendump meines Signal- wenig spektakulär.
... und hier die entsprechende CSV Datei dazu. Was ist da passiert? Hab ich irgendwas nicht mitbekommen? Gruß, brunowe
Das Format ist: Ch1;Ch2;Ch3;Ch4 Die Werte der verschiedenen ADC kommen also zeilenweise. Zumindest habe ich das bisher so verstanden!
Hallo, danke Martin, damit ist das geklärt. Ist aber sehr seltsam, dass niemand den Firmware-Entwickler darüber aufgeklärt hat. @ branadic: dann probiere ich mal mit dem SVN und baue eine .ram, die die Offsetkoreektur entsprechend anpasst. Dann können wir damit mal testen. Gruß, Guido
Aha, jetzt hab ich's auch verstanden. Die Einzelnen ADC Werte liegen Zeilenweise vor. Also erste Zeile: ADC0-ch1;ADC0-ch2;ADC0-CH3;ADC3-ch4 Zweite Zeile: ADC1-ch1;ADC1-ch2;.... usw. Mich hat nur bei branadic verwirrt, daß in seiner csv- Datei (s.h. hier Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" ) die Spalten 2, 3, 4 keine konstanten Werte enthalten, sondern irgendwelche Mülldaten die sich auch nicht mit Rauschen erklären lassen. Gruß, brunowe
Hallo zusammen, schön, dass sich einige Unklarheiten jetzt schon einmal geklärt haben. Den Takt hätte ich ja auch selbst gemessen, wenn ich ein zweites Oszi mit der notwendigen Bandbreite daheim hätte :) Und auch von Guido weiß ich, dass er über ein solches Gerät nicht verfügt. Also an dieser Stelle ein kleiner Dank an Martin. Die Ungereimtheit in der Darstellung der Daten wäre nun auch geklärt und ich nehme meine Behauptung von gestern? wieder zurück, dass der Export der Daten nicht korrekt funktioniert. Octave interpretiert nur das Semicolon als Zeilenende und importiert die Daten von Kanal 2, 3 und 4 nicht. Tausche ich jedoch die Semicolons gegen ein Komma aus, dann erhalte ich auch eine 16384x4 Matrix, wobei Spalte 1 Kanal 1 ist usw. Wäre auch das geklärt. Guido, dann ist es also wirklich schon mal so, dass die Offset-Korrekturwerte auf die falschen Samples wirken? Aber anders herum gefragt, auf die Daten die ich aus dem 16k-Samplespeicher auslese hat das doch keinen Einfluss oder? Das sind doch für mich die absoluten Rohdaten oder werden die Daten aus dem FIFO schon korrigiert in den 16k-Samplespeicher gelesen? Dann wiederum hätte die Korrekturreihenfolge natürlich einen Einfluss. Ich bin gespannt was sich tut, auch wenn der Hayo jetzt im Urlaub ist. Beste Grüße, branadic
Hallo branadic, doch die Daten sind schon vorverarbeitet (Offsetkorrektur, Invertierung, Averaging). Das erfolgt in READADC_ALL. Im anhängenden .ram habe ich mal versucht für Kanal 1 die Offsetkorrektur anzupassen, die anderen Kanäle sind unverändert, damit solltest du vergleichen konnen. Gruß, Guido
@branadic, So nen Oszi habe ich leider auch nicht, dafuer aber einen recht guten Frequenz Zaehler ;) Martin
Hallo Guido, einen Unterschied bezüglich der Zacken auf den Signalflanken zwischen der Ram-Testversion und der aktuellen,frisch compilierten 0.87 kann ich leider nicht feststellen. Mir ist bloß aufgefallen, daß mit dem Umschalten des Test_sw1 mit shft-S auf deine C-Routinen in READADC_ALL diese merkwürdigen Zacken auf den Flanken gegenüber den Assemblerroutinen vergrößert werden. Hier scheint es also noch Unterschiede in asm und C Implementierungen zu geben. Leider kann ich keinen screenshot mehr machen, da nach der Umstellung von Falk im svn die screenshot_v0.4.exe unter win32 nicht mehr zum Ende kommt. Wo gibt es eine aktuelle passende Datei? Gruß Jürgen
Jürgen schrieb: > Hallo Guido, ... > Leider kann ich keinen screenshot mehr machen, da nach der Umstellung > von Falk im svn die screenshot_v0.4.exe unter win32 nicht mehr zum Ende > kommt. > Wo gibt es eine aktuelle passende Datei? Die müßte mal jemand komplilieren.... Falk
Angehängte Dateien:
-
test_sw1_off1.png
4,6 KB
>Die müßte mal jemand komplilieren.... >Falk Eben! Zurück zum Thema: hab die 0.86 nochmal aufgelegt und hier die zwei Screenshots gemacht. Mal zum Vergleich Version 1 mit asm-routinen
Hallo Jürgen, danke für die Tests. Na das ist doch schon mal ein Fortschritt, an den C-Routinen habe ich noch nichts geändert. Da muss ich erst mal versuchen besser zu kapieren wie die Daten angeordnet sind. Erst muss ich auch mal die Screenshots zum funktionieren bringen. @ Falk: kannst du für das PC-Programm noch einen Tarball und/oder ein Zip hinzufügen? @ branadic: Würdest du bitte mal die Befehle für octave posten, mit denen du die Bilder hinbekommst? Dann muss ich nicht die ganze Dokumentation durchwühlen. Gruß, Guido
Anbei die letzte Version des screenshot tool's fuer Windows (aus dem SVN Revision 173). Geht zusammen mit dem neusten build der FW Martin
Daniel H. schrieb: > Martin H. schrieb: >> [Downsampling] > > [Downsampling^2] > > Edit: Habe das Ticketsystem im Trac nach euren Wünschen eingestellt. > Sorry, hatte das total verpennt am WE. Danke! - Habe gerade mal Bugs/Feature-Requests gefiled (könnte jmd. - bei Gelegengheit - die Priorität von #8 (https://sourceforge.net/apps/trac/welecw2000a/ticket/8)) mal auf Minor setzen?) Frage: gibt es nicht auch eine 0.87 (habe die Bugs jetzt auf 0.86 gesetzt ;) Ich wüsste da noch einige nette Plugins für Trac - soll ich da mal 'ne Liste schicken? ;) Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN setzen (aber wie beschrieben, wenn Du möchtest ;)
So, ich habe jetzt die Visualisierung mit gnuplot hinbekommen und kann die Zacken live bestaunen. Ich habe mich schon immer gefragt, warum die Zeitbasis so verrückt verwendet wird und auch Hayo wollte da ja schon länger mal ran gehen. Vielleicht haben wir ja den Grund gefunden. wenn man von 20 Werten 19 wegwirft, sind ev. die Zacken verschwunden. Allerdings war die Vermutung, dass diese Zacken nichts mit der Offsetkorrektur zu tun haben imho korrekt, die sind viel zu stark. Sollen wir es mit Datenverwürfeln pobieren? Gruß, Guido
Hallo Guido, bin leider erst jetzt nach Hause gekommen und kann mich wieder anderen Dingen widmen... Nun, wenn es wirklich so ist, dass im Speicher bereits "gewürfelte", vorverarbeitete (Offsetkorrektur, Invertierung, Averaging) Daten liegen, dann könnte ein neues Würfeln eventuell den gewünschten Erfolg bringen :) Beste Grüße, branadic
> Ich wüsste da noch einige nette Plugins für Trac - soll ich > da mal 'ne Liste schicken? ;) Da muss ich mal schauen ob es mittlerweile möglich ist, Plugins zu installieren. Anfangs konnte man definitiv nix an der gehosteten App verstellen, aber seit einiger Zeit tauchen zumindest schonmal die Settings der trac.ini im Trac-Adminbereich auf. Evtl. hat SF.net jetzt ja auch 'ne Möglichkeit, Plugins nachzuinstallieren. Ich geb die Tage bescheid wenn ich mich in der SF.net-Doku umgesehen habe, obs geht oder nicht. > Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN > setzen (aber wie beschrieben, wenn Du möchtest ;) Hab dich mal in die Developer-Gruppe gesteckt.
Angehängte Dateien:
-
Vergleich_ASM_C.PNG
79 KB
Hallo Guido, der Jürgen hat ja schon mal ein paar Screenshots geliefert, viel interessanter ist aber ein direkter Vergleich der Daten im Speicher mit beiden Routinen. Das hab ich mal für 1GS / 500MS und 250MS durchgeführt. Das Ergebnis kann man dann oben sehen. (0.86beta) Schwinger gibt es bei beiden Methoden. Das heißt für mich, dass auch im Assemblercode die falschen Samples abgeholt werden. Beste Grüße, branadic
@branadic, guido Fuer die 500Ms Stoerung habe ich eine verwuerfelung gefunden: Original date; 12345678 zu 56127834 In Angang eine CVS Datei mit den 1. Kanal von branadic und den korrigierten Daten. Martin p.s. fuer die 250Ms Daten geht dieser Ansatz leider nicht!
Daniel H. schrieb: >> Ich wüsste da noch einige nette Plugins für Trac - soll ich >> da mal 'ne Liste schicken? ;) > > Da muss ich mal schauen ob es mittlerweile möglich ist, Plugins zu > installieren. Anfangs konnte man definitiv nix an der gehosteten App > verstellen, aber seit einiger Zeit tauchen zumindest schonmal die > Settings der trac.ini im Trac-Adminbereich auf. Evtl. hat SF.net jetzt > ja auch 'ne Möglichkeit, Plugins nachzuinstallieren. Ich geb die Tage > bescheid wenn ich mich in der SF.net-Doku umgesehen habe, obs geht oder > nicht. > Schau mal unter Admin, ob Du da "links" (in dem Reiter, wo Du auch Permissions, etc findest ;) - einen Punkt Plugins hast, dann sollte nach anclicken rechts auch ein Feld "Install Plugin" auftauchen ;) Vorschläge wären: TracFigure: https://www.selidor.net/trac/wiki/TracFigureMacro Einbau von Bildern TracIncludeMacro: http://trac-hacks.org/wiki/IncludeMacro Erlaubt Inhalte anderer URLS oder Trac-Objekte in's Wiki (auch Tickets) einzubinden TracMath: (eher schwierig, braucht u.a. Latex auf dem System) Latex-Formeln in Tickets und im Wiki TracTags: http://trac-hacks.org/wiki/TagsPlugin Erlaubt Tags zu Objekten im Trac, ähnlich den Kategorien bei MediaWiki ;) TracWikiGoodies: http://trac-hacks.org/wiki/WikiGoodiesPlugin Diverse HTML-Zeichen ;) siteupload: http://trac-hacks.org/wiki/SiteUploadPlugin Erlaubt das Hochladen von Dateien in htdocs - manchmal nett zum Verlinken ;) Irgendwo gibt es auch ein Plugin für GraphViz-Dateien ;) >> Daniel: wenn Du möchtest, kannst Du mich (rowue) auch auf TICKET_ADMIN >> setzen (aber wie beschrieben, wenn Du möchtest ;) > > Hab dich mal in die Developer-Gruppe gesteckt. Bedankt ;)
Martin H. schrieb: > @branadic, guido > > [Abtaststörung] Hmmmm .... könnte es Sinn machen (wegen der Linearität) ein Dreieck-Signal zu sampeln und keinen Sinus - da müsste sich aus dem Differentenquotient (doch einiges ablesen lassen ;) Grüße, rowue
Kurze Frage:
gibt es hier Widerspruch/Bedenken, die
BF.0.87
so wie
ScS.0.3
ScS.0.4
auch als Versionen aufzunehmen?
Grüße,
rowue
Angehängte Dateien:
Hallo Martin, sieht schon besser aus, scheint aber noch nicht komplett des Rätsels Lösung zu sein. Scheinbar ist immer noch eine systematische Vertauschung drin. (siehe Bild) @ Rolf Ist schwer, denn du musst bedenken, dass auch Rauschen ein Punkt ist. Solange jedoch eine Systematik in den Daten zu erkennen ist, kann es sich nicht um Rauschen handeln, mein ich. Beste Grüße, branadic
Rolf Würdemann schrieb: > Kurze Frage: > > gibt es hier Widerspruch/Bedenken, die > > BF.0.87 > > so wie > > ScS.0.3 > ScS.0.4 > > auch als Versionen aufzunehmen? Was meinst Du mit "als Versionen aufnehmen"? Falk
Hallo, so ganz überzeugt von Martins Verwürfelung bin ich noch nicht. Als Anhang einmal ein MATLAB Ausdruck von branadics original Daten- und darunter mit Martins Verwürfelung. Wesentlich besser, aber immer noch deutliche Ausreißer. Einen Test mit einem ordentlichen Rampensignal (relativ langsam im vgl. zur Timebase) hatte ich auch schon einmal angeregt, leider fehlt mir ein entsprechendes Testsignal. Ist euch auch schon aufgefallen das immer so ca. die ersten 50-100 Samples aus der csv. Datei absolut nicht zu gebrauchen sind? Liegt das am Export, oder liegen im Speicher tatsächlich anfangs nur fehlerhafte Daten? Gruß, brunowe
Rolf Würdemann schrieb: > Schau mal unter Admin, ob Du da "links" (in dem Reiter, wo Du auch > Permissions, etc findest ;) - einen Punkt Plugins hast, dann sollte > nach anclicken rechts auch ein Feld "Install Plugin" auftauchen ;) Nein, tut es nicht. Aber bisher bin ich auch vertrauter mit der manuellen Installation von Trac-Plugins. Aber wie gesagt - ich schaue mal.
Könnte Wittig versuchen, die ADCs softwareseitig / VHDL-seitig zu synchronisieren? Eigentlich würde ich ja Phasenanpassungen am Clocksignal dafür erwarten, aber vielleicht hatten die ja mal wieder komische Einfälle? Wenn sie es bei 1GSa eingerichtet hätten und dann die gleichen Korrekturen bei niedrigeren Sampleraten anwendet? Ihr kennt euch schon besser mit dem Gesamtpaket aus, könnte sowas dahinterstecken? Gruß Michael
Interessant an Martins Korrekturvorschlag ist, dass die Korrektur am Anfang der Samplereihe eher bescheidene Verbesserungen bringt, weiter hinten dagegen sehr gute. Plottet doch mal Samples 6000-7000. Sehr eigenartig.
Noch interessanter: der Bereich von 1000-2000, hier findet ein regelrechter Übergang statt.
Angehängte Dateien:
-
Korrektur.jpg
140 KB
Hier ist mal der Bereich der Samples 1000 bis 2000 zum Ansehen.
Falk Willberg schrieb: > Rolf Würdemann schrieb: >> Kurze Frage: >> >> gibt es hier Widerspruch/Bedenken, die >> >> BF.0.87 >> >> so wie >> >> ScS.0.3 >> ScS.0.4 >> >> auch als Versionen aufzunehmen? > > Was meinst Du mit "als Versionen aufnehmen"? im Ticket-System kann man, neben der Software-Komponente (BlueFlash Firmware (NIOS), Screenshot Software (PC)) auch eine Version auswählen/anbieten. Bisher sind da die BF.0.80 - BF.0.87 drin, ich würde gerne noch die Screenshot-Versionen 0.3, 0.4 (0.5) und die BF.0.87 "anbieten" - Der Verweis auf die Version hilft etwas bei der Fehlersuche. > > Falk Grüße, rowue EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern nehmen.
Angehängte Dateien:
-
500MS.png
1,6 KB
Oh, da haben wir ja ein schönes Durcheinander. Vielleicht sollten wir uns erst mal auf Messvorschriften einigen. Dreiecksignal finde ich gut, Ramnpe wäre natürlich noch besser. Erstmal sollten wir rausbekommen, ob alle Oszis den selben Versatz haben. Bei mir ist die Zweiergruppierung von Martin nicht optimal (s.A.). Michaels Beitrag klingt auch sehr interessant, da wäre ich nicht drauf gekommen. Die ersten irgendwas Samples sind auch bei mir voll daneben. Auch dafür gibt es keine plausible Erklärung. Und die Bereiche unterhalb 250 MS/s fehlen auch noch. Viel zu tun, Guido
Rolf Würdemann schrieb: > Falk Willberg schrieb: >> Rolf Würdemann schrieb: >>> Kurze Frage: >>> >>> gibt es hier Widerspruch/Bedenken, die >>> >>> BF.0.87 >>> >>> so wie >>> >>> ScS.0.3 >>> ScS.0.4 >>> >>> auch als Versionen aufzunehmen? >> >> Was meinst Du mit "als Versionen aufnehmen"? > > im Ticket-System kann man, neben der Software-Komponente > (BlueFlash Firmware (NIOS), Screenshot Software (PC)) > auch eine Version auswählen/anbieten. > > Bisher sind da die BF.0.80 - BF.0.87 drin, ich würde > gerne noch die Screenshot-Versionen 0.3, 0.4 (0.5) > und die BF.0.87 "anbieten" - Der Verweis auf die Version > hilft etwas bei der Fehlersuche. Wo finde ich das nun wieder ;-) Mein Vorschlag: Die hier gepostete BF.0.87 habe ich im SVN mit den Änderungen für den ScreenShot zusammengeführt. Sollten wir die nicht 0.88 nennen? Dann halte ich es für eine gute Idee, die Screenshot-Version an die zugehörige Firmware-Version anzupassen. Das wäre jetzt also Screenshot 0.88. Vielleicht kannst Du noch warten, bis jemand bestätigt, daß Screenshot auch unter Windows läuft und tatsächlich zur Firmware aus dem SVN passt... > EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern > nehmen. SchirmAuszug ist auch nicht politisch korrekt ;-) Falk P.S.: irc.freenode.org:6667 #welec ist ziemlich verwaist. P.P.S.: Wie wäre es mal mit Skype? Meine Nummer ist Falk-Willberg P.P.P.S.: Heute nicht mehr ;-)
Haaar Falk,
> Sollten wir die nicht 0.88 nennen?
bedeutet das neuen Checkout und neue Bookmarks? Da kann man schon die
Lust verlieren. Oder bleibt im trunk alles beim alten?
Gruß, Guido
Guido schrieb: > Haaar Falk, > >> Sollten wir die nicht 0.88 nennen? > > bedeutet das neuen Checkout und neue Bookmarks? Nein. > Da kann man schon die Lust verlieren. Nimm vi, da hast Du keinen Ärger mit Bookmarks ;-) > Oder bleibt im trunk alles beim alten? Vorläufig ja. Solange die Struktur nicht wieder geändert wird, sollten die Änderungen im Rahmen bleiben. Falk
Hallo Guido, klar können wir uns auf ein gemeinsames Messsignal einigen. Bis 10MHz kann ich zumindest mit einem Dreiecksignal dienen. Rampe habe ich nicht, ansonsten stehen mir nur Sinus und Rechteck noch zur Verfügung. Ich muss ehrlich gestehen, dass mir nicht ganz klar ist, wie eine solche Synchronisation funktionieren sollte. Dazu müsste ja irgendein Synchronisationssignal, auf das man "triggern" könnte, von den ADCs zurück zum FPGA kommen. Ansonsten ist es doch schön zu sehen, dass sich hier was auch ohne Hayo bewegen kann :) Auch wenn eine gewisse Systematik bei der ADC-Nicht-Reihenfolge drin zu sein scheint, so könnte man doch den Eindruck gewinnen, dass irgendwie eine Form von rand(ReadADC) durchgeführt wird. Ich bin gespannt, was sich auf dem Gebiet tut. Schade nur, dass so viele scheinbar Bilder schauen, sich aber nicht dazu äußern. Seid ihr schüchtern? Beste Grüße, branadic
Nur mal so als Idee: Die Offsetkorrektur der einzelnen ADCs mit Absicht und deutlich verhageln und dann einfach kein Signal aufnehmen. Also z.B. ADC1 + 50, ADC2 +100, ADC3 -50, ADC4 -100. Da sollte man schön erkennen, wann welcher ADC im Speicher liegt.
Hallo branadic, wenn wir erstmal untereinander vergleichen, hoffe ich, dass es kein rand(ADC) ist. Eine Systematik muss schon her, sonst bleibt es wie bei Wittig: alle unangenehmen Werte werden schlicht ausgeblendet. Heute hat wieder ein potentieller Mitstreiter aufgegeben, hat bei ebay 202 Eur für sein 2022A bekommen. Vllt. haben wir damit ja einen neuen Mitentwickler gewonnen. :-) Gruß, Guido
@ Karl: wenn die Werte erstmal im Speicher sind, ist das kein Problem mehr. Ab da hat Hayo ja die ganze Sache entwickelt. Was vorher passiert kriegen wir halt nur sehr schwer raus (TrialAndError). Gruß, Guido
Ach so, die Offsetkorrektur geschieht rein in SW? Na dann vergesst das gleich wieder...
branadic schrieb: > [Martin ...] > > @ Rolf > Ist schwer, denn du musst bedenken, dass auch Rauschen ein Punkt ist. > Solange jedoch eine Systematik in den Daten zu erkennen ist, kann es > sich nicht um Rauschen handeln, mein ich. > Naja, unserer Fehler sticht ja aus dem Rauschen raus, sonst würden wir ihn nicht wahrnehmen ;) Ich habe mir die Daten eben mit einem - nennen wir es mal Dreieckssignal - angeschaut und wollte mir gerade etwas Statistik geben, als mir eine bessere Idee kam .... * Wir nehmen ein Signal mit einer steigenden Flanke, ob Sägezahn, Rechteck, Dreieck, Sinus oder was uns auch immer einfällt ist dabei (fast) egal * Wir stellen den Vorverstärker des DSO so ein, dass dieser übersteuert wird, lediglich 15 Messpunkte des Signals müssen im entsprechenden Messbereich des DSO liegen. * Von diesen 15 Messpunkten nehmen wir den, der Modulo acht null ergibt und die nächsten sieben Kollegen. Diese nach Wert geordnet sollten die Abtastfolge ergeben ;) Btw: haben wir vier oder acht ADC's/Kanal? Ich ging immer von vier aus ... > Beste Grüße, branadic Grüße, rowue
Angehängte Dateien:
-
Testsignal.png
5,2 KB
Ich habe jetzt mal mit dem o.g. System gespielt. Das Testsignal ist als
png beigefügt, die Testdateien kommen in den nächsten Einträgen (ich
liebe Trac ;).
Die Anstiegsrate beträgt 3,614 mV/ns.
Als Scanning-Order ergibt sich hieraus für
* 250Ms/sec: 2 + n*(34127856) (screenshot-0090.csv) 100mV/div
* 500Ms/sec: 4 + n*(56127834) (screenshot-0084.csv) 50mV/div
Interessant wäre jetzt eine zweite Messung, die diese Daten bestätigt.
Auffällig ist das paarweise Auftreten der Messwerte. Hier könnte sich
eine interessante Möglichkeit der Mittelwertbildung aufzeugen.
(Merken: mal schauen, wieviele Werte sich im Anstiegsbereich befinden
und ob dies dem Erwartungswert (g) entspricht ;)
Grüße,
n8,
rowue
Falk Willberg schrieb: > Rolf Würdemann schrieb: >> Falk Willberg schrieb: >>> Rolf Würdemann schrieb: >>>> Kurze Frage: >>>> >>>> [...] > > Wo finde ich das nun wieder ;-) In der Maske, wenn Du beim Trac 'nen Ticket eintütest ;) Oder im Admin-Menue unter Ticket - Versions ;) > > Mein Vorschlag: Die hier gepostete BF.0.87 habe ich im SVN mit den > Änderungen für den ScreenShot zusammengeführt. Sollten wir die nicht > 0.88 nennen? > Hmmja - als Tag haben wir derzeit -0.87 ;) - Mit der 0.88 würde ich noch etwas warten - da wurden ja einige Bugs gefiled, und der eine oder andere davon könnte einfach zu beheben sein ;) Wir wollen Versionsnummern ja nicht inflationär gebrauchen ;) > Dann halte ich es für eine gute Idee, die Screenshot-Version an die > zugehörige Firmware-Version anzupassen. Das wäre jetzt also Screenshot > 0.88. > Wer ist für die Namensgebung der Screenshot-Versionen verantwortlich? Aber stimmt - da die anscheinend eng an die Firmware gebunden sind, wäre eine direkte Kopplung sicher sinnvoll ;) > Vielleicht kannst Du noch warten, bis jemand bestätigt, daß Screenshot > auch unter Windows läuft und tatsächlich zur Firmware aus dem SVN > passt... > No Prob ;) >> EDIT: und "SS" möchte ich als Kürzel für den Screenshot nur ungern >> nehmen. > > SchirmAuszug ist auch nicht politisch korrekt ;-) Siehe Congress-Centrum ;) (CCH ;) > > Falk > P.S.: irc.freenode.org:6667 #welec ist ziemlich verwaist. > P.P.S.: Wie wäre es mal mit Skype? Meine Nummer ist Falk-Willberg > P.P.P.S.: Heute nicht mehr ;-) Wenn Du im Irc bist, kannste mich per /msg rowue ansprechen - ich schau dann mal rüber ;) (wenn ich an der Konsole bin ;) Sonst finde ich auch XMPP/Jabber nicht schlecht ;) N8 ;)
Rolf Würdemann schrieb: > Ich habe jetzt mal mit dem o.g. System gespielt. Das Testsignal ist als > png beigefügt, die Testdateien kommen in den nächsten Einträgen (ich > liebe Trac ;). > > Die Anstiegsrate beträgt 3,614 mV/ns. > > Als Scanning-Order ergibt sich hieraus für > > * 250Ms/sec: 2 + n*(34127856) (screenshot-0090.csv) 100mV/div > * 500Ms/sec: 4 + n*(56127834) (screenshot-0084.csv) 50mV/div > [...] 2 und 4 bedeuted hierbei einen Offset un 2 resp. 4 Bytes am Anfang der Datei ;)
So langsam wird das doch! Ich muss leider zugeben, dass ich nicht ganz kapiere, was mir deine csv Dateien sagen, Rolf. Kannst du dazu noch ein paar Worte sagen? Ansonsten scheint deine Nachtschicht ja recht produktiv gewesen zu sein! Gruß Michael
branadic schrieb: > Hallo Hayo, > > ich hätte einen Punkt für die Wishlist: > > Eine Kombination aus Roll und Shiftmode. Ist für den Urlaub notiert, ebenso die anderen Fehlermeldungen die seit der letzten Woche hier gepostet wurden. Am Sonnabend geht es los - das Oszi fährt mit :-) Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da wohl eine Verschiebung der Codebasis geben. Wie wir das dann abgleichen, können wir ja dann Ende August klären. Gruß Hayo
Hayo W. schrieb: ... > Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da > wohl eine Verschiebung der Codebasis geben. Wirst Du auf Basis der letzten Subversion-Version weitermachen? > Wie wir das dann abgleichen, können wir ja dann Ende August klären. Ich weise auf Beitrag "SVN wieder aktuell" hin ;-) Schönen Urlaub, Falk
Gönn' dir auf jeden Fall einen schönen Urlaub - und bevor es Krach mit der Frau gibt...wenn die Bugs zwei Wochen später gefixed werden, wird das auch keinen umbringen. Gruß, Michael
Michael H. schrieb: > So langsam wird das doch! > Ich muss leider zugeben, dass ich nicht ganz kapiere, was mir deine csv > Dateien sagen, Rolf. Kannst du dazu noch ein paar Worte sagen? Die csv Dateien sind Dateien der Messung des in dem Bild dargestellten Signals mit den angegebenen Sampleraten. Innerhalb dieser Dateien sucht mensch sich nun eine steigende Flanke und notiert sich - beginnend mit einem durch acht teilbaren Index - 24 Messwerte, welche mensch in achter Gruppen zusammenfasst - Es ergibt sich eine 8x3 Matrix. z.B.: 25 77 120 30 81 125 63 106 151 63 105 151 88 132 175 91 135 179 118 162 208 117 161 207 (aus der 500MSa/s-Datei, screenshot-0084.csv) Innerhalb dieser Gruppen sucht mensch sich nun Zahlengruppen, deren Werte innerhalb eines Intervalls liegen. Dies ergibt den Offset 2 oder 4. Die acht Zahlen innerhalb des Intervalls ordnet man nun entsprechend ihrer Größe an (je nach dem, ob steigende oder fallende Flanke). Aus der Anordnung der Indexe ergibt sich die Reihenfolge der Abtastungen. Interessant ist hierbei, dass je zwei Werte sehr dicht beieinander liegen (ein Paar bilden). Es hat den Anschein, als ob hier zweimal direkt hintereinander abgetastet wird. Hier könnte es interessant sein, aus dem jeweiligen Mittelwert der Paare und den bekannten Daten (Signalanstiegszeit, Wertebereich des ADC und Auflösungsfaktor) die (gemittelte) Zeit zwischen zwei Abtastgruppen zu ermitteln. > Ansonsten scheint deine Nachtschicht ja recht produktiv gewesen zu sein! Danke! - Wenn ich das wissenschaftlich aufbereiten soll, sagt Bescheid ;) > > Gruß > Michael Grüße, rowue
Hayo W. schrieb: > branadic schrieb: >> Hallo Hayo, >> >> [Wishlist] >> >> Eine Kombination aus Roll und Shiftmode. > > Ist für den Urlaub notiert, ebenso die anderen Fehlermeldungen die seit > der letzten Woche hier gepostet wurden. Am Sonnabend geht es los - das > Oszi fährt mit :-) Für uns schön (dass das Oszi mitkommt) aber: wolltest Du Urlaub machen oder arbeiten? ;) Ansonsten: hast Du Dir auch die Tickets im Trac mal angesehen? Ich hatte da noch die eine oder andere Kleinigkeit (Darstellungs- fehler, etc) "eingetütet" ;) EDIT: http://sourceforge.net/apps/trac/welecw2000a/report/1 > > Da mir die Abgleichmöglichkeit mit dem SFN unterwegs fehlt wird es da > wohl eine Verschiebung der Codebasis geben. Wie wir das dann abgleichen, > können wir ja dann Ende August klären. Also: Wenn Du jetzt auf Basis des svn weiterarbeitest, wollte das nicht das Problem sein, ansonsten verweise ich auf den Kommentar von Falk ;) (Wobei Du ja bisher mit Abstand das meiste gemacht hast ;) > > Gruß Hayo Grüße, rowue
Michael H. schrieb: > Gönn' dir auf jeden Fall einen schönen Urlaub - und bevor es Krach mit > der Frau gibt...wenn die Bugs zwei Wochen später gefixed werden, wird > das auch keinen umbringen. Keine Angst, Urlaub geht vor. Aber meine Frau hat einige Bücher mit im Gepäck, das ist dann der Moment in dem das Oszi ins Spiel kommt :-) @Falk Die Basis ist (bzw. war) die neu aufgeteilte Version, die ich als Vorschlag für das SFN gepostet hatte (ich glaube 0.87). Der momentane Stand weicht ohnehin schon von der aktuellen Version ab, da ich in der Zwischenzeit einige Änderungen an der Screenshotfunktion vorgenommen habe und auch den Rauschfilter erweitert bzw. verbessert habe. Wie schon gesagt, wir müssen dann mal abstimmen, was davon in die SFN-Version einfließen soll. Gruß Hayo
Rolf Würdemann schrieb: > > Ansonsten: hast Du Dir auch die Tickets im Trac mal angesehen? > Ich hatte da noch die eine oder andere Kleinigkeit (Darstellungs- > fehler, etc) "eingetütet" ;) > Nein, das hatte ich noch nicht auf dem Radar. Danke für den Tip. Da werde ich gleich mal meine Liste erweitern. Allerdings sehe ich, dass einige Punkte, die ich hier im Forum eingesammelt habe da auch auftauchen. Gruß Hayo
Hayo W. schrieb: ... > Die Basis ist (bzw. war) die neu aufgeteilte Version, die ich als > Vorschlag für das SFN gepostet hatte (ich glaube 0.87). Der momentane > Stand weicht ohnehin schon von der aktuellen Version ab, da ich in der > Zwischenzeit einige Änderungen an der Screenshotfunktion vorgenommen > habe und auch den Rauschfilter erweitert bzw. verbessert habe. > > Wie schon gesagt, wir müssen dann mal abstimmen, was davon in die > SFN-Version einfließen soll. Ich wünsche Dir viel Spaß dabei :-( Ich mache das nicht nochmal. Falk
Jürgen schrieb: >>Die müßte mal jemand komplilieren.... >>Falk > > Eben! Ich habe mal w2000a-screenshot.exe kompiliert. Ob die funktioniert, weiß ich nicht. Wenn das mal jemand (mit der FW aus dem SVN) testen könnte? Falk
Vergrault hier bloß nicht das Zugpferd des ganzen Firmwareprojekts! Vielleicht ist Hayo (wie mir) nicht klar, warum es so einen Aufwand macht, die Änderungen einzupflegen. Generell ist es übrigens etwas problematisch für Leute die der Software nicht so nahe stehen (damit meine ich mich), das alles nachzuvollziehen. Trunk? Für mich heißt das Kofferraum... Comitted? Was denn, ein Verbrechen? Gruß Michael
@Falk & Daniel Ich glaube Ihr habt mich da missverstanden. Ich wollte nicht die jetzige Struktur oder den aktuellen Stand in Frage stellen, sondern meine Änderungen so in die SFN-Version (mittels SVN) integrieren, das nichts Vorhandenes durcheinander kommt, sondern nur Korrekturen oder Verbesserungen einfließen. Das erfordert zwar etwas Handarbeit meinerseits, sollte aber doch in Eurem Sinne sein oder? Gruß Hayo
Ach ja, der Grund für die Änderungen an der Screenshotfunktion waren unter anderem massive Fehler in der Bilddarstellung bei der 0.5 und Unregelmäßigkeiten bei der Übertragung der Daten. Weiterhin habe ich den Support für Schwarz/Weiß Screenshots rausgenommen und die Steuerung welcher Typ erzeugt werden soll (BMP, PNG, CSV, ASCII) komplett ins QP-Menü des Oszi verlagert, so dass das Screenshotprogramm nur noch mit dem Schnittstellenparameter gestartet werden muß. Diese Änderungen sind vorerst nur für mich selbst entstanden, und müssen nicht in die offizielle Version einfließen. Gruß Hayo
Now something completely different: Das Ticket Nr.16 - Dieses Verhalten hatten wir schon einmal hier im Forum diskutiert und waren zu dem Ergebnis gekommen, dass das so korrekt ist. Im "Normal" Triggermodus hört die Signalverarbeitung auf sobald der Trigger nicht mehr auslöst. Nur im "Auto" Modus läuft er auch dann weiter. Das Ticket wäre demnach eigentlich keines. Oder sehe ich das falsch? Hayo
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.