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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Odic (Gast)


Lesenswert?

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.

von Odic (Gast)


Lesenswert?

Ups... hat sich überschnitten. odic ist und bleibt odic.... auch unter 
SF. ;-)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Odic (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Daniel G. (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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.

von Michael H. (stronzo83)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Na denn, willkommen in der Gemeinde und viel Spaß mit dem neuen 
Spielzeug.

Gruß Hayo

von Michael H. (stronzo83)


Lesenswert?

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

von Daniel G. (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Michael H. (stronzo83)


Angehängte Dateien:

Lesenswert?

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

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Michael H.,

das ist korrekt. Nach Änderung der Horizontalposition sieht der 
Screenshot bescheiden aus. Anbei das Bilder vorher.

Gruß Jürgen

von Michael H. (stronzo83)


Angehängte Dateien:

Lesenswert?

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

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

Und hier danach!

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

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?

von Amazz (Gast)


Angehängte Dateien:

Lesenswert?

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!

von Michael H. (stronzo83)


Lesenswert?

Du musst einfach zweimal kurz hintereinander Quickprint drücken, dann 
sollte es klappen.

Gruß
Michael

von Amazz (Gast)


Lesenswert?

mhh, dann kommen nur noch schwarze bilder raus, ohne graue balken.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Amazz (Gast)


Lesenswert?

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!

von Bernd O. (bitshifter)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Daniel G. (Gast)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von egberto (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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.

von Niklas O. (nevm)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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)

von Michael H. (stronzo83)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Michael H. (stronzo83)


Angehängte Dateien:

Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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? =)

von branadic (Gast)


Lesenswert?

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)

von Michael H. (stronzo83)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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.

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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?

von branadic (Gast)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Sebastian B. (basti84)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

Hallo Guido,

läuft denn diese TomCat denn mit der aktuellen Screenshot.exe?

Gruß, branadic

von Guido (Gast)


Lesenswert?

Nö,

da war die Basis die 0.68 wenn ich mich recht entsinne.

Gruß, Guido

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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.

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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.

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

@ 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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Jürgen (Gast)


Lesenswert?

@ 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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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 )

von Cra Z. (crazor)


Lesenswert?

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.

von branadic (Gast)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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?

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

Achso,

mit der FW hat das garnichts zu tun. Da werden nur die
Daten im FIFO abgeholt und im RAM abgelegt.

von branadic (Gast)


Lesenswert?

@ 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

von branadic (Gast)


Lesenswert?

@ 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

von Guido (Gast)


Lesenswert?

@ 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

von Michael H. (stronzo83)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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/

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Remo (Gast)


Lesenswert?

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.

von Jürgen (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Remo (Gast)


Lesenswert?

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.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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.

von Martin H. (martinh)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

... und hier die entsprechende CSV Datei dazu.

Was ist da passiert? Hab ich irgendwas nicht mitbekommen?

Gruß, brunowe

von Cra Z. (crazor)


Lesenswert?

Das Format ist:
Ch1;Ch2;Ch3;Ch4

Die Werte der verschiedenen ADC kommen also zeilenweise. Zumindest habe 
ich das bisher so verstanden!

von Guido (Gast)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

@branadic,

So nen Oszi habe ich leider auch nicht, dafuer aber einen recht guten 
Frequenz Zaehler ;)

Martin

von Jürgen (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

>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

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

Und die Version mit C-Routinen.

Gruß
Jürgen

von Guido (Gast)


Lesenswert?

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

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

Anbei die letzte Version des screenshot tool's fuer Windows (aus dem SVN 
Revision 173). Geht zusammen mit dem neusten build der FW

Martin

von Rolf W. (rowue)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von branadic (Gast)



Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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.

von Michael H. (stronzo83)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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.

von Michael H. (stronzo83)


Lesenswert?

Noch interessanter: der Bereich von 1000-2000, hier findet ein 
regelrechter Übergang statt.

von Michael H. (stronzo83)


Angehängte Dateien:

Lesenswert?

Hier ist mal der Bereich der Samples 1000 bis 2000 zum Ansehen.

von Rolf W. (rowue)


Lesenswert?

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.

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von branadic (Gast)


Lesenswert?

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

von Karl (Gast)


Lesenswert?

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.

von Guido (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

@ 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

von Karl (Gast)


Lesenswert?

Ach so, die Offsetkorrektur geschieht rein in SW? Na dann vergesst das 
gleich wieder...

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

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

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

screenshot-0084.csv

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

screenshot-0090.csv

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Rolf W. (rowue)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

@hayo
bye bye übersichtlichkeit :(

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.