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


von Blue F. (blueflash)


Lesenswert?

Hallo werte W20xxA Besitzer und Interessierte!

Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread

>Wittig(welec) Oszilloskop firmware problem<

eröffnet.

Für Hardwarethemen wird es einen eigenen Thread geben:

>Wittig(welec) DSO W20xxA Hardware>



Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

So hier noch eine kleine Wortliste damit der Thread auch von Google 
gefunden wird:

DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A 
W2024A

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

nur um sicher zu gehen: Du benutzt den Bresenham nur im Notfall? Da 
lohnt
meist eien Fallunterscheidung: horizontal, vertikal und diagonal direkt,
nur sonst Bresenham.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido wrote:
> Hallo Hayo,
>
> nur um sicher zu gehen: Du benutzt den Bresenham nur im Notfall? Da
> lohnt
> meist eien Fallunterscheidung: horizontal, vertikal und diagonal direkt,
> nur sonst Bresenham.
>
> Gruß, Guido

Hi Guido,

ja genauso hab ich es implementiert. Läuft ca. 10 mal schneller als die 
alte Implementierung von WELEC. Zur Zeit teste ich noch ob auch alles 
fehlerfrei gezeichnet wird, aber bislang sieht alles gut aus.

Gruß Hayo

von Broma.es (Gast)


Lesenswert?

Sorry wegen schlechtem deutsch, bin Spanier und beobachte Welec
Entwicklung.
Habe diesen LInk gefunden:
http://apps.sourceforge.net/phpbb/welecw2000a/view...
das ist gute Nachricht für alles Welec Oscilloscope Besitzer!
Hoffe mit euch auf gute Fortschritte bei Entwicklung-

Grusse
Broma

von Broma.es (Gast)


Lesenswert?

Sorry about this- i don't know why no funciona..
correct Link:
http://apps.sourceforge.net/phpbb/welecw2000a/viewtopic.php?f=8&t=10

von Bernhard M. (boregard)


Lesenswert?

Broma.es wrote:
> Sorry about this- i don't know why no funciona..
> correct Link:
> http://apps.sourceforge.net/phpbb/welecw2000a/viewtopic.php?f=8&t=10

na, bei dem Datum ;-))

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hab mich nochmal aufgerafft und alles heute fertiggemacht. Die 
Liesmich gibts jetzt auch in Englisch und der Updater ist auch mit 
dabei. Wie immer die Liesmich beachten. Wesentliche Neuerung ist die 
XY-Funktion.

Das File wird es auch auf Google Groups und SFN geben.

Viel Spaß

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

hab deine neue FW bereits in mein Oszi geladen und schaue mir gerade die 
XY-Funktion an.
Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser 
Einstellung die Lineare Interpolation zwischen den Messwerten 
abzustellen und nur die reinen Messwerte darzustellen? Würde die Anzeige 
schon deutlich verbessern.
Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe, 
der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie 
es ausschaut auch gleich der allererste dargestellte Messpunkt.

Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will 
heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe 
Sinussignal anlege, dass die beiden Signale auf dem Display exakt 
übereinander liegen. Das tun sie leider nicht, weswegen dann in der 
x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt 
wird.
Liegt die Ursache hierfür im FPGA-Design oder in der FW?

Zur Mathe-Funktion:
Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset 
nicht die LED am Verstell-Encoder leuchtet :)

Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale 
irgendwie Hieroglyphen im Scale-Button angezeigt werden.
Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von 
Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.

Soweit an dieser Stelle die Kritik.
Ansonsten schon ein paar schöne Fortschritte in deiner FW.

Gruß, branadic

von branadic (Gast)


Lesenswert?

Hallo Hayo,

was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen 
ist:

Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der 
Kanal-Zahl drauf.
Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn 
ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales 
auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich 
praktische Funktion.
Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen 
möchte und anschließend dessen passive Demodulation auf dem nächsten 
Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das 
demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen 
Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol 
ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in 
derer die einzelnen Kanäle angezeigt werden.

Ließe sich sowas in deiner FW integrieren?

Gruß, branadic

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

branadic wrote:

> Dazu hätt ich nun mal eine Frage, besteht die Möglichkeit in dieser
> Einstellung die Lineare Interpolation zwischen den Messwerten
> abzustellen und nur die reinen Messwerte darzustellen?

Hallo Branadic, danke für die prompte Reaktion. Bin leider erst heute 
dazu gekommen mir das anzusehen. Wenn ich Dich richtig verstanden habe 
meinst Du die Umschaltung zwischen Vektordarstellung und reine 
Punktdarstellung? Die Umschaltung erfolgt wie beim normalen Zeitsignal 
über das "Display" Menü mit der Taste Vectors.


> Dann ist mir aufgefallen, dass ich immer einen einzelnen Messwerte habe,
> der um die Nulllage herum liegt und das Bild verfälscht. Die ist so wie
> es ausschaut auch gleich der allererste dargestellte Messpunkt.

Das konnte ich leider bei mir nicht nachvollziehen. Mach doch mal ein 
Bild, damit ich mir was darunter vorstellen kann.

> Leider werden die Messdaten noch nicht korrekt wiedergegeben. Will
> heißen: Ich würde erwarten, wenn ich an zwei Tastköpfen ein und dasselbe
> Sinussignal anlege, dass die beiden Signale auf dem Display exakt
> übereinander liegen. Das tun sie leider nicht, weswegen dann in der
> x-y-Darstellung auch keine 45°-Schräge sondern eine Ellipse angezeigt
> wird.
> Liegt die Ursache hierfür im FPGA-Design oder in der FW?

Kann es sein, dass Du nicht mit einem 50 Ohm abgeschlossenen Kabel 
gemessen hast? Offenbar hast Du Dir da irgendwo eine Phasenverschiebung 
eingefangen. Bei mir gibt es eine Diagonale (siehe Bild).

> zur Mathe-Funktion:
> Mir ist aufgefallen, dass bei den Einstellungen von Amplitude und Offset
> nicht die LED am Verstell-Encoder leuchtet :)

Ja, das ist mir auch schon aufgefallen, allerdings tritt das nicht immer 
auf und war auch schon vorher so bei der originalen FW. Da ist wohl ein 
Fehler in der Menüführung.

> Dann ist mir aufgefallen, dass unter den Setting von CH1*CH2 bei Scale
> irgendwie Hieroglyphen im Scale-Button angezeigt werden.

Muß ich mal checken.

> Der Offset steht in allen Funktionen aus irgendeinem Grund nicht von
> Haus aus auf 0V, das wäre sicherlich auch noch erstrebenswert.

Das liegt an den Konfigdaten die beim Start geladen werden (Bei Dir sind 
noch die Konfigbereiche noch original). Das ist bei Welec die 
Originaleinstellung. Bei mir ist das längst anders eingestellt. Ich hab 
meine neuen Parameter noch nicht im Konfigbereich untergebracht, muß ich 
demnächst mal machen.


> Soweit an dieser Stelle die Kritik.
> Ansonsten schon ein paar schöne Fortschritte in deiner FW.

Danke und Gruß

Hayo

von Blue F. (blueflash)


Lesenswert?

branadic wrote:
> Hallo Hayo,
>
> was mir gerade so beim Herumspielen mit deiner FW ins Auge gestochen
> ist:
>
> Für jeden Kanal gibt es ja den Kanalauswahlbutton, der Knopf mit der
> Kanal-Zahl drauf.
> Von dem Tek mit dem ich beinah täglich arbeite bin ich es gewohnt, wenn
> ich diesen Kanalauswahlbutton drücke erscheint das Signal dieses Kanales
> auf dem Display im Vordergrund, eine wie ich finde wirklich unglaublich
> praktische Funktion.
> Ist zum Beispiel wichtig, wenn ich mir ein moduliertes Signal anschauen
> möchte und anschließend dessen passive Demodulation auf dem nächsten
> Kanal. Aufgrund des zwangsläufigen Spannungsabfalls verschwindet das
> demodulierte Signal nun hinter dem Signal des ersten Kanals bei gleichen
> Scale-Einstellungen und gleichem Offset. Mit dem Kanalauswahlbutton hol
> ich es mir einfach in den Vordergrund bzw. bestimme die Reihenfolge in
> derer die einzelnen Kanäle angezeigt werden.
>
> Ließe sich sowas in deiner FW integrieren?

Um sicher zu gehen dass ich Dich richtig verstanden habe (kenne diese 
Funktion bislang nicht): Mit Vordergrund/Hintergrund meinst Du bei 
Signalen die direkt übereinander liegen, welches beim Zeichnen "oben" 
und welches "unten" liegt bzw. welches Signal von welchem verdeckt wird?

Falls ich das so richtig verstanden habe, -> ja das sollte sich umsetzen 
lassen. Hört sich ganz nützlich an.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,
jetz habe ich mich auch mal an deine Beta rangetraut. Folgendes ist mir 
aufgefallen:

Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön 
zu sehen an einem "übersteuerten" Sinus.

Die Quick-Measures funktionieren nicht richtig.

Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die 
Nulllinien am oberen Bildschirmrand.

Die Multiplikation sieht komisch aus und scheint einen großen negativen 
Offset zu haben. Man muss einen positiven Offset einstellen, um das 
Signal überhaupt auf den Schirm zu kriegen.
Die Eingangskopplung stand natürlich auf AC.

Beim Versuch die Daten auf den PC zu übertragen, bleibt der 
Fortschrittsbalken in der Welec Software am Ende stehen und es passiert 
garnichts mehr.

Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der 
selbe den branadic meint.

Das symmetrische Raster ist wunderschön ;-)

Mfg,
Kurt

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

das mit dem Umschalten der Vectordarstellung hatte ich irgendwie 
verdrängt :)

Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen. 
Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.
Hab eine schöne Phasenverschiebung zwischen Kanal 1 und Kanal 2, obwohl 
sie beide am gleichen Ausgang vom DDS-Board hängen. Ich seh da jetzt 
ehrlich gesagt keinen Messfehler?
Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale 
schön voneinander phasenverschoben liegen, zum Anderen gleich noch den 
Ausreißer.

Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die 
zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht 
überschrieben.

Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität 
auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf 
auf dem Welec.

Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab 
ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die 
Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen wrote:

> Das Signal wird nicht bis zum unteren Bildschirmrand gezeichnet. Schön
> zu sehen an einem "übersteuerten" Sinus.

Ja, Fehler ist bekannt  -> hab ich in der readme beschrieben, nach der 
Ursache suche ich noch, passiert irgendwo beim Zusammenmischen der 
Grafiklayer.

> Die Quick-Measures funktionieren nicht richtig.

Hab ich befürchtet, da hier die Zerolinie völlig verschoben ist durch 
meine Änderungen -> muß ich noch machen

> Wenn man die Eingangskopplung der Kanäle auf GND schaltet, kleben die
> Nulllinien am oberen Bildschirmrand.

Oh, hatte ich ich noch garnicht bemerkt, ist das gleiche Problem wie bei 
Quickmeasure, werd ich bis zur nächsten Beta beseitigen.

> Die Multiplikation sieht komisch aus und scheint einen großen negativen
> Offset zu haben. Man muss einen positiven Offset einstellen, um das
> Signal überhaupt auf den Schirm zu kriegen.

Hier wirkt sich die Multiplikation sehr stark auf kleinste Abweichungen 
aus. Bei meinen bisherigen Testsignalen ist mir das nicht so extrem 
aufgefallen. Hab mal Dein Testsignal nachgestellt und muß Dir recht 
geben. Da muß ich mir nochmal was überlegen -> eine Idee hab ich schon.

> Beim Versuch die Daten auf den PC zu übertragen, bleibt der
> Fortschrittsbalken in der Welec Software am Ende stehen und es passiert
> garnichts mehr.

Die übertragung zum PC hab ich zur Zeit noch überhaupt nicht auf dem 
Radar, da ich davon ausgegangen bin, dass Falk hier dran ist. Allerdings 
hab ich da schon länger nichts mehr gehört. Muß ich aber erstmal hinten 
an stellen, da mir die anderen Funktionen erstmal wichtiger sind. 
Trotzdem Danke für den Hinweis.

> Beim XY ist auch auf beiden Kanälen ein negativer Offset. Vieleicht der
> selbe den branadic meint.

Konnte ich leider nicht nachvollziehen. Wie man an meinem Testsignal 
weiter oben sehen kann geht die Diagonale ziemlich genau durch den 
Nullpunkt. Wie groß ist denn Dein Offset und wie hast Du gemessen?

> Das symmetrische Raster ist wunderschön ;-)

Höre ich gerne...

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

branadic wrote:

> Ich messe übrigens nicht mit 50-Ohm-Kabeln sondern mit den Tastköpfen.
> Abgeschlossen ist das DDS-Board aber dennoch mit 50 Ohm.

Ich vermute, dass die Tastköpfe die Phasenverschiebung verursachen.

> Daher nun auch das Bild. Zum Einen siehst du wie die beiden Signale
> schön voneinander phasenverschoben liegen, zum Anderen gleich noch den
> Ausreißer.

Schicke Liss-Figur, hab ich bei mir leider nicht hingekriegt, da ich 
keine so schöne Phasenverschiebung produzieren konnte - muß ich mal mit 
den Tastköpfen probieren.

> Auf dem Bild von Kurt kannst du übrigens die Hieroglyphe sehen, die
> zieht sich dann (siehe mein Bild) in andere Menü's mit und wird nicht
> überschrieben.

Ist keine Hieroglyphe, sondern ein kleines Bild. Dachte das wäre so 
original. Keine Ahnung wo das herkommt, an der Stelle hab ich auch 
nichts verändert. Scheint noch ne Macke aus der 1.2 FW zu sein.
>
> Ansonsten hast du mich genau richtig verstanden, was die Signalpriorität
> auf dem Bildschirm angeht. Ich denke das ist eine nette Bereicherung auf
> auf dem Welec.

Kümmere ich mich drum

> Ist dein 4-Strahler heute eigentlich eingetroffen? Hin und wieder hab
> ich die Vermutung, dass einige vermeintliche Fehler in deiner FW auf die
> Tatsache zurückzuführen sind, dass ich hier noch den 2. FPGA drin habe.

Nein, Schande auch! Christian (hat im anderen Thread gepostet) hat seins 
schon - ich nicht, hmmm...
-> morgen bestimmt.

Dann werd ich da mal ein paar Vergleiche anstellen.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur 
am falschen Nullabgleich der Kanäle.
Jedoch funktionieren die Cursor hier nicht richtig.

Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht 
mit dem Raster überein.

von Guido (Gast)


Lesenswert?

So alle,

habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der
den mit einem SA o.ä. verwenden möchte? Lissajous ist ja ein schönes
Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.

@ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten
gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du 
denn
dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da
ziemlich ausgefuchste Algorithmen nötig sind.

[Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der
Horizontalen. [/Mecker:]

@ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei
niedrigen Frequenzen verursacht der Koppelkondensator so eine
Phasenverschiebung.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen wrote:
> Das mit dem Offset in der XY Darstellung nehme ich zurück. Das lag nur
> am falschen Nullabgleich der Kanäle.
> Jedoch funktionieren die Cursor hier nicht richtig.
>
> Und in der normalen Betriebsart stimmen die Anzeigen der Y-Cursor nicht
> mit dem Raster überein.

Cursor hab ich noch überhaupt nicht probiert, die müssen noch angepasst 
werden. Hatte erstmal mit der XY-Funktion und der Optimierung der line() 
Funktion alle hände voll zu tun. Wollte erstmal das Feedback zur reinen 
XY-Funktion abwarten bevor ich weitermache.

Das Gleiche gilt für die Cursor in der normalen Betriebsart.

Das Dumme ist, dass ich hier Korrekturen an Coding durchführe für die 
WELEC mehrere Jahre Entwicklungszeit hatte - dafür dass ich das nur 
nebenbei mache bin ich also recht schnell finde ich.

Nichtsdestotrotz bin ich guter Dinge, in erster Linie versuche mal die 
grundlegenden Funktionen benutzbar zu machen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Guido wrote:
> So alle,
>
> habe auch mal mit XY-Modus probiert. Bin ich eigentlich der Einzige, der
> den mit einem SA o.ä. verwenden möchte?

Was ist SA?

> Lissajous ist ja ein schönes
> Spielzeug aber dafür sind DSOs doch nicht wirklich gut geeignet.

Geht besser als mit meinem analogen 50MHz Oszi, das ist XY-Betrieb nur 
bis 100KHz spezifiziert, danach ist die interne Phasenverschiebung zu 
groß.

> @ Hayo: Die Darstellung im XY-Modus ist an der Mittelsenkrechten
> gespiegelt (Fotos mach ich später noch). Welche Y-Signale stellst du
> denn
> dar, alle passen ja wohl nicht auf den Schirm. Ich vermute, dass da
> ziemlich ausgefuchste Algorithmen nötig sind.

Wie meinst Du das mit den Y-Signalen?

> [Mecker:] Schönes Raster, aber mir fehlen echt die 2 Divisions in der
> Horizontalen. [/Mecker:]

Welche Division möchtest Du denn noch haben? Habe zum Vergleich nur mein 
analoges Oszi und da sieht es genauso aus. Ansonsten läßt sich das Grid 
über Terminal auch in die alte gepunktete Darstellung umschalten -> 
siehe readme

> @ branadic: Hast du vllt. den 2. Kanaleingang auf AC stehen? Bei
> niedrigen Frequenzen verursacht der Koppelkondensator so eine
> Phasenverschiebung.

 Das stimmt, das könnte sein...

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Guido

Ich habe mal die Sache mit dem spiegelverkehrten Signal um die vertikale 
Achse geprüft -> Du hast Recht, es ist verkehrt rum.

Muß also noch korrigiert werden. Ist in Arbeit...

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

hat etwas gedauert, aber ein Bild sagt mehr.....

Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein
TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses
Forums.

Zum Vergleich links die Aufnahme am TDS210, viel besser geht es
mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist
bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber
schwierig zu implementieren sein.

Für alle, die mit solchen Bildern nicht so firm sind: ganz links
der erste Peak ist die Nulllinie, die zur Einstellung des hor.
Offsets benutzt werden kann. Nach rechts geht es mit 50 MHZ/div
weiter. der nächste Peak ist das Nutzsignal bei 80 MHz. Dann
folgen die Oberwellen, wobei ein div einer Abschwächung um 20 dB
entspricht. Das ist meine eines Testsignal für das Welec, einstellbar
von 52 MHz bis 125 MHz, fast reiner Sinus.

Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.
Woher der "Rahmen" kommt ist mir unklar.

@ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird
ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären
horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder
her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,
da sich dieses mit einem Spannungsteiler lösen lässt.

Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht
vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?

Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich
von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde
darstellt wird das aber sinnlos. Da kann man einfacher einen
Frequenzzähler einsetzen.

Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen
merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir
kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung
ist aber immer nach dem Ausschalten weg.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Guido,
so, jetzt lass mich bitte nicht unwissend sterben...
Wozu brauchst du den XY Betrieb? Zur Spektralanalyse? Hmmm also das 
interessiert mich dann schon wie du das machst. Wenn ich das richtig 
verstanden habe führt dein TEK diese SA durch und du missbrauchst das 
Welec nur zur Anzeige des Ergebnisses- weil du dir davon eine bessere 
Darstellung versprichst?
Mal sehen wozu die eingebaute FFT im Stande ist, wenn diese einmal in HW 
implementiert ist... vielleicht verkaufst du dein TEK dann ja? Das TEK 
hat aber bestimmt eine wesentl. höhere Grenzfrequenz?

Meine Hauptanwendungen des XY -Betrieb sind:
Bestimmen von Frequenzbeziehungen- vor allem geringste Phasenjitter 
lassen sich so absolut präzise feststellen. Bei analogen Oszi's ist das 
allerdings  meist nur bis Frequenzen von ca. 1MHz möglich, da darüber 
die geräteinternen Phasenjitter zu groß werden.
Aber die wichtigste Anwendung ist die Aufnahme von Kennlinienfelder. 
Dioden, Transistoren u.v.m. lassen sich somit schnell und exakt in ihren 
elektr. Kenngrössen miteinander vergleichen.... Der XY-Betrieb ist damit 
weit mehr als nur eine Spielerei!

Gruß
brunowe

von branadic (Gast)


Lesenswert?

Hallo Hayo hallo Guido,

ich hatte beide Kanäle auf AC_Coupling. Witzigerweise habe ich diese 
Phasenverschiebung auch bei DC-Coupling.
Wäre zu prüfen, ob das durch die Tastköpfe selbst kommt oder noch eine 
andere Ursache hat.
Werd am Montag mal 50-Ohm-Kabel mitnehmen und den Versuch wiederholen.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Guido wrote:

> Mit SA meine ich einen Spektrumanalyzer, hier mein Stolz, ein
> TEK 1401A, bestimmt älter als die meisten Teilnehmer dieses
> Forums.
-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
Wußte garnicht das es damals schon sowas gab ;-)

> Zum Vergleich links die Aufnahme am TDS210, viel besser geht es
> mit einem analogen Oszi auch nicht. Die "Nachleuchtfunktion" ist
> bei dieser langen Aufzeichnungsdauer sehr hilfreich, könnte aber
> schwierig zu implementieren sein.

Sowas ähnliches wie die Nachleuchtfunktion gibt es am W20xx auch, nennt 
sich "Persist" im Display-Menü.

> Auf dem Welec ist das Bild seitenverkehrt, das Hayo ja schon im Griff.

Jupp, ist schon erledigt.

> @ Hayo: Denke einfach an die FFT: 100 MHZ bzw. 200 MHz mit 8 div wird
> ziemlich ungerade. Mir geht es mit 500 MHz genauso, deswegen wären
> horizontal 10 div (wie bei jedem Oszi) besser, Symmetrie hin oder
> her. Dass es dann mit den Spannungen ungerade wird ist kein Problem,
> da sich dieses mit einem Spannungsteiler lösen lässt.

Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu 
implementieren die auch nicht schlechter sein wird als beim TEK.
Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im 
XY-Modus hingekriegt hast -> sieht irgendwie cool aus

> Die Y-Signale: bei der Speichertiefe des Gerätes kann ich mir nicht
> vorstellen, dass du alle Werte zeichnest. Wie triffst du die Auswahl?

Korrekt, ich hatte die Auswahl zwischen wenigen Werten (schnell) und 
vielen Werten (langsam). Da die reale Speichertiefe je nach Timebase 
Zwischen 655 und 16K variiert, habe ich mich für die Darstellung der im 
Zeitbereich angezeigten 600 Punkte entschieden. Dann weiß man, dass man 
im XY-Betrieb genau das sieht was man vorher im Normalbetrieb 
eingestellt hat.

> Lissajous: Die einzige mir bekannte Nutzung dieser liegt im Abgleich
> von Oszillatoren. Mit einem DSO, das mir 1 bis 2 Bilder pro Sekunde
> darstellt wird das aber sinnlos. Da kann man einfacher einen
> Frequenzzähler einsetzen.

-> die Antwort hat Bruno schon gegeben...

> Was ich noch überhaupt nicht kapiere: kann das Gerät sich Einstellungen
> merken? Kann ich mir eigentlich nicht vorstellen (im FPGA). Aber mir
> kommt es bei der vertikalen Abschwächung so vor, die Offseteinstellung
> ist aber immer nach dem Ausschalten weg.

-> definitiv ja! Bei bestimmten Eingaben (z.B. Verstellung der Timebase) 
werden alle aktuellen Parameter ins Flash in den Konfigurationsbereich 
geschrieben (kann man bei meiner FW sehen wenn ein Terminalprogramm 
läuft). Allerdings muß ich zugeben, dass einige meiner neuen Parameter 
noch nicht gesichert werden, ist aber auch schon in Arbeit.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Eben habe ich mal diesen Phasenschieber zusammengelötet. Bei f0 macht er 
-90°. Aber durch ändern der Eingangsfrequenz ändert sich auch die 
Phasenverschiebung.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

So sieht es dann auf dem Oszi aus bei 33kHz, 66kHz und 16kHz.

von Blue F. (blueflash)


Lesenswert?

Hey, sehr schön, sowas hat mir als Bestätigung für die Funktion noch 
gefehlt. Mußte mich immer mit einer Mischung aus Sinus (Funkt. 
Generator) und Rechteck (Quarzoszillator) begnügen. Das entstehende 
Signal ist aber für Testzwecke eigentlich zu kompliziert. Daher ist das 
Bild sehr willkommen!

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Oder wer's einfacher haben will:
Passive Phasenschieberbrücke s.h. Bild

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

Kleiner Fehler im Bild: es existiert kein R2 ;) nur R4 :P

von Kurt B. (kurt)


Lesenswert?

Und es gibt leider keine Möglichkeit U2 zu messen wenn man gleichzeitig 
U1 messen möchte und/oder einen geerdeten Funktionsgenerator verwendet.

von Guido (Gast)


Lesenswert?

Hallo alle,

>Meine Hauptanwendungen des XY -Betrieb sind:
>Bestimmen von Frequenzbeziehungen- vor allem geringste Phasenjitter
>lassen sich so absolut präzise feststellen. Bei analogen Oszi's ist das
>allerdings  meist nur bis Frequenzen von ca. 1MHz möglich, da darüber
>die geräteinternen Phasenjitter zu groß werden.

Was aber am Analogteil liegt, der bei den Welecs sicher auch nicht
besser ist als bei einem analogen Oszi.

>Aber die wichtigste Anwendung ist die Aufnahme von Kennlinienfelder.
>Dioden, Transistoren u.v.m. lassen sich somit schnell und exakt in ihren
>elektr. Kenngrössen miteinander vergleichen.... Der XY-Betrieb ist damit
>weit mehr als nur eine Spielerei!

So sehe ich das auch, ein Wobbler oder SA verwendet den XY-Modus exakt
genauso.

>Nicht nötig, da ich gerade dabei bin eine Spectralanalyse (FFT) zu
>implementieren die auch nicht schlechter sein wird als beim TEK.

Vorsicht, da liegen Welten dazwischen. Die Grenzfrequenz des 1401A liegt
bei 500 MHz (sieht man ja auf dem Bild). Die Amplitudenauflösung bei 
über
70 dB. da kann das Welec niemals mithalten. Die Empfindlichkeit geht
soweit, dass ein Meter Draht am Eingang reichen um die UKW-Sender
sichtbar zu machen.

>-> Cool! Dann ist das Gerät also schon so um die 50 Jahre alt?
>Wußte garnicht das es damals schon sowas gab ;-)

Hallo hayo, dass das für dich nicht zutrifft habe ich mir schon gedacht.
Für mich übrigens auch nicht. Aber das Gerät ist rund 35 Jahre alt,
für die meisten Teilnehmer wird es also schon zutreffen.

>Allerdings bin ich ebenso wie Bruno neugierig wie Du die Darstellung im
>XY-Modus hingekriegt hast -> sieht irgendwie cool aus

Aber bitte, das Bild habe ich nicht gemacht, nur aufgenommen. Das war
schon das Welec. das X-Signal ist einfach ein Sägezahn und in Y-Richtung
sind die Peaks vorhanden, die man ja beim TDS210 auch sieht.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Ok, an die 500 MHz komme ich natürlich nicht heran, was ich aber meinte 
war die Darstellung des Signals. Da werd ich mich mal ins Zeug legen, 
dass das mal etwas geschmeidiger aussieht als ursprünglich bei den alten 
Welecs. Bin da auch schon vorbelastet, da ich sowas mal als Diplomarbeit 
gemacht habe.

-> Das mit dem Sägezahn werde ich auch mal ausprobieren, den Trick 
kannte ich noch garnicht, man lernt nie aus...

Gruß und guats Nächtle wie der Schwabe sagen würde

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Ein Sägezahn als x-Signal- also eine gleichmäßig ansteigende Spannung.
Warum erinnert mich das nur so an das Zeitbasis- Signal? Das würde doch 
bedeuten du kannst gleich den normalen Betriebsmodus wählen, wenn du 
eine entsprechende Zeitbasis- Einstellung findest?

von Guido (Gast)


Lesenswert?

Hallo Bruno We,

das ist ja ein Messgerät. Mit mal so ungefähr die Zeitbasis halbwegs
brauchbar hinkriegen wird das nichts. Aber genau für solche Fälle ist
ja der XY-Modus vorgesehen. Das 1401A hat übrigens keine eigene
Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Guido,
siehst du...
>Das 1401A hat übrigens keine eigene
>Anzeige, war also zum Gebrauch mit einem Oszilloskop vorgesehen...

das war die entscheidende Info- Das Tek stellt also auch direkt das 
passende Sägezahnsignal zur Verfügung. Das selbe kannst du mit einer 
variabel einstellbaren Zeitbasis, so wie es viele Oszi's besitzen, auch 
erreichen.
(Ein Referenzsignal vorausgesetzt)

Aber mit der Info:
1) Das Tek hat keine eigene Anzeige und
2.) Es stellt dafür ein Sägezahnsignal für die xy Ablenkung zu 
Verfügung,
hätten wir uns die letzten 10 Posts sparen können.

Gruß

von michael (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,
ich hab am Wochenende mal die neue Firmware von Hayo getestet und noch 
ein paar Probleme entdeckt, die bei mir und einem Freund (wir haben 
beide das W2024) auftraten.
Anbei sind ein paar Bilder, die das Problem beschreiben. Es sieht für 
mich so aus, als wenn eine falsche Speicherposition ausgelesen und 
dargestellt würde (letztes Bild). Bei Timebase-Einstellungen von größer 
2ms bekomme stellt das Oszi nur noch eine Linie dar (kein Rauschen). 
Dies beginnt mit nur einem Kanal und setzt sich bei größerer Timebase 
fort. Ab 50ms und größer ist das Signal eingefrohren.
Das andere Problem ist die Kalibrierung bei Kanal 3 und 4. Wenn ich 
genau die Stufen treffe (im Bild 5V und 500mV) dann ist sie gut. Stelle 
ich aber 2V ein, so habe ich einen großen Offset.

von egberto (Gast)


Lesenswert?

nur so am Rande - bei den ersten 3 Bildern ist das Gehäuse so ocker - 
hast du das umgespritzt oder rauchst du 3 Schachteln am Tag vor dem Teil 
;-)) ??

gut's Nächtle

egberto

von michael (Gast)


Lesenswert?

Ne, ich bin Nichtraucher und umgespritzt habe ich es auch nicht ;-) Hab 
nur ohne Blitz fotografiert und das bei relativ wenig Licht...

von Guido (Gast)


Lesenswert?

Hallo,

nö, vor dem XY-Modus kapituliere ich. Auch wenn ich die Vektoren
ausschalte bekomme ich nur ca. 1 Bild/s. Was macht das Ding in der
Zwischenzeit? Auch mit konstanten Signalen am Eingang springt die
Anzeige hin und her. Habe mal Lissajous bei 512 kHz probiert, sieht
aus wie Aliasing-Probleme, aber die zeitl. Abhängigkeit müsste doch
im XY-Betrieb weg sein.

Michaels Problem kann ich bestätigen, bei langsamer als 10 ms/div
friert bei mir der Bildschirm ein.

@ Bruno: das Welec hat keine variable Zeitbasis und Synchronität ist
mit sowas nicht zu schaffen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Hallo Michael,

danke für die Hinweise, leider hab ich meinen Vierkanaler immer noch 
nicht... grummel, Welec läßt sich verdammt viel Zeit, vielleich heute.

Daher bin ich auf den Kanälen 3 + 4 "blind" und kann da momentan nichts 
dran machen. An einem neuen Nullabgleich bin ich aber ohnehin dran, da 
ich auch noch nicht zufrieden war.


@Guido

Ich habe die XY-Funktion noch mal komplett überarbeitet und erweitert. 
Du hast recht, in der 0.48 dreht das Ding noch ein paar Ehrenrunden, 
deswegen sieht das auch etwas zugemüllt aus. Die neue Version ist 
schneller, hat einen komplett von der Zeitdarstellung getrennten Offset 
und - kleines Schmankerl für alle 4-Kanaler - eine zusätzliche 
XY-Darstellung für Kanal 3 + 4 die auch gleichzeitig mit Kanal 1 + 2 
dargestellt werden kann.

Nebenbei hab ich etliche Fehler beseitigt. Die neue Version gibt es 
heute oder morgen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

freut mich zu hören, dann warte ich mal ab. Zum Zeitbasisproblem:
10 ms/div geht, 20 ms/div Bildschirm eingefroren, langsamer dito.
Aktivierter Mathemodus (z.B. 2-1): 20 ms/div geht noch, ab
50 ms/div eingefroren.

Kannst du das Abspeichern der Einstellungen noch mal anschauen?
Ich muss nach jedem Einschalten ein Autozero durchführen, weil er
mindestens einen Kanal wieder verstellt hat.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

mir ist aufgefallen das in deiner FW- genauso wie im Original, im 
"Vector off- Mode" nicht nur die Messwerte dargestellt werden. Falls ich 
mich nicht verzählt habe werden in 10ns/Div 40Px gezeichnet, obwohl ja 
nur Jede Nanosekunde ein Messwert vorliegt. D.h. es wird schon irgendwie 
interpoliert...

Ich fände es, speziell für die Entwicklungsphase, weitaus besser wenn 
wirklich nur die reinen Messwerte dargestellt werden. Man könnte so 
wesentl. leichter etwaige ADC Nichtlinearitäten zuordnen (und 
beseitigen).
Slog hat das in seinem FPGA Design wunderschön vorgemacht, indem jeder 
ADC seine eigene Zeichenfarbe erhalten hat. Ich möchte jetzt keine 
Grundsatzdiskussion über Sinn und Unsinn des Vector -off Mode 
lostreten... dennoch würde dieses Feature gerade auch bei der Lösung der 
HW Probleme imens helfen.

Gruß Brunowe

von Blue F. (blueflash)


Lesenswert?

@Guido

Ja das mit dem eingefrorenen Signal konnte ich auch nachvollziehen, war 
mir nur nie aufgefallen da ich in diesen Zeitbereichen nicht so häufig 
teste. Meine Vermutung ist, dass es mit dem Trigger zusammenhängt, denn 
die Zeichenroutine wird durchlaufen, es kommt nur kein neues Signal. Ich 
hatte aber für das übernächste Betarelease ohnehin vor größere 
Änderungen durchzuführen, unter anderem wollte ich den Zeroshift wieder 
einbauen und dann einen neuen Zero-Offsetabgleich programmieren. 
Vermutlich erledigt sich das Problem dann gleich mit.


@Bruno

Ja natürlich hast Du recht, denn die Signalgewinnung und 
Signalverarbeitung sind komplett getrennt von der Zeichroutine. D.h. 
wenn umgeschaltet wird zwischen Vector und Nonvector dann betrifft das 
nur die Zeichenroutine. Die bekommt aber nur einen Wertebuffer übergeben 
der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das 
halt die interpolierten Signalwerte. Die Interpolation findet also nicht 
in der Zeichenroutine statt sondern vorher, daher wäre es etwas 
schwierig die interpolierten Werte hinterher wieder auszublenden. 
Weglassen kann man sie aber auch nicht, da sonst die Zeitachse nicht 
mehr korrekt wäre(wäre sonst wie 50 ns).

Die Features der experimentellen FPGA-Version von Slog lassen sich hier 
nur schwer einbauen (der derzeitige Stand ist dafür schon zu komplex), 
auch wenn ich Dir recht geben muß, dass es für einige Tests ganz 
hilfreich wäre.

Gruß Hayo

p.s. die neue FW kommt doch erst morgen, mein Oszi hoffentlich auch...

von Blue F. (blueflash)


Lesenswert?

Hayo W. wrote:

> der die zu zeichnenden Werte enthält - in den Bereichen > 50ns sind das

sollte natürlich heißen < 50 ns - interpoliert werden 20ns und 10 ns 
(und in Kürze auch die neue Zeitbasis 5ns)


Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

ja das habe ich mir schon fast gedacht :-(     Wäre zu schön gewesen!
Dann muss ich mich wohl bei meiner "Messerei" anders behelfen...
Eine 5ns Zeitbasis ist ein guter Einfall, setzt aber eine gute 
Interpolation (sinx/x) voraus.

Gruß
brunowe

von Blue F. (blueflash)


Lesenswert?

Ob die Interpolation gut genug ist kannst Du Dir ja mal ansehen, es gibt 
den 5ns Bereich nämlich schon - nur noch nicht im Main-Mode. Wenn Du bei 
10ns in den Delayed-Mode schaltest hast Du Ihn!

Gruß Hayo

von Guido (Gast)


Lesenswert?

>Wenn Du bei 10ns in den Delayed-Mode schaltest hast Du Ihn!

Ha,

habe ich mir das also nicht blos eingebildet. Ich mag den
Delayed-Mode!

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier wie angekündigt die aktuelle beta version 0.50 - es sind einige 
Änderungen erfolgt insbesondere im XY-Betrieb.

Wundert Euch nicht beim Neustart, wenn es erstmal komisch aussieht. Da 
ich die Ablage der Parameter im Config-Bereich geändert habe werden 
erstmal unpassende Parameterwerte gezogen. Durch Betätigung des 
Defaultsetups ist das dann aber erledigt. Bei der nächsten Verstellung 
der Timebase werden dann aktuelle Werte weggeschrieben. Einen Flashdump 
habt Ihr ja vorsichtshalber gemacht oder?

In der Defaultzeichenroutine werkelt jetzt die neue beschleunigte line() 
Funktion, da diese das Signal an den Spitzen feiner auflöst als die alte 
Zeichenroutine. Kann man gut sehen wenn man via Terminalprogramm mit den 
Tasten shift + s die Darstellung umschaltet. Die Geschwindigkeit ist so 
ziemlich gleich.

Die XY-Funktion hat jetzt eine eigene Zeroverstellung, deren Werte auch 
getrennt im Configbereich abgelegt werden, so daß nach dem 
Wiedereinschalten des Gerätes das Sinal noch an der gleichen Stelle ist 
wie vorher.

Die Leute mit einem Vierkanalgerät könnten ja mal die XY-Funktion für 
die Kanäle 3 + 4 testen die ich zwar implementiert habe, aber selber 
noch nicht zu Gesicht bekommen habe (schneuz).

Die nächste Version wird wohl etwas dauern, da erstmal Ostern anliegt 
und ich dann größere Umbaumaßnahmen vor habe, mit denen dann hoffentlich 
auch etliche aktuelle Bugs verschwinden.

Also laßt mal hören was Ihr dazu meint.

So zum Schluß muß ich nochmal meinen Frust loswerden....mein Oszi ist 
immer noch nicht da, obwohl WELEC das für den 4. April als spätesten 
Termin angekündigt hatte. Die Gutschreibung des Betrages war sogar schon 
am 27.3. . Da bin ich doch schon etwas geknickt muß ich sagen.

So langsam könnte das mal an Land kommen oder?

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,
das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt 
Kanal 2 einen winzigen positiven Offset.

Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der 
entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung, 
Nulline, Triggermarkierung.

Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig 
weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die 
geben würde) verschiebt sich der Kanal immer weiter nach oben.

Mfg,
Kurt

PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den 
Bewertungen heißt es immer "schnelle Lieferung".

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen wrote:
> Hallo Hayo,
> das schalten der Kanäle auf GND funktioniert wieder. Allerdings behällt
> Kanal 2 einen winzigen positiven Offset.
>
> Ein verstellen der Volt/Div Knöpfe sorgt dafür dass sich der
> entsprechende Kanal leicht verschiebt. Jedoch Komplett: Nullmarkierung,
> Nulline, Triggermarkierung.
>
> Noch schlimmer ist es bei Kanal 1: Wenn ich den Volt/Div Knopf beliebig
> weit nach rechts drehe, also in Bereiche von 5mV,2mV,1mV... (wenn es die
> geben würde) verschiebt sich der Kanal immer weiter nach oben.

Hmm, muß ich mir mal angucken, ich hab die Nullinie jetzt geändert, in 
der originalen FW wird einfach stumpf eine Linie beim Zerolevel 
gezeichnet, während ich das jetzt so geändert habe, dass in der 
Ausleseroutine des ADC statt der ADC-Werte Null (bzw. 127) in den 
Speicher geschrieben wird. Ansonsten würde nämlich auch das Math-Signal 
falsch berechnet werden, da ja im Hintergrund immer noch das 
ursprüngliche Signal ausgelesen und berechnet würde.

> PS: Hoffentlich verzögert Welec den Versand nicht absichtlich. In den
> Bewertungen heißt es immer "schnelle Lieferung".

Da wären sie ja schön blöd, denn breiter als hier könnten sie es wohl 
kaum irgendwo trampeln! Wenn man bei Google die entsprechenden Begriffe 
eingibt landet man zwangsläüfig in diesem Forum - Allerdings 
interessanterweise nicht in diesem Thread sondern im Alten. Anscheinend 
ist der Suchcache noch nicht aktualisiert worden.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Warum sollten die denn den Versand verzögern?

Viele Grüße,

egberto

PS: Habe heute auch so ein 4 Kanal Teil (200 MHz) geschossen - Nach 
Ostern (wenn nichts dazwischen kommt) bin ich dann (erst mal als Tester) 
hier dabei!

von Guido (Gast)


Lesenswert?

Hallo Hayo,

das sieht wieder mal richtig gut aus. Der XY-Modus ist wirklich
deutlich schneller und einen Lissajous habe ich jetzt auch
hinbekommen.

Kurts Meldung kann ich bestätigen, ist bei mir in beiden Kanälen.
Sieht aus, als ob der Drehgeber für die Aschwächung/Verstärkung die
vert. Pos. verschiebt.

Mir scheint, dass in den langsamen Bereichen eine für die Grafik
zuständige Variable überläuft. Schalte ich auf 20 ms/div, friert
der Bildschirm ein. Zurück auf 10 ms/div gibt es einen Bruch in der
Darstellung bei der 3. div (Verschiebung im Signal). Weiter runter
auf 5 ms/div, der Bruch verschiebt sich in die Mitte des Schirms.

Jetzt stehen die Signale bei mir wie eine Eins auf dem Schirm, kein
Rumspringen mehr und dementsprechend auch kein hektischer Druck auf
Run/Stopp. Liegt das an der neuen Firmware, oder hatte ich vorher
was anderes verbockt?

Gruß, Guido

von Kurt B. (kurt)


Lesenswert?

Keine Ahnung was die sich denken. Wittig/Welec ist nicht gerade für 
seine logische Handlungsweise bekannt...

von Blue F. (blueflash)


Lesenswert?

Prima,

unsere kleine Gemeinde wächst von Woche zu Woche. Da macht das 
weiterentwickeln so richtig Spass...

Ich denke übrigens nicht, dass da Absicht hintersteckt. Allerdings hab 
ich heute mal eine Anfrage abgeschickt aber noch keine Antwort gekriegt.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Oh, das sollte eigentlich eine Antwort an Egberto sein, aber ich sehe 
gerade dass da schon wieder zwei Beiträge dazwischen stehen :-)

Danke übrigens wieder für die schnellen ersten Reaktionen. Heute hab ich 
allerdings keine Lust mehr die Kiste anzuschmeißen. Werd mir das mal 
später ansehen


@ Guido

Hast Du mal den XY-Modus auf Kanal 3 + 4 gecheckt? Würd mich mal 
interessieren, ich kann das ja (noch) nicht sehen...

Gruß Hayo

von Guido (Gast)


Lesenswert?

Sorry Hayo,

ich hab ja auch nur ein zweikanaliges Gerät. Aber ich drück
die Daumen, dass dein 4-Kanaler morgen ankommt. Bei mir hatte
Herr Wittig gut eine Woche gebraucht.

Gruß, Guido

von Michael K. (michaelk)


Lesenswert?

So, jetzt hab ich mich hier auch mal angemeldet ;-)

Der X-Y-Modus funktioniert auch auf 3+4. Jedoch kann man nicht in den 
X-Y-Modus, wenn Kanal 1 und/oder 2 deaktiviert ist. Auch funktioniert 
hier der Offset noch nicht. Man muss beide Kanäle auf die Mitte regeln, 
bevor man in den X-Y-Modus geht. Das klappt automatisch nur bei 1+2.

Fotos mach ich evtl. nachher noch und stelle sie rein.

MfG, Michael

von Michael K. (michaelk)


Lesenswert?

was mir gerade aufgefallen ist:
wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet, 
dann wird das Signal an der y-Achse gespiegelt!

von Blue F. (blueflash)


Lesenswert?

@Michael

Danke für die Hinweise.

>wenn man im x-y-Modus zwischen Vektor- und Punkt-Anzeige umschaltet,
>dann wird das Signal an der y-Achse gespiegelt!

Da hab ich doch tatsächlich nur den Vektorbetrieb korrigiert und den 
Punktbetrieb vergessen -> wird gemacht.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

@Hayo
ich habe mir erlaubt die FW1.2.BF.0.50_beta.zip in die Google Groups zu 
stellen, hier im Mikrocontroller Forum findet die keiner aus dem 
internationalen Umfeld :-)

-lässt sich irgendwie ein ADC Abgleich durch den User verwirklichen?
Praktisch wäre sowas natürlich via Menü und Encoder... aber wohl zu 
komplex und eher wieder was fürs VHDL Projekt?
Bei meinen Messungen (die schon schwer im Gange sind) ist mir 
aufgefallen das wohl viele Probleme (z.B. das Rauschen) durch den 
schlechten ADC Abgleich zumindest begünstigt werden.

Gruß
brunowe

P.S.: Anbei noch ein kleines "Stimmungsbild"

von Andreas P. (andreaspfau)


Lesenswert?

Hi Community,

hab die FW mal angetestet, die bisher beschriebenen Phänomene konnte ich 
z.T. auch schon beobachten, aber was mir arg zusetzt ist der Trigger. Da 
dies die erste FW ist, die ich installiere, weiß ich nicht obs an der FW 
oder an der Hardware liegt.

Ich hab jetzt keine Ahnung ob der durch die FPGA- oder die 
Softcore-Firmware beeinflusst wird, jedenfalls konnte ich auf eine 
sporadisch auftretende Flanke (ein Taster, der an der Mittelabzapfung 
eines Spannungsteilers einen Spannungssprung erzeugt) beim besten Willen 
nicht triggern, während es bei periodischen Signalen problemlos klappt.

Ansonsten, danke für die FW :-)

von Michael K. (michaelk)


Lesenswert?

Das mit dem Trigger ist mir auch schon aufgefallen. Jedoch meine ich das 
es nur bei CH1 extrem war und die anderen funktionierten. Werde das aber 
heute Abend nochmal ausprobieren.

von Andreas P. (andreaspfau)


Lesenswert?

Bei mir klappt das angegebene Experiment auf keinem der Kanäle. Auch 
nicht mit Puls-Trigger, welcher ja eigentlich noch besser geeignet wäre 
für so was. Und auch bei keiner Timebase-Einstellung.

Okay, ich habe dem Projekt bereits meine Hilfe angekündigt, da weiß ich 
ja jetzt wo was zu tun ist :-)

von Blue F. (blueflash)


Lesenswert?

Hi,

bin aus dem Osterurlaub zurück und - Überaschung - das W2014 ist da. 
Also, alles wird gut. Übrigens steht auch nur W2014 (ohne A) auf dem 
Gehäuse, ich vermute mal das da alte Restbestände an Gehäusen oder 
Labels verwendet werden. Die Hardware scheint aber aktuell zu sein.

Hab erstmal das komplette Flash gesichert, wer also seins zerschossen 
hat kann gerne anfragen.

@Andreas

Mach mal erstmal noch nichts wegen des Triggers. Wie ich schon im readme 
beschrieben habe hängt das unter Umständen mit der Deaktivierung des 
Zeroshifts zusammen, den ich wegen des Nullabgleichs vorgenommen hatte. 
Zur nächsten Beta werde ich das wieder aktivieren, ab da wird es dann 
wirklich interessant wegen Nullabgleich, Trigger und Cursor. Der 
derzeitige Stand ist nur ein Zwischenstand. In der nächsten Version 
werde ich ebenfalls mal die Funktionen von Kanal 3 + 4 prüfen und 
überarbeiten.

Gruß Hayo

von Andreas P. (andreaspfau)


Lesenswert?

@Hayo,

nochmal zum Trigger: wenn ich den Trigger auf AC stelle, klappts. 
Seltsam, da ich überzeugt bin, dass der Trigger auch bei DC-Coupling 
auslösen müsste, wenn ich den Triggerpegel zwischen H- und L-Level des 
Signals lege.

von egberto (Gast)


Lesenswert?

So, ich habe jetzt auch mein 2024A -> wie mache ich denn ein Backup von 
dem Teil (bevor ich mit der Beta experimentiere??)

Viele Grüße,

egberto

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Och egberto...
wie oft hatten wir das denn schon?
Lese doch einfach mal die alten Posts.
Tipp: Welec Updater... (wenn du "nur" mit Hayo's FW spielen willst...)

von egberto (Gast)


Lesenswert?

Ok, ich war zu faul.....wollte aber auch auf Nummer sicher gehen - ob 
ich dann auch alle Parameter etc. mitnehme.

Ich werd dann wohl mal lesen (müssen)

Schönes WE,

egberto

von Johannes S. (demofreak)


Lesenswert?

Bruno We wrote:
> wie oft hatten wir das denn schon?
> Lese doch einfach mal die alten Posts.

Macht doch mal einen Artikel draus. Schliesslich breiten sich die Geräte 
hier ja nun doch etwas aus, und jedem neuen Nutzer nahezulegen, 100e 
Posts in mehreren Threads zu lesen... hust ;)

/Hannes

von Blue F. (blueflash)


Lesenswert?

Liest eigentlich keiner das readme das ich dem FW-Update beigelegt habe?
Da steht doch alles drin und der Updater ist doch auch schon dabei.

Also hier noch mal zum Mitschreiben im Detail.

Backup erstellen:

- DSO und PC mit dem seriellen Kabel verbinden - beide anschalten!
- den Welecupdater starten, in der Parameterauswal (Pfeiltaste neben dem 
grünen IC-Symbol) den Adressbereich einstellen.
- Komplettdump 00040000 bis 007FFFFF davor steht nichts drin und danach 
fängt das RAM an.
- FW-Dump 00040000 bis 000DFFFF
- Config, protected Config und Signalspeicher 000E0000 bis 007FFFFF

- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken, 
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv
- Beim Welec-Updater den Download starten
- Nach dem Download mit dem Speichernbutton (Diskettensymbol) den Dump 
in eine Datei speichern

Dump wieder zurückspielen:

- Am DSO die linken beiden Funktionstasten unter dem Bildschirm drücken, 
es wird erst weiß dann schwarz - der Germs-Monitor ist aktiv.
- Beim Welec-Updater den Upload starten, die Flashdumpdatei auswählen 
und den Upload bestätigen.
- wenn der Upload fertig ist kommt entweder eine Timeoutmeldung 
(Übertragungsfehler) oder die Meldung "Fertig". Beides ist gut.
- danach DSO auschalten und dann wieder einschalten - das war es

Gruß Hayo

von egberto (Gast)


Lesenswert?

Danke!

Deine Beta wollte ich ja sonst erst auspacken, wenn ich das Backup 
habe.....
Mal sehen, ob ich heute noch dazu komme (ich muß mir ja auch die 
originale Firmware erst mal etwas anschauen!).

Viele Grüße,

egberto

von Andreas P. (andreaspfau)


Lesenswert?

@Hayo,

der WelecUpdater hat bei mir erst funktioniert nachdem ich den Pfad auf 
die .flash-Datei in der .ini-Datei angepasst hatte, erst dann wurde der 
Download-Button grün (war davor disabled). Hat mich ne ganze weile 
gekostet das herauszufinden, da der Pfad absolutcodiert auf das 
Verzeichnis C:\Temp zeigt. Evtl. sollte in einem Future-Release ein 
relativer Pfad (z.B. ".\tomcat.flash") angegeben werden.

von egberto (Gast)


Lesenswert?

Stimmt, war bei mir genauso.

Viele Grüße,

egberto

von Carlos (Gast)


Lesenswert?

Dito

Viele Grüße,

Carlos

von Blue F. (blueflash)


Lesenswert?

Hi,

der Welecupdater ist von Markus geschrieben worden, daher 
Änderungsvorschläge direkt an Ihn richten. Ansonsten kann ich aber in 
zukünftigen Betareleases auf diese Eigenheiten hinweisen.

Ach ja, eine Frage - ich habe gerade eine Zwischenversiomn fertig, bei 
der ich die XY-Funktion bzw. die Menüsteuerung angepasst habe und auch 
sonst noch einige Kleinigkeiten in Bezug auf die Vierkanalfunktion 
geändert habe. Soll ich die hier einstellen, oder lieber bis zum 
nächsten größeren Release warten?

Gruß Hayo

von Andreas P. (andreaspfau)


Lesenswert?

Hi @Hayo,

also angesichts der Tatsache dass jede FW, insbesondere die originale, 
mit einigen Bugs behaftet ist, nehme ich jedes Release gerne an, solange 
es keine anderen Funktionen außer Kraft setzt. Außerdem ist das W2024A 
mein einziges Oszi, über jede Verbesserung an meinem 
oszillographierenden Messknecht bin ich froh :-) Gerade die 
Menügeschichten klingen nützlich.

von egberto (Gast)


Lesenswert?

Ich denke auch, so lange nicht neue Baustellen aufgerissen werden 
sondern Dinge korrigiert - nur raus damit.

Nebenfrage: Ich habe das Teil ja erst seit Freitag (bin also noch in der 
"Gewöhnungsphase), gibt es eine Möglichkeit die Samplerate runter zu 
setzen (zwecks Vergleich mit meinem OWON)? Dann müsste sich doch auch 
das (sichtbare) Rauschen verringern?

Viele Grüße,

egberto

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, hier wie angekündigt die vorgezogene beta 0.54.

Highlights sind:

- neue Timebase 5ns -> Trigger stimmt hier noch nicht
- manuelle Abgleichfunktionen für DAC und ADC
- neu implementierter Zeroshift
- diverse Bugs die Ihr mir gemeldet habt sind behoben
  (Invers-Bug, Triggeroffset etc.)

einige Sachen sind leider noch offen, da ich wegen der etwas 
überhasteten Veröffentlichung keine Zeit mehr zum Testen und korrigieren 
hatte.

Dem Paket habe ich auch eine aktualisierte Anleitung für das Erstellen 
eines Backups und die Handhabung des Updaters beigefügt.

Die Kurzanleitung für den manuellen Abgleich findet Ihr am Ende des 
Readme. Für diese Funktionen braucht Ihr auf jeden Fall ein 
Terminalprogramm. Wenn es dazu noch Fragen gibt immer raus damit.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Na das ist doch mal Klasse, danke!

 Gruß, brunowe

von egberto (Gast)


Lesenswert?

Vielen Dank!!

(heute teste ich aber nicht mehr - komme gerade aus dem Biergarten 
<=8-))

von Johannes S. (demofreak)


Lesenswert?

So, hab die FW grade mal draufgeflasht (ist ja in Verbindung mit dem 
Backup ein abendfüllendes Programm :D) und werd dann mal bissi 
rumspielen.

Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen 
des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven 
Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am 
Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von 
Kanal 1. Find ich irgendwie umständlich.

/Hannes

von Michael W. (slackman)


Lesenswert?

Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine 
Möglichkeit, das über USB zu erledigen? Junge, Junge...

Die Kallibrierung:
beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben 
hin(3,2,1) immer stärker...

Ich muss mich erstmal intensiver mit dem Teil beschäftigen (Spruts USB 
PIC Brenner z.B. der hat bei mir eine zu hohe Brennspannung...). Die 
Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu 
70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...
Heute (gestern) hatte ich auf der Hannovermesse ein LeCroy in Action 
gesehen - huuuh, ganz andere Liga, 15k€...

Michel

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hey,

@Slackman: warum das über USB nicht geht, frag ich mich auch jedes 
mal...
Hat schon einmal jemand versucht, die neue FW einfach in die Original 
Flash reinzukopieren (nach den Bootlader) und dann via original 
W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen 
mit anderem Adress- Aufbau... war ja nur so ein Gedanke.
Wüsstest du das Lecroy derzeit eine Oszi- Abwrackprämie anbietet (ich 
glaub 3000€- für Oszis ab 12k€) da kannst du dir jetzt direkt ein 
Schnäppchen holen.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Johannes Studt wrote:

> Was mir grade wieder auffällt: wäre es nicht sinnvoll, wenn durch Wählen
> des aktiven Kanals auch gleich diese Triggerlevelmarke mit zum aktiven
> Channel wechseln würde? Wenn ich Kanal 2 auswähle und dann am
> Triggerlevel rumdrehe, ändert sich nach wie vor der Triggerlevel von
> Kanal 1. Find ich irgendwie umständlich.

Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher 
wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es 
kommt ja auch vor, dass auf dem einen Signal getriggert und das andere 
begutachtet wird.

Was man natürlich machen könnte, wäre beim Abschalten eines Kanals 
gegebenenfalls die Triggersource automatisch auf den nächsten aktiven 
Eingang zu legen.


Michael Werner wrote:
> Gerade habe ich die neue Firmware geflasht - gibt's eigentlich keine
> Möglichkeit, das über USB zu erledigen? Junge, Junge...

Klar ginge das. War auch schon mal angedacht. Falk und Markus hatten 
sich hierzu schon Gedanken gemacht. Da scheint aber noch nichts passiert 
zu sein. Ich selbst bin mit USB nicht so gut vertraut und habe mich 
daher erstmal auf die Firmware konzentriert.

> Die Kallibrierung:
> beim vierten Kanal ist das Rauschen sehr gering gewesen, nach oben
> hin(3,2,1) immer stärker...

Ja das sieht bei mir auch so aus. Das fällt einem bei der originalen FW 
nur nicht so auf.


> Die Anzeige scheint mir aber immer noch sehr langsam. Slog soll ja bis zu
> 70(!) Frames/s mit dem neuen FPGA-Design hinbekommen...

Stimmt, das liegt daran, dass im WELEC (Referenz) NIOS-Design keine 
extra Multiplikationseinheit vorgesehen ist (es gibt auch ein Design mit 
extra Multiplikator). Nun muß ich aber um die Anzeige genau zu machen 
pro Meßwert eine Floating Point Multiplikation durchführen - das kostet 
Zeit.
Die original WELEC-Firmware erkauft sich die Geschwindigkeit mit hoher 
Messungenauigkeit! Meßt mal die genauen Pegel mit einem geeichten 
Multimeter nach, dann wißt Ihr was ich meine. Besonders hoch sind die 
Abweichungen in den 2er und 1er Bereichen.

Hier bin ich aber trotzdem dabei noch weiter zu optimieren.


Bruno We wrote:

> Hat schon einmal jemand versucht, die neue FW einfach in die Original
> Flash reinzukopieren (nach den Bootlader) und dann via original
> W2000-update hoch zu laden? Ja ich weiß- original sind S2 Code- Zeilen
> mit anderem Adress- Aufbau... war ja nur so ein Gedanke.

Klar hab ich da schon rumexperimentiert. Leider erwies sich die 
WELEC-Software als ziemlich zäh und widerborstig. Alle Möglichkeiten 
habe ich hier sicher noch nicht ausgelotet - es besteht also noch 
Experimentierpotential. Wenn jemand das hinkriegt, liefere ich die 
Flashs auch gerne im WELEC-kompatiblen Format. An den Adressen liegt es 
aber glaube ich nicht. Die kann man beim Updater von Markus vor dem 
Download in der INI-Datei einstellen und damit eine entsprechende 
Testdatei erzeugen.
Falls es nur daran liegen sollte, ist es wohl kein Problem einen 
entsprechenden Kommandozeilenkonverter schnell  zusammenzuklöppeln.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Hayo W. wrote:
> Der aktive Kanal muß aber nicht unbedingt der Triggereingang sein! Daher
> wäre es ja nicht sinnvoll die Triggersource einfach zu wechseln. Es
> kommt ja auch vor, dass auf dem einen Signal getriggert und das andere
> begutachtet wird.

Hm, da hatte ich einen Denkfehler drin. Ich war irgendwie der Meinung, 
dass jeder Kanal unabhängig voneinander getriggert wird, aber das ist ja 
Unfug.

> Was man natürlich machen könnte, wäre beim Abschalten eines Kanals
> gegebenenfalls die Triggersource automatisch auf den nächsten aktiven
> Eingang zu legen.

Das passiert immerhin zwischen Kanal 1 und 2 schon jetzt.

/Hannes

von Andreas P. (andreaspfau)


Lesenswert?

Hi,

erstmal danke für die neue FW - funktioniert soweit gut, vor allem das 
mit der Nulllinie freut mich.

Aber eine kleine Frage zum Updater: ist es normal, dass der Flashvorgang 
mit Schreibfehlern endet? Das war jetzt mein 2. Updatevorgang, und am 
Schluss gabs jedes mal Fehler und Retries. Das Oszi tut allerdings 
trotzdem.

Wenn das nur bei mir auftritt werd ich mir die genaue Meldung beim 
nächsten mal aufschreiben.

von Johannes S. (demofreak)


Lesenswert?

Siehe beiliegende Dokumentation ;)

von Andreas P. (andreaspfau)


Lesenswert?

Ooops... hab die Backup Howto übersehen, die war bisher nicht dabei. 
Sorry.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

so, hab mich etwas mit der ADC Kalibrierung gespielt.
Interessant was zu erreichen wäre wenn...
Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut 
kalibriert!

von Blue F. (blueflash)


Lesenswert?

Bruno We wrote:
> Hallo Hayo,
>
> so, hab mich etwas mit der ADC Kalibrierung gespielt.
> Interessant was zu erreichen wäre wenn...
> Aber so ganz perfekt ist das Ganze nicht- entweder ist Ch1 ODER Ch2 gut
> kalibriert!

Ja die Kalibrierung bringt nicht immer die gleichen Ergebnisse. Nach 
drei Durchläufen ist sie aber meistens konstant. Die automatische 
ADC-Kalibrierung wird übrigens für alle Kanäle durchlaufen wenn die 
"Search Zeros" Funktion benutzt wird (und zwar direkt vorher).

Bei der manuellen Kalibrierung läßt sich das für jeden Kanal einzeln 
einstellen. In den ersten 15 Schritten (jedes Mal beim Drücken von
shift + Q wird ein Schritt weitergeschaltet) werden verschiedene 
Kombinationen durchlaufen - dann kommt als letzter Schritt ein 
automatischer Abgleich für den Kanal. Mit shift + Z kann man zum 
nächsten Kanal schalten und das Spiel neu beginnen. Wenn man alles durch 
hat, kann man das Ergebnis mit shift + O in den protected Bereich 
schreiben - dann wird es beim nächsten Start wieder geladen.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero 
lines" alles wieder überschrieben wird?! ÄCHZ
Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich 
den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom. 
Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC 
nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der 
Anpassung reicht für diesen ADC nicht aus.
Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen) 
nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!

Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert 
wäre...
Auf jeden Fall kann ich jetzt gut weitermachen, danke!

Gruß, brunowe

von Johannes S. (demofreak)


Lesenswert?

Das sieht auf jeden Fall schon mal sehr "mögig" aus. :)

von Blue F. (blueflash)


Lesenswert?

Bruno We wrote:
> ..und so lange verwendet wird, bis durch ein Aufruf der "Calibrate Zero
> lines" alles wieder überschrieben wird?! ÄCHZ

Nein, der protected Bereich wird definitiv nur mit shift + O 
überschrieben. Dieser Bereich ist eigentlich nur für Factory Settings 
vorgesehen - hier steht unter anderem auch die Seriennummer. Wenn ein 
Zero-Abgleich durchgeführt wird, dann ist das nur temporär. Beim 
nächsten Start werden wieder die Werte aus dem protected Bereich 
geladen.

> Mit den möglichen 15 Kombinationen des manuellen Abgleich bekomme ich
> den Abgleich des Kanal 1 übrigens nicht so gut hin, wie mit der autom.
> Kalibrierung. Es scheint mir als ob die Anpassung mindestens eines ADC
> nicht mit den 15 Kombinationen abgedeckt wird- d.h. der max Bereich der
> Anpassung reicht für diesen ADC nicht aus.

Sorry, mir waren das einfach zu viele Kombinationen, da hab ich dann die 
genommen, die bei meinen beiden Oszis am besten funktioniert haben.
Bei den Einserkombinationen hab ich noch alle sinnvollen genommen, bei 
den 2ern hab ich dann nur eine Auswahl verwendet. 3er hab ich garnicht 
berücksichtigt, obwohl diese natürlich auch nicht ausgeschlossen sind - 
bei mir allerdings nicht auftreten (Bei mir 2110 und 1001).
Nenne mir doch mal die Werte die die automatische Kalibrierung ergibt, 
dann kann ich die Kombination mit einbauen.

> Schade das die autom. Kalibrierung (auch bei mehrmaligen Versuchen)
> nicht für beide Kanäle gleichzeitig zufriedenstellend arbeitet!

Da ich diese in den Standardablauf mit eingebaut habe sind meine 
Möglichkeiten hier erstmal beschränkt - alles Weitere ist in Arbeit...

> Aber die Darstellungen auf meinen obigen Fotos finde ich schon ok...
> Wenn jetzt das Optimum des Ch1 mit dem Optimum des Ch2 kombiniert
> wäre...
> Auf jeden Fall kann ich jetzt gut weitermachen, danke!

Es zeigt auf jeden Fall, dass man hier noch Einiges herausholen kann.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

nur zur akt. Diskussion: gib bitte noch mal einen Suchbegriff an, mit
dem diese Kalibrierung in hardware_t.cpp gefunden werden kann. Ich
hatte das schon mal angesehen, jetzt finde ich es nicht mehr.

Wenn Bruno eine Toolchain hat, kann er das leicht selbst probieren
(schien mir unproblematisch).

Ich danke mal für die neue Version und werde nächste Woche testen.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

ok, der protected Bereich wird mit "Zero Calibration Line" nicht 
überschrieben- ist mir gestern nur so vorgekommen.
Meine optimale Kalibrierung für Ch1 ist 2340 (bzw. 3450 sieht auch recht 
gut aus), für Ch2 0112. Ich hab die Einstellung für beide Kanäle jetzt 
recht gut hinbekommen. Als nächstes will ich mal checken ob mein Kanal 2 
auch auf ein Rauschen von ±1Digit zu bekommen ist. Das ist, glaub ich, 
ein durchaus akzeptabler Wert.
Mein Kanal 1 sieht jetzt echt gut aus... nur schade das da noch keine 
Analog-Stufen dranhängen!!!

Gruß, brunowe

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Das heißt natürlich: "Calibrate Zero Lines"

von Blue F. (blueflash)


Lesenswert?

@Guido

In hardware_t.cpp Zeile 3258 - das ist der Buttonhandler

(Suchbegriff Test Funktion 0 Q)


@Bruno

2340 ist aber echt heftig! Da kann ich mir gut vorstellen wie das Signal 
unkalibriert aussieht...

Wenn Du in das oben genannte Coding gehst, kannst Du Dir eigene 
Kombinationen dazubasteln. Ansonsten werde ich Deine mal mit aufnehmen 
für die nächste Version.

Ich habe übrigens gerade festgestellt, dass es nicht 15 Kombinationen 
sind, sondern 26 (ich war noch in Gedanken auf dem alten Stand) - die 
27igste ist dann Autokalibrierung.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

es ist (zum Glück) nicht notwendig das ich im Code herum operiere. Ich 
habe via auto calibration den optimalen Abgleich für Ch1 erstellt, dann 
manuell den Abgleich für Ch2 durchgeführt und das Ganze mit Shift O 
abgespeichert- scheint zu funktionieren. Eine sehr gute Basis fürs 
weitere Vorgehen!

Gruß brunowe

von egberto (Gast)


Angehängte Dateien:

Lesenswert?

Ich bin mal Bruno We's Beispiel gefolgt und habe das mal an meinem 
A2024A durchgeführt...

Viele Grüße,

egberto

von egberto (Gast)


Lesenswert?

Anmerkung:

bei 10mV Eingangsempfindlichkeit (wie bei Bruno We) sieht es bei mir 
nicht so gut aus - am Besten klappt es anscheinend bei 50 mV (bei 100 mV 
ist es schon wieder schlechter).

Viele Grüße,

egberto

von Johannes S. (demofreak)


Lesenswert?

Genau, am besten ist es immer in den "5er" Messbereichen, also 5V, 
500mV, 50mV, am schlechtesten sieht es in den "1er" Messbereichen aus. 
Ich bekomme es auch manuell nicht so hin wie Bruno.

Wie ist da eigtl die Vorgehensweise? Aus den Zeilen, die da im Terminal 
erscheinen, einen Mittelwert je DAC bilden und dann den Ausgleich 
errechnen? Ich hab jetzt nur der Reihe nach alle Kombinationenn 
durchgedrückt und geschaut, wo es am hübschesten aussieht.

Irgendwie kommt es mir so vor, als wenn ich da irgendwas noch nicht 
begriffen habe. :D

/Hannes

von sunny (Gast)


Lesenswert?

hallo bastelfreunde

zu aller erst mal ein großes HUT AB und DANKESCHÖN an hayo, bruno und 
die anderen entwickler die so viel arbeit und zeit in dieses projekt 
investieren.
seit vorige woche bin ich auch besitzer eines w2024. die entwicklungen 
hier im forum verfolge ich nun schon seit ein paar tagen. mich erstaunt 
wieviel potential wittig bei dem gerät verschenkt hat. wenn es also was 
zu testen gibt stehe ich gern zur verfügung. ich schrecke auch vor 
hardwarebastellein am gerät nicht zurück. als vergleichsgerät steht ein 
lecroy 9400 zur verfügung. ein paar kenntnisse in C sind auch vorhanden.

grüße sunny

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo sunny,

na dann erstmal herzlich willkommen. Vielleicht hast du ja Lust etwas 
mit an der HW rumzubasteln? Momentan bin ich anscheinend der Einzigste, 
dessen Oszi schon seit Tagen auseinandergebaut am Arbeitsplatz liegt und 
für Messungen an Herz und Leber herhalten muss?! Für Unterstützung und 
evtl. für Vergleichsmessungen wäre ich durchaus dankbar!
Evtl. meldest dich ja mal via Skype bei mir? Skype- Name: brunowe1

von egberto (Gast)


Lesenswert?

Hallo Bruno We,

auch wenn wir (die primär nicht an der Hardware arbeitenden) dich nicht 
direkt vorwärts bringen können- könntest du so etwas wie eine kurze 
Abgleichanleitung mit etwas Hintergrund (warum z.B. entsteht durch 
schlechten Nullinienabgleich eine Schwingung mit 250 Mhz?) hier rein 
stellen?

Neben Johannes und mir gibt es bestimmt noch mehr Einsteiger in die 
Thematik.

Viele Grüße,

egberto

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo egberto,

mir ist leider nicht ganz klar was du mit Abgleichanleitung meinst.
Wie ich meine ADC abgeglichen habe? Eigentlich ist das da nicht viel 
dabei...
Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen 
Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen, 
öffentl. verfügbaren Dokumentationen nachzulesen.
Ich denk mir, wer sich ernsthaft mit der Materie auseinandersetzen will, 
sollte sich vlt. erstmal die HW Beschreibung auf SF ansehen.
http://apps.sourceforge.net/trac/welecw2000a/
Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in 
unserem SF-Wiki abzulegen- nutzt sie.
Ich bin überzeugt, das dir dann sofort klar wird wie es zu den 250MHz 
kommt.
Nur so nebenbei... auch mit der Niederschrift meiner Messergebnisse hab 
ich versucht etwas Klarheit in die Funktion des Oszi's zu bringen.

Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie 
ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC 
soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen 
Abgleich nicht korrigiert werden kann.

Gruß brunowe

von egberto (Gast)


Lesenswert?

Hallo Bruno We,

vielen Dank für die Antwort.

Es ist halt das alte Problem, man muss erst viele Dinge lesen (und 
ellenlange Threads abarbeiten) um eine Antwort auf eine sich stellende 
Frage zu erhalten.

Mir ist klar, das der Grat zwischen nerven der (kundigen) 
Forumsteilnehmer und Aufgabe wegen zu hohem Einarbeitungsaufwand schmal 
ist.

Darum die Bitte, auch mal eine doofe Frage wohlwollend zu beantworten - 
das macht den Einstieg wesentlich leichter.

Viele Grüße,

egberto

von Johannes S. (demofreak)


Lesenswert?

Bruno We wrote:
> Ist doch alles in der Liesmich von Hayo's FW, (evtl. in meinen
> Messprotokollen- wg. 250MHz Schwingung) und in diversen anderen,
> öffentl. verfügbaren Dokumentationen nachzulesen.

Hm, ich hab zu diesem Punkt nix gefunden. Liegt vllt auch daran, dass 
ich nicht ein Werkzeug entwickeln, sondern nur Verbesserungen, welche 
andere daran vornehmen, verwenden möchte (s.u.) und dementsprechend nur 
das Liesmich gelesen und nicht irgendwo im Netz in vielen Dokumenten 
dazu nachgeforscht habe.

> Wir haben uns viel Arbeit gemacht alle Info's über die W2000 Oszis in
> unserem SF-Wiki abzulegen- nutzt sie.

Versteh mich bitte nicht falsch: ich finde das absolut bemerkenswert, 
was ihr hier macht, aber für mich ist das Gerät nicht Selbstzweck, 
sondern Werkzeug. Ich helfe gern im Rahmen meiner beschränkten 
Möglichkeiten, indem ich zum Beispiel nach einer vorgegebenen 
Verfahrensanleitung eine OS-Firmware flashe, ein Paar Testpunkte 
abarbeite und dann ein Ergebnis poste, aber mitentwickeln oder auch 
nur mich in die Funktionsweise hineindenken möchte ich eigtl nicht. 
Darum kann ich die Nachfrage von egberto uneingeschränkt nachvollziehen.

> Noch ne Anmerkung: der etwas kompliziertere Weg des ADC- Abgleich wie
> ich ihn oben durchgeführt habe, ist eh nur notwendig wenn mind. ein ADC
> soweit aus dem Bereich raus ist, das er mittels Hayo's manuellen
> Abgleich nicht korrigiert werden kann.

Ich hab gerade ein paar Fotos gemacht vom Zustand nach dem Einschalten 
und vom Zustand nach dem mehrfachen Ausführen von "Calibrate Zero 
Lines". Ich finde, das bringt nicht nur nix, sondern verschlechtert 
das Rauschen (von den unverändert abweichenden Zerolines mal ganz 
abgesehen). Also mache ich entweder etwas grundlegend verkehrt, oder 
dort ist ein Wurm drin.

/Hannes

P.S: Fotos poste ich gleich, muss sie nur noch zusammenfügen.

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

So,

jeweils ein Bild vom Zustand direkt nach dem Einschalten (erstes und 
drittes Bild) und vom Zustand nach dreimaligem "Calibrate Zero Lines" 
(zweites und viertes Bild) bei unterschiedlicher zeitlicher Auflösung.

/Hannes

von Guido (Gast)


Lesenswert?

Hallo,

mal eine Schnellanleitung für den ADC-Abgleich: Ihr müsst ein
Terminalprogramm über die ser. Schnittstelle mit 115,3 kBaud/8N1
anschließen. Oszi lange warmlaufen lassen (1 h oder so).
Einstellung für alle Kanäle: 5 V/div, 50 ns/div.
Unter Utilities-> Auto-Calibrate mehrmals durchführen.

Falls die Linien für die Kanäle unterschiedlich dick sind (sieht
aus wie Rauschen) im Terminalprogramm mit Shift+Z den gestörten
Kanal wählen. Dann immer wieder Shift+Q drücken und die Anzeige
beobachten. Mit jedem Tastendruck wird eine von 22 Kombinationen
eingestellt und ihr könnt euch für die optimale Entscheiden. Die
letzte Kombination ist wieder ein Auto-Zero, jetzt aber spez. für
den eingestellten Kanal. Habt ihr die optimale Kombination für
alle Kanäle eingestellt, könnt ihr diese mit Shift+O dauerhaft
speichern.

@ Bruno We: Ich verstehe überhaupt nicht, warum diese Kalibrierung
für die Kanäle unterschiedlich ist. Es sind doch dieselben Wandler?

@ Hayo: Sollen wir mal eine Sammlung an Kalibrierwerten anlegen?

In den den 1er-Bereichen habe ich jetzt einen bleibenden Offset,
2er- und 5er-Bereiche stimmen optimal überein. Kann (muss) man das
auch individuell kalibrieren.

@ all: Viele Spaß beim Experimentieren,

Gruß, Guido

von Guido (Gast)


Lesenswert?

Ahh, upps,

gerade gefunden Shifz+W/E, wird erst beim Umschalten übernommen.

Schon toll, wenn man sein Oszi so kalibrieren kann.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo

@Guido, ja es sind die selben Wandler. So wie ich das momentan sehe, 
werden die ADC nicht extern mit einer Referenzspg. versorgt, sondern 
nehmen als Referenz einfach die Hälfte der angebotenen Versorgungsspg.
Wahrsch. kommt diese Abweichung dann einfach durch Bauteilunterschiede 
zustande.

@Johannes: Inwieweit die "Calibrate Zero Lines" für die 4 Kanäler gut 
arbeitet kann ich nicht beurteilen. Das muss Hayo beantworten. Wenn du 
dein erstes Foto mit meinem Foto von oben vergleichst, dann liegt beim 
Einschalten dein Rauschniveau in etwa so wie bei mir auf Ch2. Mein Ch1 
ist das Optimum (vom analogen Standpunkt aus betrachtet- ohne 
nachträgliche digitale Bearbeitung)- da will ich meinen Ch2 in etwa 
hinbekommen. Noch mal für alle (die die obigen Post's nicht gelesen 
haben) bei meinem Ch1 wurde die Verbindung zum analog- Part der 
Schaltung abgelötet- das ±1 Digit an Fehler wird also vom ADC bzw. von 
der anschl. digitalen Verarbeitung erzeugt (eher unwahrscheinlich).

Man muss auch nochmal erwähnen das Hayo's aktuelle FW etwas überstürzt 
heraus gegeben wurde, um genau diesen Punkt des ADC- Abgleich wenigstens 
schon einmal experimentell durchführen zu können. D.h.man muss halt noch 
ggf. gewisse Einschränkungen in der Bedienung hinnehmen. Irgendwann wird 
dieser manuelle Abgleich der einzelnen ADC bestimmt nicht mehr notwendig 
sein- weil ich überzeugt bin Hayo bekommt den autom. Calibrate Zero Line 
gut hin!


Gruß, brunowe

von Johannes S. (demofreak)


Lesenswert?

Ja, dass du den analogen Teil der Eingangsschaltung abgetrennt hast, 
hatte ich zwar gelesen, aber gleich wieder "verdrängt". Sorry. ;-)

Wie kann man sich erklären, dass Nulllage und auch Rauschen in den 5er 
und 2er Messbereichen jeweils deutlich besser sind als in den 1er 
Messbereichen? Im 1V/div-Bereich habe ich auf Channel 4 aller paar 
Sekunden Rauschen im Bereich einer Div-Teilung, m.a.W. 1Vpp, und wenn 
ich auf 500mV runterschalte, wird es verglichen damit recht glatt (genau 
wie in der anderen Richtung, also bei 2V/div und 5V/div).

Die Nulllage ist bei 5er und 2er MB fast korrekt, bei 1er MB dagegen 
ziemlich daneben, und ich kann sie auch mit ShiftW/E nicht verschieben.

/Hannes

von Kurt B. (kurt)


Lesenswert?

Hallo Bruno,
wie hast du eigentlich Slog's Design ins Oszi gekriegt?
Habe ich das so richtig Verstanden?

USB Blaster installieren
Quartus Programmer installieren
Hello_W2000_v0_1_4.sof ins Oszi Programmieren
Jetzt sieht es so aus wie 
http://www.mikrocontroller.net/attachment/49782/Ch1_ohne_R31uR32-Slog_V1_3_.jpg
Nach Neustart des Gerätes ist der Zauber wieder vorbei
USB Blaster deinstallieren, damit sich das Oszi wieder als HID meldet
Backup des 24C64 ist nicht nötig

Mfg,
Kurt

von branadic (Gast)


Lesenswert?

Hallo Hannes,

wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch 
noch nicht mit deinem Gerät beschäftigt.
Dir wäre dann nämlich aufgefallen, dass das Gerät nur über drei 
Messbereiche verfügt. Man hört wie beim Umstellen des Messbereiches ein 
Relais schaltet.
Dir hätte auch auffallen können, dass Wittig/Welec die optimale 
Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV 
angibt.

Die Summe der so gesammelten Informationen führt dann zu der 
unglaublichen Erkenntnis, dass die 2V/1V Darstellung nur eine 
Vergrößerung der 5V-Messung sind, 200mV/100mV der 500mV-Messung und wer 
hätte das gedacht, die 20mV/10mV die der 50mV-Messung. ;)

Gruß, branadic

von branadic (Gast)


Lesenswert?

Hallo Kurt,

genau so läuft das ab.

Gruß, branadic

von Johannes S. (demofreak)


Lesenswert?

branadic wrote:
> wie ich sehe hast du dich noch nicht wirklich mit der Materie und auch
> noch nicht mit deinem Gerät beschäftigt.

Du wirst lachen, nein. Ich mach das hier nur nebenher mit, während ich 
ein Layout zu Papier bringe. :)

> Dir wäre dann nämlich aufgefallen, dass das Gerät nur über drei
> Messbereiche verfügt. Man hört wie beim Umstellen des Messbereiches ein
> Relais schaltet.

Doch, das ist mir aufgefallen. Ich hab nur nicht tiefschürfend darüber 
nachgedacht, an welcher Stelle da etwas umschaltet.

> Dir hätte auch auffallen können, dass Wittig/Welec die optimale
> Darstellung der Signale in ihrer Produktbeschreibung bei 5V/500mV/50mV
> angibt.

Ist wirklich an mir vorbeigegangen, stimmt.

> Die Summe der so gesammelten Informationen führt dann zu der
> unglaublichen Erkenntnis, dass die 2V/1V Darstellung nur eine
> Vergrößerung der 5V-Messung sind

Das dachte ich mir schon, aber 1V/div sieht eben nicht aus wie eine 
Vergrößerung der 2V/div-Darstellung, weil sich auch die Nullage gewaltig 
verschiebt und das Rauschen nicht nur doppelt so groß, sondern 
unverhältnismässig größer wird. Daher frug ich. :)

> 200mV/100mV der 500mV-Messung und wer hätte das gedacht, die 20mV/10mV
> die der 50mV-Messung. ;)

Das wiederum wird dann selbst mir klar.

Bin zwar kein Elektroniker, aber auch kein Depp. :D

/Hannes

von egberto (Gast)


Lesenswert?

Sehr interessant - das mit dem abgetrennten Kanal hatte ich auch 
verdrängt; über die 1V/2V/5V Thematik hatte ich noch nicht nachgedacht, 
allerdings wäre ich nie auf den Gedanken eines "Softwaretricks" 
gekommen.

Wieder eine Anfängerfrage: Was genau verbessert SLOGs FPGA Design? (ist 
wohl noch sehr beta, sonst hätten es ja alle fest installiert..) (bitte 
sagt jetzt nicht, ich soll das russische Forum durcharbeiten ;-)!)

Vielen Dank für die Infos....

egberto

von Kurt B. (kurt)


Lesenswert?

Danke branadic!

Slog's Design verbessert wohl hauptsächlich die Geschwindigkeit weil es 
Hardwaremultiplikationen ermöglicht und auch die Abfrage der 
Bedienelemente in Harware realisiert. Dadurch wird die CPU stark 
entlastet.

http://www.kurts-werkstatt.de/wittig/slog.avi (3,21MB)

Das Video ist in Echtzeit! Man beachte die flüssige Verstellung von 
Zeitbasis, Vertikalauflösung und Signallage. Viel mehr kann man 
allerdings noch nicht machen, da sich Slog auf das FPGA Design 
konzentriert und die Software entsprechend mager ausgerüstet ist 
(Messungen sind nicht möglich).

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier noch ein Foto.

Wieso habe ich nicht die bunten Sample Punkte der ADCs?

Probiert hatte ich
Slog_Project_with_Nios_v0.1.3.zip und
Hello_W2000_v0_1_4.zip

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

oje, ich weiß gar nicht wo ich mit den Richtigstellungen und Erklärungen 
anfangen soll...

Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die 
Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben- 
sollten am besten nicht weiterlesen! ;-)

Also erstmal, nehmt euch doch mal meinen Schaltplan des Oszi's zur Hand:
http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment.pdf
Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.
Links oben im Schaltplan seht ihr die beiden Relais die dieses 
Umschalten erledigen- das Klack ist ja auch deutlich zu hören. Je 
nachdem in welchem Messbereich ihr euch befindet wird das Eingangssignal 
unterschiedl. stark gedämpft. Wenn ihr euch in 5V; 2V; oder auch 1V 
befindet wird das Eingangssignal durch das Widerstandsnetzwerk von 
Relais 1 bedämpft(geteilt) und zusätzlich durch das Netzwerk unter 
Relais 2.
Befindet ihr euch in einem der Messbereiche 500mV, 200mV, 100mV, so ist 
nur das Relais 2 in off- Position und teilt das verkleinert das 
Eingangssignal ca. um den Faktor 10 (genaueres dazu steht recht 
ausführlich in meinem Messprotokoll Nr.1)
Das bedeutet also, das jegliche folgende Signalverarbeitung auf die 3 
Fälle 10mV, 20mV und 50mV Messbereich zurückzuführen ist. Die Teilung am 
Anfang ist relativ problemlos und muss nicht weiter beachtet werden.

So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch 
das ist kein SW- sondern ein Schaltungstrick. Ihr habt den Schaltplan 
noch zur Hand? Unten in der Mitte befinden sich 3 Op's (AD8131) und 
zwischen dem 1ten und 2ten, bzw. dem 2ten und 3ten unterhalb jeweils 
elektronische Schalter (U7AD) (deshalb kein Klack!). Nur wenn der 
Schalter geschlossen ist wird der nachfolgende AD mit einem 
differentiellen Eingangssignal
versorgt und das Signal um den Faktor 2 verstärkt, ist der Schalter 
offen liegt nur am positiven Input des AD das Eingangssignal an- seine 
Verstärkung beträgt in diesem Fall 1.
Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1; 
1:2 oder 1:4 Verstärkung statt- ob jetzt durch einen weiteren Kniff das 
wieder zu 1:2:5 hingebügelt wird wollte ich noch prüfen, glaub es aber 
eigentl. nicht.

Zur Vollansteuerung der ADC ist an beiden (diff) Eingängen ein Signal 
von ±0,3125V nötig- d.h. das Signal am positiven Ausgang des letzten AD 
kann/ soll sich um ±0,3125V um den Mittelwert von +1,4V ändern, am 
negativen Ausgang des AD ebenso, nur eben um π Phasenverschoben. Auch da 
wollte ich nochmal checken inwieweit das passt.

Zu Slog's VHDL Design:
Prinzipiell muss man sagen das es mehrere funktionierende VHDL Designs 
gibt, nicht nur die von dir oben erwähnten. Die VHDL Arbeit basiert 
allerdings immer auf der großartigen Vorarbeit von Slog- er hat sich nun 
mal als erstes mit Oszi intensiv auseinandergesetzt und es als VHDL- 
Entwicklungsboard missbraucht.
D.h. den einzelnen VHDL Designs liegen ganz unterschiedl. Zielsetzungen 
zu Grunde. Während der Eine über spezielle Aspekte der internen 
Datenverarbeitung seine Masterarbeit schreibt- will der Andere "nur" 
sein VHDL verbessern... aber das Gute daran ist, das man all diese 
Arbeiten durchaus zusammenführen kann.
Alle VHDL Designs sind bislang nur temporär ausgelegt , d.h. nach dem 
Ausschalten des Oszi's ist alles wieder weg (nicht weiter tragisch, das 
aufspielen dauert ca. 10s!)- es werden keine Daten intern überschrieben 
und man kann nichts kaputt machen. Das liegt einfach daran weil derzeit 
von jedem Design nur spezielle Aspekte getestet/ entwickelt werden.
Und ja- man kann mit Slog die einzelnen ADC Werte farbig darstellen 
lassen, so wie in meinem Foto im Messprotokoll 2. spiele dich einfach 
mal mit den Tasten- wie gesagt du kannst dabei nichts kaputt machen- 
maximal haben sie keine Auswirkung da sie halt via VHDL-Code nicht 
verarbeitet werden. Das aktuelle Slog Design hat übrigens genau die ADC 
Kalibrierung und vor allem das Timing der einzelnen ADC zum Thema- 
deshalb diese schöne farbige Darstellmöglichkeit. Die Zeitbasis lässt 
sich nicht verändern, ist glaub ich fix auf 50ns/Div eingestellt. (damit 
müsste jeder gemessene ADC-Wert einem Pixel auf der zeitl. Achse des 
Displays entsprechen.

so, jetzt ist aber erstmal genug-
Gruß, brunowe

von Johannes S. (demofreak)


Lesenswert?

Bruno We wrote:
> Vielleicht vorab noch ein Hinweis: Leute die sich nicht in die
> Funktionsweise des Oszi's hineindenken wollen- s.h. Zitat weiter oben-
> sollten am besten nicht weiterlesen! ;-)

Ich les trotzdem weiter. Nicht hauen bitte. :D

> Das Umschalten zwischen den Bereichen 5V-2V-1V etc. ist kein SW Trick.
> [...]
> Anfang ist relativ problemlos und muss nicht weiter beachtet werden.

Klar.

> So, wie geschieht nun die Umschaltung zwischen 50mV, 20mV und 10mV? Auch
> [...]
> Soweit findet in diesem Bereich also (abhängig vom Messbereich) ein 1:1;
> 1:2 oder 1:4 Verstärkung statt-

Also wird das Rauschen hauptsächlich von diesen OPV und vllt noch den 
elektronischen Schaltern bestimmt?

> ob jetzt durch einen weiteren Kniff das wieder zu 1:2:5 hingebügelt wird
> wollte ich noch prüfen, glaub es aber eigentl. nicht.

D.h. dort wird dann das 1:4-Rauschen in Software auf 1:5 erhöht, 
deswegen sieht das auch unverhältnismässig größer aus als bei 1:2?


Es ist übrigens schön, wenn einem das mal ein Berufener so erklärt, dann 
versteht man auch gleich was (oder man beginnt wenigstens damit). In die 
Schaltung allein habe ich geguckt wie die sprichwörtliche Sau ins 
Uhrwerk.

Jetzt muss ich nur noch irgendwie die Trennlinie bzw. das Zusammenspiel 
von dem, was Hayo macht mit dem, was Slog da bearbeitet, begreifen.

/Hannes

von Guido (Gast)


Lesenswert?

Hallo Buno We,

zur Spannungsverstärkung noch folgendes: Der OPA656 ist in der
Verstärkung zwischen 1 und 1,25 umschaltbar. So entstehen die
Gesamtverstärkungen von 1, 2.5 und 5. Das ist auch nicht ganz
uninteressant, da bei 1,25-facher Verstärkung eine Frequenzkompensation
für den OPA zugeschaltet wird, die die hochfrequenten Störungen etwas
reduziert.

@ Kurt: Danke für das Video, wirklich beeindruckend.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Guido,

das mit dem Verstärkung des OPA656 war mir noch nicht ganz klar- (das 
mit der Frequenzgangkompensation schon). Wie kommst du auf 1:1,25?
Klär uns doch mal über die Fkt. des OPA656 auf...

von Blue F. (blueflash)


Lesenswert?

Alter Schwede hier ist ja was los...

Ich dachte ich hätte in diversen älteren Beiträgen schon mal auf den 
Grund des unterschiedlichen Rauschens hingewiesen. Allerdings gebe ich 
zu, dass es auch etwas nervig ist alle alten Beiträge durchzuforsten. 
Daher möchte ich hier ergänzend zu Brunos Ausführungen mit wenigen 
Worten die Problematik erklären:

- die einzelnen Stufen haben durchaus jede Ihre eigene 
Spannungsvorteilung (wie Bruno ja auch schon anmerkte - kein Fake also)
- die Übersetzung ist jedoch so (unglücklich) gewählt, dass in den 
unterschiedlichen Stufen bei der Grafikausgabe unterschiedliche 
Skalierungsfaktoren nötig sind.
- bei den 5er Bereichen ist der Skalierungsfaktor ca. 2, bei den 2er und 
1er Bereichen ist er ca. 3,3

D.h. wenn die Offsetabweichung eines ADC 3 ist (z.B. 3012 oder 0321), 
dann stellt sich das in den 5er Bereichen mit eine Peak von 6 Pixeln 
dar, wärend sich das in den anderen Bereichen mit einem Peak von 10 
Pixeln darstellt.

Das ist schon ein deutlicher Unterschied.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Bruno We,

wir sollten uns in den Hardware-Thread verziehen. :-))

Ist U3 am OPA656 geöffnet, bilden R21 und R14 seine Gegnkopplung.
Rechnerische Spannungsverstärkung 1,244, wird in der Praxis wohl
1,25 sein. Schließt U3, ist der OPA ein Impedanzwandler, in beiden
Fällen wirkt R14 auch als Mindestlast.

Durch ide Wirkung der Kompensation bin ich auf die Idee gekommen
mit Kondensatoren zu experimentieren. Leider halt ohne großen
Erfolg.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Hallo Hayo,

wo findet denn die Skalierung der ADC-Werte statt? Ich finde es
nicht. Heute abend möchte ich mal mit den Verstärkungen spielen,
da müsste ich die Skalierung für die 1er und 2er Bereiche
ändern.

Danke, Guido

von Blue F. (blueflash)


Lesenswert?

Guido wrote:
> Hallo Hayo,
>
> wo findet denn die Skalierung der ADC-Werte statt? Ich finde es
> nicht. Heute abend möchte ich mal mit den Verstärkungen spielen,
> da müsste ich die Skalierung für die 1er und 2er Bereiche
> ändern.
>
> Danke, Guido

In der Datei tc_vars.cpp Zeile 1437 (float scale_factor[16])

Gruß Hayo

von Guido (Gast)


Lesenswert?

@ Hayo,

danke, Guido

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

ich habe mal die Testfunktionen 1 und 2 so erweitert, dass sie
für den gewählten Test_Channel wirken. Die Einstellungen werden
im Protected_Flash angehängt.

Schau dir das bitte mal durch und pflege es ggf. in deine Quellen
ein. Bei meinem W2012A scheint es für beide Kanäle zu funktionieren,
ich habe 4 Kanäle vorgesehen, kann die aber nicht kontrollieren.

Über die Verstärkungseinstellungen berichte ich morgen, heute schaffe
ich wohl nicht mehr viele Tests.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

ja das hatte ich ohnehin vor, aber da Bruno gerne schnell testen wollte 
hab ich die Version etwas unfertig rausgehauen...

Wie ich sehe hast Du auch schon schön nach einzelnen Spannungsstufen 
getrennt, kann ich dann ja so 1:1 übernehmen - spart Zeit ;-)

Danke und Gruß Hayo

von Ronny S. (ronnysc)


Lesenswert?

Hallo,

habe mal eine Frage zur PC Software. Wie kann ich die gespeicherten 
Messwerte bzw. Kurven mit der PC Software übertragen. Ich kann nur die 
aktuelle Kurve in den PC laden.
Werde dann auch mal die FW1.2.BF.0.50 nach Flashsicherung aufspielen. 
Aber das kann ja bekanntlich dauern...
Gruß
Ronny

von Ronny S. (ronnysc)


Lesenswert?

Die Version FW1.2.BF.0.50 läuft auf meinem W2024A sehr gut. Habe dann 
mal die FW1.2.BF.0.54 aufgespielt und das Nullinien-Rauschen war nach 
einem "Calibrate Zero Lines" erheblich stärker auf Kanal 1-3, Kanal 4 
war besser. Werde jetzt erstmal die vorige Version aufspielen und das 
nochmal versuchen. Mauellen Abgleich der ADCs habe ich nicht 
vorgenommen.
Gruß
Ronny

von Ronny S. (ronnysc)


Lesenswert?

Nach Aufspielen der FW1.2.BF.0.50 und "calibrate zero line" ist das 
Nullinien-Rauschen bedeutend geringer als mit FW1.2.BF.0.54, Kanal 3 ist 
am Besten.

von Ronny S. (ronnysc)


Lesenswert?

Eine Datenübertragung zum PC geht auch nicht mehr, habe jetzt erstmal 
das Original wieder aufgespielt. Schade...

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo alle,

ich habe mir mal Gedanken zum Userinterface gemacht. Wenn jemand
Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.
Zufrieden bin ich eigentlich nur mit der Triggerposition, die
läuft in ihrem begrenzten Laufstall imho sehr schön.

@ Hayo: Was ich geändert habe steht im zip unter anders2.txt. Das
ist sicher nur ein Proof of Concept und lässt sich mit Sicherheit
noch verbessern. Bei meinem momentanen Codeverständnis kriege ich
es aber nicht besser hin. :-(

Gruß, Guido

von Johannes S. (demofreak)


Lesenswert?

Guido schrieb:
> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.

30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40 
Stunden dem Flashen zugeschaut?

/Hannes

von Ronny S. (ronnysc)


Lesenswert?

Direkt über eine serielle Schnittstelle geht es recht fix, nur mit einem 
USB-RS232 Adapter dauerte es bei mir ewig (ca. 10h).

von Guido (Gast)


Lesenswert?

Hallo Ronny Schmiedel,

was nutzt die USB-Übertragung, wenn das Gerät sonst nur sehr
eingeschränkt nutzbar ist? Ich habe mir das Welec eigentlich
auch deswegen gekauft, hilft aber nicht weiter. Also geh zum
Regal, nimm den K&R und lege los. :-)

@ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum
Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst
nehmen) ein Laptop mit XP gekauft. Da macht man sich aber
natürlich Gedanken: das USB-Interface würde um keinen Deut
weiterhelfen, auch über RS232 kann es höchstens 2 Minuten
dauern die Daten zu Übertragen. Teste mal!

Gruß, Guido

von Johannes S. (demofreak)


Lesenswert?

Guido schrieb:
> @ Johannes: Nö, ne knappe halbe Stunde brauche ich noch zum
> Flashen, habe als Linuxer aber extra (naja, nicht ganz ernst
> nehmen) ein Laptop mit XP gekauft.

Hm, ich hab bisher mit dem fwupload.pl rumprobiert (bekomme ich nicht 
ans Rennen) und dann in einer Virtualbox mit USB->RS232-Adapter. Das 
funktioniert, dauert aber ca. 1,5h.

Auch auf die Gefahr hin, dass ich wieder darauf hingewiesen werde, dass 
das alles schon mal schön übersichtlich irgendwo beschrieben steht: wie 
muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei 
antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt 
offenbar auch das fwupload.pl stehen und wartet bis zum 
St.-Nimmerleins-Tag.

/Hannes

von Johannes S. (demofreak)


Lesenswert?

Johannes Studt schrieb:
> muss das Oszilloskop auf das Schreiben der Zeilen der Firmwaredatei
> antworten? Bei mir sagt das irgendwie keinen Mucks, deswegen bleibt
> offenbar auch das fwupload.pl stehen und wartet bis zum
> St.-Nimmerleins-Tag.

Kaum sucht man nochmal, findet man plötzlich was: ein + sollte da 
auftauchen, das ist wohl der Prompt des GERMS-Monitors. Eben schreibe 
ich deine Flash-Datei mit Minicom ins Oszi, mal sehen, wie lange das 
dauert.

/Hannes

von Johannes S. (demofreak)


Lesenswert?

Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von 
Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit 
Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier 
einwandfrei.

Das Leben ist schön. :D

/Hannes

P.S: ich liebe Monologe.

von Blue F. (blueflash)


Lesenswert?

Johannes Studt schrieb:
> Guido schrieb:
>> Lust zum Testen hat ist eine Rückmeldung erwünscht. Ich habe nach
>> ca. 30 Flashvorgängen kein Gefühl mehr dafür wie es vorher war.
>
> 30? Dauert das nur bei mir so lange, oder hast du jetzt echt ca. 40
> Stunden dem Flashen zugeschaut?

Hab jetzt über 100 Flashvorgänge hinter mir. Dauert ca. 21 Minuten pro 
Durchlauf - allerdings mit echtem RS232 (auch an langsamen Rechnern). 
Ich hatte unter Linux einen Kommandozeilenuploader entwickelt, der hat 
es in 2 bis 3 Minuten geschafft, allerdings nicht zuverlässig genug. Da 
hab ich dann irgendwann aufgehört und den WELEC-Updater genutzt, der ist 
wenigstens zuverlässig.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Johannes Studt schrieb:
> Na juchhu aber auch. Eben hab ich bemerkt, dass der Welec-Updater von
> Markus ja auch für Linux verfügbar ist. Nachdem ich jetzt bissi mit
> Lazarus und Freepascal rumgezappelt habe, läuft das Ding hier
> einwandfrei.
>
> Das Leben ist schön. :D
>
> /Hannes
>
> P.S: ich liebe Monologe.

Ich mach das jetzt mal zum Dialog:

Die Linux-Version läuft bei mir mindestens zehnmal länger als die 
Windowsversion. Wie ist das bei Dir?

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Da hab ich keinen echten Vergleich, weil ich die Windowsversion 
ebenfalls unter Linux in einer XP-VM (und das zu allem Überfluss auch 
noch mit dem USB->RS232-Adapter) laufen hatte. In dieser Konstellation 
haben sie beide ca. gleich lange gebraucht.

Ich hatte bisher angenommen, dass das DSO der Part ist, der bremst, weil 
ja der Welecuploader nix anderes macht, als auf das '+' zu warten und 
dann sofort die nexte Zeile abzuwerfen.

Jetzt werd ich mal das Notebook meiner Frau zünden und mit der dort noch 
anwesenden echten RS232-Schnittstelle Vergleiche anstellen.

/Hannes

von Johannes S. (demofreak)


Lesenswert?

Ja, das kannste vergessen. Am Notebook meiner Frau benimmt sich das DSO 
bockig. Nach ca. 15% bricht die Datenübertragung ab und der Welecupdater 
wartet, bis die Elbe austrocknet. Bis kurz vor den Hänger meint er, er 
würde ca. 52 Minuten brauchen wollen (Windowsversion).

Ich werd's jetzt nochmal mit einer Linux-LiveCd versuchen.

von Johannes S. (demofreak)


Lesenswert?

So, das hat jetzt 1:50 gedauert, also deutlich langsamer als unter 
Windows, dafür isses aber durchgelaufen.

von Uwe S. (us1)


Lesenswert?

Ja, ich habe ähnliche Erfahrungen gemacht. Ich habe unter Windows keinen 
kompletten Download zustande gebracht(auf zwei verschiedenen Laptops 
getestet). Unter Linux hat es dann geklappt, wenn auch etwas langsamer.
Der Upload klappte problemlos auch unter Windows.

Uwe

von Blue F. (blueflash)


Lesenswert?

@Guido

Ich bin gerade dabei die Erkenntnisse der letzten Tage in die aktuelle 
Version einfließen zu lassen. Deine Erweiterung der Testfunktion 1 + 2 
hab ich unverändert übernommen. Die Änderung der Flashroutine hab ich 
nicht übernommen, da die Zero-offsetwerte schon im normalen 
Configbereich des Flash gespeichert werden. Eine weitere Speicherung im 
Protected-Bereich ist also nicht nötig.

Insbesondere implementiere ich gerade die neue Integerscalierung - der 
Upload läuft noch - ich bin gespannt was rauskommt.

Ansonsten beisse ich mir zur Zeit die Zähne daran aus diesen blöden 
Freeze-Fehler zu finden der das Signal bei Zeitbasen größer 5ms 
einfrieren läßt. Immerhin hab ich das Problem schon soweit eingekreist, 
dass ich weiß, das ich mir den Bug zwischen version 0.32 und 0.33 
eingebaut habe. Es kommt einfach vom ADC kein Data-Available-Signal mehr 
an. Die berühmte Nadel im Heuhaufen...

Ich halte Euch über die Fortschritte auf dem Laufenden.


Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Upload ist fertig,

erstes Ergebnis: Super! Genauigkeit ist genau wie bei der Floating-Point 
Skalierung, aber die Geschwindigkeit ist im Einkanalbetrieb so schnell, 
dass ich die Anzahl der Bildwiederholungen nicht mitzählen kann für 
einen Vergleich.

Gefühlt würde ich sagen 2 - 3 Mal schneller.

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

das hört sich ja gut an. Wegen dem Flash-Eingriff: Da habe ich
schlicht nicht kapiert was gespeichert wird und wollte sicher
gehen.

Mit dem Freeze: ich habe den Eindruck, dass eine Variable überläuft.
Wenn man ein paar mal rauf- und runterschaltet, werden immerhin
noch Teile des Bildschirms aktualisiert (in manchen Zeitbereichen).

Ich hänge noch mal die Erläuterung zu den Drehgebern an, ist zwar
suboptimal aber damit bekomme ich die Pfeile synchron zur
Drehung auf dem LCD aktualisiert. Ev. wäre das ja noch was für
die nächste Version.

von Guido (Gast)


Lesenswert?

Achso,

natürlich noch:

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Mit dem Freeze: ich habe den Eindruck, dass eine Variable überläuft.
> Wenn man ein paar mal rauf- und runterschaltet, werden immerhin
> noch Teile des Bildschirms aktualisiert (in manchen Zeitbereichen).

Das liegt daran, das bei Änderung der Zeitbasis der ADC-Durchlauf neu 
gestartet wird, dadurch wird dann zumindist ein Signaldurchlauf gelesen 
- das wars dann aber auch.

> Ich hänge noch mal die Erläuterung zu den Drehgebern an, ist zwar
> suboptimal aber damit bekomme ich die Pfeile synchron zur
> Drehung auf dem LCD aktualisiert. Ev. wäre das ja noch was für
> die nächste Version.

Hast Du gesehen, dass ich einen ähnlichen etwas einfacheren Ansatz auch 
schon implementiert habe? Bei irgendeiner User-Interface-Eingabe werden 
alle weiteren Berechnungen und Ausgaben abgebrochen und erstmal der 
Drehgeber ausgewertet. Dann erst wird weiter auf dem Schirm ausgegeben. 
Das hab ich einfach mit einem Flag realisiert (UI_request), das in den 
entsprechenden Interrupt-Serviceroutinen gesetzt und am Ende des 
Hauptschleifendurchlaufs wieder gelöscht wird.

Gruß hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ja, das UI_request habe ich schon gesehen, aber es wirkt nicht
richtig. Deshalb meine Idee die Änderung in Tomcat anzusetzen.
Das wirkt dann auch und benötigt nur sehr wenige Änderungen.

Mit dem freeze: ich habe nicht den Eindruck, dass es voll
hängt (kann mich aber auch täuschen). Mir kommt es eher vor,
als ob die Grafikaufbereitung außerhalb des sichtbaren
Bereiches erfolgt (erst verschwindet 1/3 des Schirms, bei
größerer Zeitbasis dan 2/3 anschließend passiert garnichts
mehr).

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Nach meinen Vorankündigungen hier die aktuelle Beta. Neu ist die rein 
integerbasierte Grafik, die entsprechend schnell geworden ist. Angepasst 
ist die normale Siganlausgabe, der delayed Modus und die XY-Darstellung.

Die erweiterte Testfunktion 1 + 2 für den manuellen Nullabgleich von 
Guido ist auch schon drin (ungetestet).

Morgen (bzw. heute) werde ich mich mal weiter dran machen und den blöden 
Freeze-Bug suchen, damit ich mal endlich dazu komme die FFT weiter zu 
machen.

guats Nächtle

Hayo

von Kurt B. (kurt)


Lesenswert?

Hallo Hayo,
die Geschwindigkeit ist schonmal super. Vor allem im XY-Modus!

Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der 
Nullpunkt.

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:

> Wenn ich da jedoch die Vektordarstellung abschalte, verschwindet der
> Nullpunkt.

Danke für die schnelle Rückmeldung. Fehler ist schon lokalisiert, da ist 
mir doch wieder so ein typischer copy and paste Fehler durchgegangen.

Ist in der nächsten Version beseitigt.

Gruß Hayo

von Kristian T. (krissy1983)


Lesenswert?

Hallo,

ich bin seit einiger Zeit Besitzer eines W2014a und verfolge die 
Entwicklung hier aufmerksam.

Ich habe gerade die Beta V0.55 ausprobiert. Der Unterschied in der 
Darstellungsgeschwindigkeit ist echt beeindruckend.

Bezüglich des Flashens will ich mal meine Erfahrungen darstellen. Das 
Flashen dauert bei mir ca. 15-20 min auf einem System mit Win XP und 
einem USB-RS232-Adapter der Firma systec-electronic. Mit der "normalen" 
RS232-Schnittstelle habe ich keine Verbindung mit dem Oszi bekommen.


Viele Grüße

Kristian

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Kristian da kannst du dich glücklich schätzen- ich bin froh wenn ich's 
so in 4-5 Std. hin bekomme- ist jedes mal ne Nacht füllende Aktion.
(Mit Delock Adapter USB to seriell)

Noch ein paar Fragen an die Programm-Kundigen:
Ich spiel mich gerade mit dem DAC Abgleich.
1.) Was bedeuten den die Zeilen:
CH1 Zero Sign Offs 1   = 2<\n>
CH1 Zero Sign Offs 2   = 0<\n>
CH1 Zero Sign Offs 3   = -1<\n>
(sind das die abgelegten DAC Werte für die Messbereiche 1:2:5 ?)
Irgendwie kann ich bei Shift +W bzw. auch bei Shift +E keine Änderung am 
Welec Display erkennen (wohl aber an der Terminal Ausgabe)- schade- ich 
hab da einen echt groben Offset.

Schön wäre es, die "Zero Level Werte" direkt eingeben zu können - für 
jeden der Messbereiche 1:2:5er extra.

Sobald ich Cal. Zero lines durchführe, ist der offset zwar korrigiert, 
aber leider auch meine Optimierung der ADC's futsch.

2.) Was hat den der Enable Debug mode für einen praktischen Nutzen?

3.)Was bedeuten den die Zeilen beim Start des Oszi, die auf dem 
seriellen Terminal ausgegeben werden, speziell folgende:
...
Volt_Correct_float   = 1.625<\n>
Scale Factor         = 3.250<\n>
CH1_DAC_Offset       = 8194<\n>
multi_active         = 1<\n>

Auf dem Hardware Sektor gibts auch Neuigkeiten- werde ich später im HW 
Thread posten.

Gruß, brunowe

von Guido (Gast)


Lesenswert?

Hall0 Bruno We,

zu 1): Die Zeilen geben die Zahlenwerte für die Offsets der
einzelnen ADC an, sollten also dieselben sein wie die, die
beim Shift+W drücken in einer Zeile angezeigt werden. Die
Änderung auf dem Bildschirm macht sich erst bemerkbar, wenn
du den Eingangswahlschalter hin- und wieder zurückdrehst.

Ich gehe so vor: Cal. Zero-Lines, Offset stimmt für einen
Bereich (norm. nehme ich einen 5er Bereich). Umschalten in
nächsten Bereich (2er) und mit Shift W optimieren. Als letztes
noch den 1er Bereich und dann speichern.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Oops,

oben immer Shift+Q einsetzen (statt Shift+W).

Guido

von Blue F. (blueflash)


Lesenswert?

He Folks,

erst mal abwarten. Ich hab mich in den letzten Tagen ordentlich 
reingekniet um die Jungs an der Hardwarefront zu supporten. Nachdem ich 
den ADC-Abgleich etwas nachlässig implementiert hatte, hab ich jetzt 
Nägel mit Köpfen gemacht und einen Abgleich gemacht der für alle vier 
Kanäle zuverlässig arbeitet. Weiterhin bin ich noch am DAC-Abgleich 
zugange. Die Graphikausgabe hab ich nochmal optimiert, so dass die 
Skalierung jetzt ganz ohne Multiplikation auskommt (merkt man im delayed 
Modus).

Als Schmankerl hab ich die bisherigen Testschalter ins Utility-Menü 
gelegt, so dass man sie bequem betätigen kann auch ohne Terminal 
(ADC-Abgleich, DAC-Abgleich, Gridumschaltung, Graphikmodusumschaltung). 
Die neue Version gibt heute Abend - mal sehen wie weit ich noch komme.


Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

@Hayo- das hört sich ja Spitze an!

@Guido: ich glaube du verwechselst da ADC Abgleich mit dem DAC Offset- 
Abgleich!

Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt 
soweit im Griff, nur der generelle Offset stimmt eben nicht.
CH1 Zero Sign Offs 1   = 2<\n>
CH1 Zero Sign Offs 2   = 0<\n>
CH1 Zero Sign Offs 3   = -1<\n>
Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's 
sein, schon eher die DAC Offset Werte wie ichs vermute.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Bruno We schrieb:

> Wie gesagt, den ADC Abgleich der einzelnen ADC pro Kanal hab ich jetzt
> soweit im Griff, nur der generelle Offset stimmt eben nicht.
> CH1 Zero Sign Offs 1   = 2<\n>
> CH1 Zero Sign Offs 2   = 0<\n>
> CH1 Zero Sign Offs 3   = -1<\n>
> Diese 3 Werte können nicht die ADC Kalibrierungswerte der 4! ADC 's
> sein, schon eher die DAC Offset Werte wie ichs vermute.

Diese Werte sind die Offsetkorrekturwerte für die DACs, die den 
Nullpunkt der Eingangs-OPVs steuern. Pro Kanal gibt es drei Werte, und 
zwar immer für alle 5er Bereiche (Nr. 3) für aller 2er (Nr 2) und die 
1er (Nr. 1).

Der DAC wird von 0 bis 16384 ausgesteuert, die Mitte des Grids liegt bei 
8192 (idealerweise). Der Offset korrigiert mit einem entsprechenden 
Faktor diese Nulllage.

Bin mit dem DAC-Abgleich schon recht weit, teste nur noch kleinere 
Änderungen.

Die 0.56 gibts dann nachher...

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

@Hayo...
so macht das Sinn, Danke.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier ist sie, bin mit dem DAC-Abgleich nicht ganz fertiggeworden. 
Aber seht selbst - geht nach dem flashen einfach mal ins Utility Menü 
und probiert es aus. Wenn Ihr die ADC-Werte sehen wollt die der 
Abgleichermittelt, dann müßt Ihr ein Terminalprogramm laufen lassen, da 
werden dann die ermittelten Werte ausgegeben.

Ansonsten wie gesagt habe ich die Grafikroutine nochmal beschleunigt - 
sieht man im Normalbetrieb nicht so deutlich, aber im Delayed-Mode wo ja 
doppelt so viele Signale geschrieben werden merkt man es schon.

Viel Spaß

Hayo

von Blue F. (blueflash)


Lesenswert?

Bin immer noch am DAC-Abgleich. Leider ist das ziemlich Zeitaufwändig, 
da man nach jeder Kleinigkeit die man testweise ändert warten muß bis 
die Firmware wieder geladen ist bevor man weitermachen kann. Bin aber 
schon recht weit.

Übrigens geht der DAC-Abgleich schon so ein bißchen wenn man vorher die 
Nulllage des entsprechenden Kanals auf die Mitte des Grids stellt.

Hat es schon jemand ausprobiert?

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.
Ich hatte übersehen, dass die Linien in Schirmmitte sein
müssen und so hat jeder Tastendruck den Offset um 1 div nach
unten verschoben. Geht das momentan nur für Kanal 1 oder wie
kann man umschalten? Aufgefallen ist mit, dass dieser Abgleich
jetzt eh nur noch für die 1er Bereiche nötig sind die 2er
stimmen nach AutoZero im 5er Bereich auch. Zufall?

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> Hallo Hayo,
>
> ich habe letzte Nacht noch schnell probiert, aber ohne Erfolg.
> Ich hatte übersehen, dass die Linien in Schirmmitte sein
> müssen und so hat jeder Tastendruck den Offset um 1 div nach
> unten verschoben. Geht das momentan nur für Kanal 1 oder wie
> kann man umschalten?

Nein, geht für alle Kanäle gleichzeitig.

> Aufgefallen ist mit, dass dieser Abgleich
> jetzt eh nur noch für die 1er Bereiche nötig sind die 2er
> stimmen nach AutoZero im 5er Bereich auch. Zufall?

Nein, hab an der ursprünglichen Zero-Routine auch ein paar Kleinigkeiten 
geändert.

Die Search Zero und die Calibrate DAC Funktion haben zwar das gleiche 
Ziel, arbeiten aber völlig unterschiedlich. Ich bin mir noch nicht ganz 
sicher, ob Calibrate DAC die alte Funktion komplett ersetzen wird oder 
nur für's Feintuning als Zusatzfunktion bleibt. Mal sehen.

Gruß Hayo

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

hast du von der Software aus zugriff auf den Programm-Speicher? Evtl. 
würde sich ein zweiter Bootloader rentieren, der den Speicher schneller 
vollbringt. Ich stelle mir das Entwickeln bei den Upload-Zeiten ziemlich 
langweilig vor ;-)

Wirklich ein super Projekt.

Gruß,
Stefan

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

Neue FW- Spitzenarbeit!!!
Super, mit dem erweiterten Menü- so stell ich mir das vor!
Jetzt noch den DAC Offset hinbügeln und dann "Beta" aus der Bezeichnung 
streichen.

Also auch mein Rauschen ist, bedingt durch den tollen ADC- Abgleich, 
wesentl. besser. (Seltsamerweise Kanal 1 jetzt viel besser als Ch2- 
liegt auch tw. an meiner kleinen HW Modifizierung- lass mich bitte in 
dem Glauben!)

Soweit ich's bisher testen konnte, echt erstklassige Arbeit von dir!

Gruß, brunowe

von Johannes S. (demofreak)


Lesenswert?

Hm,

bei mir wird das Rauschen immer nur schlimmer. Sobald ich die "Search 
Zero Lines"-Funktion verwende, bekomme ich Rauschen im Bereich von einem 
halben bis zu einem ganzen Div, je nach Messbereich und 
Erwärmungszustand. Schlimm sind v.a. die Kanäle 3 und 4.

"Calibrate ADC" verändert an der Intensität des Rauschens im Grunde nix, 
es verändert nur ein wenig die Form.

"Calibrate DAC" lässt die Nulllage je nach Messbereich mit jedem 
Tastendruck um bis zu ein Div nach unten wandern, auch wenn ich vorher 
die Nulllage aller Kanäle auf die Mitte drehe. "Search Zero Lines" fängt 
das wieder ein, allerdings habe ich trotzdem auf den Kanälen 3 und 4 
immer ein negatives Offset.

Mit dem Offset könnt ich leben, aber das Rauschen macht das Gerät in 
meinen Augen ziemlich unbenutzbar.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"
Meine aktuellen Rauschpegel mit der neuen FW nach ADC Calibration.
Probe- Klemme auf Gnd.

von Kristian T. (krissy1983)


Lesenswert?

Hallo,

vielen Dank für die neue Firmware.

Bei meinem 2014A liegen die Kanäle 3 und 4 auch immer im negativen 
Bereich (Kanal 3 ca. 500mV, Kanal 4 ca. 1V).

"Calibrate DAC" führt bei mir auch zu einer Verschiebung der Signale in 
den negativen Bereich. Dies scheint aber stark vom jeweilig 
eingestellten Spannungsbereich abzuhängen.

Das Rauschen erscheint bei mir (zumindest für Kanal 1 und 2) deutlich 
verringert.

Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die 
Beschriftungen der anderen Kanäle sind vorhanden.

Gruß

Kristian

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ich krieg hier noch die Krise...

Muß erstmal etwas Frust ablassen, Hrmpf. Da tut die positive Rückmeldung 
von Euch ganz gut. Bin immer noch an dem besch... DAC-Abgleich. Um die 
Situatuion kurz zu schildern:

Vor dem Abgleich wird per Coding alles auf die Nulllinie (Gridmitte) 
gefahren, dann der Abgleich durchgeführt. Trotzdem bleibt ein 
Restoffset. Wenn ich die Nulllinien manuell auf die Gridmitte einstelle 
klappt alles ordentlich. Ich hab alles dazwischen gecheckt und auch 
schon eine Verzögerung eingebaut weil ich mir dachte dass die DACs 
eventuell nicht schnell genug regeln - hilft nix.

Morgen hab ich leider nicht viel Zeit dafür, daher hier erstmal die 
inoffizielle beta 0.57 nur als Flash zum ausprobieren.

Wie gesagt, wenn die Nulllinien auf Gridmitte sind reichen 2 - 3mal 
Drücken und die die Lage stimmt. Bitte zu beachten:

- es wird zur Zeit nur der aktuell eingestellte Bereich
 (1er, 2er oder 5er) calibriert.
- das Ergebnis wird zur Zeit noch nicht ins Flash geschrieben.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Kristian Trenkel schrieb:

> Bei mir fehlt die blau 3 neben der Anzeige der V/Div für Kanal 3. Die
> Beschriftungen der anderen Kanäle sind vorhanden.

Ja das passiert bei mir aber auch mit der aktuellen 1.4 FW von Welec. Da 
das allerdings erstmal von der Prio her weit hinten rangiert werde ich 
das noch nicht in Angriff nehmen (es sei denn ich stolpere zufällig 
darüber.

Zur Zeit gibt es folgende Prio:

1. DAC-Abgleich
2. Den Freeze-Bug finden den ich mir in Version 0.33 eingebaut habe
   (Signal friert ein bei Zeitbasen > 5ms)
3. FFT einbauen -> damit hat eigentlich vor einem halben Jahr alles 
angefangen, aber bei all den Ungereimtheiten bin ich immer noch nicht 
dazu gekommen...

Gruß Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Bruno We schrieb:
> frei nach dem Motto: "ein Bild sagt mehr als tausend Worte"

So denn, das ist Kanal 4.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Johannes Studt schrieb:

> So denn, das ist Kanal 4.

Tja, da muß ich leider sagen, es ist nicht der ADC-Abgleich der hier 
nicht hinhaut sondern hier dürften Störungen oder Eigenresonanzen 
verantwortlich sein. Mein Kanal 4 sieht zeitweise noch viel schlimmer 
aus. Die Bilder kennt Ihr ja schon. Da hilftnatürlich auch kein 
ADC-Abgleich. Hinzu kommt, dass der ADC-Abgleich natürlich auch dadurch 
gestört wird. Wie sieht denn Dein Kanal 3 aus? Der ist bei mir nämlich 
glatt wie ein Babypopo.

Gruß Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Bittesärrrrr. ;)

/Hannes

von Ronny S. (ronnysc)


Lesenswert?

Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage 
Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das 
Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt. 
Ich bin raus...

von Blue F. (blueflash)


Lesenswert?

Ronny Schmiedel schrieb:
> Darum habe ich auch jetzt meinen W2024 innerhalb des 14Tage
> Rückgaberecht wieder zurückgeschickt. Bei mir war das Gleiche, das
> Rauschen nahm nur zu. Hoffe für Euch, das Ihr das in den Griff bekommt.
> Ich bin raus...

Na sowas, das muß man sportlich sehen. Da ist halt recht viel 
Optimierungspotential ;-)

Gebe allerdings zu, dass für professionelle oder semiprofessionelle 
Anwendungen die WELECs nicht die erste Wahl wären. Aber für Hobbybastler 
und Optimierer super bei dem Preis. Wenn ich jetzt auch noch Geld dafür 
kriegte müßte ich mich nicht mehr "nebenbei" für SAP krumm machen.

@Hannes

warum macht Ihr eigentlich immer Bilder vom 10ns Bereich? Da muß man in 
Gedanken immer die interpolierten Werte rausrechnen um sich ein Bild des 
Werteverlaufs zu machen. Der 50ns Bereich ist da ideal, weil er die 
Werte 1:1 wiedergibt bei voller Samplerate.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Weil Bruno das so macht und ich keinen Plan habe, was für wen warum auch 
immer am besten ist.

Sprich: hier einfach der Vergleichbarkeit der Bilder wegen. 
Normalerweise[TM] mache ich auch andere Bilder.

von Guido (Gast)


Lesenswert?

Hallo,

@ Hayo, mach mal Pause, dann fällt es einem oft wie Schuppen aus den
Haaren. Den Ansatzpunkt (manuell versus auto) hast du ja schon.

Wegen dem Freeze suche ich auch noch mal, das ist aber wohl was
fieses kleines.

@ Johannes: Kanal 4 sieht wirklich schlimm aus. Eigentlich ist der
doch am weitesten von Netzteil entfernt, das Rauschen muss also
woanders her kommen. Kanal 3 kannst du besser einstellen. Da sieht
man noch die Abweichungen zwischen den ADCs (periodisch). Probier
mal mit einem Terminalprogramm (sofern nicht schon getestet).

@ Bruno We: jo, so etwa bekomme ich den Abgleich auch hin. Für
mich verfestigt sich der Eindruck, dass da ein Schwingen im
Eingangskreis stattfindet. Das ist kein Rauschen der Bauteile,
dafür ist es um Größenordnungen zu stark. Normalerweise würde
ich zu Ferritperlen raten, aber das geht in dem SMD-Layout wohl
nicht?

Gruß, Guido

von Johannes S. (demofreak)


Lesenswert?

Guido schrieb:
> woanders her kommen. Kanal 3 kannst du besser einstellen. Da sieht
> man noch die Abweichungen zwischen den ADCs (periodisch). Probier
> mal mit einem Terminalprogramm (sofern nicht schon getestet).

Ändert nix, damit habe ich schon rumgespielt. ;)

/Hannes

von branadic (Gast)


Lesenswert?

@ Guido,

wie wäre es statt Ferritperlen mit Ferrit Beads? Die gibt es für die 
unterschiedlichsten Frequenzbereiche und in unterschiedlichen Packages. 
Schau mal bei RS nach, da solltest du schnell fündig werden.

Gruß, branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,
der Grund warum ich Fotos im 10ns Bereich mache ist eigentl. ganz 
simpel: ich hatte lange Zeit (und habe tw. immer noch) massive Probleme 
mit HF Schwingungen, eben auch mit dem ADC Abgleich und mit einer NF 
Überlagerung bei offenen Eingängen. Bei 50ns ist es sehr schwer eine 
eine HF Frequenz auszuzählen und eine Regelmäßigkeit zu erkennen. Das 
mit den interpolierten Werten stellt kein Problem bei 10ns dar, erstmal 
geht es ja um die Minimas und Maximas der Anzeige- und die sind auf 
keinen Fall interpoliert. Darüber hinaus fällt es bei 10 ns leichter die 
Anzahl der wirklichen Sprünge abzuschätzen, also um wieviele Bit des ADC 
die Anzeige des Display sich wirklich ändert. Als letztes möchte ich 
auch das Verstärkerrauschen mit untersuchen, das ist nach bisherigen 
Erkenntnissen in den 1er Messbereichen am grössten.

@Guido:
Ich antworte dir im HW Thread.

Gruß, brunowe

von Ulrich P. (uprinz)


Lesenswert?

Ich bin echt beeindruckt!

Es ist schon genial, was hier die Entwickler und Tester auf die Beine 
stellen. Mich juckt es ja so sehr, ebenfalls einen Welec zu ersteigern. 
Aber ich habe für mein Hobby bereits einen Agilent 54622D und ich 
vermisse bei dem Welec einfach die 16 digitalen Kanäle, ohne die ich 
nicht leben könnte :)

Trotzdem mal ein paar Ideen für die ganze Offset/Zeroing Problematik, 
gerade weil ich diesen Abgleich vom Agilent her ein wenig kenne. 
Allerdings habe ich für dieses Gerät, trotz Vorzugspreis und so weiter, 
einen aus Hobby-Sicht stolzen Preis bezahlt und es daher noch nicht 
geöffnet.

Der Agilent fährt bei einer User-Calibration ein recht aufwändiges 
Muster an Kurven durch, dem man auch zuschauen kann. Wenn Euch das 
hilft, versuche ich mal davon ein Video zu machen. Es sind wohl einige 
unter Euch, die aus den dargestellten Mustern rückschließen können, was 
da eingemessen wird.
Was ich bei dem Welec bislang vermisse, ist ein Referenz-DAC, der zur 
Kalibration aller anderen verwendet werden kann. Ist der noch irgendwo 
verborgen, oder wurde der tatsächlich eingespart? Oder gibt es bei den 
verschiedenen Multiplexern eventuell eine Stellung in der sie auf 0 und 
eine, in der sie auf eine Vref geschaltet werden können? Dann kann man 
eventuell den Gain-DAC dazu verwenden, die OVs auszumessen.
Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte 
zu bringen, bevor man eine ZeroCal durchführen kann.

Eine softwaretechnische Frage wäre dann noch, ob der Welec seine 
Software aus dem FLASH laufen lässt, oder ins RAM bootet und dort dann 
arbeitet. Für die Entwickler wäre die Idee, einen weiteren Bootloader zu 
schreiben sicherlich sehr hilfreich, der originiale scheint, ehrlich 
gesagt, Murks zu sein. Das Flashen von 8MB dürfte nicht länger als max. 
4min dauern.
Sollte sich jemand daran wagen, dann wäre es wohl sinnvoll, den 
Bootloader ins RAM zu kopieren, große Blöcke ins RAM zu laden und von 
dort aus zu flashen. Bitte beachtet dabei, dass die Toggle-Bits einiger 
AMD/Spansion und Kompatibler erst nach ein paar ms gültig sind. Ist eine 
Falle, die das Flashen enorm verlangsamen kann, wenn man diese zu früh 
abfragt und dann in eine Fehlerbehandlung rennt, die nicht nötig ist. 
Ich meine MX gehört zu den Spansion kompatiblen. Wenn das ganze ins RAM 
kopiert wird, dann sollte der Bootloader das auch unterstützen, damit 
man eine Software auch ohne Flashen mal schnell ausprobieren kann.

Hat jemand eine Info, in wie weit diese Scopes noch nachgefertigt 
werden? Wenn Welec/Wittig nur noch Restbestände abverkaufen, und alles 
deutet darauf hin, dass nur noch die Retouren aufgearbeitet und 
abverkauft werden, was dann? Die Arbeit ist auf keinen Fall vergebens, 
aber es wäre sicherlich besser, wenn man länger was davon hätte, auch 
wenn ich nicht weiß, ob sich ein OpenSource Oscar auf dem Markt 
durchsetzt.
Allerdings wäre das doch sicherlich ein interessantes Geschäftsmodell 
für Wittig um seinen Laden zu retten. Ich hatte eigentlich gehofft, dass 
er sich mehr für das Projekt einsetzen würde. Nun, auf der Sourceforge 
Seite angekündigte Bereitstellung von Mustern an die Maßgeblichen 
Entwickler ist ein Schritt in die richtige Richtung.

Ich verfolge das auf jeden Fall mal weiter, vielleicht kann ich mein 
Hobby-Budget mal wieder aufstocken :)

Gruß, Ulrich

von egberto (Gast)


Lesenswert?

Das der Beitrag bezüglich des Sponsorings vom 1. April ist, hast du 
gesehen?? ;-)

Viele Grüße,

egberto

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

@Guido

wg. des Freeze-Problems bräuchtest Du die Sourcen der 0.32 und 0.33, da 
läßt sich das am einfachsten herausfinden da ein direkter 
Sourcenvergleich möglich ist. Guckst Du im Anhang...

Der Fehler ist mit Sicherheit in der Hardwareroutine zu finden, denn die 
Grafikausgabe wird, wie ich schon rausgefunden habe, korrekt durchlaufen 
- die Drehgeberroutinen übrigens auch. Der Grund warum keine neuen Daten 
gelesen werden ist sekundär, dass das ADC_Data_Available Flag nicht 
gesetzt wird und dann auch der ADC nicht ausgelesen wird (Handle_ADC() 
Zeile 19418). Warum es aber nicht mehr gesetzt wird, das versuche ich 
rauszukriegen. Müßte eigentlich eine Änderung sein die ich mit BF 
gekennzeichnet habe.


@Bruno

ok, das kann ich einsehen. Für meine Zwecke benutze ich meistens die 
50ns Einstellung da ich hier immer alle realen Punkte ohne Zommfaktor 
zur Verfügung habe (deswegen hab ich auch das Freeze-Problem nicht 
bemerkt).


@Ulrich

Mußte Deinen Beitrag noch ein zweites Mal lesen, da er so lang war, dass 
ich am Ende nicht mehr wußte was am Anfang stand (Altersbedingt).

Also zum Bootloader: Das Programm läuft natürlich im RAM. Beim 
Anschalten des DSO wird ein kleines Bootloaderprogramm aus dem Flash 
geladen (steht an Adresse 0x00040000) dieses kopiert dann den Rest der 
Firmware ins RAM (Adresse 0x00800000), von wo es dann gestartet wird.

Zur Flashgeschwindigkeit: Klar, ich hab es mit einem selbstgeschriebenen 
Linux-Kommandozeilenprogramm in 3 Minuten geschafft. Leider war mir das 
Programm nicht zuverlässig genug, da hab ich dann lieber das von Markus 
genommen. Anscheinend ist es nicht so einfach ein RS232 
Übertragungsprogramm zu schreiben, das auf allen Rechnern gleich gut 
funktioniert (liegt wohl auch am Hardware Abstraction Layer). Bin aber 
ganz froh, dass es überhaupt so gut funktioniert.
Zudem hatte ich anfangs auch nicht vermutet dass es sooo viel zu tun 
gibt und ich innerhalb kürzester Zeit auf weit über 100 Uploads komme.

Zu den Abgleichkurven: Ja, immer her damit. Ich laß mich gerne von 
Profilösungen inspirieren.


Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Ulrich

Ach ja, eins hatte ich noch vergessen, der Trend geht zum Zweitwelec ;-)


Da kann man schön vergleichen und kann auch mal eins zerlegen.

Gruß Hayo

von Ulrich P. (uprinz)


Lesenswert?

Ok, kürzer :)
Hoffe ich kann das Video mit meiner kleinen WebCam ordentlich hin 
bekommen und irgendwo hin uploaden.

Ich denke, dass es nötig ist, den Bootloader so zu erweitern, dass man 
auch direkt ins RAM schreiben kann, falls das nicht ohnehin schon 
unterstützt wird, damit man eine neue Software direkt testen kann ( 
Flashloader überspringen). Wegen der fehlenden FlashErase und 
Schreibzyklen sollte das weit unkritischer sein und damit auch 
unkritischer für die serielle Kommunikation. Wurde auf Seite des Wittig 
eventuell das RTS/CTS Handling übersehen, oder hat der diese Leitungen 
nicht angeschlossen?

Gruß, Ulrich

von egberto (Gast)


Lesenswert?

@Hayo / Guido

Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?

Was muß ich mir dafür installieren?

Viele Grüße,

egberto

von Blue F. (blueflash)


Lesenswert?

Ulrich P. schrieb:
> Es wundert mich doch sehr, dass es notwendig ist, die Strahlen auf Mitte
> zu bringen, bevor man eine ZeroCal durchführen kann.

Das liegt daran, das ich einen anderen Ansatz verfolge als die Routine 
von WELEC. Ist eigentlich ganz simpel. Ich prüfe einfach bei offenen 
Eingängen die ADC-Werte. Diese müssen bei GND 127 betragen (oder 128 je 
nachdem wo man die Nullinie hinlegt). Ich ermittle also nur die 
Differenz zu den 127 und korrigiere dann den DAC-Wert um die Differenz 
und einen Faktor. Da aber nur bei DAC-Nulllage auch 127 rauskommt, muß 
ich vorher die DACs in die Nulllage fahren. Übrigens wird kein absoluter 
Korrekturwert ermittelt, sondern der von der Search Zero Routine 
ermittelte Wert wird nach oben oder unten korrigiert - ein Feintuning 
sozusagen.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

egberto schrieb:

> Anfängerfrage (nicht hauen!) - womit commpiliert ihr das eigentlich?
>
> Was muß ich mir dafür installieren?

Du brauchst ein Linux-System dafür. Kann man ganz easy zusätzlich zum 
Windows installieren. Bei mir hat es mit Open SUSE prima hingehauen (War 
auch Linux-Anfänger). Ich hatte auch schon mal ein how to geschrieben, 
ich hänge das hier nochmal an.


Viel Erfolg

Hayo

von egberto (Gast)


Lesenswert?

Danke, das ging ja schnell.

Und das kann man ja sogar "nebenbei" in der Firma machen ;-)......

Viele Grüße,

egberto

von Ulrich P. (uprinz)


Lesenswert?

Ok, ich hatte jetzt noch nicht die Zeit die Datenblätter der DACs und 
ADCs durch zu arbeiten. Aber normalerweise ist doch ein signed bei 
0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht. 
Allerdings nur, wenn man die Wandler ensprechend einstellt. Ich habe die 
ganzen Threads innerhalb eines Tages durchgelesen, und meine mich 
erinnern zu können, dass die Eingangsstufen die Messpannung auf 
Wandlermitte anheben, also wird nur positiv gemessen.

Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da 
die OVs der Eingangsstufe dann frei laufen. Gibt es keine Option, die 
Stufe auf GND zu schalten? Das wäre schon mal ein Anfang. Optimaler wäre 
es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten 
zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs 
kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige 
brauchbare Referenz aller Kanäle gemeinsam?

Nochwas zum HP. Er führt die User-Calibration offenbar unter 
Berücksichtigung der eigenen Temperatur durch, diese vermerkt er 
jedenfalls in den Logdaten zur Cal. Viel mir nur gerade ein, weil einige 
ja darüber klagten, dass der Welec nur bei bestimmten Temperaturen 
sauber funktioniert. Vermutlich fehlt der Sensor im Welec-Design, oder 
er wurde noch nicht gefunden. Andernfalls müsste man für eine schnelle 
Aufbereitung der Daten für jeden Wandler eine Korrekturtabelle von 256 
Werten anlegen. Diese wird beim HP vermutlich durch die User-Calib 
extrapolieert.

Wo kann ich denn das Video ggf. ablegen. Die User-Calib dauert ein paar 
Minuten... Werde ich dann heute Abend aufnehmen.

Gruß, Ulrich

von Kurt B. (kurt)


Lesenswert?

Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und 
Agilent Geräten.
Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei 
fehlenden Tasten beim Welec und anderen Softkeys.
Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in 
Y-Richtung.
Siehe Bedienungsanleitung: 
http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf

Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent? 
Aber warum sind dann Hard-und Software so buggy?

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Was mich extrem wundert, sind die Ähnlichkeiten zwischen Welec und
> Agilent Geräten.

Das wundert mich nicht. Wenn ich ein neues Gerät auf den Markt bringen 
wollte, würde ich mich auch an Bewährtem orientieren

> Z.B. sind die Bedienelemente 100% identisch. Abgesehen von zwei
> fehlenden Tasten beim Welec und anderen Softkeys.
> Auch das Bildschirmdesign ist zu 99% identisch. Auch die 4 SubDiv/Div in
> Y-Richtung.

Das hätten sie allerdings nicht abkupfern müssen. Da halte ich es eher 
wie die Japaner: Gut abkupfern und dann verbessern!

> Siehe Bedienungsanleitung:
> http://cp.literature.agilent.com/litweb/pdf/54622-97036.pdf

Die hätte WELEC man auch abkupfern sollen, denn die taugt wenigstens 
was. Die werd ich mal als Anhaltspunkt für weitere Entwicklungen nehmen 
und evtl. auf dieser Basis mal eine richtige Anleitung für das WELEC 
stricken.

> Verwendet Welec wirklich leicht abgeänderte Orginaldesigns von Agilent?

Wohl nur das Äußere würde ich sagen. Genaueres kann uns da nur ein 
Agilent-Besitzer sagen.

> Aber warum sind dann Hard-und Software so buggy?

Weil sie halt nicht von Agilent sind (schade)

Gruß Hayo

p.s. vielleicht kann man ja eine Platine von Agilent kriegen und ins 
WELEC einbauen ;-)

von Blue F. (blueflash)


Lesenswert?

Ulrich P. schrieb:
> Aber normalerweise ist doch ein signed bei
> 0..127 positiv und bei 128..255 negativ, wobei 128 der -1 entspricht.

Und 127 die Null. Soweit korrekt.

> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
> die OVs der Eingangsstufe dann frei laufen.

Da gebe ich Dir recht.

> Gibt es keine Option, die
> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.

Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
mich schlau. Ich wollte mich erstmal an vorhandener Hardware
orientieren, damit alle was davon haben.

> Optimaler wäre
> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
> brauchbare Referenz aller Kanäle gemeinsam?

Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
intensiv unter die Lupe genommen. Tja da war ich wohl vor 15 Jahren
schon weiter als ich für die Diplomarbeit mein externes Oszi für den
Parallelport konstruiert habe. Da gab es nämlich Abgleichreferenzen und
auch eine schicke Spektralanalyse auf dem PC. Da lief aber die komplette
Software auf dem PC und man mußte nicht so mit Resourcen geizen wie
hier.
Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
ausgebaut.

> Nochwas zum HP. Er führt die User-Calibration offenbar unter
> Berücksichtigung der eigenen Temperatur durch, diese vermerkt er
> jedenfalls in den Logdaten
...
> Vermutlich fehlt der Sensor im Welec-Design, oder
> er wurde noch nicht gefunden.>

Temperatursensor? Was ist das möchte man fragen. Sowas gibt es hier
nicht. Da hilft nur nachkalibrieren, und damit das gut klappt legen wir
uns hier ja ins Zeug.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

wenn das Freeze-Problem wirklich zwischen 0.32 und 0.33 eingetreten
ist (h.h. in der 0.32 war es noch nicht), liegt es sicher nicht an
hardware. Da wurde fast nichtsgeändert, wie ein diff zeigt.
Es muss von display kommen, die meisten Änderungen betreffen wohl
den Delayed-Mode. Es kann eineWeile dauern, das durchzuschauen
aber das werden wir schon finden. 8-)

Gruß, Guido

von Ulrich P. (uprinz)


Lesenswert?

Hayo W. schrieb:
>> Die Zero-Linie bei offenem Eingang zu messen halte ich für kritisch, da
>> die OVs der Eingangsstufe dann frei laufen.
>
> Da gebe ich Dir recht.
>
>> Gibt es keine Option, die
>> Stufe auf GND zu schalten? Das wäre schon mal ein Anfang.
>
> Mir ist keine bekannt, aber wenn es da andere Erkenntnisse gibt macht
> mich schlau. Ich wollte mich erstmal an vorhandener Hardware
> orientieren, damit alle was davon haben.

Wenn ich mir den Schaltplan unter
http://welecw2000a.sourceforge.net/docs/pcb/Analog_+Inputs_updated2.png
ansehe, dan gibt es dort wohl mehrere Möglichkeiten. Leider sind in der 
letzten Version die IC-Nummern raus gefallen.
Der MAX4704 kann das Signal aus der Vorstufe über NO2 auf GND schalten. 
Damit wäre die mittlere Stufe in die Kalibration einbezogen.
Er kann mit NO1 auch gegen einen Pin D8 vom FPGA geschaltet werden, was 
das für einen Sinn hat weiß ich nicht, aber wenn der Pin ein Ausgang 
ist, kann man damit zumindest einen Bezug zu Digital-Masse und Digital 
Vcc herstellen. Allerdings scheint da 0V anzuliegen...

Die Vorstufe rund um die OPAs müsste über K1 und K2 ebenfalls zu 
beruhigen sein, hier liegt leider ein 110K Widerstand im Weg zur Masse. 
Immer noch besser, als zu floaten.

>
>> Optimaler wäre
>> es sicherlich, die Gesamtaussteuerung zu durchlaufen und dann die Daten
>> zu mitteln. Dazu müssten aber wenigstens die DACs für das GAIN halbwegs
>> kalibriert sein. Gibt es denn in dem ganzen Scope keine einzige
>> brauchbare Referenz aller Kanäle gemeinsam?
>
> Nicht das ich wüßte. Allerdings hab ich die Hardwareseite noch nicht so
> intensiv unter die Lupe genommen.

Ich auch gerade erst, aber weil ich halt nur mal so mitspiele, habe ich 
auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute 
nach jeder kleinen Verbesserung lechzen :)

> Unter anderem gab es auch eine Korrektur der ADC-Kennlinie, die hatte
> ich beim WELEC auch schon probeweise eingebaut (Y = beta*X + alpha) aber
> wegen der massiven Performanceeinbrüche bei der Graphikausgabe wieder
> ausgebaut.
>
Ich kenne die Software, wie gesagt, nicht. Ich spiele daher also nur mal 
mit Gedanken. Wenn man die Werte als Byte einliest, aber in einem Word 
oder Longint speichert und das gleich als 2. oder drittes Byte.
Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt 
verschobenen Faktoren und multipliziert dann nur ein einziges Mal und 
das als int und nicht float. Klar, die Tabelle müsste dann natürlich für 
die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am 
besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas 
Platz, spart aber Zeit.

Gruß, Ulrich

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

@Guido

Ich bin mir relativ sicher, dass die 0.32 noch anständig läuft. Hier 
sicherheitshalber die Flashdatei wenn Du das probieren möchtest.


@Ulrich

> weil ich halt nur mal so mitspiele, habe ich
> auch keine Hektik :) Muss ja keinen Code ändern, weil hunderte Leute
> nach jeder kleinen Verbesserung lechzen :)

Ich bin zum Glück seelisch stabil ;-) - sonst wär ich auch als 
EDV-Fachmann völlig im verkehrten Beruf - Kunden können echt grausam 
sein...

> Dann baut man sich eine Kalibriertabelle, ebenfalls mit korrekt
> verschobenen Faktoren und multipliziert dann nur ein einziges Mal und
> das als int und nicht float. Klar, die Tabelle müsste dann natürlich für
> die geraden und ungeraden Faktoren abgelegt werden, also mind. 2mal. Am
> besten sogar für jeden Messbereich und jeden Kanal. Das braucht etwas
> Platz, spart aber Zeit.

1. Platz ist rar. Brauche schon eine Menge für die trigonometrischen 
Tabellen die ich bei der FFT einsetze.

2. Bei 8 Bit ist der Benefit des Abgleichs kombiniert mit der 
Ablesegenauigkeit nicht so berauschend. Den Fehler kann man also wohl 
verschmerzen.

3. Diese Tabellen müßten ja für jedes Gerät separat ermittelt und 
gespeichert werden - was für ein Aufwand an Abgleichroutinen.

Ich denke die Anderen werden mir Recht geben dass es momentan andere 
Baustellen gibt die mehr an nutzbarem Erfolg bringen wenn wir sie in den 
Griff kriegen.

Nichts desto trotz immer her mit konstruktiven Vorschlägen, dann kann 
man Für und Wider hier ausdiskutieren bevor ich (oder andere Berufene) 
da was einbauen.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

@Ulrich- mit dem Problem des "Eingangstest" (Power on self Test) hab ich 
mich auch schon beschäftigt... der FPGA1 PIN D8 scheint allerdings als 
Input geschalten zu sein...(Wir- im VHDL Projekt- hatten schon mal 
angedacht einen definierten Spannungsverlauf über diesen Pin auszugeben 
und das Ergebnis an den ADC's mit dem abgespeicherten Sollzustand zu 
vergleichen)

Über die jetzige Fkt. der dortigen Beschaltung gibt's meines Wissens 
noch keine tieferen Erkenntnisse.

Evtl. könnte man auch über den DAC eine definierten Spannungsverlauf 
ausgeben- da müsste man einmal sehen wie schnell der ist...

Also ich verbinde meinen BNC- Eingang für die Kalibrierung immer mit 
GND- speziell da mein OPA gern schwingt.

Nehm doch bitte den Schaltplan in der Google Groups, der ist immer auf 
dem neusten Stand (und wesentl. ausführlicher). Derzeit in Version 1.32
http://groups.google.com/group/welec-dso

Gruß, brunowe

von Ulrich P. (uprinz)


Lesenswert?

Hi Bruno,

Ok, dann beziehe ich mich auf diesen Schaltplan, für den aber vorerst 
das gleiche gilt. Mir ist die Funktion aller OVs darin noch nicht ganz 
klar, aber das wird schon. In der Diskussion dieser drei Threads war die 
Rede davon, dass der ADC Single-Ended angesprochen wird. Die Schaltung 
ist aber eher differential ausgelegt. Aber ich bin halt nicht der 
analoge Crack, bei mir fängt die Signalaufbereitung normalerweise auch 
erst im DAC/ADC an.
Daher spinn ich jetzt mal was herum. Wenn der DAC eingesetzt wird, um 
den negativen Bereich in den Positiven zu verschieben, dann ist keine 
saubere 0-Linien Berechnung zu machen, weil die Verzerrungen und die 
Offsetfehler der OVs hoch skaliert werden. Nutzt man den ADC als 
Differential und den DAC nur zum Offsetabgleich und Gain, dann würde man 
doch viel genauere Messwerte gerade bei kleinen Signalen erhalten? 
Beschimpft mich nicht, erklärt es mir, ich lern gerne noch was dazu.

Gruß, Ulrich

von Guido (Gast)


Lesenswert?

@ Ulrich: Der ADC wird differentiell angesteuert. Der DAC verschiebt
direkt den Offset des OPA-Eingangsverstärkers. Er könnte damit direkt
für Testsignale verwendet werden. Aber alles zu seiner Zeit. Solange
die Offseteinstellung noch hakt macht es wenig Sinn daran rumzuspielen.

@ Hayo. Jo, die 0.32 läuft noch. Ich gehe mal das diff durch.

Gruß, Guido

von Ulrich P. (uprinz)


Lesenswert?

Ist schon ok, ich klemm mich mal wieder raus und schau mal, ob ich eine 
UserCalib vom Agilent aufzeichnen kann.

Gruß, Ulrich

von Blue F. (blueflash)


Lesenswert?

@Guido

ja da bin ich auch gerade dabei. Ich muß Dir Recht geben, die 
Hardwareroutinen geben keinen Hinweis. Ich hab danach mal die 
Displayroutinen gescannt, aber auch nichts direktes gefunden außer einem 
Verdächtigen in der DrawSignals(), den ich jetzt mal per 
Terminaldebugging etwas unter die Lupe nehme - Upload läuft noch...

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: mit dem diff bin ich durch, da ist mir nichts
gravierendes aufgefallen. Ich bin schon am überlegen,
ob es nicht eine Race-Condition ist, aber das sieht
eigentlich auch sauber aus. Ich hab mal "Signal_Loaded"
rausgeworfen, wird eh nicht benutzt aber wohl auch keine
Besserung bringen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Tja bei mir sieht es ähnlich aus. Der Diff-Vergleich bringt nur 
unspektakuläres. Hab jetzt mal ein paar Debuggingausgaben eingebaut.

Folgende Details:

Timebase < 18 und >28 - ADC wird gestartet, ADC meldet per ISR Data 
available, Daten werden vom ADC abgeholt, Zeichenroutine gibt Signal 
aus, ADC wird gestartet....usw.


Timebase >= 18 und <= 28 - ADC wird gestartet, keine Rückmeldung vom 
ADC, es werden keine Daten abgeholt (wegen der fehlenden Rückmeldung), 
Zeichenroutine gibt das alte Signal aus das immer noch im Buffer steht, 
ADC wird gestartet... usw.


Also ich kann mir da im Moment keinen Reim drauf machen. Werd mal als 
nächstes die PIO-Register checken. Schaff ich aber heute und morgen 
nicht.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

heute blicke ich auch nicht mehr viel. Aber suche doch mal
in hardware nach "Start_Record", das wird selbst im
Timerinterrupt aufgerufen. Es macht mich halt misstrauisch,
dass der Fehler vom Timing abhängt.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> Es macht mich halt misstrauisch,
> dass der Fehler vom Timing abhängt.

Ich habe da einen weiteren Verdächtigen ausgemacht. Vielleicht schaffe 
ich es nach der Arbeit noch schnell eine neue Testversion upzuloaden 
bevor ich wieder los muß.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Ich habe die 0.56er Sourcen jetzt compiliert bekommen, meine 
TomCat.flash ist allerdings 1307517 Byte groß, die von Hayo 1307650 
Byte.

Habe ich was falsch gemacht (die in der Anleitung beschriebenen 
"offical" Sourcen hatten kein Makefile, ich habe die "improved" genommen 
und dort das src Verzeichnis durch das von Hayo ersetzt)???

Viele Grüße,

egberto

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ich habe bei mir das loader file etwas geändert, das wird dann mit dem 
Flashfile zusammengemerged. Hier noch mal alle wichtigen Ordner ohne den 
src Ordner.

Das sollte es sein. Wenn nach dem Upload alles im Oszi läuft wie es soll 
kann es nicht so verkehrt sein.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Noch eine Frage: hattest Du überhaupt das Loader-File? Wenn nicht 
funktioniert es nicht, da ist der Bootloader drin, der das Programm 
nachher in den RAM-Speicher lädt. Deshalb muß das Loader-File mit dem 
Tomcat.Flash kombiniert werden. Sieht man auch wenn man mit dem 
Texteditor ins Flashfile geht. Das ist im Makefile schon alles 
eingebaut.

Gruß Hayo

von egberto (Gast)


Lesenswert?

Hallo Hayo,

loader ist dabei gewesen(801 Bytes).

Mit deinen Build-Dateien bekomme nach "make clean all" nun auch deine 
Dateigröße.

Viele Grüße,

egberto

von Blue F. (blueflash)


Lesenswert?

@egberto

prima, dann kannst Du ja auch gleich mit einsteigen...


@Guido
Der nächste Verdächtige scheidet auch aus. Hab mal alle UI_requests 
rausgenommen, geht aber trotzdem nicht - die Suche geht weiter. Hab 
schon die nächste Idee, komme aber erst morgen oder übermorgen dazu.

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

es ist mir gelungen den Fehler einzugrenzen und einen
Workaround zu implementieren. Der wird uns hoffentlich
helfen den Fehler zu finden. Näheres findest du im zip
als freeze.txt.

@ all: Im zip ist auch ein Tomcat.flash, das außer dem
Workaround Hayos letzter Beta entspricht. Vielleicht hat
jemand Lust zum Testen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

das Löschen der availability Abfrage bringt uns aber nicht näher an den 
Fehler. Das Problem ist ja, dass der ADC gestartet wir, aber aus 
irgendeinem Grund keinen Ready-Interupt mehr auslöst. Da muß ich wohl 
die Register prüfen, allerdings hatte ich da eigentlich nichts geändert. 
Zur Eingrenzung werde ich auch noch mal versuchen die 0.32er 
Display-Routine mit der 0.33er Hardware-Rotine zu kombinieren und 
umgekehrt. Dadurch läßt sich vielleicht der Fehler weiter eingrenzen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Availability-Prüfung habe ich längst wieder drin. Du musst
da keine weiteren Tests machen. Das Problem ist einfach, dass
der ADC in der Grafik gestoppt wird, so dass sein Interrupt
nicht ausgelöst wird. Ich vermute, dass das in Copy-Planes
erfolgt. Das können wir noch weiter untersuchen, im Moment
arbeitet das Welec mit dem Workaround aber wie gewünscht.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Oh, sorry - da fehlte wohl ein Zeilenumbruch in Deiner Datei. Ich hab 
nur den ersten Teil gelesen. Hab eben nochmal die Zeilen umgebrochen und 
den Rest gelesen. Ok, das ist schon mal ein Hinweis dem man nachgehen 
kann. Die Copy und Transfer Planes Routinen sind leider spärlich 
kommentiert, so dass die Suche etwas schwierig ist. Evtl. könnte man 
nach StopRecord() suchen, denn damit kann man den ADC-Lauf abbrechen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

muß heißen

Stop_Record()

Hayo

von Blue F. (blueflash)


Lesenswert?

Hab ich mal gecheckt, Stop_Record() scheidet aus.

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ich werde später erst mal versuchen den Workaround auf die
schuldige Funktion zu begrenzen (im Moment sind es ja noch
3). Wenn da irgendwo in dem Assemblerteil ein Bit getoggled
wird, könnte die Suche lang werden. :-(

Es könnte aber auch Absicht dahinterstecken, weil sonst ein
Konflikt beim Zugriff aufs RAM entsteht.

Wir werden es rausfinden, Guido

von Blue F. (blueflash)


Lesenswert?

Ok,

ich glaube ich hab es. Durch Deinen Workaround bin ich da auf einen 
Gedanken gekommen. Es gab in der 032 eine Variable - DrawSignals_Needed 
- die hab ich in der 033 rausgenommen (zumindest in der Graphikroutine) 
weil mir die Funktion redundant erschien.

Wenn ich jetzt so darüber nachdenke sollte diese Variable wohl 
verhindern, dass die Gaphikroutine zu früh aufgerufen wird und damit 
natürlich auch das nächste Start_Record(). Denn in Start_Record() wird 
erstmal der alte Aufruf gestoppt und dann wieder ein Neuer gestartet. 
Das erklärt narürlich, warum dann bei langen Wandlerlaufzeiten keine 
neuen Daten mehr gelesen werden. Ich werde das mal morgen reparieren und 
schicke dann die nächste Beta raus. Da sieht man wieder, zu zweit sieht 
man einfach mehr als ein Einzelner.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Ich hab auch schon einen viel eleganteren Lösungsansatz.

In der Routine Start_Record() braucht man nämlich nur das Flag - 
adc_started - abzufragen und bei gesetztem Flag die Routine zu verlassen 
und schon sollte die Welt wieder in Ordnung sein und da die 
Graphikroutine trotzdem noch durchlaufen wird, reagiert sie auch auf 
User-Eingaben.

Das halte ich auch für nachlässig programmiert (von WELEC), denn es 
macht ja keinen Sinn den ADC aufzurufen wenn er noch läuft.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

das haben die sicher so gemacht, damit bei Änderung der
Einstellungen nur Start_Record aufgerufen wird. Sonst muss
man einen Messzyklus abwarten, bis die Signalanzeige
aktualisiert wird (das ist mir eh noch ein Dorn im Auge, jedes
andere Oszi kann das besser), oder erst Stop_Record und dann
noch Start_Record aufrufen.

So, TransferPlanes (allein) ist unschuldig. Werde gleich noch
mal flashen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Bin gerade zuhause angekommen, schnell mal Linux gestartet und die 
Änderungen programmiert und den Updater angeworfen - Upload läuft. Bin 
gespannt was rauskommt.

Gruß Hayo

von Guido (Gast)


Lesenswert?

> Bin gespannt was rauskommt.

Wird schon klappen, ist sehr beruhigend, dass es nur das
Start_Record ist. Braucht man nicht im Assemblercode zu
wühlen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Jo ich habs!!!!!!!!!!!!

Details erzähl ich später. Muß jetzt los.

Hayo

von sunny (Gast)


Lesenswert?

ich hab mal eine frage an die firmware coder. ich spiele gerade etwas 
mit dem schaltverhalten des switch U3 und den softwareskalierungen rum. 
wenn ich die ändere passt der offsetmarker nicht mehr zur nulllinie. 
gibt es für die markerposition auch korrekturfaktoren?

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

das klingt ziemlich unsinnig. Die Nulllinie sollte ja da sein,
wo man sie mittels Marker hinsetzt. Die Kalibrierung des Offsets
stimmt aber nur für die in der Firmware vorgesehenen
Einstellungen der Verstärkung.

Gruß, Guido

von sunny (Gast)


Lesenswert?

der sinn, das schaltverhalten des U3 zu ändern (zu invertieren), besteht 
darin die auflösung in den 1er und 2er messbereichen zu verbessern.
im original verstärkt der opa656 im 5er bereich mit 1,25 und in den 1er 
und 2er bereichen mit 1. das hat zur folge, dass in den 1er und 2er 
bereichen die aussteuerung des adc recht gering ist und eine 
softwareskalierung >3 notwendig ist, um den screen zu füllen. betreibt 
man den opa 656 jedoch genau umgekehrt, so dass er im 5er bereich mit 1 
und in den 1er und 2er bereichen mit 1,25 verstärkt, reduziert sich die 
nötige softwareskalierung auf einen faktor von etwa 2. das vermindert 
das sichtbare rauschen und verbessert die darstellungsqualität.
problem ist dass die ausgangsspannungen des offset dac nicht mehr zu den 
verstärkungen des opa656 passen. der offsetmarker erreicht das obere 
ende des screens ca 1,5div vor der nullinie.

die werte in dem float Volt_Correct_float array in der tc_vars.cpp 
müssten doch das sein was ich suche. richtig?

von Guido (Gast)


Lesenswert?

Hallo sunny,

das hängt jetzt davon ab, welche Firmware du benutzt. In der neuesten
Beta hat Hayo die Umrechnung auf Int umgewandelt, so dass die
Tabelle obsolet ist.

Eigentlich sollte U3 immer geöffnet sein (meine Meinung). In den
5er Bereichen bringt das eine bessere Auflösung (Umrechnungsfaktor
auf die Grafik dann 2), in den 1er und 2er Bereichen ist die 1,25
fache Verstärkung sowieso nötig. Da müssen wir mal einheitlich
was festlegen. Dazu sind dann 3 Offsetwerte nötig, was bisher
schon vorgesehen ist.

Gruß, Guido

von sunny (Gast)


Lesenswert?

ich nutz die .56
in der funktion ON_Zero_Channel_x wird das array noch genutzt. ich weiß 
nicht wann hayo das geändert hat.

ich hab den u3 im 5er bereich schlißen lassen, weil dann die 
softskalierung in allen 3 bereichen gleich ist. du hast allerdings 
recht. es macht eigendlich keinen sinn ihn im 5er bereich zu schließen. 
damit verschenkt man nur aussteuerbarkeit. man könnte wirklich mal 
versuchen ihn ständig ausgeschaltet zu lassen.

von Guido (Gast)


Lesenswert?

Tja sunny,

da gibt es schon noch Unstimmigkeiten. Dein Hinweis ist
da schon hilfreich, damit das nach und nach geändert
werden kann.

Mal was anderes: Du hast ja rausgefunden wie U21 und U23
angesteuert werden (hab ich auch schon ;-)). Findest du
ev. wie und wo U24 angesteuert wird? Das wäre für den
Offsetabgleich super, dann könnte man mit dem MAX4704
hierfür die Eingänge auf GND legen.

Gruß, Guido

von egberto (Gast)


Lesenswert?

Dafür, U3 rauszuschmeißen spricht auch die Simulation von Bruno im 
Hardwarethread -> man würde gleich 2 Fliegen mit einer Klappe 
erschlagen.

Mal sehen, was bei Brunos Lötaktion so raus kommt.

Viele Grüße,

egberto

von Blue F. (blueflash)


Lesenswert?

@sunny

Die Marker repräsentieren nur die Nulllinie (Grid-Zerolevel), diese wird 
nur als direkter gridproportionaler Integerwert im Zerolevel geführt. 
Die FW unterscheidet den Grid-Zerolevel (0 - 400) und den virtuellen 
Zerolevel (-8192 bis +8192) der den Aussteuerbereich des DAC 
repräsentiert. Man kann den Zerolevel also bis in den Virtuellen Bereich 
verstellen, nur das der Grid-Zerolevel dann auf 0 oder 400 stehen 
bleibt.

Die Werte im float Volt_Correct_float array sind für die Skalierung des 
DAC-Offsets (Zerolevels) verantwortlich, für die Signalskalierung haben 
sie keine Auswirkungen. Die Mitte (Gridmitte) des DAC-Offsets liegt bei 
8192. Hinzuaddiert wird der virtuelle Zerolevel skaliert durch diesen 
Faktor und korrigiert durch die DAC-Korrektur, die ja bei SearchZero() 
ermittelt wird.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok hier nun einige Details.

Nachdem ich gestern mit Guidos Hilfe auf den (eigentlich sekundären) 
Fehler gestoßen bin, hab ich erstmal einiges Ausprobiert und analysiert.
Ausglöst wurde der Fehler durch eine Variable die ich gelöscht hatte, 
die aber eigentlich von hinten durch die Brust ins Auge die 
Start/Stop-Logik steuern sollte (in der Graphikroutine!).

Ich hatte ja gestern die Idee in der Start_Record() den erneuten Aufruf 
zu unterbinden. Vom Gedanken her auch korrekt, aber es läuft nicht, da 
die Start/Stop-Logik des ADC so krude implementiert ist, dass es immer 
wieder zu Hängern kommt. Also gleich wieder Nägel mit Köpfen gemacht und 
die Logik vernünftig implementiert. Die Startsequenz hab ich also aus 
der Graphikroutine rausgenommen - wo sie auch wirklich nichts zu suchen 
hat -  und in den ADC-Handler verfrachtet - wo sie auch hingehört. 
Zusätzlich hab ich noch eine Start/Stop-Sequenz in den 
TimebaseWheel-handler eingebaut. Auf die komische Steuervariable die ich 
ja ohnehin schon an diversen Stellen gelöscht hatte, kann man jetzt ganz 
verzichten. Außerdem wird jetzt die Graphikroutine unabhängig vom 
Abtastprozess des ADC durchlaufen was eine bessere Reaktion auf 
Usereingaben bewirkt.

Zusätzlich bin ich bei der Gelegenheit auf eine weitere Baustelle 
gestoßen, die auch die aktuelle FW 1.4 betrifft.
Und zwar laufen Zeitbasen > 20S im 50ns Modus, man kann also mit der 
Zeitbasis 200s ein Signal mit einer Frequenz von z.B. 5 MHz sauber 
darstellen.

Wie das mit dem Timebaseregister zusammenhängt kann man in der 
aktualisierten Fassung meiner Programming Maps sehen die in der 
Timebasetabelle die aktuellen Einstellungen zeigt (siehe Anhang).

Ursprünglich war wohl für Zeitbasen im Sekundenbereich der sogenannte 
Rollmode vorgesehen, der nicht eine Zeitlinie nach der anderen 
darstellt, sondern mit einem Zeitfenster durch die Zeitlinie fährt. Man 
kann sich das so vorstellen wie die Anzeige auf einem Herzschlagmonitor.

Der Programmierer hat jedoch alle Stellen zum Rollmode in der FW 
auskommentiert. War wohl noch unausgegoren. Ich werde das auch nicht 
wieder aktivieren sondern lieber gleich richtig machen. Dauert aber 
natürlich etwas.

Die aktuelle FW ohne Freeze-Bug gibt es heute abend.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

da bin ich aber mal gespannt. Ich hatte mir auch Gedanken gemacht
und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
die Daten verarbeitet werden, gibt es keinen zusammenhängenden
Kurvenzug mehr. Auch bei der Triggerung könnte das zu Problemen
führen. Soweit ich das bisher verstehe, haben wir ja keine echte
Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
durchsucht.

Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
wer kommt schon auf die Idee über eine Stunde zu warten, bis das
Sampling abgeschlossen ist.

Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
müssen wir noch implementieren (hab schon eine Idee) sonst sind
die langsamen Bereiche next to useless.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Die Zeitbasisprobleme kann man wohl nur in der Firmware erkennen,
> wer kommt schon auf die Idee über eine Stunde zu warten, bis das
> Sampling abgeschlossen ist.

Nein, schließ mal ein 5MHz Signal an und gehe auf 100s oder 200s, das 
sieht genauso aus wie im 50ns Bereich. Bin drauf gekommen weil mich die 
hohe Wiederholrate stutzig gemacht hat. Bei 10s und 20s geht es noch 
(hab ich einfach ausgesessen).

> Rollmode, das ist der Begriff, der mir gestern gefehlt hat. Den
> müssen wir noch implementieren (hab schon eine Idee) sonst sind
> die langsamen Bereiche next to useless.

So ist es. Der rein physikalisch Vorgang ist eigentlich ganz einfach. 
Man sampled immer nur ein kurzes Stück und scheibt es auf der einen 
Seite in den Signalbuffer rein. Hinten läßt man das alte einfach 
"rausfallen". Dann gibt man das Siganl aus. Dann Sampled man erneut und 
schiebt dann wieder nach. Das sieht dann so aus, als würde das Signal 
(ein Impuls z.B.) von links nach rechts über den Bildschirm wandern. 
Dadurch hat man dann bei Sampleraten um 1Sa/s auch keine ewigen 
Wartezeiten bevor man was sieht.

Ideen hab ich auch schon, aber ich muß mal meine Prioritätenliste 
sortieren und sehen was mir wichtig erscheint.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Ich hatte mir auch Gedanken gemacht
> und war zu dem Ergebnis gekommen, dass Start_ADC in Display_Signals
> schon seinen Grund hat. Wenn der ADC schon wieder sampled, während
> die Daten verarbeitet werden, gibt es keinen zusammenhängenden
> Kurvenzug mehr.

Nein, kein Problem, der ADC-Handler wartet ja mit dem Auslesen des
nächsten Samples bis die Graphikroutine fertig ist - es sei denn es
kommt ein UI-Interrupt.

> Auch bei der Triggerung könnte das zu Problemen
> führen. Soweit ich das bisher verstehe, haben wir ja keine echte
> Hardware-Triggerung, es wird nur das aktuelle Sample entsprechend
> durchsucht.

Der Trigger verschiebt im Prinzip nur den angezeigten Ausschnitt aus dem
Signalbuffer. Ich habe die Variable die den Startpunkt des Fensters
markiert irgendwann mal umbenannt in MemWinStart falls Du mal im Coding
suchen willst.

Gruß Hayo

von sunny (Gast)


Lesenswert?

hi

@guido
>Findest du ev. wie und wo U24 angesteuert wird?
ja, ich denke schon.
der U24 hängt hardwaremäßig hinter dem U22 welcher für die ansteuerung 
des CH2 zuständig ist. du machst also

SwitchesCH2 &=0x00FF;
SwitchesCH2 |= 0x**00; // ** sind die daten die an U24 erscheinen sollen
SetSwitches(2, -1);

ich denke so müsste das gehen.

@hayo
die signalskalierung hatte ich schon gefunden.  mir ging es hier um die 
skalierung der dac ausgangsspannung in bezug auf die markerposition. ich 
hatte das etwas blöd beschrieben. auf jeden fall danke für die 
erklärung. ich werd mein glück noch mal versuchen.

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

danke, damit werde ich mal spielen.

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok hier wie angekündigt die neue 0.59 beta.

Hab noch schnell einige Sachen geprüft, aber soweit scheint alles stabil 
zu laufen (außer den bekannten Bugs). Wer mitgelesen hat der weiß schon, 
dass der Freeze-Bug endlich gefunden und beseitigt ist. Der DAC-Abgleich 
ist noch in Arbeit und funktioniert nur wenn man die Zerolevel vorher 
auf Gridmitte gestellt hat.

Der neu gefundene Fehler in der Zeitbasis, der auch in der originalen FW 
steckt kann nur durch die Implementierung des Rollmode beseitigt werden 
- Fertigstellungstermin noch unklar.

Wie immer alles andere in der readme. Ich hab auch noch die How To für 
die Linux und CDK Installation mit reingepackt.

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich hab die neue FW mal aufgespielt und auch den ADC-Abgleich 
durchgeführt, soweit so gut.

Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch 
nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null 
gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.
Oder hängt das noch mit dem DAC-Abgelich zusammen?

Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein 
wenig herumprobieren.

Gruß, branadic (W2014A)

von egberto (Gast)


Lesenswert?

Hallo Hayo,

ich hatte das ja bei meinen Compilierversuchen schon angedeutet - die in 
deiner Anleitung angegebenen Sourcen stehen da nicht mehr, und die als 
"improved" zu findenden haben einen anderen loader als du.
Könntest du nicht diese build.zip in jede weitere Beta einschließen? 
Dann hat man ein Makefile und auch deinen loader. So könnte sich eine 
breitere "Masse" damit auseinandersetzen.

Leider geht z.Z. mein Hausumbau vor, aber deine "Programming_Maps" 
empfinde ich als sehr hilfreich zum Verständnis - bitte mehr in dieser 
Art bzw. umfangreiche Kommentare in den Sources.

Viele Grüße,

egberto

von Johannes S. (demofreak)


Lesenswert?

branadic schrieb:
> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert? Kanal 1 und 2 werden ziemlich gut auf Null
> gebracht, bei Kanal 3 und 4 liegen die Signale unterhalb der Nulllinie.

Bei mir ganz genauso.

/Hannes

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich weiß nicht inwiefern dir das jetzt noch hilft, aber bei mir spuckt 
der automatische ADC-Abgleich folgende Werte aus:

CH1 ADC1 Voltage offset = 3
CH1 ADC2 Voltage offset = 0
CH1 ADC3 Voltage offset = 1
CH1 ADC4 Voltage offset = 0

CH2 ADC1 Voltage offset = 0
CH2 ADC2 Voltage offset = 0
CH2 ADC3 Voltage offset = 0
CH2 ADC4 Voltage offset = 0

CH1 Zero Sign Offs 1    = 113
CH1 Zero Sign Offs 2    = 134
CH1 Zero Sign Offs 3    = 91

CH2 Zero Sign Offs 1    = 115
CH2 Zero Sign Offs 2    = 140
CH2 Zero Sign Offs 3    = 104

Man merkt auch den Geschwindigkeitszuwachs durch deine Aufräumarbeiten 
:)
Wirklich schon schön anzuschauen.

Gruß, branadic

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

habe mich mal durch das Assembler-Listing durchgelesen, das du im 
anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil 
es ja zur Software gehört. Ich hoffe, dass stört keinen.

Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es 
langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch 
funktioniert. Der Durchschnitt wird nicht mit den benachtbarten 
Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom 
letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert, 
werden dadurch verschiedenste Werte gemittelt.

Mehr dazu dann Morgen, wenn ich es ganz verstanden habe.

Gruß,Stefan

von Blue F. (blueflash)


Lesenswert?

Stefan schrieb:

> habe mich mal durch das Assembler-Listing durchgelesen, das du im
> anderen Thread veröffentlich hast. Ich antworte einfach mal hier, weil
> es ja zur Software gehört. Ich hoffe, dass stört keinen.

Das ist hier schon ganz richtig, hatte nur das Thema von Bruno im 
Hardwarethread aufgegriffen, von daher überschneiden sich auch einige 
Themen in den Threads was ja nicht schlimm ist.

> Alles habe ich noch nicht 100% verstanden, aber den Größtenteil. Es
> langt auf alle Fälle um zu erkennen, warum das Averaging so ganz komisch
> funktioniert. Der Durchschnitt wird nicht mit den benachtbarten
> Messwerten gebildet, sondern mit den Messwerten die noch im Speicher vom
> letzten Aufruf stehen. Wenn der Trigger etwas ungenau funktioniert,
> werden dadurch verschiedenste Werte gemittelt.

Das wäre allerding etwas merkwürdig. Wundern täte es mich allerdings 
nicht, nach dem was ich bislang schon alles im Coding gefunden habe.
Aber schön, dass Du Dich da reinkniest, ich gebe zu ich hatte keine 
Lust, Assembler ist immer so mühsam.

Da gut optimiertes C-Coding auch nicht langsamer ist war ich schon am 
überlegen ob man das nicht in C umschreibt.

Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

@ egberto: deine Probleme kann ich nachvollziehen, probier mal mit
dem angehängten loader.flash aus dem "Offical_Build", bei mir geht das.

@ Stefan: Probier mal, es sieht wirklich nicht so schlimm aus. Freue
mich auf Rückmeldungen! Wie du das mit dem Trigger meinst, verstehe ich
nicht. Der Mittelwert sollte ja schon aus aufeinanderfolgenden Messungen
berechnet werden.

Gruß, Guido

von Günter J. (gjung)


Angehängte Dateien:

Lesenswert?

Hallo,

erstmal vorallem Danke an Hayo und Bruno für die bisherige hervorragende
Arbeit.

Ich habe mich mal mit der Idee beschäftigt das Flash für die
Entwicklungsarbeit zu umgehen und die Firmware direkt ins RAM zu laden.
Das geht gut in dem man anstatt dem Loader einfach ein "r0" an den
Anfang schreibt um den Relocate zu umgehen.

Das angehängte Makefile erzeugt zusätzlich zum TomCat.flash ein
TomCat.ram welches man ohne lange Wartezeit sehr schnell ins RAM
laden kann.
Durch den S8 Record am Ende wird die Firmware dann auch gleich 
gestartet.
Dieser "S8" Record ist vermutlich auch der Grund für den Timeout
wenn man das Flash beschreibt, da der GERMS Monitor dann die
Firmware starten will, aber ein einer falschen Stelle.
Im Flash File sollte man diesen Record entfernen (mach ich mich als
nächstes drüber).

Mit gtkTerm kann ich das Ram File in knapp 3 Minuten zuverlässig laden, 
damit spart man viel Zeit beim Testen, und das Flash wird auch nicht so
oft neu beschrieben was der Haltbarkeit des selben zu gute kommt.

Gruß,
Günter

von Kurt B. (kurt)


Lesenswert?

Könnte man eigentlich die Bootzeit verkürzen indem man den 
Startbildschirm rausnimmt, der 5 Sekunden angezeigt wird?
Man kann ihn ja immer noch über Utility/About Oscilloscope anzeigen.

Außerdem: Nach dem verstellen der Zeitbasis, wenn der Scrollbalken 
ausgeblendet wurde, bleibt die Anzeige kurz stehen. Ist das normal?

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> Kann es sein, dass die SearchZeroLines bei den Kanälen 3 und 4 noch
> nicht richtig funktioniert?

Ich hab die Search Zero Funktion bis auf ein paar kleine Reparaturen 
wieder auf original gesetzt weil ich die Feinkorrektur in Calibrate DAC 
machen will.

> Ansonsten sieht die FW bei mir momentan stabil aus, werd mal noch ein
> wenig herumprobieren.

Einen kleinen Bug hab ich eben noch gefunden und auch schon beseitigt, 
nach Calibrate Zero läuft das Signal nicht wieder los. Man muß erst am 
Timebase-Knopf drehen bevor es weitergeht.

Dass Dein einer Kanal bei 0000 liegt ist schon Glücksache, das Glück 
haben nicht Viele (ich denke da z.B. an Bruno). Bei mir liegen auch alle 
Offsets zwischen 0 und 3.

@Egberto

Ich hab das nicht mit ins Package reingetan, weil sonst der Umfang zu 
sehr anschwillt und das Limit irgendwann erreicht ist. Ich kann aber mal 
ein aktuelles Build auf Google Groups ablegen und die Links dahin 
aktualisieren (mach ich morgen).

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

Hi,
gerade habe ich mal die Firmware auf allen Kanälen durchgetestet und es 
sah recht gut aus (interner Rechteckgenerator).

Später dann (30 Minuten) habe ich diese Tests nochmal duchgeführt und 
gemerkt, dass die Kurven nur bei eingehendem Signal gezeichnet werden. 
Sobald der Triger weg ist, bleiben die Kurven stehen - böse Sache. Wenn 
ich den getriggerten Eingang auf Null gelegt habe, steht immer noch die 
'alte' Kurve. Sobald das Signal wieder am getriggerten Eingang liegt, 
wird das Bild wieder gemalt. Ist aber auch möglich, dass ich irgendwo 
zwischendurch was verdreht habe (Level, protrigger)...

Allerdings habe ich die Tests immer nur mit einem geschalteten Eingang 
durchgeführt. Wie es sich mit 2+ Signalen verhält, weiss ich nicht.

Im großen Ganzen ist der Rauschteppich aber merklich kleiner geworden - 
Danke dafür.

Michel

von Blue F. (blueflash)


Lesenswert?

Ok, danke für die Info,

ich schau es mir mal an.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Michel

Konnte ich nicht nachvollziehen. Kriegst Du das nochmal hin? Wenn ja 
dann die genauen Einstellungen posten (evtl. Bild).

Gruß Hayo

von Michael W. (slackman)


Angehängte Dateien:

Lesenswert?

Sorry,
hab an den EInstellungen gespielt...
Wenn ich von 'Edge' auf 'Pulse Width' gehe. Ein Redraw findet statt 
(Marker rechts und links zucken, nur die Kurven werden nicht neu 
gezeichnet. Allerdings denke ich mal, dass die Einstellungen nicht so 
ganz passen: Delta T 115us bei 1kHz Signal... ?

Bild ist nur mit 'nem Handy aufgenommen, sorry dafür. Hatte keinen Bock 
die Kamera zu suchen.

Michel

von Blue F. (blueflash)


Lesenswert?

@Michel

Ok Problem erkannt. Allerdings habe ich festgestellt, dass es nicht an 
meinen Änderungen liegt, denn die original FW 1.4 hat genau das gleiche 
Problem.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Hab noch mal ezwas rumgetestet, sobald die Triggereinstellungen zur 
Pulsweite passen läuft er weiter. Mir fehlt jetzt etwas die Erfahrung 
mit anderen DSOs, insofern weiß ich nicht ob dies als Fehler anzusehen 
ist, oder ob es gewollt ist. Kann hier jemand weiterhelfen?

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

Da ich in den letzten Jahren nur Hochsprachen gemacht habe, traue ich 
mir eine solche hardwarenahe Programmierung nicht zu, würde aber gerne 
helfen...

@Hayo:
vielleicht sollte ich mich mit dem USB beschäftigen? Die serielle 
Schnittstelle geht mir auf den Zwirn. Vielleicht auch den Updater 
(Option: In's RAM oder Flashen...)

Gibt es einen Teil im Code, der den USB behandelt? Ich bin leider 
FPGA-mäßig nicht so fit (s.o.), ist die serielle Schnittstelle direkt in 
den FPGA integriert? Die Aktivierung über die Funktionstasten läßt ja 
sowas vermuten...

Kann ich die Entwicklung auch unter Windows machen oder ist es unter 
Linux einfacher?

Werde mal auf Google Groups nach den entsprechenden Quellen fahnden...

Michel

von Crazor (Gast)


Lesenswert?

Oszi-seitig hängt am USB ein Cypress FX1. Das ist ein USB-fähiger 
8051er. Der FX1 ist außer per JTAG nur per einer weiteren UART mit dem 
FPGA verbunden. Das heißt du gewinnst nicht viel.

Für die Anwender ist der FX1 nur ein teurer USB<->RS232 Wandler, aber 
für die FPGA-Bastler kann man auf den FX1 auch eine nette Firmware 
laden, die das Oszi dann zum Rechner hin wie einen Altera ByteBlaster 
aussehen lässt. Somit kann man direkt ohne das Gerät zu öffnen neue 
Configs in den FPGA übertragen.

Beide UARTs (die für den seriellen und die für den USB-Anschluss) werden 
im FPGA realisiert und sehen von der Software her deshalb vermutlich 
auch beim NIOS aus wie normale serielle Schnittstellen. Außerdem denke 
ich dass auch an der USB-UART bei 115200 Baud schluss ist. Aber das ist 
jetzt Spekulation.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Danke Crazor, gute Erklärung.
Was ich mich in diesem Zusammenhang schon öfter gefragt habe:
Warum muss ich beim Welec-Updater den Germs-Monitor zum Upload starten, 
beim original W2000-updater von Welec nicht? Offensichtlich gibt es 
einen grundsätzlichen Unterschied zwischen den beiden Update- 
Verfahren?!
Hat Jemand tiefere Erkenntnisse diesbezüglich?

@werner: Für einen Updater per USB wäre ich seeeehr dankbar!
Mit diesen USB-seriell ist das echt ne Qual.

Gruß, brunowe

von Michael W. (slackman)


Lesenswert?

... ich hab' mal'n Bischen rumgesucht...

Leider bringt er es laut irgendeinem Schema auf Google Groups nur auf 
57k zum FPGA, laut Datenblatt kann der Cypress bis zu 230k. Wie die 
Anbindung an den FPGA funktioniert, muss ich erst rauskriegen.

Bleibt mir die Firmware wohl nicht erspart...
@Hayo
Ist es vielleicht möglich mir zwei weiteren Funktionstasten das Scope an 
dem USB lauschen zu lassen?

Was macht eigentlich die Firmware für den Cypress im Originalzustand? 
Nur Sampledaten ausgeben?

Michel

von Blue F. (blueflash)


Lesenswert?

Hi, das sind jetzt aber viel Fragen,

- erstmal kann jemand bei der Sache mit dem stehenden Signal 
weiterhelfen und mal kundtun ob das so sein muß oder nicht?

- es gibt USB-Routinen in der FW. Wenn jemand die Windows oder 
Linux-Seite übernimmt, könnte ich die Verarbeitung auf der DSO-Seite 
übernehmen.

- Der GERMS-Monitor ist normalerweise Bestandteil aller Developmentkits 
(hatte ich auf meinem DSP56000 Board auch) und ist wegen Minimalcodings 
nur auf RS232 ausgelegt. Die Schnittstelle ist eigentlich nicht für den 
Normalbetrieb gedacht, aber freundlicherweise hat WELEC sie gewollt oder 
evtl. sogar ungewollt zur Verfügung gestellt.

- Zur aktuellen Beta die bei mir gerade heranwächst: Der DAC-Abgleich 
wird langsam rund. Ich mache gerade noch ein paar Tests, ich denke 
morgen müßte ich soweit sein.

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

also ich kann nur von meinem täglichen Arbeitsgerät berichten:

Ist die Triggerquelle weg, dann wird die Anzeige auch weiterhin mit den 
digitalisierten Werten aktualisiert, allerdings aufgrund des fehlenden 
Triggers wandert das Signal wahllos durch den Bildschirm.
So kenn ich das jedenfalls und das macht auch irgendwo Sinn. 
Zugegebenermaßen arbeite ich mit einem DPO, nicht mit einem DSO.

Vielleicht weiß jemand anderes etwas anderes zu berichten.

Gruß, branadic

von branadic (Gast)


Lesenswert?

Hallo Hayo,

mir ist noch eine Sache aufgefallen.
Angenommen ich habe eine Zeitbasis von 5ms, lasse mir ein Signal 
anzeigen und stoppe dann, dann sollte ich theoretisch bis 5ns herunter 
den Zeitbereich verstellen können und somit im aktuellen Ausschnitt 
näher an das Signal heran zoomen können. So kenn ich das zumindest von 
dem Tek mit dem ich arbeite.
Tatsächlich kann ich aber nur bis 1ms/div verstellen. Klar kann ich das 
Signal nur im Rahmen der aktuellen Samplerate auflösen, dennoch sollte 
das funktionieren.
Das dies notwendig sein kann weiß ich aus meiner aktuellen Arbeit. Mit 
einem einfachen Triggerereignis hätte mir da nicht geholfen, aber das 
Reinzoomen.

Man muss immer davon ausgehen, dass man am Anfang nicht weiß wonach man 
in einem Signal sucht. Erst wenn man weiß wonach man sucht (dazu sollte 
man das Ereignis mal wenigstens kurz über den Bildschirm gerauscht haben 
sehen) kann man den Trigger auf ein entsprechend Ereignis einstellen.
Daher auch mein oberer Beitrag nach Sinn oder Unsinn der 
Bildschirm-aktualisierung bei fehlendem Triggerereignis.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo alle,

da ja Einiges aufgelaufen ist, mal ein paar Anmerkungen.

@ branadic: Das eigentliche Problem ist ja, dass afaik es keine
Triggerung gibt. Es wird gesampled und anschließend das Sample
nach einem passenden Event durchsucht. Das mit dem Zoomen im
Stop-Modus schaue ich mal an. Ich fürchte nur, dass es mal wieder
kein Bug sondern ein Feature ist, weil es sonst garnicht geht (Hayo
kann da nix für).

@ Hayo: Mach dir keine Gedanken um den Quatsch mit PW-Triggerung. Das
ist was für Logicanalyzer und im Source wohl noch drin wie andere
LA-Fragmente.

@ Michael Werner: Ob USB oder RS232 spielt eigentlich keine große
Rolle. Ein USB-Zugang wäre halt für die Leute wertvoll, die keine
RS232-Schnittstelle mehr haben. Einfach wird das aber nicht, da
sich das Welec als HID anmeldet und damit ein entsprechender Treiber
benötigt wird. Eine verbesserte Version des Welec-Updaters wäre
schon schön. Die enorme Flashdauer hierin wird wohl hauptsächlich
durch den Einsatz einer Klasse für RS232 hervorgerufen, die sowohl
für Linux als auch Windows nutzbar ist. Uhhnd, blos nix gegen den
GERMS-Monitor, der hilft sogar, wenn man fast alles kaputt geflasht
hat.

Gruß, Guido

von Karl (Gast)


Lesenswert?

Zum Trigger: Agilent bietet die 2 Einstellungen "Normal" und "Auto". 
Erstere zeichnet nur neu, wenn auch ein Trigger-Ereignis stattgefunden 
hat, letztere triggert immer mal wieder (0.3 s?) und zeichnet auch, was 
dann gemessen wurde. Beide sind nützlich.

Ein Oszi ohne Pulsweitentriggerung kommt mir nicht mehr ins Haus. Das 
ist mitnichten etwas für einen LA!

von Blue F. (blueflash)


Lesenswert?

@Karl

das heißt also das WELEC läuft im "Normal" Modus, und es fehlt 
eigentlich nur der "Auto" Modus.

Es ist also kein Bug sondern ein fehlendes Feature - korrekt?

Hayo

von michaelk (Gast)


Lesenswert?

So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt, 
die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde 
in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...

Uum Reinzoomen:
in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf 
"High Resolution" umstellen. Dann samplet das Osiz höher und man kann 
ohne Probleme reinzoomen. Das ist schon sehr praktisch.
Ob man sonst eine Beschränkung in der Zeitbasis hat, kann ich aber 
gerade nicht sagen.

Hat schon jemand das Makefile von Günter ausprobiert? Wenn das 
funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag 
probieren ob es bei mir klappt.

MfG, Michael

von Blue F. (blueflash)


Lesenswert?

michaelk schrieb:
> So, ich kann nun auch compilieren. Wenn es also eine Kleinigkeit gibt,
> die sich für den Einstieg eignet könnte ich mich daran versuchen. Werde
> in der nächsten Zeit mal versuchen mich in den Code einzuarbeiten...

Die Datenübertragung via USB für die PC-Software ist von mir weder 
getestet noch komme ich dazu hier was zu bauen (evtl. Erweiterungen). 
Hier wäre also Unterstützung notwendig.

Mein letzter Stand war, dass die FW1.2 einen Fehler in der 
Datenübertragung hat, und die Open Source FW basiert ja auf einer frühen 
Version der 1.2 FW (anscheinend aber nicht auf der offiziellen FW1.2).

> Uum Reinzoomen:
> in der Uni arbeite ich mit einem Agilent. Dort kann man im Menü auf
> "High Resolution" umstellen. Dann samplet das Osiz höher und man kann
> ohne Probleme reinzoomen. Das ist schon sehr praktisch.

Solche Sachen müssen erstmal auf die Wunschliste, es macht keinen Sinn 
damit anzufangen solange so viele unerledigte Baustellen offen sind. 
Deshalb bin ich mit der FFT ja auch noch nicht weiter, da ich einsehen 
mußte, das es einfach keinen Sinn macht. So langsam kommt aber Struktur 
in die Sache und ich denke wir können bald anfangen die Wunschliste 
abzuarbeiten.

> Hat schon jemand das Makefile von Günter ausprobiert? Wenn das
> funktioniert wäre es ja super zum Testen. Werde mal heute Nachmittag
> probieren ob es bei mir klappt.

Ich werde heute ein komplettes Build zur neuen 0.62 beta zur Verfügung 
stellen

Hayo

von Kurt B. (kurt)


Lesenswert?

Was meint ihr zum weglassen des Startbildschirms?

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Was meint ihr zum weglassen des Startbildschirms?

Meinst Du den ganzen Startbildschirm mit Versionsanzeige etc. oder nur 
das Logo? Ich finde das immer ganz nützlich. Außerdem braucht die Kiste 
die Zeit ohnehin um sich zu initialisieren.

Ich kann aber gerne mal eine logofreie Version machen wenn das der 
konsenz ist.

Hayo

von Kurt B. (kurt)


Lesenswert?

Ich meine den ganzen Bildschirm. Aber wenn während der Anzeige noch 
weiter initialisiert wird, macht es keinen Sinn.

von Blue F. (blueflash)


Lesenswert?

@Kurt

ja und es wird auch noch etwas länger dauern wenn ich die FFT 
implementiere, da ich die Zeit der Sartsequenz nutzen werde um die 
trigonometrischen Tabellen anzulegen (zumindest solange die nicht im 
Flash untergebracht sind). Diese Funktion ist zur Zeit nur deaktiviert 
weil ich mit dem Rest der FFT noch nich´t so weit bin.

@all

Zur Zeit bin ich beim Feintuning der DAC-Calibration Routine. Dabei bin 
ich auf einige Ungereimtheiten (mal wieder) beim Setzen der ADC-Register 
der Kanäle 3 + 4 gestoßen. Evtl. könnten hieraus einige der für Kanal 3 
+ 4 gemeldeten Effekte resultieren. Ich werde der Sache mal nachgehen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo,

nochmal zur Triggerung: mein Tek TDS210 verhält sich da exakt
genauso wie die Beta 0.59. Von Fehler kann also wohl keine Rede
sein, eher von Wunschliste.

Wenn sich jemand an der Firmware was vorknöpft, bitte hier
melden, damit nichr mehrere Leute am selben Problem arbeiten. Das
gibt sonst nur Frust und Probleme gibt es ja genug für alle.

Gruß, guido

von Michael W. (slackman)


Lesenswert?

@ Guido:
kannst Du mir mal einen Tipp geben, wie Du die Entwicklungsumgebung auf 
Ubuntu eingerichtet hast? Das, was im Forum stand, war ein wenig kurz 
und unsortiert. Ich bin gerade dabei 'Mint' bei mir einzurichten, 
gefällt mir besser als normales Ubuntu.

@Hayo:
kann ich Dein komplettes Build so übernehmen oder muss ich Anpassungen 
machen? Sind Deine letzten FWs (oder die letzte) komplett oder muss ich 
die alten Source dazubauen?

Besten Dank im Voraus
Michel

von Guido (Gast)


Lesenswert?

@ Michael W: Ich habe garnichts eingerichtet (wenn ich mich recht
erinnere). Nur das ndk4nios nach /usr/local kopiert (ausgepackt).
Im Makefile musste ich noch /usr/include in die Include-Liste
aufnehmen. Zum Kompilieren muss ich einmal/Tag den Pfad erweitern,
mit meiner Einrichtung mit:
"export PATH=$PATH:/usr/local/ndk4nios/bin".

Dann läuft make im "Official Build" durch. Für neue Betas mache ich
erst make clean und überschreibe dann das src-Verzeichnis im
Official Buil mit Hayos neuem src.

von michaelk (Gast)


Lesenswert?

@ Michael W.:
die Einrichtung auf Ubuntu ist eigentlich sehr einfach. Du lädst dir die 
deb-Pakete von der Google-Groups-Seite runter und installierst sie 
(entweder per Doppelklick oder im Terminal mit dpkg -i ...). Danach 
musst du noch den Installationspfad (z.B. /opt/cdk4nios) in die 
PATH-Variable eintragen (z.B. export PATH=$PATH:/opt/cdk4nios/bin). Dann 
brauchst du noch unix2dos. Das kannst du über die Paketverwaltung 
installieren (tofrodos). Danach solltest du im Terminal per make-befehl 
compilieren können.

von Michael W. (slackman)


Lesenswert?

Hi,
danke erstmal, nach dem zweiten Versuch habe ich Mint dann auch 
draufbekommen (Installerscript ist wohl buggy). Nachdem mir das Script 
den Windows Boot zerschossen hat, muss ich erstmal sehen, wie ich den 
wieder hinbekomme - shit, ist mir ewig nicht mehr passiert (hab seit 
Slackware 4.x in regelmäßigen Abständen mit diversen Linuxen gespielt). 
Ärgerlich, wahrscheinlich muss ich Alles platt machen und wieder neu 
installieren (Win & Linux) :-(.
WinXP Boot macht Bluescreen...

Michel

von Guido (Gast)


Lesenswert?

>wahrscheinlich muss ich Alles platt machen und wieder neu
>installieren (Win & Linux) :-(.

Blos nicht! Eine Reparatur müsste doch einfach sein, erstmal
mit der Windows-CD. Weitere Möglichkeiten könnte ich noch
suchen.

Guido

von Blue F. (blueflash)


Lesenswert?

Das komplette Build welches ich heute auf Google Groups zur Verfügung 
stelle muß man einfach nur in ein beliebiges Homeverzeichnis kopieren. 
Nach einem "make clean" und anschließendem "make all" (man muß natürlich 
ins Buildverzeichnis wechseln) sollte alles durchlaufen.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier kommt sie die 0.62 beta.

Highlight: Die DAC-Kalibrierung funktioniert jetzt richtig gut. Ich habe 
eine How to für den Abgleich beigelegt.

Zusätzlich habe ich Registerwerte für den Kanal 3 + 4 verändert. Bei mir 
konnte ich keine Auswirkungen beobachten. Wer was feststellt bitte mit 
detailierter Beschreibung posten.

Die Beschreibnungen für die Linuxinstallation habe ich mit neuen Links 
versehen u.a. zum aktuellen Build 0.62. Die Sources und das komplette 
Build sind auf Google Groups verfügbar.

http://groups.google.com/group/welec-dso/files -> 
BlueFlash_Build_0_62.zip

Gruß Hayo

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Bruno,

ich habe gerade deine neue FW aufgespielt und wie beschrieben den 
Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.
Die Linien liegen sauber um Null und schauen recht glatt aus.

Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den 
einzelnen Kanälen angeschaut.
Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling 
dargestellt.
Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor 
8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf 
10:1 eingestellt. Kanal 1  3  4 sind auf Einstellung 500mV/div, Kanal 
zwei auf 2V/div.
Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere 
Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie 
glatt wie zuvor aus.

Soweit gerade die ersten Dinge, die mir aufgefallen sind.

Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu 
entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

Mist aber auch, scheine auch schon irgendwie durch den Wind zu sein. Das 
passiert, wenn man mit dem Kopf gleichzeitig bei verschiedenen Dingen 
ist. Streiche Bruno und schreibe Hayo. Asche auf mein Haupt!

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> ich habe gerade deine neue FW aufgespielt und wie beschrieben den
> Abgleich durchgeführt, für alle Kanäle in allen Spannungsbereichen.
> Die Linien liegen sauber um Null und schauen recht glatt aus.

Wie bei mir auf beiden Geräten. Ich hatte allerdings das Gefühl das die 
Nulllinien auch noch eine leichte thermische Drift haben. Wenn das Gerät 
kalt ist liegt der Nullpunkt ganz leicht verschoben zum warmen Gerät.

> Danach habe ich mal das 1kHz-Testsignal hergenommen und mir auf den
> einzelnen Kanälen angeschaut.
> Trotz DC-Coupling wird das Signal auf allen Kanälen wie AC-Coupling
> dargestellt.

Ich hab mal mit dem Signalgenerator getestet, die AC/DC-Kopplung 
arbeitet korrekt.

> Auf Kanal 2 stimmt auch irgendwas nicht. Hier wird das Signal um Faktor
> 8 größer als auf den anderen Kanälen wiedergegeben. Hab alle Kanäle auf
> 10:1 eingestellt. Kanal 1  3  4 sind auf Einstellung 500mV/div, Kanal
> zwei auf 2V/div.

Du mußt Dich da irgendwie beim Messen verhauen haben. Hast Du Tastköpfe 
verwendet? Wenn ja, sind die alle auf 1:1 eingestellt?
Hab mit dem Signalgenerator an 50 Ohm Abschluß mit 1KHz mit Deinen 
Einstellungen getestet - alles ok.

> Auf Kanal drei zeigen sich mit dem Testsignal am Tastkopf größere
> Störungen/ Ausbrecher, nimmt man das Signal wieder weg schaut die Linie
> glatt wie zuvor aus.

Nicht meine Schuld, bzw. nicht die der FW. Das sind Störungen bzw. 
Schwingungen die zusätzlich eingekoppelt werden.

> Soweit gerade die ersten Dinge, die mir aufgefallen sind.

Danke für die schnelle Rückmeldung

> Ich hoffe es ist detailiert genug beschrieben. Ich bitte das Photo zu
> entschuldigen, aber ich denke man kann das von mir beschriebene erahnen.

Das Foto ist allerdings harter Toback. So sieht mein Gesichtsfeld nach 
einer durchzechten Nacht aus ;-)

Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

nein ich habe mich nicht verhauen. Ich habe die Tastköpfe verwendet und 
alle auf 10:1 eingestellt, hatte ich ja auch geschrieben.
Und wie gesagt, AC/DC-Coupling funktioniert bei mir mit der neuen FW 
nicht mehr korrekt.

Das Kanal drei Störungen zeigt wollt ich auch nicht auf die FW schieben, 
wollt es nur erwähnt haben.

Wegen dem Photo, so sieht das halt aus, wenn man das Telefon als Kamera 
verwendet.

Gruß, branadic (der die FW jetzt noch mal erneut aufspielt)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So sieht das bei mir aus.

Hayo

von Michael W. (slackman)


Lesenswert?

Help compile...

Ich bekomme immer
michael@michael-laptop ~/W20xx_Firmware/src $ make all
# 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean 
all M=16")
make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,
  benötigt von »obj/TomCat.out«, zu erstellen.  Schluss.
-----

what's wrong?

Michel

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Und so die AC/DC Kopplung.

Das Signal hat einen DC-Offset von ungefähr halber Sigalamplitude wie 
man sehen kann.

Oben auf Kanal 1 DC-gekoppelt unten auf Kanal 2 AC-gekoppelt. alles wie 
gehabt bei 1 KHz an 50 Ohm

Hayo

von Johannes S. (demofreak)


Lesenswert?

Ich hab bisher nur die DAC-Kalibrierung getestet, und das klappt am 2024 
nunmehr einwandfrei. Alle Kanäle liegen genau auf der Höhe des 
Nullmarkers. Super Sache. :)

Jetzt stört an sich "nur" noch das utopische Rauschen. Solange man in 
den 5er Bereichen messen kann, geht es auch so, aber leider hab ich 
zufällig gerade eine Standardanwendung, wo es eben nicht klappt.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Michael W. schrieb:
> Help compile...
>
> Ich bekomme immer
> michael@michael-laptop ~/W20xx_Firmware/src $ make all
> # 2009.05.17.19:07:48 --- (Note: to make for Nios 16, try "make clean
> all M=16")
> make: *** Keine Regel vorhanden, um das Target »obj/TomCat.cpp.o«,
>   benötigt von »obj/TomCat.out«, zu erstellen.  Schluss.

Wenn ich das richtig sehe hast Du die Anleitung nicht richtig gelesen.
Du machst Dein make all im Sourceordner, richtig? Du must dazu aber im
Buildordner sein, damit der Compiler alles findet. Steht auch in der
Anleitung.

Versuchs nochmal so.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Hannes

Tja den Rest Rauschen kann man nur Reduzieren, wenn man die 
Eingangsteilung verändert, und zwar so, dass der Fullscalebereich des 
ADC besser genutzt wird. In den 2er und 1er Bereichen werden nur 128 Bit 
genutzt. Dadurch muß das Signal so aufgezoomt werden, dass das Rauschen 
natürlich richtig heftig wird.

Hayo

von Blue F. (blueflash)


Lesenswert?

Was mir gerade so durch den Kopf geht -

Man könnte natürlich die vorhandenen Bereich umskalieren.

Der 1er Bereich wäre dann ein 2er Bereich und der 2er ein 4er. Damit 
sollte das Rauschen dann minimal sein. Die Schrittweite beim Umschalten 
wäre dann allerdings nicht mehr normgerecht.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Hm, das ist mir ansatzweise klar, und ich warte ja schon sehnsüchtig, 
dass ihr euch im Zusammenspiel zwischen Hardware- und Firmwarefraktion 
eine ganz tolle neuartige Methode einfallen lasst. :-D

/Hannes

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich hab die FW erneut aufgespielt, es ändert sich nichts.
Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe 
direkt mit dem Tastkopf an der Probe-Buchse. Ich lass das Gerät jetzt 
mal eine Weile laufen und mache nachher ein paar Messungen mit dem 
DDS-10.
Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen 
FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.

AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los 
ist.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> Der Faktor auf Kanal 2 hat sich als Faktor 10 herausgestellt. Ich messe
> direkt mit dem Tastkopf an der Probe-Buchse.

> Die deutlich größeren Störungen auf Kanal 3 waren in den vorherigen
> FW-Versionen nicht so extrem. Werd noch mal ein wenig herumspielen.
>
> AC/DC-Coupling macht bei mir keinen Unterschied, keine Ahnung was da los
> ist.


Bei allen drei Punkten spielen Dir garantiert die Tastköpfe einen 
Streich. Deshalb mache ich meine Testmessungen auch immer an 50 OHm, 
denn da gilt:

What You see it what You mess (oder so ähnlich).

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich kann übrigens gerne mal eine umskalierte Fassung raushauen, wenn Ihr 
mal sehen wollt wie das aussieht. Müßt Ihr nur sagen...

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo zusammen!

@Hajo

Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?
Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das 
1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo 
sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!

Oder?

Gruß Jürgen

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Spannungsbereiche lassen sich ja noch leicht etwas verbessern,
wenn man die Verstärkungen 1.25/2.5/5 wählt. Hatte ich mal eine
Firmware mit gebaut, bin aber nicht zum Testen gekommen und
sonst hatte wohl auch keiner Lust.
Damit hätten wir 200/160/160 Werte. Hätte mich interessiert, warum
Wittig das geändert hat.

Ein 4er Bereich neben dem 5er ist halt suboptimal.

Gruß, Guido

von Guido (Gast)


Lesenswert?

P.S.: @ Hayo: Kannst du den verdammten Testgenerator in der
Betaphase nicht einfach disablen? Es gäbe dann weniger
Messfehler ;-).

Guido

von Kurt B. (kurt)


Lesenswert?

Ja, das Testsignal ist AC! 800mVSS. Bei mir ohne Offset.

von Blue F. (blueflash)


Lesenswert?

Jürgen schrieb:

> Irgend etwas stimmt wohl doch nicht mit Deiner Erklärung?
> Laut Stromlaufplan und laut meiner Messung mit Multimeter sollte das
> 1kHz Referenzsignal doch etwa symmetrisch um die Masse liegen. Ergo
> sollte es keinen Unterschied zwischen AC- und DC-Kopplung geben!

Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an 
50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch 
korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset 
mit und geht dann aber wieder auf Mitte.

So soll es doch auch sein oder?

Was das Testsignal angeht, ich hab es mit dem Tastkopf gemessen - wie Du 
schon sagst, da es keinen DC-Offset hat sieht es in beiden 
Kopplungsarten gleich aus.

Hayo

von Michael W. (slackman)


Lesenswert?

Hi Hayo,
das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder? 
Nur Dein neues war da. Nun bekomme ich:
...
# 2009.05.17.20:12:57 --- Converting TomCat to S-Record
cat loader.flash > TomCat.flash
cat TomCat.srec >> TomCat.flash
unix2dos TomCat.flash
# 2009.05.17.20:12:57 --- Making TomCat.nm
# 2009.05.17.20:12:57 --- Making TomCat.objdump
Segmentation fault
make: *** [obj/TomCat.objdump] Fehler 139
michael@michael-laptop ~/Build $
....
'n Tipp?

Danke
Michel

von Jürgen (Gast)


Lesenswert?

Hayo schrieb:

> Meine Tests sind alle mit einem externen Signalgenerator durchgeführt an
> 50 Ohm. Wenn ich im DC-Betrieb einen Offset draufgebe wird dieser auch
> korrekt dargestellt. Bei AC-Kopplung geht das Signal kurz mit dem Offset
> mit und geht dann aber wieder auf Mitte.

Ach so, na dann passt ja alles!

Vielleicht hat Guido ja Recht mit disablen des Testgenerators ;-)

Jedenfalls ist die Bildwiederholrate in der 0.62-er super!

Jürgen

von branadic (Gast)


Lesenswert?

So, ich habe jetzt noch mal die FW neu aufgespielt, alle Leitungen 
gegengeprüft, da war tatsächlich der Wurm drin und alles kalibriert.

AC/DC funktioniert jetzt auch bei mir, hab jetzt mein DDS10 dran und 
einen Rechteck angeschaltet.

Das Terminalprogrammt spuckt nach der Kalibrierung und dem Abspeichern 
der Werte auf allen ADC's einen Offset von 0 aus.
Die DAC-Korrekturwerte liegen bei mir zwischen 82 und 133.

Was aber als Behauptung stehen bleibt ist, dass Kanal 3 bei mir schon 
mal in einer der vorherigen Versionen schöner aussah.
Die Störungen sind bei einem Rechtecksignal noch recht klein, schalte 
ich aber auf Sinus um machen sich die Störungen um so mehr bemerkbar.
Aber etwas ähnliches hatten wir ja schon einmal als Thema. Bei Kanal 3 
schein Welec irgendwas versaut zu haben.

In der x-y-Darstellung scheint der Offset von Kanal 1 und 3 invertiert 
zu sein. Dreh ich nach links wandert das Signal nach rechts. Muss ich 
hier nur umdenken oder sollte das nicht anders sein? Ich meine mich 
daran erinnern zu können, dass das beim Tek anders ist.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Michael W. schrieb:
> Hi Hayo,
> das Build fehlte, besten Dank. Bei Google groups war es aber nicht oder?
> Nur Dein neues war da. Nun bekomme ich:

Wie schon oben geschrieben:

http://groups.google.com/group/welec-dso/files

-> BlueFlash_Build_0_62.zip


> make: *** [obj/TomCat.objdump] Fehler 139

Den 139 er Fehler bekomme ich momentan auch. Weiß aber nicht woran es 
liegt. Betrifft aber anscheinend nicht die erzeugte Firmware, denn die 
läuft trotzdem problemlos. So wie es aussieht ist es nur der Objektdump 
der davon betroffen ist.

Hayo

von Michael W. (slackman)


Lesenswert?

@Hayo:

ich hatte Deinen Build bei Google Groups schon gefunden nur das 
Originale nicht. Und die paar Dateien in den Firmwareupdates kamen mir 
für ein Build immer sehr wenig vor.

Denn kann's jetz ja für mich auch losgehen :-)

Kann man die Source für den Updater irgendwo laden? Ich finde nur 
'Exen'...

Michel

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab hier auch so eine fw bei der in allen bereichen die 1,25 
vorverstärkung aktiv ist. es ist die .59 von hayo. falls jemand sich mal 
den unterschid ansehen will.

@hayo
ist denn die änderung für adc fullscale nicht ziemlich umständlich? es 
müssten ja eine menge änderungen gemacht werden. ein interessanter test 
währe es sicherlich.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

sunny schrieb:

> ist denn die änderung für adc fullscale nicht ziemlich umständlich? es
> müssten ja eine menge änderungen gemacht werden. ein interessanter test
> währe es sicherlich.

Ist schon in Arbeit, kommt nachher, muß erstmal uploaden und testen.
War selbst mal neugierig...

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier die umskalierte 0.62 experimental. Sehr eindrucksvolle 
Demonstration dessen was ich an Theorie hier schon zum Besten gegeben 
habe.

Besonders interessant für diejenigen, die wie ich zwei Geräte haben und 
daher direkt den originalen 200mV Bereich mit dem umskalierten 200mV 
Bereich vergleichen können.

Wenn jetzt der Eingangsteiler für die 4er und für die 2er Bereiche um 
Faktor 2 angepasst würde (Widerstände ändern) dann hätten wir auch 
wieder unsere 2er und 1er Bereiche aber mit dem reduzierten Rauschen.

Wenn ich mir das so ansehe bin ich echt am Überlegen ob ich mir da ein 
paar andere Widerstände reinlöte.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Kleiner Vergleich für alle!

Hier die originale Skalierung...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...und im Vergleich die umskalierte Fassung.

Alles mit dem gleichen Signal.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...und hier zum direkten Vergleich der originale 100mV Bereich der ja 
der umskalierte 200mV Bereich ist

Hayo

von Odic X. (odic)


Lesenswert?

Guten Abend zusammen,

vorab erstmal meine volle Hochachtung an alle, die hier Zeit und Nerven 
investieren, um nicht nur sich sondern auch der Allgemeinheit etwas 
Gutes zu tun.

Da ich momentan selbst auf der Suche nach einem günstigen DSO bin, 
verfolge ich die Entwicklungen um die Wittig- Oszis seit etwa einer 
Woche. Mit den ständigen Verbesserungen werden die Geräte zunehmend 
interessanter für mich. Leider habe ich aber bis dato noch kein 
vollständiges Bild im Kopf, was die Geräte denn nun können und was 
nicht. Gibt es denn irgendwo eine Übersicht die darstellt, was

- fehlerfreie Funktionen
- eingeschränkt benutzbare Funktionen
- fehlende / nicht nutzbare features

an diesem Gerät (gemessen an normalen Eigenschaften eines DSO in der 
Leistungsklasse) sind?
Falls es so etwas nicht gibt: lässt sich sagen, was die gravierendsten 
Vor- und Nachteile, beispielsweise im Vergleich mit einem TDS210 o.ä. 
sind?

Das würde mir eine Kaufentscheidung deutlich erleichtern....

Viele Grüße und macht weiter so,

odic

von Guido (Gast)


Lesenswert?

Hallo Hayo,

mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA
auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die
Verstärkungen 1-2-4. Richtig? Damit wird Auflösung verschenkt.
Oder hast du 1,25-2.5-5 mit dem OPA immer auf Vu=1.25?

Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf
dem Schlauch.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Odic

Es kommt auf Dein Einsatzgebiet drauf an. Für den Hobbybereich bei 
Frequenzen bis 25 MHz auf jeden Fall ein Schnäppchen. Bei höheren 
Ansprüchen nur nach Verbesserungen an Hard und Software. An beidem sind 
wir dran - allerdings ohne Garantien. Für professionelle Zwecke lieber 
ein Tek oder Agilent.

Hayo

von Guido (Gast)


Lesenswert?

Hallo odic,

ganz klar: wenn du ein Oszi für die tägliche Arbeit suchst, lass
die Finger von dem Welec. Wenn du für rel. wenig Geld ein tolles
Spielzeug mit Zukunft willst, bist du damit bestens bedient. Afaik
gibt es am Welec keine fehlerfrei Funktion, viele sind aber schon
benutzbar.

Soweit erstmal, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> mal langsam zum Mitdenken. Du hast jetzt die Verstärkung des OPA
> auf 1 geschaltet (keine Umschaltung mehr) und damit insgesamt die
> Verstärkungen 1-2-4. Richtig?

Falsch. Ich hab an der Verstärkung nix geändert. Ich hab bloß die 
Skalierung für die Ausgabe geändert. Dadurch bleibt der 5er Bereich ein 
5er Bereich aber der 2er wird ein 4er und der 1er wird ein 2er Bereich.

Ergibt die Schritte 5V/4V/2V/0,5V/0,4V/0,2V usw

> Welche Widerstände willst du denn umlöten? Da stehe ich völlig auf
> dem Schlauch.

Wenn ich das richtig in Erinnerung habe gibt es ein Widerstandsnetzwerk 
welches eine Vorteilung vornimmt (korrigier mich wenn ich da falsch 
liege). Wenn man die Vorteilung für die beiden Bereiche um Faktor zwei 
ändert dann kann man mit der umskalierten FW wieder mit den normalen 
Bereichen arbeiten 5V/2V/1V/etc.

Hab ich das vernünftig erklärt oder war das eher konfuziös?

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

ich fürchte heute wird das bei mir nix mehr. Wird aber langsam besser.
Ich glaube jetzt kann ich dir folgen (habe gerade 3 mal editiert).

Die Teiler sind aber nur für die Bereiche ab 100 mV/div zuständig,
Mit der Änderung fliegen die Grundbereiche 50-20-10 mV/div über
Board. Das ginge wieder nur mit mehr (Hardware-) Verstärkung.

Ich muss jetzt gleich noch einen (kurzen) Testberich schreiben.

Gruß, Guido

von Guido (Gast)


Lesenswert?

So jetzt sauber getrennt zur Beta 0.62:

@ Hayo: Super, die Kalibrierung von ADC und DAC funktioniert für
meine 2 Kanäle perfekt. Das ist wirklich ein Fortschritt, die
Testfunktionen können dann gelegentlich entfernt werden (damit
die Tasten frei werden ;-)).

Eine kleine Unstimmigkeit ist mir noch aufgefallen: Im Delayd-Mode
werden die Offset-Marken für beide Kanäle im unteren Fenster leicht
verschoben dargestell. Im oberen Fenster sind sie korrekt.

Nochmal Gruß, Guido

von Jürgen (Gast)


Lesenswert?

Hallo Hajo, hallo Guido,
100% Ack für Guido! Was soll wohin scaliert werden? Es kann alles 
angepasst werden. Wo haben wir definiert was 100% für die Anzeige sind? 
Bisher sind sicher nur 8Bit für 100% definiert :-) Sind 100% ADC jeweils 
8 Divs(mit entsprechendem Faktor) = 100% TFT in jedem (1,2,5-er)Bereich? 
Wollen wir uns an die üblichen Bereiche 1-2-5 halten?Alles weitere 
leitet sich daraus ab. Mit Sicherheit ergeben die kleinsten 
Softwarefaktoren auch das geringere Rauschen!
Dank Hajo`s bisheriger fantastischer Arbeit ist ein guter Stand 
erreicht, aber es gibt genug Baustellen, die abgearbeitet werden müssen: 
z.B. Triggerung allgemein, PW-Triggerung, USB-Comm... usw., somit die 
endgültige Scalierung wohl auch von den Ergebnissen an der HW-Seite 
abhängt! Die Scalierung sollte nach meiner Meinung jetzt nicht mehr die 
höchste Priorität haben.

Gruß Jürgen

von Odic X. (odic)


Lesenswert?

"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)

Danke für eure Antworten, ich muss aber doch nochmal nachhaken. Ich 
vermute, dass noch niemand eine vollständige Qualifizierung des Geräts 
durchgeführt hat. Daher frage ich gar nicht nach Punkten wie 
Messgenauigkeit, Temperaturverhalten o.ä.

Vielmehr interessieren mich ganz pragmatische Punkte, die für ein 
halbwegs vernünftiges Arbeiten mit dem Scope - selbst im Hobbybereich - 
erforderlich sind. Hiermit meine ich beispielsweise:

- Skalierung von Amplitude und Zeitachse (schrittweise / frei, auch nach 
der Triggerung)
- Verschieben der Signale in X- und Y-Richtung (auch nach der 
Triggerung)
- (funktionierende) Einstellmöglichkeiten für die Triggerung (Single, 
Normal, Auto, Triggerquelle, ...) und deren Zuverlässigkeit
- Möglichkeiten der Signalkopplung
- ...

Vielleicht könnte man - falls es so etwas noch nicht gibt - mal eine 
Liste von Oszi-Eigenschaften inkl. (subjektiver) Bewertung deren 
technischer Umsetzung im Wittig-Scope erstellen.

Ich habe zwar selbst kein Gerät, kann mich aber an der Erstellung der 
Kriterien gerne beteiligen...

odic

von sunny (Gast)


Lesenswert?

hi hayo,

die ergebnisse sehen ja ganz nett aus. mit der änderung der verstärkung 
des eingangsverstärkers ist das so eine sache. die verstärkungen für die 
1,2 und 5er bereiche werden nicht durch ein wiederstandsnetzwerk 
festgelegt.
es sind 3 volldifferenzial opv's verbaut welche intern fest auf eine 
verstärkung von 2 eingestellt sind. die umschaltung der verstärkungen 
erfolgt, indem 2 der 3 opv's etweder mit einem symetrischen (effektive 
verstärkung=2) oder mit einem asymetrischen eingangssignal (effektive 
verstärkung=1) betrieben werden. dafür wird jeweils ein eingang durch 
einen analogschalter etweder auf masse oder auf den ausgang des vorigen 
opv geschaltet.
man müsste diesen verstärkerteil also neu designen. daran arbeite ich 
zzt. komm nur im momment nicht so recht weiter. wer interesse hat, kann 
hier noch etwas mehr darüber lesen. 
http://d-amp.org/include.php?path=forum/showthread.php&threadid=586&postid=last

von Guido (Gast)


Lesenswert?

Hallo odic,

>"keine fehlerfreie Funktion"... höre ich da einen gewissen Zynismus? ;-)

nö, kein Zynismus, uns macht das ja Spaß. Es ist halt momentan wirklich
so, dass die von dir angesprochenen Eigenschaften (was verstehst du
unter: nach der Triggerung?) vorhanden sind, zum größten Teil aber nicht
das gewünschte Ergebnis bringen. Wie du dem Thread entnehmen kannst, 
wird
noch an der Darstellung der Messwerte auf dem Bildschirm gearbeitet, da
diese unbefriedigend ist. Die anderen Dinge (z.B. eine funktionierende
Triggerung) sind erstmal aufgeschoben, aber je mehr Leute sich an der
Entwicklung beteiligen, desto schneller geht es.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Sunny

Hm, schade, dann ist die Änderung der Vorteilung wohl doch etwas 
schwieriger. Wenn Du und Bruno da weiter kommen könnte es ja dennoch was 
werden. Ihr könnt ja auf jeden Fall die Anforderung im Hinterkopf 
behalten.


@Odic

Die Punkte die Du hier aufzählst sind eher als unkritisch einzustufen. 
Entweder sie sind schon benutzbar oder sie lassen sich rein 
Softwaretechnisch nachrüsten. Kritischer ist da die Reduzierung des 
Rauschens welches als eines der Hauptmankos von den meisten hier 
wargenommen wird.

Dennoch läßt sich mit dem Gerät auch jetzt schon eine Menge im 
Hobbybereich anstellen. Nicht zuletzt ist es eine schöne Spielwiese für 
Optimierungswütige!

Eine kleine Sammlung an Punkten findest Du in dem Beta-Paket in der 
readme Datei (bzw. liesmich) und im Header der tc_vars.cpp.

Hayo

von Kurt B. (kurt)


Lesenswert?

Wie steht es eigentlich um die QuickMeasure Funktionen? Währe schön, 
wenn die wieder funktionieren würden.

von Michael W. (slackman)


Lesenswert?

Hi,
bei mir leider nicht alles ok nach dem neuen Update...
Werde wohl nochmal flashen.
Probleme:
Kanal 1 und 4 triggern nicht, Kanal 2 nur auf fallend und Kanal 3 auf 
steigender Flanke. Da ist MEIN Build wohl doch nicht erfolgreich 
gelaufen. Werde ich Hayo's Kater nochmal flashen (müssen)... :-/

Michel

von Blue F. (blueflash)


Lesenswert?

@Kurt

Quick Measure und Cursorpositionen muß ich noch machen, das hatte ich 
erstmal aufgeschoben bis die Skalierungsfragen geklärt sind, sonst muß 
ich das evtl. doppelt machen.


@Michael

der Trigger funktioniert leider auch bei mir nur bedingt. Insbesondere 
Rechtecksignale scheint er nicht zu mögen, während es bei Sinus 
erheblich besser klappt. Auch das ist noch eine offene Baustelle die 
ebenfalls mit der Skalierung zusammenhängt und deshalb von mir 
aufgeschoben wurde. Dazu kommt, das mir die technische Umsetzung der 
Triggerung noch nich so ganz klar ist.

Vom Coding her habe ich den Eindruck, dass es eine kombinierte Harware- 
und Softwaretriggerung ist. Es werden für die Triggerung einige Register 
gesetzt deren Zweck ich erst ergründen muß und es wird das Signal 
Softwareseitig je nach Triggerung im Fensterausschnitt hin und her 
geschoben.

Vielleicht können die Jungs von der Hardwarefront hier etwas zur Klärung 
beitragen. Ich wüßte auch nicht, wie sonst der externe Trigger 
realisiert sein sollte wenn nicht hardwareseitig.

@all

Da jetzt doch einige Köche im Brei rühren hier zur Abstimmung ein kurze 
Roadmap die ich mir vorgenommen habe:

- Codeoptimierung an der Skalierung, wird nach außen nicht weiter
  sichtbar sein, wird aber den Code wartbarer bzw. erweiterbarer machen
  für den Fall dass wir die Verstärkung Hardwareseitig ändern.

- Rollmode/Shiftmode für die ganz langsamen Zeitbasen implementiern.
  Hierzu hab ich mir inzwischen einige Gedanken gemacht und das
  Konzept steht schon (in Rohfassung)

- Trigger und Cursor auf die neue Skalierung anpassen evtl. bei der
  Gelegenheit die Triggerung optimieren

- Mathfunktionen noch mal an die neue Integerskalierung anpassen.

- FFT implementiern. Hab ich teilweise schon implementiert, aber zur
  Zeit deaktiviert angesichts der drängenden Probleme an anderen 
Stellen.


Eine echte Hilfe wäre es wenn diejenigen, die neu einsteigen sich mit 
dem Coding vertraut machen indem sie nach Fehlern suchen oder 
grundsätzliche Funktionen erforschen wie z.B.:

- es wird nach meiner Vergrößerung des Grids immer noch der untere Rand
  des Signals abgeschnitten. Fehler liegt vermutlich irgendwo in
  CopyPlanes() und/oder TransferPlanes() an der Größe der übertragenen
  Bildschirmabschnitte.

- Im delayed mode hab ich leider noch eine Verschiebung drin zwischen
  oberem und unterem Fenster.

- Wie arbeitet die Triggerung im Detail?




Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die ext. Triggerung wird wohl hauptsächlich in Hardware erledigt
(Schwelle über PWM, ..., Ausgang direkt auf den FPGA). Ich habe
den Eindruck, dass die interne Triggerung nur über Software
simuliert wird. Bei meinen 2 Kanälen geht es mit der 0.62, aber
halt nur, wenn das Signal den halben Bildschirm füllt.

Das abgeschnittene Signal kommt imho nicht von TransferPlanes,
da dort die Grenzen für alle Planes gleich sind und das Grid...
ja korrekt überttragen werden. Da muss man die ganze Kette ab
READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr
gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal
vor.

Ev. sollte man die Roadmap als Artikel im Wiki anlegen, da kann
sich dann jeder mit Wünschen und Arbeitswillen melden. Das
kann doch bestimmt jemand besser als ich?

@ Kurt: Hat das QuickMeasure denn mal halbwegs vernünftig
funktioniert? Ich habe es nie ausprobiert. Es gibt da eine
Funktion CALCQMDATA, die ist mehr als 2400 Zeilen lang. Ich denke,
da muss man erstmal Struktur reinbringen.

Gruß, Guido

von Kurt B. (kurt)


Lesenswert?

Halbwegs vernüftig ja. Aber doch recht ungenau und nicht immer in sich 
schlüssig.

Man sollte wirklich mal eine Wiki Seite machen: Wer arbeitet aktuell 
woran, wer testet auf welchem Gerät, an welchen Problemen wird z.Zt. 
nicht gearbeitet und aus welchem Grund...

Mein W2024 ist seit Donnerstag unterwegs. Hoffentlich kommt es Heute. 
Dann kann ich die offizielle Firmware noch einigen Test unterziehen.

von Blue F. (blueflash)


Lesenswert?

@Guido

Ich bin mir da nicht sicher ob evtl. doch auch auf Hardwarebasis 
getriggert wird. Das gilt es aber auf jeden Fall zu klären bevor wir da 
am Coding rumschrauben

Wenn Du die Sache mit dem abgeschnittenen Signal fixen könntest wär das 
natürlich super. Mein Ansatz war, einfach mal die einzelnen Planes 
abzuschalten (in Transfer Planes auskommentieren) evtl. auch mehrere 
gleichzeitig und dann mal sehen von welcher Plane das Signal 
überschrieben wird. Das schränkt die Suche doch ungemein ein. 
Hauptverdächtige sind ohnehin die unteren Bereiche der UI-Planes evtl. 
auch die Marker-Plane.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Gibt es die offizielle FW1.4 eigentlich als Download auf Wittigs 
Homepage? ansonsten stelle ich sie gerne als Flashdump zur Verfügung.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Guido

Wenn ich mir das so überlege wäre es natürlich noch sinnvoller die 
Stellen auszukommentiern an denen ClearPlanes() aufgerufen wird.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: Das ist aber eigentlich nur im UserInterface.

Guido

von branadic (Gast)


Lesenswert?

Hallo Hayo,

die aktuelle FW1.4 wurde nicht von Wittig/Welec auf der Homepage bereit 
gestellt.
Das mit dem Wiki (im Sourceforge) halte ich für eine gute Idee, zum 
jeder angemeldete User Änderungen vornehmen kann.

Vielleicht können wir da heute Abend was in Angriff nehmen.

Gruß, branadic

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

ein Backup der FW1.4 vom 2024A gab es hier:

Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"

Gruß
Jürgen

von Guido (Gast)


Lesenswert?

Hallo,

Problem gelöst, es müssen in den Transfer-Routinen halt einfach
die zusätzlichen 16 Zeilen transferiert werden. Hierzu habe ich
einfach den Loop-Counter entsprechend erhöht.

@ Hayo: einfach in hardware_t vom Editor alle 7740 durch 8060
ersetzen lassen, das wars. Die Zahlen sind dezimal in Longwords,
falls jemand nachrechnen möchte.

Gruß, Guido

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Achso,

falls es sich jemand anschauen möchte.

Guido

von branadic (Gast)


Lesenswert?

Hallo Guido,

welche FW-Version hast du verwendet? Die letzte Beta von Hayo?

Gruß, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

>welche FW-Version hast du verwendet? Die letzte Beta von Hayo?

jepp, wie immer (also die 0.62).

Gruß, Guido

von Stefan (Gast)


Lesenswert?

Hallo Guido,

>Das abgeschnittene Signal kommt imho nicht von TransferPlanes,
>da dort die Grenzen für alle Planes gleich sind und das Grid...
>ja korrekt überttragen werden. Da muss man die ganze Kette ab
>READADC_ALL untersuchen. Habe jetzt von Stefan nichts mehr
>gehört, wenn er sich nicht mehr meldet, nehme ich mir das mal
>vor.

Das WE war leider keine Zeit. Ein abgeschmierter Xp-Rechner in einer 
saublöden Hardwarekonfiguration hat den ganzen Sonntag gekostet...

In den ganzen READADC-Assembler-Funktionen steige ich einigermaßen 
durch. Wie ihr sicher erwartet habt, ist das nicht für schwache nerven, 
wenn ich euch jetzt ein paar Details erzähle. Das der Code überhaupt je 
funktionsfähig wurde, grenzt fast an ein Wunder.

@Hayo
Ich bin mir nicht sicher, wie weit du dich in den Assembler-Code 
eingearbeitet hast, weil da ein Fragezeichen im Code angefügt ist. Für 
das Verständnis erkläre ich mal einwenig den Ablauf der einzelnen 
Funktionen

Also: zuerst muss READADC_ALL2 aufgerufen werden. Die Funktion liest den 
genannten Kanal aus und speichert die gewünschte Anzahl Werte im 
Speicher an der Andresse DataArray1.

Danach muss PREPARE_READADC aufgerufen werden. Die Funktion speichert 
die Offsetwerte der vier ADC eines Kanals und die Anzahl der Samples in 
globale Register.

READADC_ALL liest die in READADC_ALL2 eingelesenen Daten wieder aus und 
sortiert um, verarbeitet sie weiter (invertieren, Offset-Abgleich, 
Averaging) und speichert sie wieder ab. Die which-Parameter wird (so 
sehe ich das) nicht abgefragt (ist also überflüssig).

Problematisch ist der Code an mehreren Stellen:
- Die Übergabe der einzelnen Funktionen erfolgt über globale Register 
(gibt davon insgesamt 7 Stück). Da zwischen den ASM-Blöcken noch C-Code 
liegt ist meineserachtens nicht sichergestellt, dass die Register auch 
noch richtig gesetzt sind. Vielleciht ist irgendwo noch ein 
Schutzmechanismus. So gut kenne ich mich damit aber nicht aus.
- In READADC_ALL2 kann man zwar einen anderen Adressbereich zum 
Zwischenspeichern als Parameter angeben. Davon ist ab schwer davon 
abzuraten genauso wie vor jeder Veränderung der Speicheraufteilung im 
RAM. In den ASM-Blöcken finden sich nämlich Hart-Codierte Adressen 
wieder. Alle Stellen zu finden, wo der Entwickler zu faul war, 
Konstanten oder Zeiger zu verwenden, dürfe ziemlich aufwendig werden ;-)

Das Invertieren und Averaging findet unter Einbeziehung des 
ZeroLevel-Wertes statt. Der Offset zum ZeroLevel wird allerdings erst 
nach dem Averaging und Invertieren subtrahiert. Das ist wohl nicht 
wirklich schlau ;-), da der Offset-Abgleich (zumindest beim Invertieren) 
in die falsche Richtung wirkt

Gruß,
Stefan

von branadic (Gast)


Lesenswert?

Hallo Firmware-Gemeinde,

ich war mal so frei im Sourceforge-Wiki eine Seite für die Firmware 
anzulegen. Ich war außerdem mal so frei Hayo's aufgeführte Roadmap 
gleich mit zu übernehmen.
Soviel ich weiß hat Hayo ja einen Souceforge-Account. Alle anderen 
FW-Entwickler würde ich bitten wollen, sofern nicht vorhanden, einen 
solchen Account anzulegen, damit ihr im Wiki aktualisieren könnt.

Somit hätten wir eine gemeinsame Plattform, wo auch die Firmware erfasst 
ist. Natürlich können wir die Seite um die bereits implementierten 
Funktionen erweitern.

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

So, weil es so viel Spaß macht zu posten, hier nun auch noch der Link:

http://apps.sourceforge.net/trac/welecw2000a/wiki/Firmware

So long, branadic :)

von Guido (Gast)


Lesenswert?

Hallo Stefan,

schön von dir zu hören ;-).

über die Inputregister würde ich mir nicht allzuviel Gedanken
machen, davon gibt es ja mehrere Sätze und ich unterstelle
einfach, dass der C-Compiler das im Griff hat.

Sowas mit der verdrehten Reihenfolge habe ich vermutet,
vielleicht kannst du das einfach mal umdrehen und probieren.
Wenn es dann doch wieder Probleme gibt, müssen wir da halt
tiefer einsteigen.

æ branadic: Bravo, mit direktem Link, damit sogar ich das finde.
Muss ich gleich verbookmarken. Ev. sind ja da die Ladezeiten
kürzer als heute im mikrocontroller.net.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Mann! Da ist (bzw. ißt) man nur kurz beim Griechen und schon geht hier 
die Post ab.

@Guido

Super, das hat mich schon die ganze Zeit genervt. Aber irgendwie hatte 
ich auch keine Lust danach zu suchen. Sehr cool! Werd das mal gleich 
einbauen.


@Stefan

Na das nenne ich eine echte Detailanalyse. Den groben Ablauf hatte ich 
mir schon so rausgelesen, zumindest reichte es aus die Funktionen in 
meinen Abgleichroutinen einzusetzen. Aber was da im Detail abging hatte 
ich noch nicht raus. Allerdings überrascht es mich irgendwie nicht, das 
die grundlegenden Hardwareroutinen genauso zusammengeschustert sind wie 
der Rest. D.h. wir müssen die ADC-Korrektur vor die Averaging und 
Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?


@Branadic

Prima, das ist eine gute Idee und ja, ich hab einen User für SFN. 
Allerdings gebe ich zu, dass  die etwas anstrengende Menüstruktur und 
Handhabung mich immer etwas abgeschreckt hat. Aber das ist natürlich ein 
Grund sich da nochmal ranzusetzen.


@all

Ich freue mich über die inzwischen so aktive Hilfe und Resonanz. Wie man 
sieht beschleunigt das den Prozess doch ungemein.
So werd mich mal schnell noch etwas ins Coding stürzen - Das Forum hab 
ich dabei natürlich im Blick...


Hayo

von egberto (Gast)


Lesenswert?

Pass aber auf wegen der vielen Ouzos ;-))

von branadic (Gast)


Lesenswert?

So Jungs,

ich hab noch ein wenig in der Menu-Struktur herumgefuscht. Von der 
Firmware-Page aus könnt ihr nun also in die Roadmap, in die History und 
in die Wish-List wechseln. Hat alles seine eigene Seite, damit es auch 
übersichtlich bleibt.

Ihr dürft euch jetzt an den Seiten verlustieren und erweitern.

Gruß, branadic

von Michael W. (slackman)


Lesenswert?

Hallo Hayo,

ich wollt' Dich nochmal gerne ärgern:
Gerade habe ich die 0.59 Firmware eingespielt, weil ich mir sicher war, 
dass flankengesteuertes Triggern auf allen Kanälen funktionierte - und:
jawoll! In der 0.59 funktionierte die Triggerung besser als in der 
Neuen.
Hier hast Du also irgendwas verändert, was nicht gut war.
(Obwohl mir der Abgleich wirklich gut gefällt, Triggerung ist mir fast 
noch wichtiger.)
Zusammenfassung:
0.59: flankengesteuertes Triggern auf allen vier Kanälen sowohl steigend 
als auch fallend: ok
0.62: Kanal 1 & 4: keine flankengesteuerte Triggerung möglich
Kanal 2: nur steigent; Kanal 3: nur fallend.

Jámas! alter Grieche ;-)

Michel

von Michael W. (slackman)


Lesenswert?

Ach ja: Testsignal war der interne Rechteck

Michel

von Robert (Razer) (Gast)


Lesenswert?

Hallo Hayo,

Habe gerade eben auch die 0.62 geflasht.
Auf Kanal 1 u. 4 funktioniert bei mir auch keine flankgengesteuerte 
Triggerung.

Auf Kanal 2 funktioniert nur die Triggerung auf die fallende und auf 
Kanal 3 nur eine Triggerung auf steigende Flanke.

lg Robert (W2024A)

von Blue F. (blueflash)


Lesenswert?

Hm...

dann muß ich nochmal sehen was ich da geändert habe. meines Wissens hab 
ich an der Triggerung nichts geändert. Allerdings hab ich ein Register 
für Kanal 3 + 4 anders gesetzt. Ich Schau mal - wir wollen ja auch keine 
Rückschritte machen.

Hab übrigens die Korrektur von Guido eingespielt, sieht gut aus so ohne 
abgeschnittenes Signal.

Bis morgen

Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

@Guido,
es werden noch einige Pixel nicht richtig gesetzt.

@Hayo,
Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder 
raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die 
alten Werte verloren gehen. Allerdings nur beim Autotrigger. 
Normaltrigger und Singe Shot sind OK.

von Stefan (Gast)


Lesenswert?

@Stefan

>D.h. wir müssen die ADC-Korrektur vor die Averaging und
>Invert-Routine verlegen. Fühlst Du Dich berufen da Hand anzulegen?

Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung 
und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden, 
mach ich das doch glatt.

Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen 
RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das 
"+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die 
Post ab.

von Blue F. (blueflash)


Lesenswert?

Stefan schrieb:

> Nach dem ich es jetzt geschafft habe, mit dem Makefile von Günter Jung
> und gtkTerm, das Programm direkt in den Ram den Oszilloskops zu laden,
> mach ich das doch glatt.
>
> Ist echt praktisch, läuft nur ca 3min, auch unter Linux und über einen
> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das
> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
> Post ab.

Ich bin nicht im Bilde! Wie geht das? Kannst Du mal eine detailierte 
Beschreibung geben, oder sagen wo es eine gibt? Das hört sich ja so an 
als wenn man die Entwicklungszyklen dramatisch verkürzen könnte.

Mach mich schlau!

Hayo

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> @Guido,
> es werden noch einige Pixel nicht richtig gesetzt.

Ja hab ich schon gesehen, das ist aber anscheinend eine andere 
Baustelle, die den Gridlayer betrifft, denn die Signale sind soweit ich 
gesehen habe nicht davon betroffen. Ich vermute, das da irgendwo Pixel 
im Löschmodus gesetzt werden in der Gridroutine ("set" Parameter auf 
Null).

> @Hayo,
> Wenn man misst und auf Stop drückt kann man ja in das Signal rein oder
> raus zoomen. Dabei wird aber immer eine neu Messung gestart sodass die
> alten Werte verloren gehen. Allerdings nur beim Autotrigger.
> Normaltrigger und Singe Shot sind OK.

Muß ich mir heute abend mal ansehen.

Gruß Hayo

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

@Hayo

Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich 
nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.

Günter hat weiter oben ein neues Makefile gepostet 
(http://www.mikrocontroller.net/attachment/50963/Makefile.zip)

Das erzeugt eine TomCat.ram, die genau wie die ursprüngliche .flash 
aufgebaut ist, nur fehlen darin die Befehle, den Flash zu löschen und in 
den Flash zu schreiben. (So sehe ich das) Deshalb wird der Code direkt 
in den Ram geschrieben und mit dem letzten Befehl gestartet.

Ich habe mein provisorischen Perl-Skript angehängt. Bitte nicht schlagen 
für die Form. Ist nur zum testen, funktioniert aber schon einwandfrei. 
Bei Bedarf gibts auch eine schönere Form. Habe dafür aber jetzt keine 
Zeit

Damit das läuft musst du natürlich noch deine Schnittstelle im 
Perl-Skript auswählen und das Skript in den Build-Ordner legen.

Wenn Perl das Modul nicht findet musst du das hier installieren:
http://search.cpan.org/CPAN/authors/id/C/CO/COOK/Device-SerialPort-1.04.tar.gz

mit (als root)
perl Makefile.pl
make
make Install

Heute Abend habe ich wieder mehr Zeit.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

@Robert + Michel

Ok Jungs Ihr hattet Recht. Ich hab tatsächlich was am Trigger geändert 
in der 0.60 die ja nicht als beta rausgegangen ist. Das läßt sich 
schnell wieder fixen. Allerding ist das genau die Stelle an der noch 
optimiert werden muß um den Trigger besser zu machen. Ich werde das 
erstmal wieder auf den alten Stand bringen und dann weiter sehen.

Danke!

Hayo

von Stefan (Gast)


Lesenswert?

Kleine Ergänzung:
Das Perl-Skript erkennt eine fehlerhafte Übertraung und bricht dann ab. 
Da das bisher noch nie passiert ist, ist auch keine automatische 
Korrektur nötig. Nach dem letzten Befehl wartet das Skript auf eine 
Rückmeldung kommt natürlich nicht mehr, da der Oskar schon läuft. Also 
einfach abbrechen.

Stefan

von Blue F. (blueflash)


Lesenswert?

Ok danke,

bin schon echt neugierig und kann es kaum erwarten nach hause zu kommen.

Hab mir mal Günters Beitrag vom 16.5. rausgesucht. Der ist irgendwie an 
mir vorbeigegangen, dabei ist das ja eine wirklich interessante Sache. 
Gut dass wir nochmal drüber geredet haben...

Gruß Hayo

von sunny (Gast)


Lesenswert?

hallo stefan

dein script rennt ja durch wie schmitt's katze. super! lässt sich damit 
auch die .flash datei übertragen?

gruß sunny

von Stefan (Gast)


Lesenswert?

@sunny

Keine Ahnung, ob das schon geht. Getestet hab ich es nicht. Kommentare 
erkennt es jedenfalls nicht, die in der .flash drinnenstehen. Da müsste 
man noch anpacken. Viel ändern muss man wahrscheinlich nicht mehr.

Stefan

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab's mal ein wenig abgeändert so dass man es auch für die .flash 
datei verwenden kann.

von Kurt B. (kurt)


Lesenswert?

@Hayo,
also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen. 
Siehe Screenshot.

von Stefan (Gast)


Lesenswert?

@sunny

Wie schnell läufts mit der .flash?

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

Hallo,

Kurt Bohnen schrieb:
> @Guido,
> es werden noch einige Pixel nicht richtig gesetzt.

super, ich dachte schon in hätte ein Hardwareproblem. :-)
Sehe ich aber nur mit Lupe. Die vertikalen Gridlinien
sind bei mir auch nicht ganz durchgezogen, da werde ich mal
suchen. Die fehlenden Pixel sind bei mir im letzten Drittel
des Schirms wieder da, wird nicht so leicht zu finden sein.

@ Stefan: hast recht, das Ramloaden ist schon super, vor
allem aus dem gtkTerm heraus.

Gruß, Guido

von Günter J. (gjung)


Lesenswert?

@Stefan
> RS232-Wandler. Bei mir war es nur zusätzlich noch nötig, gtkTerm auf das
> "+" als Bestätigung vom Oszilloskop warten zu lassen und schon ging die
Hatte ich vergessen zu sagen, zusätzlich sollte man noch die CRLF
Anpassung einschalten
> Funktioniert super! 3min pro Zyklus unter Linux. Allerdings verwende ich
> nicht mehr gtkTerm sondern ein eigenes Perl-Skript zum Upload.
gtkterm hat den Vorteil, daß man danach auch gleich im Terminal für
die serielle Schnittstelle ist.

@sunny
> dein script rennt ja durch wie schmitt's katze. super! lässt sich damit
> auch die .flash datei übertragen?
das wird nicht zuverlässig funktionieren, da der GERM nach jeder
empfangenen Zeile ein '+' schickt, unabhängig davon ob der Teil zum
verarbeiten der Zeile fertig ist oder nicht. D.h. wenn der gerade mit
dem Schreiben eines Flash-Blocks beschäftigt ist, wird der Eingangs-FIFO
überschrieben, und dann hängt das ganze.
Ich denke man müsste nach jeweils 64k eine Pause von ein paar Sekunden
einlegen damit das ganze zuverlässig geht.

Ich wollte mich mal drüber machen das 'nr' Kommando aus dem SDK
(ist bei Linux nicht mit dabei) mit genau diesen Funtionen neu zu 
schreiben, leider bin ich im Moment beruflich etwas im Stress so daß
ich nicht allzu viel machen kann.

Gruß,
Günter

von Guido (Gast)


Lesenswert?

Hallo Kurt,

>also bei mir habe auch die Signale fehlende Pixel auf beiden Kanälen.
>Siehe Screenshot.

hast recht, ist bei mir auch so, sieht man nur mit einem
Rechteck. In der linken Hälfte fehlen die Pixel wohl in
jeder 2. Spalte, imd der rechten sehe ich sowas nicht.
Wird wirklich blöd zu suchen sein.

Gruß, Guido

von sunny (Gast)


Lesenswert?

@stefan
genau so schnell wie mit der .ram

@günter
ich hab es 4x durchlaufen lassen und keine probleme festgestellt. ich 
glaub auch das + wird erst gesendt wenn der letzte vorgang abgeshlossen 
ist. das sieht man gut am anfang wenn die speicherblöcke gelöscht 
werden. da dauert es immer einen kurzen moment bist die bestätigung 
kommt.

von Robert S. (razer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

Ich habe gerade die Experimental Firmware (0.62) mit der umskalierten 
Anzeige geladen.

Auf Kanal habe ich jedoch in den neuen Skalierungen (4V, 2V, 400mV, 
200mV, 40mV, 20mV) extreme Ausreißer (siehe Screenshot). Wenn ich auf zB 
500mV umschalte sind sie weg. Nach einer Zeit legen sich diese 
Ausreißer.

von Günter J. (gjung)


Lesenswert?

@sunny
ich hatte genau die gegenteilige Erfahrung,
ist immer nach ca der Hälfte (ca 300k) stehen geblieben.
Bis dahin lief es immer genau so schnell wie ins RAM,
was mich zu der Vermutung bringt, das eben nicht bis zum
Ende des Schreibvorgangs gewartet wird bevor das '+' kommt.

Gruß,
Günter

von Blue F. (blueflash)


Lesenswert?

Welches GTKTerm benutzt Ihr?

Das französische oder das deutsche? Von der Beschreibung her würde ich 
ja auf das französische tippen in der Version 0.99.5, ist das korrekt?

Hayo

von sunny (Gast)


Lesenswert?

dann ist das vll. systemabhängig. ich missbrauche meinen satreciver für 
die linux geschichten. das ist ja ein relativ langsames system. 
möglicherweise bleibt dadurch genügend zeit für den schreibvorgang.
also sollte man vll. doch eine verzögerung einbauen. da ich bis gerade 
ebend noch nie was mit perl gemacht habe, wüsste ich allerdings nicht 
wie.

von Günter J. (gjung)


Lesenswert?

das letzte Mal das ich was in Perl gemacht habe ist leider 10 Jahre her.
Aber sowas wie ein 'usleep' gibt es sicher auch in Perl.
Gerade nachgeschaut, ist im Time::HiRes Modul: usleep ($microseconds);

Gruß,
Günter

von sunny (Gast)


Angehängte Dateien:

Lesenswert?

ich hab das mit den waitstates mal versucht. es werden jetzt 2000 zeilen 
am stück übertragen und dann 1 sek gewartet.

von Günter J. (gjung)


Lesenswert?

werd ich heute abend mal ausprobieren.

von Blue F. (blueflash)


Lesenswert?

Sagt mal einer was zu der verwendeten Version von GTKTerm? Es scheint da 
zwei unterschiedliche Programme mit dem gleichen Namen zu geben.

Hayo

von Günter J. (gjung)


Lesenswert?

so wie es aussieht gibt es wirklich zwei:
  GTKTerm -> sowas wie xterm
  gtkterm -> serielles Terminal
die unterscheiden sich nur in der Gros-/Kleinschreibung,
das war mir so auch nicht klar.

Gruß,
Günter

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Version 0.99.5 funktioniert bei mir prima. Ob die englisch
oder französisch ist weiß ich nicht.

Guido

von Günter J. (gjung)


Lesenswert?

wobei GTKTerm seit 2004 nicht mehr gepflegt wird.

von Guido (Gast)


Lesenswert?

So,

habe jetzt dreimal hintereinander eine .flash Datei mit
GtkTerm übertragen. Hat dreimal geklappt, die 0.62
dauert etwa 3,5 Minuten, ältere Versionen gehen etwas
schneller.

Möglicherweise bremst das Terminalprogramm ausreichend
(mal weitere Tests anwarten). Ich hatte beim
WelecUpdater unter Linux den Eindruck, dass er etwa 3 bis
4 mal länger braucht als unter Windows (beim Download)
und dass die Gtk-Ausgabe hierfür veranzwortlich war.

Guido

von Stefan (Gast)


Lesenswert?

Also bei mir geht es mit gtkterm nicht zuverlässig. Da überträgt er zwar 
und startet. Danach hängt sich die Software aber so gut wie immer auf. 
Deshalb das extra Skript, dass überprüft ob die Zeile wieder richtig 
zurück kommt.

Stefan

von Günter J. (gjung)


Lesenswert?

Es liegt dann offensichtlich an der Geschwindigkeit des jeweiligen 
Rechners.
D.h. zuverlässig wird es nur mit zusätzlichen Wartezeiten wie im perl 
Skript gehen.

von Guido (Gast)


Lesenswert?

Hallo Stefan,

sorry ich habe vergessen zu erwähnen, dass ich eine normale
ser. Schnittstelle verwende. Vllt. macht das den Unterschied.

Gruß, Guido

von Günter J. (gjung)


Lesenswert?

also normale RS232 oder USB-Adapter mach keinen Unterschied.
Hab' ich beides schon probiert.
Der unterschied zwischen einem einfachen USB-Adapter und einer
echten RS232 liegt hauptsächlich in der Ansteuerbarkeit der
Handshake-Leitungen.
Der GERMS benutzt aber keinerlei Handshake, weder Hardware RTS/CTS
noch Software XON/XOFF.

Gruß,
Günter

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

So,
nochmal für alle, die mit gtkterm Probleme haben, oder die lieber per 
Skript den Code laden wollen, eine verbesserte Version.

Alle 2000 Zeilen wird 1 Sekunde gewartet.

Gestartet wird über eine Kommandozeile mit den Parametern (die natürlich 
an die eigenen Bedürfnisse angepasst werden müssen.)

perl flashloader.pl /dev/ttyUSB0 TomCat.ram

von Blue F. (blueflash)


Lesenswert?

Also gtkterm krieg ich überhaupt nicht zum Laufen. Bei .configure meldet 
er etwas von missing TERMINAL_WIDGET.

Dann hab ich das mal mit Deinem ersten Script ausprobiert - wollte auch 
nicht so richtig. Nach etwas rumgezackere hab ich dann dieses paket 
installiert gekriegt mit irgendwelche Zusatzroutinen. Dann hab ich mal 
Dein letztes Script ausprobiert - mit /dev/ttyS0 (hab einen echten RS232 
Port) - und es läuft und zwar blitzschnell. Super, muß mir nur noch was 
überlegen damit ich nicht immer die ganze Kommandozeile eingeben muß.

Hast Du echt prima hingekriegt, und das man ins RAM laden kann ist auch 
echt klasse, danke nochmal an dieser Stelle an Günter.

Muß erstmal wieder los, bis nachher

Gruß Hayo

von Günter J. (gjung)


Lesenswert?

Hi,

also ich hab' das jetzt mal auch mit dem Laptop getestet.
Ich eindeutig ein Geschwindigkeits Thema.
Auf dem Laptop geht der Flashupdate sowohl mit echter RS232 als auch
mit USB-Adapter problemlos mit gtkterm, auf dem Arbeitsplatzrechner geht
nur das Perl-Skript zuverlässig.
Beim Laden ins RAM gibts kein Problem mit der Geschwindigkeit.

Gruß,
Günter

von Günter J. (gjung)


Lesenswert?

@Hayo,

Du hast doch OpenSuse?
Dann versuch doch mal
   http://rpm.pbone.net/index.php3/stat/4/idpl/11318475/com/gtkterm-0.99.5-7.1.i586.rpm.html
zu installieren, eventuell musst Du noch ein paar gtk libs 
nachinstallieren.

Gruß,
Günter

von Blue F. (blueflash)


Lesenswert?

@Günter

muß ich morgen mal machen, heute komme ich nur noch dazu die 0.63 zu 
pflegen, damit der Trigger wieder läuft etc..

Gruß Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

So,

ich hab gerade mal fix die flashloader.pl etwas aufgeräumt und mit einer 
Timeout-Behandlung versehen, weil das Ding sonst bis zum 
St.Nimmerleinstag wartet, wenn das DSO nicht reagiert.

/Hannes

EDIT: muss übrigens dem Autor des Scripts meinen tief empfundenen Dank 
aussprechen, das macht das Testen^WRumspielen wirklich viel einfacher. 
Hab grade nur mal so zum Spaß das Backup der Original-FW wieder 
eingespielt, welches zum Sichern damals ca. 4,5h benötigt hat. Dauer des 
Restore: ca. 7 Minuten. Ich LIEBE es. :D

von branadic (Gast)


Lesenswert?

Hallo Johannes,

könntest du vielleicht so gut sein und auf Sourceforge im Trac/Wiki 
einen entsprechenden Beitrag zum exakten Vorgehen unter Windows/Linux 
setzen, damit auch unsere internationalen Freunde etwas davon haben?
Wäre wirklich super und für die nächste Entwicklungszeit in einer 
Übersicht festgehalten.

Besten Dank, branadic

von Blue F. (blueflash)


Lesenswert?

Mal eine Frage als Perl-Unwissender. Kann man das Perlscript auch unter 
Windows verwenden? Denn für Windows gibt es Perl doch auch. Muß man 
evtl. noch was installieren?

Ich wollte das Script und eine Anleitung der nächsten Beta beilegen, 
genauso wie der TomCat.ram für Leute die streßfrei einfach nur mal 
testen wollen. Dafür wäre es natürlich nicht schlecht wenn man auch 
Windows-User mit einbeziehen könnte.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Klar, wenn du mir nochmal den Link gibst.

Mir wäre es zugegebenermassen allerdings lieber, wenn ich das Perlscript 
mal versuchshalber für Windows und Linux tauglich mache (bisher geht es 
nur unter Linux), das alles hierher schreibe und du das dann in SF 
einstellst. Dort müsste ich mich erst anmelden... und überhaupt. :D

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Kurt + Guido

Die Pixelfehler kann man besonders gut sehen wenn man einen Kanal auf 
Ground-Coupling schaltet und mit der Nullinie langsam durch den 
kritischen Bereich fährt. Das sieht schon recht merkwürdig aus...

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hannes,

so aufgeräumt sieht das Skript gleich nochmal besser aus ;-)

Da merkt man doch gleich, wenn jemand schon öfter Perl verwendet hat.

Hallo Hayo,
ich habe testweise mal die Assembler-Routine umgebaut und der Fehler 
beim Invertieren ist weg. Probiere da noch ein wenig dran rum, um das im 
Ganzen halbwegs zu verstehen.

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

@ Hayo: Die Pixelfehler sind schon weg. Ich probiere gerade noch
den hässlichen Streifen zu entfernen. Gleich mehr.

Gruß, Guido

von Guido (Gast)


Lesenswert?

@ Stefan: Das klingt ja super!

@ All: Mir ist beim Debuggen aufgefallen, dass momentan nach fast
jeder Einstellungsänderung das Config-Flash überschrieben wird.
Muss man sich da Sorgen machen? Ich habe für meine Tests den
Funktionsaufruf in Tomcat auskommentiert.

Gruß, Guido

von branadic (Gast)


Lesenswert?

Hallo Johannes,

hier kurz der Link: http://apps.sourceforge.net/trac/welecw2000a/

Gruß, branadic

von Stefan E. (stefan_e)


Lesenswert?

@Guido

Im Datenblatt, dass im Wiki mit dem Flash verlinkt ist, steht was von 
"Minimum 1 million erase cycle guarantee per sector".
Hast also noch ein paar Versuche

von Blue F. (blueflash)


Lesenswert?

Also heute geht es ja richtig ab hier oder? Fortschritte an allen Ecken 
und Enden, so macht das echt Spaß!

Da kann ich auch gleich noch einen nachschieben - Trigger geht wieder.

Dann werde ich mal auf Guido und Stefan warten und dann eine schöne 
runde 0.63 beta zum langen Wochenende rausschieben bevor ich mit dem 
Rollmode/Shiftmode anfange.

Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

der Streifen bleibt. :-( Ich dachte dir Ursache wäre dieselbe wie
mit dem Pixelfheler. Der resulierte daher, dass die Menü-Plane
über das Grid kopiert wurde (UI_Plane2). Abhhilfe:

Am Anfang von TransferPlanes ändern:
1
if (UpdateMenuTextPlane)
2
    {
3
  /* Gudo test:change
4
        TransferDataPlane_asm_persistant(0x008DBB24, 0x00970F30);  */  
5
  TransferDataPlane_asm_persistant(0x008DC254, 0x00971660);
6
    }

Und in TransferDataPlane_asm_persistant die Loop-Variable von
1460 auf 1000 reduzieren.

Der Upload ins Ram hat aber nicht geklappt, da das Oszi immer
eine Microsofz-Behandlung gewünscht hat. :-(

Falls es sich jemand anschauen möchte, Anhang.

@ Stefan: Dann muss ich mir wohl doch keine Gedanken machen, ich war
von einem Hundertstel ausgegangen.


Gruß, Guido

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

So Hayo,
hier die abgeänderte Datei. Geändert hat sich nur etwas in der 
READADC_ALL.

Zweimal hatte ich den fall, dass sich ein Kanal beim Verschieben vom 
Nullpunkt vom Nullpunktpfeil proportional verschoben hat. Ein erneutes 
ADC und DAC-Kalibrieren hat das dann behoben. Denke, dass muss woanderst 
liegen. Das Rauschen nimmt jedenfalls jetzt nicht mehr zu beim 
Invertieren.

von Blue F. (blueflash)


Lesenswert?

Alles klar Ihr Beiden. Vielen Dank für die schnelle Lösung. Ich werde 
das dann mal einfließen lassen.

Zum Flash - da gibt es keinen Grund zur Sorge, bis da das Ende der 
Schreibzyklen erreicht ist sind die Leuchtkathoden vom Bildschirm schon 
in den ewigen Jagdgründen und es gibt nur noch einen Blackscreen. Das 
Wegspeichern ist deshalb so häufig nötig, damit das Oszi beim nächsten 
Start wieder mit den alten Einstellungen starten kann.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

och eine Erfolgsmeldung - es reißt nicht ab - ich hab den Fehler mit
dem Triggercursor am oberen Gridrand beseitigt. Da blieb ja beim Drücken
des Default Setup immer eine Leiche irgendwo links oder rechts neben der
neuen Position zurück. Ist erledigt - nicht zuletzt dank der jetzt so 
kurzen Upload Zeiten ins RAM.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja zu guter Letzt - kaum noch auszuhalten - der Fehler 139 beim 
Erzeugen des Objektdumps ist auch Geschichte.

So jetzt ist aber gut.

Bis morgen also

Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Hab jetzt das Perlscriptchen (hoffentlich) OS-unabhängig gemacht. Bei 
mir unter Linux geht es noch, jetzt müsste nur mal einer unter Windows 
testen, ob es auch mit ActivePerl und dem Module Win32::SerialPort 
klappt.

Zum Benutzen muss man wie gesagt je nach Betriebssystem das Modul 
Win32|Device::Serialport installieren. Das geht unter Linux am 
einfachsten mit dem distributionseigenen Paketmanager (das Paket heisst 
üblicherweise in der Art wie perl-Device-Serialport oder etwas in der 
Preislage), und wenn man es da nicht findet, dann in einem Terminal via 
CPAN (Archiv von Perlmodulen):
1
su -
2
perl -MCPAN -e 'install Device::SerialPort'

Alle darauf folgenden Fragen immer nur mit Enter bestätigen, dann 
sollten benötigte Module gleich mit installiert werden.
Wie man das unter Windows macht, ist mir gerade nicht klar, da gibt's 
aber IIRC auch so ein Archiv bei Activestate.

Wenn das dann geklärt ist, kann man im Terminal folgendes ausführen 
(vorausgesetzt, das Script befindet sich in einem Verzeichnis zusammen 
mit der Tomcat-Datei und man befindet sich auch in diesem Verzeichnis 
;-):
1
perl flashloader.pl /dev/ttyUSB0 TomCat.flash

Portbezeichnung und Dateiname sind natürlich entsprechend anzupassen.

/Hannes

von Crazor (Gast)


Angehängte Dateien:

Lesenswert?

Moin Leute,

nachdem ich mir gestern beim ersten Versuch des Flashens gleich mal 
alles geschossen habe, habe ich am Skript noch ein bisschen 
rumgefummelt. Es sendet nun nicht erfolgreich übertragene Zeilen 
nochmals zu senden. Da meine serielle Schnittstelle etwas flaky ist und 
gern mal alle zigtausend Zeichen eines verschluckt, war das auch absolut 
notwendig, um das Gerät wieder zum Laufen zu bekommen ;)

Da ich aber mit der Version weitergebastelt hab, die ich gestern 
Nachmittag irgendwann geladen habe, sind natürlich die neuesten 
Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird 
sich dem noch annehmen. Wichtig: Das Skript enthält KEINE sleeps mehr. 
Die sollten aber nicht nötig sein, da im Fehlerfalle ja erneut gesendet 
wird.


Ansonsten nochmal mein Aufruf: So viel wie hier aktuell los ist, würde 
ich es sehr begrüßen, wenn auch der Hayo-Branch der Firmware sowie die 
tollen Tools die hier entstehen, versioniert werden würden. Ihr seid 
alle herzlich eingeladen, die vorhandenen Ressourcen des welecw2000a 
Projekts bei Sourceforge zu nutzen ;) Dann gäbe es (endlich) eine 
zentrale Anlaufstelle für alle Neulinge (und alten Hasen) und vorallem 
einen Platz für dauerhafte Dokumentation!

Viele Grüße

Daniel

von Crazor (Gast)


Lesenswert?

Nachtrag: Ok, ein sleep(1) im Fehlerfall ist doch noch drin, das könnte 
auch noch raus, war nur zu Testzwecken.

von Johannes S. (demofreak)


Lesenswert?

Crazor schrieb:
> Da ich aber mit der Version weitergebastelt hab, die ich gestern
> Nachmittag irgendwann geladen habe, sind natürlich die neuesten
> Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird
> sich dem noch annehmen.

Ok, das werd ich dann mal mergen...

/Hannes

von Stefan E. (stefan_e)


Lesenswert?

Wie sich mein Skript verselbstständigt ist echt cool ;-)

von Blue F. (blueflash)


Lesenswert?

Das endgültige Skript werd ich dann heute oder morgen mit zu der 0.63 
beta packen.

Hayo

von Kurt B. (kurt)


Lesenswert?

Das wird aber auch unter Windows laufen und zusammen mit einer passenden 
tomcat.ram ausgeliefert? ;-)

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Das wird aber auch unter Windows laufen und zusammen mit einer passenden
> tomcat.ram ausgeliefert? ;-)

Das ist das Ziel. Je praktikabler das Ganze wird, desto mehr werden es 
ausprobieren und sich anstecken lassen...


Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

habe noch den hässlichen Balken beseitigt. Dazu muss in
tc_vars.h BOT_PLANE_MIN von 8480 auf 8600 vergrößert
werden. Das wird afaik eh nur benutzt um eine Init aus
dem Flash zu laden.

Gruß, Guido

von Guido (Gast)


Lesenswert?

@ Hayo: Oder noch besser, den teil erst garnicht aus dem Flash
laden. Dazu auskommentieren:
1
void Display::DrawStartScreen(void)
2
{
3
  unsigned long lX;
4
  //Top area above the grid
5
  for (lX = TOP_PLANE_MIN; lX < TOP_PLANE_MAX; lX++)
6
  {
7
    Buffer_UI2Plane[lX] = *(UI_Plane2_Flash + lX);
8
    UI_Plane3[lX] = *(UI_Plane3_Flash + lX);
9
  }
10
/* BF del for the new grid
11
  //Grid area
12
  for (lX = GRID_PLANE_MIN; lX < GRID_PLANE_MAX; lX++)
13
  {
14
    Grid_Plane[lX] = *(Grid_Plane_Flash + lX);
15
    
16
    if (tc_hw_version < 0x4c7) {if ((lX % 20) == 0) Grid_Plane[lX] = Grid_Plane[lX] << 2;} // Gap
17
  }  
18
 BF end  */   
19
  //Bottom area
20
  /*for (lX = BOTT_PLANE_MIN; lX < BOTT_PLANE_MAX; lX++)
21
  {
22
    UI_Plane1[lX] = *(UI_Plane1_Flash + lX);
23
    Buffer_UI2Plane[lX] = *(UI_Plane2_Flash + lX);    
24
    UI_Plane3[lX] = *(UI_Plane3_Flash + lX);
25
    UI_Plane4[lX] = *(UI_Plane4_Flash + lX);
26
    UI_Plane5[lX] = *(UI_Plane5_Flash + lX);
27
  }*/

Das Bottom-Area.

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Aufgemerkt!

Es gibt die 0.63 beta. So viele Fixes habe ich noch in keinem Release 
auf einmal gemacht. Nicht übel.

Das komplette Build gibt es ebenso wie die Firmware bei Google Groups

http://groups.google.com/group/welec-dso/files

Ich habe das beigelegte Perlskript nochmal umbenannt und noch zwei 
Shellskripte für den Flash und den RAM-Upload dazugetan. Es gibt auch 
eine neue How to.

@Guido

Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr 
dazu gekommen bin mir das anzusehen.

Gruß Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Hab jetzt diesen Schreibwiederholversuch da eingepflegt und es unter 
Linux getestet, das klappt einwandfrei. Will mal sehen, ob ich jetzt fix 
noch ein Activeperl mit Win32::SerialPort in die VM geballert bekomme 
und es dort noch schnell testen kann. Oder fühlt sich ein 
Windowsbenutzer berufen, das mal fix auszuprobieren?

/Hannes

von Kurt B. (kurt)


Lesenswert?

Unter WinXP-SP3 überträgt das Script ca. 1 Zeile pro Sekunde am echten 
RS232. Wird das noch schneller?

von Johannes S. (demofreak)


Lesenswert?

@Kurt: welche Variante des Scripts hast du versucht? Die aus dem 
FW-Archiv?

Das Problem mit dem Schreiben von nur einer Zeile pro Sekunbde hatte ich 
auch schon, das lag am falschen Zeilenende. Muss ich also offenbar für 
Windows anpassen. Fixe ich schnell, keine Angst, ich bin nur grade noch 
am Windows-Perl-Installieren ;)

von Kurt B. (kurt)


Lesenswert?

Deine letzte und die von Hayo zuletzt gepostete.

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

einfach Klasse! Das Triggern geht wieder auf Ch1 am 2012a funktioniert 
wieder auf positive und negative Flanke auf dem Probe-Ausgang!

Gruß Jürgen

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Sodele,

bei mir klappt das jetzt unter Windows (in einer VM allerdings) und 
unter Linux mit vollem Tempo. Bitte um Test.

/Hannes

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

>@Guido

>Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr
>dazu gekommen bin mir das anzusehen.

Falls es sich trotzdem jemand ansehehn möchte: auf Basis 0.63.

Hoffentlich klappt es bald auch für die Windowsuser mit dem
Ramupload.

Habe gearde gesehen, dass die Änderungen das Quickmeasure stören,
da muss ich wohl noch nachlegen. Als Nächstes schau ich mir aber
erst mal die Softbuttons an, die sollten einheitlich aussehen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Hi, ich sehe es regt sich noch was.

Bin schon an der 0.64 zugange und baue gerade den Ultra Slow Timebase 
Modus ein (Shift und Roll). Mal sehen wann ich einen ersten Prototyp zur 
Verfügung stellen kann.

@Jürgen

Jupp. So soll es sein.

Hayo

von Kurt B. (kurt)


Lesenswert?

Geht immer noch nicht schneller.

von Johannes S. (demofreak)


Lesenswert?

Kurt Bohnen schrieb:
> Geht immer noch nicht schneller.

Dann bin ich erstmal ratlos. Muss mir mal nen Rechner mit 
Hardware-Serial und Windows besorgen, dann schau ich dort mal.

Wie viele Punkte (oder gar X) siehst du vor dem OK am Ende der Zeile?

/Hannes

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

2 Punkte

von Blue F. (blueflash)


Lesenswert?

@Guido

Hab mal Deine Demo eingespielt.

Ich finde eigentlich die Version mit unterlegtem Balken besser, weil es 
den UI-Bereich klarer abgrenzt.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: hmmh, ist natürlich Geschmackssache, mich hat der Balken
immer gestört. Nundenn ...

Gruß, Guido

von Kurt B. (kurt)


Lesenswert?

Mit Balken finde ich auch schöner.

Unter OpenSuse 11.1 in der VirtualBox läuft das Skript rasend schnell 
durch. ;-)

von Kurt B. (kurt)


Lesenswert?

Ist es normal, dass sich beide Signale exakt in der Schirm Mitte 
befinden müssen damit die Mathefunktionen korrekt arbeiten?

Das Problem gibt es in der 0.62 und der 0.63.

von Blue F. (blueflash)


Lesenswert?

Seit ich den Zero-Shift wieder eingebaut habe (DAC-Offsetverschiebung) 
ist die Mathfunktion davon betroffen. Hier muß ich noch den neuen 
variablen Zerolevel einbauen. da ich aber gerade in höheren 
Programmiersphären schwebe (Shift und Rollmode) muß das erstmal warten 
;-)

Hayo

von Martin H. (martinh)


Lesenswert?

@ Hannes Ich hatte das selbe problem wie Kurt unter Windows.
Um den download zu beschleunigen habe ich folgende zeilen geaendert:

53 $serial->read_const_time(1);

83       if ($readcount++ > 1000) {

es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer 
read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen 
wurden!

Gemessen Zeiten download der version 0.64 mit echter UART:
 download ins RAM: 2 min. 40 sek.
 download ins FLASH: 2 min. 45 sek.

Martin

von sunny (Gast)


Lesenswert?

beim testen der .63 ist mir ein etwas im delayed modus aufgefallen.
gerät: w2024
signal: 1mhz rechteck 10vpp an ch1
main timebase: 100ns/div

bei einer delaed timebase von 50ns ist der auswahlbereich um ca 1div 
nach rechts verschoben im vergleich zu dem was im delayed fenster 
angezeigt wird.

ab einer delayed timebase von 20ns wird im delayed fenster ein völlig 
anderer bereich des signales dargestellt.

hat man die signalaufzeichnung gestoppt und ändert den delayed 
auswahlbereich, wird das aktuell angezeigte signal gelöscht und eine 
erneute aufzeichnung gestartet. es ist also nicht möglich, den 
zoombereich auf ein einmaliges event zu vergrößern oder zu verkleinern.

von Johannes S. (demofreak)


Lesenswert?

Martin H. schrieb:
> es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer
> read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen
> wurden!

Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut, 
danke.

/Hannes

von sunny (Gast)


Lesenswert?

was mir bei der .63 noch aufgefallen ist, das die messwerte der cursor 
nicht mehr angezeigt werden.

von Michael (Gast)


Lesenswert?

Moin Moin!

Ich weiß net, ob's hier erlaubt ist.
Aber ich würde mein Oszi gerne Verkaufen,
ist ein W2022A mit 200 MHz / 2 Kanal.
Daher erstmal die vorsichtige Anfrage, ob das hier möglich ist.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Dafür gibts in diesem  Forum einen Markt!
http://www.mikrocontroller.net/forum/markt

gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

Hallo,
ich habe mir erlaubt, das svn-repository 
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/welec/improved/src/ 
auf den aktuellen Quellcode zu aktualisieren. Können wir uns darauf 
verständigen, alle Änderungen dort zu hinterlegen?

Gruß,
Stefan

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Johannes Studt schrieb:
> Martin H. schrieb:
>> es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer
>> read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen
>> wurden!
>
> Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut,
> danke.

Hab da jetzt nochmal bissl rumgegraben. Das Windows-Modul arbeitet auf 
jeden Fall irgendwie anders als der Linux-Nachbau, es werden 
(zumindestens hier) nicht bei jedem Leseaufruf die "geforderte" Anzahl 
Bytes zurückgeliefert. Unter Linux steht bei mir vor dem OK immer genau 
ein Punkt (ergo genau ein Leseversuch), unter Windows sind es 
unterschiedlich viele, meist jedoch 2-3.

Der ganze Unsinn, den ich da mit Linebreaks verzapft hatte, war völlig 
unnötig. Hab's jetzt so ungefähr wie Martin gemacht, und das führt auf 
meinem System zu folgenden Zeiten für das Flashen der 0.63:

Linux nativ: 3m15s
WinXP in VM: 5m01s

Dauert zwar unter Windows immer noch deutlich länger, aber 
verschmerzbar, denke ich. Die Zeit wird hier bei mir übrigens auch davon 
beeinflusst, ob ich das cmd-Fenster sichtbar oder minimiert habe. Die 
Ausgabe der Zeilen scheint ein durchaus erheblicher Faktor zu sein, und 
offenbar ist da irgendetwas[TM] schlau genug, bei minimiertem Fenster 
die Ausgabe einfach zu unterdrücken.

/Hannes

von Kurt B. (kurt)


Lesenswert?

Jetzt läuft er auch unter Windows super!

von Blue F. (blueflash)


Lesenswert?

Was ist los? Keiner mehr auf? Rollmode läuft, feile aber noch am Timing. 
Shiftmode ist in Vorbereitung.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Klar bin ich noch wach. Warte ja auf die nexte Version... :D

von Guido (Gast)


Lesenswert?

@ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der
Einzige, bei dem bei Invertierung der Signale auch die ADC und
DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir
etwas knifflig vor.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

Das hab ich mir noch nicht so im Detail angesehen. Bist Du sicher, dass 
die Werte invertiert werden müssen? Das wäre dann ja Stefans Baustelle 
oder?

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Guido schrieb:
> @ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der
> Einzige, bei dem bei Invertierung der Signale auch die ADC und
> DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir
> etwas knifflig vor.
>
> Gruß, Guido

Hallo,
kannst du das etwas genauer erklären? Meinst du vielleicht die leichte 
Verschiebung des Signals um den Nullpunkt, wenn der Eingang 
kurzgeschlossen ist?

Die Invertierung läuft folgendermaßen ab:

- Abzug des (AD-spezifischen) DAC-Korrekturwertes vom Eingangswert
- Berechnung der Differenz zum ZeroLevel
- Fallweise Addition oder Subtraktion der Differenz zum Zerolevel 
(jenachdem ob davor drunter oder drüber)

Vielleicht stimmt der Offsetabgleich noch nicht ganz, Vielleicht kann 
Hayo testweise eine zusätzlichen iterativen Abgleich einführen, der den 
Offset solange verändert, bis das normale und invertierte Signal die 
"gleichen" Werte haben.

Ich kann erst wieder ab Montag oder Dienstag testen. Deshalb kann ich es 
nicht selber ausprobieren.

Gibt es eigentlich die Möglichkeit eine Zeitmessung über einen der Timer 
einzubauen? Mich würde interessieren, welche Routine welche Zeit 
braucht. Evtl. lässt sich die Geschwindigkeit an der Stelle dann ja 
erhöhen. z.B müssen ja nicht immer alle 4000 Werte umkopiert werden, 
wenn das Gerät läuft. Erst wenn auf Stop gedrückt ist, werden z.B alle 
Daten aufbereitet.

Gruß,
Stefan

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

@ Hannes:
Habe deine abgeanderters script ausprobiert bei mir benötigt es ca. 5 
min. 20 sek. und ich sehe immer zwei Punkte vor dem OK (bei meiner 
Version waren es drei!) Um das besser zu verstehen habe ich mir die DOC 
von Win32::SerialPort angesehen, di inizialisiert immer auch zwei 
weitere Parameter (read_interval(x) und read_char_time(x)). Ich habe 
diese versuchsweise in deinem Script ergaenzt, und siehe da: nur noch 
ein Punkt vor dem OK!
Des weiteren ist es so möglich zu deine original Werten zurueck zu 
gehen.
(read_const_time(1000) und 10 versuche).

Download ins RAM der 0.63 in ca. 2 min. 5 sec.
Download ins Flash der 0.63 in ca. 2 min. 12 sec.

Im Anhang meine Version (nur unter Windows getestet)

Martin

von Johannes S. (demofreak)


Lesenswert?

Martin H. schrieb:
> Im Anhang meine Version (nur unter Windows getestet)

Super Sache. Ich werde das dann später mal unter Linux testen, hab heute 
leider keinen Brückentag.

/Hannes

von Bernhard M. (boregard)


Lesenswert?

Bei mir gehts unter Linux (debian) nicht wegen read_interval:
1
Can't locate object method "read_interval" via package "Device::SerialPort" at ../GERMSloader-win.pl line 51.

Entweder ist das unter Linux nicht dabei (Paket 
libdevice-serialport-perl), oder noch in einem anderen Paket...

Vielleicht liegts auch daran:
 "Write timeouts and read_interval timeouts are not currently 
supported."

aus 
http://www.justanotherperlhacker.com:8911/cpan/Device::SerialPort/Device::SerialPort_-_Linux_POSIX_emulation_of_Win32::SerialPort_functions..html

Leider habe ich nur rudimentäre Perl-Kenntnisse....

von Bernhard M. (boregard)


Lesenswert?

Noch ein Nachtrag:
Der GERMSloader.pl braucht bei mir für TomCat.ram (0.63) 2:48, also 
unter 3 Minuten. Das ganze unter Debian Linux mit USB-RS232 
Konverter....
Dabei kommen 3-4 mal mehr als ein Punkt vor dem OK (bis zu 4)...

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo und Stefan,

ein Bild sagt mehr ... Der ADC- und DAC-Abgleich funktionieren
bei mir sehr gut. Invertiere ich das Signal (Kanal 2) wird es
unschön. Wenn ich damit neu kalibriere, sieht Kanal 2 so gut
aus wie Kanal 1. Dann die Invertierung wieder aus, sieht wieder
aus wie im Bild.

Ich vermute, dass da die Abgleichwerte invertiert werden müssen,
was eigentlich in der UI-Funktion erfolgen sollte.

Bin ich wirklich der Einzige, bei dem das so stark ist?

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Bin ich wirklich der Einzige, bei dem das so stark ist?

Definitiv ja! Bei mir ist das Signal immer gleich egal ob invertiert 
oder nicht. Stefan hat hier also ganze Arbeit geleistet.

Aber deine Teilung der Bottom Plane sieht interessant aus.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Hannes + Martin

Ich möchte zusätzlich zu Linux auch unter Win XP Firmware laden. Was 
brauche ich außer dem neuen Perlskript noch zusätzlich?
(irgendeine favourisierte Perlversion, Module?)

Hayo

von Guido (Gast)


Lesenswert?

>Aber deine Teilung der Bottom Plane sieht interessant aus.

Hmmh, ist die unveränderte FW 0.63. Ich sage ja, dass ich damit
irgendwie noch nicht zufrieden bin. ;-)

Muss mir später mal die Abgleichwerte der ADC anschauen.

Gruß, Guido

von Martin H. (martinh)


Lesenswert?

@ hayo

Ich verwende ActivePerl 5.8.8 (habe ich von 
http://www.oldapps.com/Perl.php geladen).

Zusaetzlich benoetigst du das Modul Win32:SerialPort

Am einfachsten ist die Installierung via Perl Package Manager (PPM):

1. Neues Repository eintragen via Edit -> Preferences
   und den Reiter Repositories
   Name: Bribes
   Location: http://www.bribes.org/perl/ppm
   (ein ausfuerliches help findest du unter
    http://www.bribes.org/perl/ppmdir.html)

2. Jezt kannst du das Modul Win32-SerialPort installieren:
   Zeile mit Win32-SerialPort suchen und an klicken
   Action -> Install Win32-Serialport 0.19

Das sollte alles sein.

Martin

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Ich habe mal zwei Batchdateien geschrieben. Dann kann man z.B. eine 
Verknüpfung auf dem Desktop anlegen und den Flashvorgang per doppelklick 
starten.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Ramloader

von Martin H. (martinh)


Lesenswert?

@ Hayo

Ups habe vergessen zu erwähnen das du am Ende den grünen Pfeil auswählen 
musst sonst wird das Modul nicht installiert!!

Martin

von Blue F. (blueflash)


Lesenswert?

Packagemanager für Windows???

Hab ich das korrekt verstanden?

Hayo

von Kurt B. (kurt)


Lesenswert?

Ich hatte zuerst ActivPerl installiert:
http://www.activestate.com/activeperl/

Und anschließend diese Datei mit WinRar enpackt und das Readme befolgt:
http://search.cpan.org/CPAN/authors/id/B/BB/BBIRTH/Win32-SerialPort-0.19.tar.gz

von Martin H. (martinh)


Lesenswert?

@ Hayo

Ja einfach vom dos prompt aus "ppm<enter>" eingeben oder ueber START 
usw. auswählen. (nach dem du ActivePerl installiert hast)

Martin

von Stefan E. (stefan_e)


Lesenswert?

Hallo Guido,

dein Phänomen ist mir neu. Und ich kann es mir auch noch nicht erklären. 
Hast du probiert, nochmal alle Einstellungen zurückzu setzen und den 
kompletten Abgleich neu gemacht? Poste mal die DAC-Korrekturwerte für 
beide Kanäle und ohne Invertierung und mit Invertierung. Was passiert 
bei Averaging? Und warum schaut deine Bottom-Plane so komisch aus?

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

Hallo Stefan,

die ADC-Korrekturwerte: Kan1, 3110; Kan2. 3140;
DAC-Korrekturwerte: Kan1.77/94/70; Kan2. 15/96/76.

Die bleiben bei Invertierung gleich. Averaging summiert die
Störungen auf, sonst ändert sich nichts.

Was habt ihr nur mit meiner Bottom-Plane? Ich hab da nichts
geändert (noch!!!). Wie sieht die denn bei euch aus?

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Vielleicht solltest Du mal ein komplettes Backup einspielen. Mir scheint 
da ist was vergurkt.

Hayo

von branadic (Gast)


Lesenswert?

Hallo Guido,

die Bottom-Plane sollte in etwa so aussehen:

http://www.welec.de/graphics/images/W2_100u_50mV.gif

Zumindest scheint die bei allen anderen so auszusehen.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

besten Dank, jo, ist bei mir anders.

@ Hayo: Gute Idee! Die 1.3 von welec hat nichts geändert, probier
jetzt mal mein Backup, sonst muss ich mal den alten Thread
durchwühlen. Btw.: Das Flashen über USB ist schnarchlangsam ;-).

Gruß, Guido

von Guido (Gast)


Lesenswert?

Hallo,

habe jetzt die Alpha 1.4 geflasht und damit eine saubere
Bottom-Plane. Anschließend die Beta 0.63 geflasht und jetzt
klappt es. Kann ich mir zwar nicht erklären aber man muss ja
nicht alles verstehen.

Danke Hayo für den Tip, sorry Stefan, ich hoffe ich habe dir
nicht allzuviel Arbeit gemacht.

Gruß, Guido

von branadic (Gast)


Lesenswert?

Hallo zusammen,

fühlt sich einer der Perl-Terroristen im Stande die Vorgehensweise zum 
Flashen des Gerätes unter Windows noch mal genau aufzuführen?
Also was muss installiert werden, wie geht man vor.
Ich habe dafür einen extra Bereich im Trac unter Firmware eingerichtet:

http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload

Ich würde das gern wieder für alle festhalten wollen.

Beste Grüße, branadic

von Stefan E. (stefan_e)


Lesenswert?

Guido schrieb:

> Die bleiben bei Invertierung gleich. Averaging summiert die
> Störungen auf, sonst ändert sich nichts.

Meinst du damit, dass sie gleich bleiben, auch wenn du im invertierten 
Zustand den Abgleich neu ausführst? Wenn nicht, dann mach das mal bitte. 
Also erst normal die Werte, dann invertieren, wieder abgleichen und 
nochmal die Werte notieren.

Ich könnte mich täuschen, aber deine DAC-Werte erscheinen ungewöhnlich 
hoch zu sein.

Gruß,
Stefan

von Stefan E. (stefan_e)


Lesenswert?

War wohl zu langsam beim tippen ;-)

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Bernhard M. schrieb:
>
1
Can't locate object method "read_interval" via package
2
> "Device::SerialPort" at ../GERMSloader-win.pl line 51.

Hab diese beiden Parameter jetzt OS-abhängig gemacht. So geht es hier 
unter Linux und in der XP-VM auch einwandfrei. Vielleicht ist das ja 
jetzt ein Stand, der möglichst vielen Hardwarevarianten gerecht wird. :D

Linux: 3:14
Win-VM: 3:42

/Hannes

von Guido (Gast)


Lesenswert?

Hallo,

nochmal ausdrücklich: Sorry Stefan!

Wäre der Fehler mit der Bottom-Plane nicht gewesen, hätte ich
ewig suchen können.

Damit tauchen aber neue Probleme auf: Ich weiß jetzt, warum ihr
den Balken (der jetzt ja keiner mehr ist) besser findet. Die
Menü-Routinen sind völlig buggy und dieses wird durch einen
Flashload einfach überbraten. Resultat (irgendwer hatte es schon
gemeldet, ich sehe es erst jetzt) ist, dass für Cursor oder
QuickMeasure die Messwerte nicht mehr angezeigt werden. Das habe
ich schnell per Fallunterscheidung gelöst, jetzt habe ich die
Pixelfehler wieder. Da muss mal grundsätzlich aufgeräumt werden,
ich kümmere mich darum.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

Alles klar, super dass Du Dich drum kümmerst.


@Hannes

Klasse mit dem Perl Skript. Bin noch nicht zum Testen gekommen da wir 
dieses Wochenende Besuch haben, aber die neueste Version wird mit 
aktualisierter How to in der nächsten Beta dabei sein.

Ansonsten auch noch Dank an alle die wie Branadic zur Dokumentation 
beitragen, denn das Thema wird langsam so vielschichtig dass man leicht 
den Überblick verliert, insbesondere als Neuankömmling.

Zur aktuellen Entwicklung:

Bin immer noch am Rollmode zugange, ist schon ganz nett anzusehen, aber 
das Timing ist etwas widerborstig. Vorabdemo gibt es in Kürze. Das 
Konzept und die aufgetretenen Probleme werde ich dann dem Wiki zuführen.

Guats Nächtle

Hayo

von Michael W. (slackman)


Lesenswert?

Hi, Ihr Perlen,

Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die 
Meldung, dass das DSO nicht antwortet... :-(
Sowohl realer Port am PC als auch Konverter am  Laptop bringt nichts. 
Für einen Tipp wäre ich dankbar.
(Bei den Porttests bekomme ich auch nur ein durchwachsenens Protokoll - 
ärgerlich...)

Michel

von branadic (Gast)


Lesenswert?

Hallo Michel,

ich habe bisher zwar nur mit dem WelecUploader geflasht, aber bei mir 
hat es bisher auch maximal 25min gedauert, bis das neue FlashFile im 
Gerät war.

Zum Germsmonitor: Es ist notwendig die beiden Softbuttons einen Moment 
lang gedrückt zu halten (so etwa 2-3sec. mach ich das immer, um sicher 
zu gehen, dass die Übertragung richtig initialisiert wird), nachdem man 
den WelecUpdater zum Upload bewegt hat. Einfach nur kurzes Drücken wird 
dich nicht zum Erfolg bringen.

Wie das bei der neuen Uploadmoglichkeit ist kann ich dir nicht sagen.

Gruß, branadic

von michaelk (Gast)


Lesenswert?

Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide 
Tasten drückt und dann die Rechte eher los lässt als die Linke... Da 
reicht es dann auch nur etwa eine Sekunde zu drücken.

von Johannes S. (demofreak)


Lesenswert?

Michael W. schrieb:
> Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die
> Meldung, dass das DSO nicht antwortet... :-(

Das Problem hatte ich allerdings auch schon. Das Win32::SerialPort-Modul 
scheint den Port nicht korrekt zu initialisieren (bzw. ich tu es nicht 
richtig mit dem Modul, je nachdem, wie man es sehen möchte :D). Ich 
musste bisher schon ab und zu erst mit der WelecUpdater.exe einfach 
einen Upload beginnen, nach ein paar Zeilen abbrechen und dann den 
Script starten. Habe das bisher auf die Kombination aus XP in einer VM 
und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist, 
werde ich das nochmal untersuchen.

michaelk schrieb:
> Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide
> Tasten drückt und dann die Rechte eher los lässt als die Linke... Da
> reicht es dann auch nur etwa eine Sekunde zu drücken.

Klasse. Klappt hier auch einwandfrei.

/Hannes

von Kurt B. (kurt)


Lesenswert?

Auch bei mir scheint der Port nicht richtig initialisiert zu werden. 
Dann stelle ich kurz mit Hyperterminal eine Verbindung her und beende 
sie direkt wieder. Danach funktioniert auch das Skript wieder.


PS:
Mein 2024 ist immer noch nicht da. Ich hatte das verfusselte Gerät am 
9.5 zurückgeschickt. Seit dem 14.5. sollte das neue unterwegs sein. Zwei 
Anfragen wegen der Trackingnummer blieben unbeantwortet. Montag werde 
ich bei ebay den Artikel als nicht erhalten melden.

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Johannes Studt schrieb:
> Script starten. Habe das bisher auf die Kombination aus XP in einer VM
> und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist,
> werde ich das nochmal untersuchen.

Man sollte sich wirklich mal mit Dokumentationen befassen. Ich glaube, 
dass da bisher was fehlte. ;)

@Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit 
HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es 
auf jeden Fall hingehauen.

/Hannes

von Kurt B. (kurt)


Lesenswert?

Leider nicht besser.

von Johannes S. (demofreak)


Lesenswert?

Tse,

elende Computertechnik. :D
Dann bleibt halt, bis da mal einer den wirklichen Fehler erkannt hat, 
nur der Umweg über die Initialisierung mit Hyperterminal. Wenn diese 
Krücke in der Dokumentaion mit auftaucht, wird sich sicher schnell ein 
betroffener Perlkundiger finden, der das dann mal wirklich repariert.

/Hannes

von Kurt B. (kurt)


Lesenswert?

Ganz so schlimm ist es ja auch nicht. Die initialisierung muss man ja 
immer nur jeweils ein einziges mal nach dem start des PCs machen.

von Michael W. (slackman)


Lesenswert?

... Satatn Ziege !
Das ist ja wirklich schnell - Junge-Junge! Gefühlt keine 2 Minuten!

Bei mir hat's jetzt hingehauen. Besten Dank nochmal. So macht ein Flash 
doch mal Spaß.
Werde ich mir also den Updaten vornehmen und mal sehen, ob ich das mit 
dem auch hinbekomme...
Kann mir jemand diese Zeilen erklären:
-  if ($line =~ /^#.*/) {
-     while ($buffer !~ /\+/) {

Ich würde gerne den Updater umschreiben/aktualisieren. War in Lazarus, 
oder?

Michel

von Guido (Gast)


Lesenswert?

@ Johannes Studt : Perl kenne ich zwar nicht, aber unter Windows muss
man meist die Flags des DCB noch auf 0 setzen. Z.B. $serial->flags(0)
oder so ähnlich. Die Flags sind hierbei LongInt.

Gruß, Guido

von Stefan E. (stefan_e)


Lesenswert?

>-  if ($line =~ /^#.*/) {
>-     while ($buffer !~ /\+/) {

1.Zeile: Klammer ausführen, falls keine #-Zeichen am Anfang der Zeile 
vorkommt
2.Zeile: Schleife solange ausführen bis ein +-Zeichen zurück kam.

Perl ist schon eine geile Sprache ;-)

von Johannes S. (demofreak)


Lesenswert?

Stefan E. schrieb:
> Perl ist schon eine geile Sprache ;-)

ACK!

von Martin H. (martinh)


Lesenswert?

Johannes Studt schrieb:
> @Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit
> HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es
> auf jeden Fall hingehauen.

Hallo Hannes,

Bei mir ist nun auch die Initialisierung in Ordnung.
Der unterschied laesst sich leicht testen.

1. COM Port mit einem Terminal program (z.b. Teraterm) auf eine andere 
Baudrate stellen (z.b 1200 Baud).

2. Download mit GERRMSLoader.pl versuchen:
   --> das alte script scheitert
   --> mit dem neuen get's!

Martin

von Crazor (Gast)


Lesenswert?

Moin,

der aktuelle GERMSloader ist echt super! Funktioniert immernoch mit 
meiner gammeligen Schnittstelle perfekt (drei oder vier retries, geht 
eigentlich). Einzig das letzte Datum in der Flash-Datei (S804852AFC50) 
funktioniert nicht. Eventuell sollte noch eine speziellere Behandlung 
für S8-Records eingebaut werden?

;Daniel

von Stefan E. (stefan_e)


Lesenswert?

>Einzig das letzte Datum in der Flash-Datei (S804852AFC50)
>funktioniert nicht.

Das Oszi schickt hier nichts mehr zurück. Deshalb wartet das Skript. 
Gehen tut es aber trotzdem.

Kann man aber abfangen, wenn man will. Habe nur gerade keine Zeit, dass 
anzupassen. Ist im Prinzip sogar schon drinnen, nur wurde es im Laufe 
der Entwicklung an die falsche Position geschoben ;-)

Stefan

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

So,
jetzt wieder mit Enderkennung.
Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine 
Versionsnummer verpasst.

Stefan

von Martin H. (martinh)


Lesenswert?

Stefan E. schrieb:
> So,
> jetzt wieder mit Enderkennung.
> Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine
> Versionsnummer verpasst.
>
Hallo Stefan,

Meiner meinung nach war die end Erkennung vorher besser platziert (so 
wird sichergestellt das auch die letzte Zeile richtig übertragen wurde).
Was fehlte ist eine Behandlung des S8 records (S8 bedeutet "Start 
programm with 3 Byte Address" das bedeutet dass der GERMS Monitor 
verlassen wird)

Ich habe das ergaenzt (V1.0.1)

Martin

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

Ups habe den Anhang vergessen!

Martin

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Letzten Endes ist die Zeilennummer als Endkriterium eh Käse, weil nie 
mehr kommen kann als der Inhalt der Flashdatei. Darum ist die Behandlung 
des S8-Befehls als Abbruch-Kriterium sicher das Sinnvollste.

Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder 
anderweitig an der Antwort hindern?

/Hannes

von Günter J. (gjung)


Lesenswert?

Johannes Studt schrieb:
> Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder
> anderweitig an der Antwort hindern?

Tja GERMS steht für G (go) E (erase) R (relocate) M (memory) S (srec)

==> G ist auch ein Kandidat ohne Rückkehr
    und natürlich S7 (4 Byte Startadresse) und S9 (2 Byte Startadresse)
Gruß,
Günter

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Hallo,

ich spiele gerade am Kantentrigger rum. Habe den Kanal 1 mal umgestellt. 
Kanal 2-4 sind unverändert. Ich finde, das Einstellen des Triggerpegels 
funktioniert schon deutlich besser. Dazu ist zu beachten, dass bei 
aufsteigend getriggerter Flanke, der obere Rand eines Signal gut erkannt 
wird und der untere nicht. Bei negativer Flanke verhält es sich genau 
umgekehrt.

Außerdem trifft die Flanke noch nicht den eingestellten Zeitpunkt. Das 
kommt auch noch ;-)

Bitte mal rückmelden, ob es bei euch auch besser ist. Ich habe es bis 
jetzt nur mit dem internen Signalgenerator getestet. Vielleicht kann 
jemand mal andere Signalformen testen.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Leute,

um keine Langeweile aufkommen zu lassen hier schon mal die versprochene 
Rollmode-Demo. Der Rollmode setzt automatisch bei Timebases >= 5 S/Div 
ein. Wenn Ihr kein geignetes langsames Signal habt könnt Ihr durch 
Drehen am Zerolevel eine quasi Flanke erzeugen die dann den Verlauf des 
Signals zeigt. leider ist das Timing immer noch etwas widerborstig wie 
Ihr evtl. sehen werdet.

Der Shiftmode ist in Arbeit und kommt demnächst. Trigger und 
Memoryscrolling stehen in diesen Betriebsmodi nicht zur Verfügung und 
sind meines Erachtens auch eher überflüssig.

Gruß Hayo

von nur mal so (Gast)


Lesenswert?

Moin,

hab's gerade runtergeladen und der Downloadzähler ist immer noch bei 0 ?

hmmm

von Blue F. (blueflash)


Lesenswert?

Ich sehe eine 4!

Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

wenn Du mit der Triggererkennung weiterkommst, poste mal das Coding, 
dann kann ich das in die nächste Beta mit einbauen. Wie Du sicher 
gesehen hast, hab ich an den Stellen auch schon meine Duftmarke 
gesetzt...


Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja,

die Verschiebung des Triggerzeitpunkts findest Du unter "TOC" 
(TriggerOffsetCalc), wie der Programmierer das genannt hat.

Gruß Hayo

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

ich schicke dir bei Gelegenheit mal meine Änderungen. Hast du es mal 
probiert, ob es bei dir auch besser funktioniert?

Ich habe die Berechnung für das Triggerschwellenregister mal neu 
formuliert. Hier muss doch der Schwellwert in der Größenordnung, wie der 
ADC im eingestellten Spannungsbereich Werte liefert, gespeichert werden 
(also z.B. zwischen einen Wert zwischen 100 und 160)

von Blue F. (blueflash)


Lesenswert?

@Sefan

Da bist Du auf dem richtigen Weg. Das stand bei mir auch noch auf der 
Liste, aber man kommt ja zu nichts. Und zwar wollte ich statt des festen 
Wertes, der definitiv falsch ist, mal die Berechnung des Zerolevels 
verwenden so wie ich ihn in Hardware::ReadOut_Signal() zur Berechnung 
des Ground-Coupling verwendet habe:

Virtual_Zero = ADC_ZERO + int((float)Virtual_ZeroLevelCH1 / 
scale_factor[Selected_Voltage_CH1]);


Zum Vergleich sinngemäß die nicht funktionierende Originalroutine die 
ich ersetzt habe:

Virtual_Zero = (ZeroLevelCH1 + 64) >> 1

So ähnlich sieht das ja auch beim Triggerlevel aus. Daher vermute ich 
mal das es damit schon getan sein sollte.

Bin allerdings noch nicht zum Testen Deiner Source gekommen, da ich in 
den letzten Tagen etwas eingespannt war und nur gestern abend schnell 
mal die Demo rausgehauen habe.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Bin heute erst recht spät wieder zu hause, vielleicht hast Du bis dahin 
ja schon ein Ergebnis. Werd mich dann mal melden.

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Sodala Hayo,

habe meine hardware_t.cpp in SourceForge hochgeladen. Änderungen sind in 
UpdateTrigger, Handle_ADC, und in FindTrigger zufinden. Man könnte die 
Werte, die in FindTrigger und UpdateTrigger jetzt berechnet werden auch 
global zwischenspeichern. Bin mir aber nicht sicher, ob sich das für die 
Geschwindigkeit her lohnt.

Ich bin jedenfalls ganz zufrieden. Er triggert sauber, auch auf den 
Überschwinger den der interne Rechteckgenerator an der Flanke liefert.

By the way,
ich habe in SourceForge mal in die tc_vars.h eine Reihe defines für 
MenuStatus eingefügt. Kannst du die per Suchen/Ersetzen in die Dateien 
einfügen? Ich werde sonst verrückt ;-) Und wenn ich das mache gibts nur 
ein Versionschaos, weil ich nicht weiß, wo du gerade werkelst.

Gruß,
Stefan

von sunny (Gast)


Lesenswert?

hallo

@stefan
ich habe deine änderung mal getestet. sieht gut aus. jetzt passt die 
triggerung auch zu den triggermarken. es ist mir jedoch etwas 
aufgefallen. getestet mit dem calib. rechteck. mit aktivem autotrigger 
lässt sich nur bis zu einer zeitbasis von 200us triggern. bei 
schnelleren zeitbasen funktioniert die triggerung nich mehr. es ist also 
nicht möglich, sich die steigende oder fallende flanke eines rechtecks 
genauer anzuschauen. im normalmodus des triggers funktioniert es.

@hayo und guido
ich hatte es weiter oben schon mal geschrieben als die .63 rausgekommen 
ist. glaub aber es ist damals in der diskusion um das perl script 
untergegangen.
es ging um die, seit der .63 fehlenden, werte der readout cursor und um 
die merkwürdige verschiebung im delayed modus. bis 50ns wird das delayed 
signal, in bezug auf den auswahlbereich, etwas verschoben dargestellt. 
ab 20ns wird offenbar ein komplett falscher speicherbereich ausgelesen. 
das delayed signal passt dann gar nicht zum auswahlbereich und wenn man 
den auswahlbereich weiter nach links verschiebt, werden irgendwelche 
konstanten daten aus dem ram im delayed fenster angezeigt.

übrigens zzt. lässt sich der build aus dem svn nicht compilieren weil in 
tc_vars.h die deklaration von iScale_Factor auskommentiert ist. das 
array wird aber in der InterpretUART-funktion benötigt.

gruß sunny

von Stefan E. (stefan_e)


Lesenswert?

@ sunny

sorry, mein Fehler. Hab eine alte Datei verarbeitet. Etz müsste es 
wieder passen.

Ich habe bis jetzt nur mit dem normalen Trigger getestet. Auto muss ich 
dann morgen mal probieren.


Gruß,
Stefan

von Guido (Gast)


Lesenswert?

Hallo,

@ sunny: habe oben schon geschrieben, dass es bei mir jetzt auch
sichtbar ist und bin dran (Flash läuft gerade). Falls ich es
hinbekomme, muss ich erst nocht testen, welche Änderungen nötig
sind.

@ stefan: ah, dann probiere ich ev. später auch noch mal, ich habe
mit den Syntaxfehlern kapituliert.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Hi Jungs,

bin grad zu hause eingetrudelt. Hier tut sich ja in letzter Zeit 
geradezu erschreckend viel. Bin ich aus den letzten Monaten gar nicht 
gewöhnt.

@Stefan

Ich werd mir Deine Änderungen morgen mal zu Gemüte führen und einbauen. 
Evtl. werd ich schon früher eine neue Beta raushauen, damit die 
Änderungen für alle verfügbar sind und wir auf der gleichen Basis 
weitermachen. Die Perlskriptecke war ja auch recht aktiv. Da kommt 
wieder eine Menge zusammen im nächsten Release.


@Sunny

Nein die Anmerkungen sind nicht untergegangen. Hatte nur noch keine 
Zeit. Ich denke an den fehlenden Cursorwerten ist Guido dran, da das 
wohl direkt mit den Änderungen an der Plane-Größe zusammenhängt. Die 
Zeitverschiebung
des Delayed-Signals hab ich schon länger im Auge, hab dem aber keine so 
hohe Priorität zugeordnet.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo,

hab die Probleme bis auf eine Pixelzeile reduziert und die
kriege ich auch noch hin. Dann fange ich noch mal mit einer
sauberen Beta 0.63 an, um die Änderungen auf das notwendige
Maß einzuschränken. Also, morgen oder übermorgen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@all

Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger 
Kommentar dazu gekommen ist. Liegt es daran dass

- die Funktion eher uninteressant ist?
- Ihr kein geeignetes Testsignal habt?
- Ihr nicht so richtig wißt um was es geht?
- Ihr mit anderen Themen beschäftigt seid?

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

>Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger
>Kommentar dazu gekommen ist. Liegt es daran dass

>- die Funktion eher uninteressant ist?
>- Ihr kein geeignetes Testsignal habt?
>- Ihr nicht so richtig wißt um was es geht?
>- Ihr mit anderen Themen beschäftigt seid?

Habs sogar gestern noch ausprobiert, dann aber wohl vergessen zu 
erwähnen.
Hat bei mir gut geklappt. Was noch abgefangen werden muss ist, dass man 
nicht den Trigger-Modus auf "normal" stellen können darf.

Gruß,
Stefan

von Johannes S. (demofreak)


Lesenswert?

Hayo W. schrieb:
> - Ihr kein geeignetes Testsignal habt?
> - Ihr mit anderen Themen beschäftigt seid?

Sorry. ;-)
Aber am Wochenende komm ich sicher dazu, mal wieder was zu machen.

/Hannes

von Blue F. (blueflash)


Lesenswert?

ich frag nur weil ich gerade die Shift-Funktion eingebaut habe und es ja 
sein könnte dass es da Änderungsvorschläge gibt oder so.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Ja Du hast recht, mit dem Triggermode muß ich mir was einfallen lassen - 
und genau das meinte ich, das war mir nämlich noch gar nicht 
aufgefallen.

Danke Hayo

von Michael W. (slackman)


Lesenswert?

Hi,
mal ein paar simple Fragen zum Scope, bzw. Messen:

Gestern Nacht habe ich mal ein wenig die höheren Frequenzen an dem 
W2024A getestet. Ich hatte eine Schaltung mit 20 MHz Quarz am Oszi (Pic 
Brenner für USB von Sprut):
- Das Signal am Quarz war beinahe sinusförmig, erwartet hätte ich eher 
ein Rechtecksignal. Allerdings habe ich keinerlei Erfahrungen und vorher 
nie ein Signal am Schwingquarz gemessen. Außerdem war die Amplitude sehr 
niedrig, 500 oder 600 mV, bei 10:1 Tastkopfeinstellung sind das dann ja 
nur 50 bzw. 60mV. Erwartet hatte ich TTL-Pegel oder wenigsten die Pegel 
für 3V Logik. Liegt die Sinusform an den kleinen Kerkos am Quarz?

- Das Signal hatte ich mit der Tastkopfeinstellung 10:1 gemessen. Als 
ich auf 1:1 umgestellt hatte und die Empfindlichkeit am Scope 
entsprechend in die andere Richtung geändert hatte, bekam ich kein 
Signal auf den Schirm. Erwartet hatte ich das gleiche Signal oder 
höchstens in der Amplitude unterschiedlich... Auch hier muss ich sagen: 
vorher kaum/keine Erfahrungen mit dem Messen und dem Ändern der 
Tastkopfeinstellungen.

Habe ich irgendwo Denkfehler? Wenn ich heute Abend wieder zu Hause bin, 
könnte ich einen Screenshot posten.

Michel

von branadic (Gast)


Lesenswert?

Hallo Michael,

du hast tatsächlich einen Denkfehler. Der Tastkopf hat keinen 
Verstärker, sondern einen "Abschwächer".
Wenn man den Tastkopf auf 10:1 stellt, dann wird dein gemessenes Signal 
bei 1:1 Einstellung im Gerät um den Faktor 10 kleiner dargestellt. 
Abhilfe schafft hier die Umstellung des betreffenden Kanals auf 10:1, 
dann wird dein Signal wieder umgerechnet und mit "realer" Amplitude 
dargestellt.

Aus einem Quarz kommt vereinfacht angenommen ein sinusförmiges Signal. 
Tatsächlich besteht das Signal jedoch aus einem komplexen 
Frequenzspektrum. Was du zu meinen scheinst ist ein Quarzoszillator. 
Hier befindet sich noch eine aktive Schaltung unter dem Gehäuse, die für 
das rechteckförmige Signal bestimmter Amplitude sorgt.

Gruß, branadic

von Guido (Gast)


Lesenswert?

Hallo Michael,

als Ergänzung zu branadics Erläuterung noch: Im 1.1 Betrieb hat
der Tastkopf ca. 40 pF Eingangskapazität. Wenn du das direkt an
den Quarz legst, reißt die Schwingung wahrscheinlich ab.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Stefan

Bin gerade dabei Deine Änderungen zu sichten und einzubauen. Sehe ich 
das richtig, dass Du bei ReadOut_Signal() einen Parameter gelöscht hast 
weil er überflüssig war?

Hayo

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

siehst du richtig. Der Parameter kam in der ganzen Funktion nicht vor. 
Kommt auch kein Compilerfehler und es geht immernoch. Also weg mit den 
Altlasten ;-)

Stefan

von Blue F. (blueflash)


Lesenswert?

Alles klar!

Wie verwurstet das Coding war kann man auch daran sehen, dass trotz 
zahlreicher Neuerungen von mir das Coding immer kleiner geworden ist 
durch die ganzen Löschungen und Redesigns.

Trotz einiger Aufräumaktionen gibt es immer noch zig nicht benutzte 
Variablen und Funktionen. Ein weiterer Kandidat sind die Routinen für 
Timer 1 mit dem eigentlich der Autotrigger-Timout gesteuert werden 
sollte. Nach meinen derzeitigen Erkenntnissen wird das aber überhaupt 
nicht genutzt. Ich werde da noch mal weiter prüfen und gegebenenfalls 
deaktivieren.

Gruß

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Jo,

da gibts noch eine ganze Menge Sachen, die einfach krank sind. Auch die 
ganzen einzelnen Konstanten, die für alle Kanäle einzeln angelegt sind. 
Wie blöd ist das eigentlich. Der Code würde sich mindestens auf die 
Hälfte reduzieren, wenn der Kerl an der einen oder anderen Stelle ein 
Array verwenden würde.

Am besten finde ich ja den Kommentar in der ursprünglichen Source:

>TMW: "Some bugs found, not easy to understand software structure"
>TMW: "All to be improved!!!"

Stefan

(THW ist das Kürzel des Namensgebers der Firma)

von Blue F. (blueflash)


Lesenswert?

Ich denke die Aussage "Some bugs found" trifft das Ausmaß der Sache 
nicht so ganz...


Das mit den nicht verwendeten Arrays hat mich auch schon genervt. An 
einigen Stellen hab ich das auch schon geändert im Rahmen der DAC und 
ADC-Kalibrierung. Aber es sind zu viele solcher Baustellen um es auf 
einmal zu machen. Also weiter Stück für Stück.



Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo Leute,

ich möchte gern noch mal nachfragen, ob jemand noch einmal das genaue 
Vorgehen für den Flash/RAM-Upload unter Windows und Linux zusammenfassen 
kann.

1. Was für Tools werden benötigt?
2. Wie ist die Reihenfolge beim Upload?

Ich würde es natürlich begrüßen, wenn der- oder diejenige dies direkt 
auf SF erledigen würde, damit alle Leute international etwas davon haben 
und es auf der Projekthomepage gebannt ist.
Wir sind nach wie vor bestrebt mehr und mehr Übersichtlichkeit in die 
Projekthomepage zu bekommen und ich denke wir sind da auf einem recht 
guten Weg.
Ihr könnt euch ja selbst davon überzeugen und seid herzlich eingeladen 
dabei auch mitzuwirken, sei es durch Beiträge oder 
Verbesserungsvorschläge.

Vielen Dank, branadic

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

ich hoffe, dass die Pixelfehler jetzt endgültig behoben
sind. Es sind nur kleien Änderungen nötig, wie du dem
Anhang entnehmen kannst (sieht nur so lang aus, weil ich
einfach Codeteile kopiert habe um Suchbegriffe zu liefern).
Alle Änderungen in hardware_t.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Ich werde für die nächste Beta meine "Beipackzettel" dahingehend 
erweitern. Dann braucht nur noch einer den Text der englishen Fassung 
ins SFN zu kopieren. Ist das ok?

Apropo, mein letzter Stand bezüglich GERMSloader-Skript war 1.0.2 - ist 
das der aktuelle Stand?

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

das wäre in jedem Fall sehr hilfreich. Ich würde das dann einpflegen.

Nebenbei bemerkt hat die Projektseite ein etwas anderes Gesicht:

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

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Ja ich hab mich da heute auch schon getummelt um Stefans Sourcen 
runterzuladen. Macht wirklich einen netten Eindruck. Ich werde den Link 
mal mit in mein Package aufnehmen. Was ich vermisse ist eine 
Downloadecke wie bei Google Groops in der man ganze Softwarepakete für 
den Download hinterlegen kann. Zudem mußte ich etwas nach unseren 
Sourcen suchen, da ich sie nicht unter "FPGA" vermutet hätte.

Alles in allem aber schon sehr ansprechend und auch sehr hilfreich für 
Neueinsteiger. Die Online-Versionsverwaltung ist auch nicht übel, aber 
hier muß sich jeder seine Source selbst zusammenstellen aus den 
verschiedenen Versionen. Da wären zusätzliche Komplettpakete ganz 
hilfreich (oder hab ich die Ecke übersehen?).

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

für den Upload/Download steht das Repository zu Verfügung. Hintergrund 
ist einfach, dass die Sachen halbwegs geordnet sind und nicht einfach 
wild upgeloadet werden und durcheinander in einem einzigen Ordner 
liegen, wie es bei GoogleGroup der Fall ist.
Dies ist die Downloadecke für SF.
Eine Übersicht zur Repository Struktur ist auf der Startseite vom Trac 
zu finden:

http://apps.sourceforge.net/trac/welecw2000a/wiki/Repository

Das die Sourcen zur FW ausgerechnet unter FPGA liegen ist auch bei uns 
noch ein kleiner Diskussionspunkt.
Prinzipiell hat man recht zu sagen, dass die FW im FPGA läuft. Auf der 
anderen Seite kann man aber wieder argumentieren, dass unter FPGA eher 
das Design und der Softcore-Entwurf zu verstehen sei und die FW nur zur 
Ansteuerung des Softcores da ist.
Man kann argumentieren wie man will und jeweils für und wider finden.

Vielleicht ist es ja schon hilfreich das Repository als Downloadecke 
besser kenntlich zu machen?

Beste Grüße, André

von Crazor (Gast)


Lesenswert?

Hallo Leute,

wie gerade schon mit André geklärt, ist das Repository nicht wirklich 
für Release-Downloads zuständig. Sourcen gehören da rein zwecks 
Versionierung, klar. Aber so ganze Zips, wie Hayo sie veröffentlicht, 
gehören in die Sourceforge-Download-Ecke. Die ist allerdings etwas 
ätzend zu verwalten, man muss die Sachen irgendwie erst per SFTP 
hochladen, um sie dann per Webinterface aus diesem Staging-Server auf 
die Seite zu bringen. Dafür kann man aber Kategorien und sowas alles 
anlegen für die Downloads und auch direkt Versionen anzeigen usw.

Können das gern mal zusammen erproben, wie dort was hochgeladen wird. 
Ich hatte das schonmal testweise für den USB-Blaster-Treiber gemacht, 
und ich denke, wenn man das ein paarmal gemacht hat, geht das auch recht 
fix von der Hand. Am Besten wäre, wenn Hayo oder jemand anderes, der die 
Releases machen will, mal im Skype-Chatroom vorbeischaut, dann können 
wir die Probleme zeitnah klären.

Grüße

;Daniel

von Crazor (Gast)


Lesenswert?

Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV 
stellen und den Finger an die Messspitze halten ;)

Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern, 
also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande

von Blue F. (blueflash)


Lesenswert?

Crazor schrieb:
> Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV
> stellen und den Finger an die Messspitze halten ;)

Hier ist das Motto eile mit Weile. Man sollte schon etwas Zeit 
mitbringen. Ich hätte das natürlich auch Zeitlupenmodus nennen können 
;-)

> Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern,
> also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande

Das flackert deshalb, weil zwischen zwei Meßwerten die Graphikroutine 
(anders als im Normalmodus) mehrfach durchlaufen wird (bis der Timer 
einen Interrupt auslöst) und bei jedem Durchlauf die Markierungen 
gelöscht und dann neu geschrieben werden.

Hayo

von branadic (Gast)


Lesenswert?

Hallo zusammen,

für alle die genauso fit mit Perl sind wie ich hier mal schnell eine 
kleine Anleitung für die Windows-User.

Ich hab mir Active Perl installiert. Anschließend hab ich mir noch 
Win32-SerialPort-0.19 aus dem Netz geladen und unter C:\Perl\lib\ 
entpackt.
Nun über Start-->Ausführen-->cmd die Windows-Console starten und in das 
Verzeichnis mit der .ram bzw. .flash Datei wechseln. Dort sollte sich 
auch die GERMSloader_1.0.2.pl befinden. Mit cd und cd.. sollte man 
vertraut sein.
Um die TomCat.ram in das Gerät über den Port COM1 zu laden muss in die 
Console folgende Zeile eingetippt werden:

perl GERMSloader.pl COM1 TomCat.ram

@ Hayo:

Mir ist beim Verstellen der Zeitbasis ohne vorherige Kalibrierung 
ausgefallen, dass Kanal3 ab 10µs wieder dutzende von Spikes bei mir 
anzeigt, die bei 5µs und kleiner jedoch nicht auftreten.
Nach der Kalibrierung sind sie dann plötzlich weg. Falls also jemand mit 
ähnlichen Symptomen zu kämpfen hat wei0 er wo er dran drehen kann.

Beste Grüße, branadic

von Blue F. (blueflash)


Lesenswert?

Prima Anleitung - werd ich mal direkt übernehmen und auch ins Englische 
übersetzen.

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

vielleicht noch ein kleiner Nachtrag, bevor man die Console aufruft muss 
der GERMSmonitor noch gestartet werden.

Ansonsten findet sich eine aktuelle (englische) Beschreibung zum Umgang 
mit dem WelecUpdater und dem Upload via Perl unter Windows im SF-Wiki:

http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo,

mal ganz naiv gefragt: konnten wir nicht eine der Testfunktionen
verwenden um direkt in den GermsMonitor zu springen? Damit könnten
wir den Upload weiter automatisieren (nicht dass jemand langweilig
wird ;-)).

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, hier zum langen Wochenende was zum spielen.

Die neue 0.65 beta enthält im Wesentlichen den neuen Roll und den 
Shiftmodus. Die Umschaltung findet Ihr im Timebasemenü (Main/Delayed).

Weiterhin habe ich die Änderungen von Stefan für die Triggerung 
eingebaut. Allerdings klappte das trotz der eigentlich korrekten Formel 
noch nicht so ganz 100 prozentig. Da die Ursache nicht offensichtlich 
ist habe ich erstmal mit harten Korrekturen das Triggerverhalten so 
hingebogen dass es ganz passabel läuft.

Der Fehler mit den fehlenden Cursorwerten ist noch nicht gefixt, da ist 
Guido wohl dran, so dass der Fix erst in die nächste Beta einfließt.


Zur Source:
Die Ersetzungen mit den neuen #defines für die Menüs ist noch nicht 
nicht ganz komplett, kommt aber noch.

Viel Spaß

Hayo

von Michael W. (slackman)


Lesenswert?

Hi,
hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell 
Adapter zum Laufen bekommen? Mit dem realen Port meines Rechners geht's 
ohne Probleme, mit dem Adapter an meinem Laptop nicht :-(

Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem 
Script wirklich häßlich :-/

Michel

von Johannes S. (demofreak)


Lesenswert?

Michael W. schrieb:
> hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell
> Adapter zum Laufen bekommen?

Ja.

> Mit dem realen Port meines Rechners geht's ohne Probleme, mit dem Adapter
> an meinem Laptop nicht :-(

Was heißt "geht nicht"? Wenn du das genauer ausführen kannst, kann man 
vllt was "löten" ;)

> Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem
> Script wirklich häßlich :-/

Das werd ich mir jetzt auch mal ansehen, kann ja schliesslich kaum eine 
große Änderung sein, die den WelecUpdater dann genauso beschleunigt wie 
das Perlscript. Sind sicher nur irgendwelche Parameter des Ports bzw. 
der Serial-Dingsda-Unit.

/Hannes

von Blue F. (blueflash)


Lesenswert?

...bei der Gelegenheit auch gleich für die Dateiendung .ram 
freischalten!

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo,

@ Hayo: den Fix zu den Cursorwerten habe ich gestern schon
gepostet. Hast du wohl übersehen.

@ all: Habt ihr auch Zeichenfehler im ganz linken Button? Falls
nötig mache ich noch Bilder. Ich suche seit 2 Tagen nach dem
Grund und habe schon Drawsoftbutton und Pixelp komplett neu
geschrieben. Ich glaube fast, dass ich da ein Hardwareproblem
habe.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Mach mal Bilder, damit man sich was drunter vorstellen kann.
Bei mir spackt der linke Button auch hin und wieder etwas rum.

Deinen Fix hatte ich tatsächlich übersehen.
Pflege ich schnell nach, dann gibt es morgen eine neue Beta.


Hayo

von Robert (Razer) (Gast)


Lesenswert?

Bei mir schaut der linke Soft-Button auch mal komisch aus. Er ist nur 
ein normales gelbes Rechteck. Kein abgerundetes.

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

erstmal ein Bild. Die Buttons sehen komisch aus, weil die Ecken
noch fehlen. Die Fehler sind aber die weißen Linien im linken
Button, sowohl im Menu als auch in den Cursordaten. Mit:
1
//Testlines
2
  y = 300;
3
4
  for ((x = 0); (x < 640); x++)
5
  {
6
    PIXELP(x, y, 1, UI_Plane1); 
7
  }
8
  y += 20;
9
  
10
  for ((x = 0); (x < 640); x++)
11
  {
12
    PIXELP(x, y, 1, UI_Plane4); 
13
  }
14
  y += 20;
15
16
  for ((x = 0); (x < 640); x++)
17
  {
18
    PIXELP(x, y, 1, UI_Plane5); 
19
  }

habe ich noch drei Linien gezeichnet, wobei die graue (UI_Plane5) und
die gelbe (UI_Plane4) korrekt gezeichnet werden. Die weiße (UI_Plane1)
jedoch nicht.

Ich hänge im nächsten Post noch das Tomcat.ram an, dann könnt ihr
das auch mal probieren.

Gruß zum Ersten, Guido

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Und noch das Tomcat.ram!

Gruß zum zweiten, Guido

von Michael W. (slackman)


Lesenswert?

Jupp,
linker Softbutton ist bei ir auch defekt (Überlagerung?).

@Jo
In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen 
Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich 
bekomme.

Zum Updater:
Im Vergleich zum Script wirklich unübersichtlich. 1500 Codezeilen gegen 
120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater 
kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht, 
jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich 
umständlich.

Michel

von Guido (Gast)


Lesenswert?

Hallo Michael W.,

jo Überlauf um 1 LW, das würde aber bedeuten, dass die Plane falsch
definiert ist, was ich mir kaum vorstellen kann.

Mit dem Updater habe ich mich auch schon rumgeplagt. Ist wirklich
sehr unübersichtlich. Ich habe nur unter Linux das Schreiben in
die Edit-Komponente rauskommentiert und direkt in ein File
geschrieben. Damit habe ich mein Original-Backup in akzeptabler
Zeit hinbekommen. Schon das war aber ganzschön langwierig, also
viel Spaß ;-).

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

sieht bei mir alles exakt genauso aus wie bei Dir. Hardware scheint also 
in Ordnung zu sein.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Michael W. schrieb:
> In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen
> Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich
> bekomme.

Wenn ich den Stecker ziehe, kommt die Meldung, dass es den Port nicht 
gibt. Wenn es die Timeout-Meldung wirft, sollte er vorher auch einige 
Punkte ans erste Zeilenende gemalert haben.

> 120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater
> kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht,

Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein 
großer Akt.

> jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich
> umständlich.

Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der 
Nebel.

/Hannes

von Kurt B. (kurt)


Lesenswert?

@Hayo,
die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche 
Kommentare.
Am besten nochmal die hier ins Archiv packen: 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die 
beiden Softkeys ausgegraut. (W2022A)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier die 0.66 Beta mit dem Bugfix von Guido.


@Kurt

> die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche
> Kommentare.

Ist erledigt.

> Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die
> beiden Softkeys ausgegraut. (W2022A)

Tja da hast Du wohl die Homeedition. Dann must Du auf Professional 
upgraden, wird nicht billig...  ;-)

Im Ernst: Der USTB-Modus (Ultra Slow TimeBase) wird automatisch ab 
5S/Div aufwärts aktiv. Dann stehen auch die beiden Menüpunkte zu 
Verfügung. Gleichzeitig wird das Delayed Menü deaktiviert und die 
Triggerung zwangsweise auf AutoFreeRun geschaltet.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja, XY-Modus hab ich vergessen abzuschalten, kommt in der 0.67

Hayo

von Johannes S. (demofreak)


Lesenswert?

Johannes Studt schrieb:
> Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der
> Nebel.

Ich geb's erstmal auf, das werd ich demnext mal komplett leerlöschen und 
neu schreiben.

> Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein
> großer Akt.

Und darum hab ich das erstmal fix gemacht. Stell ich dann oder morgen 
noch hier rein, wenn es wirklich fertig ist.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Super!

Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute 
reinstellen wollte, aber da warte ich noch bis Dein Skript kommt.

Hab noch einige Detailverbesserungen eingebaut und wieder mal 
überflüssiges Zeugs über Bord gekippt (wie schon vermutet war alles zum 
Thema Timer 1 so überflüssig wie ein Kropf - wer also für seine eigenen 
Routinen einen Timer braucht...)

Für den USTB-Modus habe ich die Timersteuerung umgestellt, läuft jetzt 
gleichmäßiger ohne Ruckler und ohne "Warmlaufphase".

Der XY-Modus wird jetzt im Menu deaktiviert wenn ultra slow gemessen 
wird.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Hayo W. schrieb:
> Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute
> reinstellen wollte, aber da warte ich noch bis Dein Skript kommt.

Wird wirklich erst heute im Laufe des Tages, hatte grade noch Besuch. 
Sry.

/Hannes

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Hm,

habs vorsichtshalber schon mal angehängt, falls ich heute Morgen doch 
nicht dazu komme. Es funktioniert auf jeden Fall, aber die neue 
Fortschrittsanzeige muss ich noch in den Schreibmodus übernehmen, und 
sicher auch noch ein paar andere Kleinigkeiten fixen, die meine 
Bettschwere jetzt verdeckt.

Es ist ein neuer Parameter dazugekommen, der den Modus bestimmt:
1
perl GERMSloader.pl <Schnittstelle> <MODUS> <Datei> [<Startadresse> <Endaddrese>]

Also zum Schreiben der Firmware z.B.
1
perl GERMSloader.pl COM3 -w Tomcat.flash

und zum Lesen
1
perl GERMSloader.pl /dev/ttyUSB0 -r Tomcat.backup 40000 7fffff

Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder 
Schrägstrich nehmen, "/R" ginge also auch.

Wenn man die Adressen weglässt, verwendet das Script beim Auslesen 
defaultmässig 0x040000 und 0x7fffff.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Kein Problem,

hab auch noch ein paar Stellen gefunden die ich fixen muß. Dann kriegen 
wir auf jeden Fall ein schönes rundes Pfingst-Release hin.

Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Sodele,

ich denke, so kann man's erstmal nehmen. Wär schön, wenn es dieser oder 
jener zeitnah testet. Bei mir läuft das Komplettbackup von 0x40000 bis 
0x7FFFFF in 0:40h durch, mit dem WelecUpdater hab ich das (nach Löschen 
aller Bildschirmausgaben im Code) in 1:42h geschafft. Ist also durchaus 
etwas schneller.
Schreiben geht nach wie vor wie bisher auch, nur die Fortschrittsanzeige 
ist etwas hübscher.

Bedienung:
1
perl GERMSloader.pl <Schnittstelle> <MODUS> <Datei> [<Startadresse> <Endadresse>]
>
> Also zum Schreiben der Firmware z.B.
>
1
perl GERMSloader.pl COM3 -w Tomcat.flash
>
> und zum Lesen
>
1
perl GERMSloader.pl /dev/ttyUSB0 -r Tomcat.backup 40000 7fffff
>
> Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder
> Schrägstrich nehmen, "/R" ginge also auch.
>
> Wenn man die Adressen weglässt, verwendet das Script beim Auslesen
> defaultmässig 0x040000 und 0x7fffff.

Fehler werden fast gar nicht abgefangen, mal abgesehen von nicht les- 
oder schreibbaren Dateien oder fehlenden Parametern. Insbesondere wird 
NICHT gewarnt, wenn beim Auslesen der Firmware eine bestehende Datei 
überschrieben würde. Also immer Augen auf beim Eierkauf.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Super!

Ich werde das mal wieder schön in Shellskripte (bzw. in Batchdateien) 
verpacken. Dann ist das schön komfortabel

Hayo

von Kurt B. (kurt)


Lesenswert?

Ich habe eben ein BackUp mit dem Script gemacht. Dauer 42 Minuten.
Im Vergleich dazu ein Backup mit dem Updater. Dauer 45 Minuten.
Allerdings liest das Script eine Zeile mehr ein.

Die letzten Zeilen vom Script:
S315007F0480050000000000803F266F420050FE9F005F
S315007F049077004000E9CA9944871A443663D64200FA
S315007F04A064000000000C9200000000002323232339
S313007FFFF0FFFFFFFFFFFFFFFFFFFFFFFFFFFF8C
r0


Die letzten Zeilen vom Updater:
S315007F0480050000000000803F266F420050FE9F005F
S315007F049077004000E9CA9944871A443663D64200FA
S315007F04A064000000000C9200000000002323232339
r0

von Johannes S. (demofreak)


Lesenswert?

Jo, ist aber nicht schlimm. Der Updater lässt Zeilen, die 
ausschliesslich 0xFFFF enthalten, weg. Das mache ich auch, aber nicht 
ganz so akkurat (ich suche nur nach kompletten Zeilen, und da die Zeile 
nicht komplett ist, landet sie doch im Backup).

Interessant ist, das der WU bei dir fast genauso schnell ist wie das 
Perlscript. Ist das beim Schreiben auch so?

/Hannes

von Kurt B. (kurt)


Lesenswert?

Der WU braucht ca. 12 Minuten zum schreiben ins Flash glaube ich, das 
Script nur 128 Sekunden.

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Interessant...

Hab grade noch gesehen, dass das Schreiben unter Windows in einem 
standardmässigen CMD-Fenster räudig aussieht, weil ich glatt über die 80 
Zeichen Breite wegschreibe. Kommt zwar eigtl nicht drauf an, aber ich 
habs trotzdem noch geändert.

/Hannes

von Interessent (Gast)


Lesenswert?

[OT]

Hallo,

vorab entschuldige ich mich schonmal dafür, euren Thread zu 
"missbrauchen". Ich mach's auch kurz. Versprochen ;-)

Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für 
380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand 
bessere / günstigere Anbieter?

Grüße,
ein-vielleicht-baldiger-W2024A-Besitzer

[/OT]

von André (Gast)


Lesenswert?

Mir ist ueberhaupt kein anderer Anbieter bekannt. Bei dem Ebay 
Verkaeufer handelt es sich auch um irgendwen der Fa. Wittig.

Kurzum: Wenn nicht jemand die Nase voll von seinem Oszi hat und es dir 
verkauft, ist Ebay der einzige Weg.

Gruessle

von Blue F. (blueflash)


Lesenswert?

Interessent schrieb:

> Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für
> 380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand
> bessere / günstigere Anbieter?

Wenn Du ein W2014 günstiger kriegen kannst nimm es! So wie es momentan 
aussieht unterscheiden sich die 100MHz Geräte und die 200MHz Geräte wohl 
nur durch das Label. Ich selbst habe auch beide Varianten und effektiv 
nutzen kann man beide ohnehin nur bis 25MHz (zumindest im 
Originalzustand).

Hayo

von Interessent (Gast)


Lesenswert?

Danke für die Hinweise. Darf man denn Fragen, was ihr so für die Geräte 
hingelegt habt?

von André (Gast)


Lesenswert?

Die bei Ebay ueblichen Preise natuerlich. Ich hab mein 2024 fuer 350,65 
bekommen.

Nu schluss mit OT. Entweder ists dir den normalen Preis wert oder eben 
nicht. Mehr Oszi fuer weniger Geld gibts ohnehin nirgends und Dank der 
Spitzenarbeit von Bruno, Guido, Hayo & Co (alphabetische Reihenfolge ;)) 
wirds wahrscheinlich irgendwann sogar noch zu einem ganz gut brauchbaren 
Geraet.

Gruessle

von Odic X. (odic)


Lesenswert?

@Interessent

Ich habe die Wittig Electronics GmbH direkt über info@welec.de 
kontaktiert. Funktioniert ebenfalls.

Beste Grüße,
odic

von Guido (Gast)


Lesenswert?

Hallo,

ich bin erst jetzt dazu gekommen die neue Beta zu testen. Das
sieht ja klasse aus. Die Triggerung funktioniert wirklich gut
und auch der Rollmode macht Spaß. Ich messe zwar selten soo
langsame Signale, aber der "Gummibandeffekt" durch den
Linienalgorithmus ist echt toll. Warum setzt der Rollmode erst
so spät ein? Das könnte doch ruhig schon bei 200 ms/div so
losgehen.

Es geht sichtbar voran, das liefert genau die nötige Motivation
um weiße Pixelfehler zu analysieren.

Gruß, Guido

von Fritz R. (f_richter)


Lesenswert?

Erstmal vielen Dank für die vielen Infos welche hier schon 
zusammengetragen wurden.
Ich habe mich heute mal mit der USB-Problematik beschäftigt, mit dem 
Ziel das Firmware-flashen etwas einfacher und vielleicht auch schneller 
zu machen.
Nachdem mein Programm nun, zumindest im im groben erstmal funktioniert 
ist mir allerdings klar geworden, das das zweite Ziel (schneller) mit 
der derzeitigen Implementation leider nicht zu erreichen ist.

Was interessantes habe ich nebenbei trotzdem herausgefunden, nachdem ich 
im Welec W2000Update ein bischen geschnüffelt habe.
Gebt mal, nachdem das Programm gestartet ist "89174" ein, dann 
erscheinen einige weitere Buttons, mit denen man vielleicht irgendetwas 
sinnvolles anstellen kann?
Soviel habe ich schon rausgefunden:
- c:\workfiles muß existieren dort werden die ausgelesenen Dateien 
abgelegt.
- "USB-Reset" löscht den EEPROM vom USB-Controller also besser ! NICHT ! 
probieren
- Receive Flash liest irgendwelche Speicherbereiche aus und schreibt sie 
in Files in o.a. Directory, Achtung dauert ewig wie oben schon 
geschrieben.

Gruß

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Guido,

ich hätte den Rollmode auch gerne schon früher eingesetzt, aber hier
sind uns leider natürliche Grenzen gesetzt. Wenn ich den Timer auf Null
setze komme ich auf eine minimale Zeitbasis von 2,5 S/Div - für 2 S/Div
reicht es also gerade nicht mehr und die nächste ist dann 5 S/Div.

Ich habe den ADC-Count schon auf 128 runtergesetzt, aber das wirkt sich
nur auf das Auslesen aus, der Wandler wandelt trotzdem alle 16385 Werte
bevor er den Interrupt auslöst. Falls Du eine Möglichkeit findest das zu
ändern, könnte ich hier natürlich noch was machen.

Anbei mal der generelle Ablauf im Rollmode -> kann auch gerne zu
Dokumentationszwecken ins SFN-Wiki.


Im Übrigen bin ich schon die ganze Zeit dabei lauter kleine
Unstimmigkeiten zu beseitigen und den Rollmode für den XY-Betrieb
einzurichten. Mit dieser Funktion dürfte unser DSO wohl auf dem Markt
ein Unikum sein schätze ich...

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

das wird schon ein riesiger Aufwand, weil in alle benutzte Funktionen
Fallunterscheidungen bzgl. USTB eingebaut werden müssen. Meine
Überlegung ist, die ADC sehr schnell laufen zu lassen und das
Timing über den Timer(2?) zu realisieren, wobei dessen eigentliche
Funktion in der ISR über einen Zähler mimikriert wird.

Es kommt aber auch noch eine vernünftige Realisierung der Funktionen
für Start/Stop und Single hinzu.

D.h.: Wenn dir Anderes wichtiger ist, lass es als Skelett erstmal wie
es ist. Im Vergleich zum Original zeigt es immerhin, wie es aussehen
sollte.

Wenn ich den verdammten Zeichenfehler gefunden habe, fange ich mal an
die ADC-Routinen in C umzusetzen (ich bin dann Disassembler ;-)).
Das könnte wirklich ganz interessant werden und die Rolle rückwärts
wäre bei zu langsamen Lauf leicht zu bewerkstelligen.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Uups, ganz vergessen:

@ Fritz Richter: Das ist echt nett, die Postleitzahl von Herrn
Wittig? Die Flashdownloads betreffen wohl die zu ladenden
Hintergründe der Grafik. JTAG sieht ganz interessant aus. Ich
habe mich aber nicht getraut einen Button zu drücken, vllt.
probier ich noch. Wäre ja schön, wenn es mir mitteilt welche
Datei nicht gefunden wurde.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> Meine Überlegung ist, die ADC sehr schnell laufen zu lassen und das
> Timing über den Timer(2?) zu realisieren,

Genauso funktioniert das ja jetzt auch -> siehe Schematik.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier die Pfingst-Edition mit dem neuen Skript von Hannes. An dieser 
Stelle noch mal meinen Dank an die Skriptschreiber, da die 
Entwicklungszeit sich dadurch drastisch verkürzt hat. So schnell wie 
jetzt bin ich vorher nie vorangekommen.

Die neue Version ist im Wesentlichen stabiler, fehlerbereinigter und hat 
eine etwas geänderte Menüstruktur

Grid und Draw Switch sind jetzt im Displaymenü, der Browsebutton ist 
jetzt im Timebasemenü.

An Bord ist natürlich das neue Perlskript von Hannes und angepasste 
Shellskripte. Die Batchdateien für's Backup und Restore hab ich nicht 
mehr geschafft, haben aber die gleiche Syntax wie die Shellskripte.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier die angepassten batch Dateien.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF. Also nur das 
reine Programm ohne Config/Protected flash.

von Guido (Gast)


Lesenswert?

Hallo Hayo,

die Schematik habe ich schon angeschaut. Wenn sich Timer2 nicht
feiner granulieren lässt (timerperiodh/l), müsste man das ev. in
den Timer1 einbauen, der ja ganz offensichtlich schneller kann.

Aber wie schon gemeint, es handelt sich doch um eine eher seltener
benutzte Funktion.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Hallo Kurt,

> Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF.

aha, dein Ersatzgerät ist wohl angekommen! Mach noch einen
einen Download mit Config-Bereich, kann man manchmal brauchen,
wie ich gelernt habe.  ;-)

Gruß, Guido

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hallo Guido,
ja, das Ersatzgerät ist angekommen. Zwei mal ;-)

Das erste hatte auch Staub, ein klapperndes Metallteil und einen 
Kurzschluss zwischen der Main/Delayed Taste und Mode/Coupling.

Das zweite hat nur noch Staub. Aber so wenig, dass es nicht mehr stört.

Hier noch der Config von 0x000E0000 bis 0x007FFFFF

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

So ein Komplettbackup hab ich auch noch hier rumliegen vom W2024. Wenn 
wir jetzt einmal beim Hochladen sind... ;)

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Guido

Das Problem ist nicht der Timer. Der läuft wie er soll und läßt sich 
auch prima einstellen - übrigens sind alle drei Timer gleich aufgebaut - 
das Problem ist, dass man mit der Timerperiode nicht kürzer werden darf 
als die Wandlungszeit des ADC - und die ist leider so lang weil man 
immer warten muß bis alle Werte gesampled sind. Einzige Möglichkeit wäre 
rauszufinden wie man den ADC dazu bringt weniger Werte zu holen.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: Das habe ich mir gedacht, aber ist es nicht möglich
die Samplerate von der Timenase zu entkoppeln? Die ADC können
ja nun mal rasend schnell. Ich frage so doof, weil ich denke
du hast da einiges parat, während ich erst die ganzen Menüs
durchwühlen müsste.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

Ja hab ich gemacht, der ADC läuft im USTB-Mode mit vollen 1Gsa/S
(Timebaseregister mit 0xFFFFFFFF laden -> siehe tc_vars.cpp Zeile 353).

Davon werden dann 128 Werte genommen und zur Glättung das arithmetische
Mittel berechnet. Das ADC-Set hat aber wenn es den Interrupt auslöst
trotz allem 4 x 4096 Werte gesampled. Diese Ansteuerung ist im FPGA
realisiert und ich weiß nicht, ob es im Design vorgesehen ist auch
weniger Werte zu holen. Das hieße nämlich das irgendwo ein
Counterregister anders gesetzt werden müßte. Wenn wir allerdings die
hardwarenahen Routinen umsetzen stoßen wir ja vielleicht darauf.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: Sorry, ich kapiere es immer noch nicht. Für die
4096 (*4) Sample benotigt der ADC doch nur rund 16 µs.
Das kann doch bei 100 ms/div nicht ausbremsen?

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Ja, das hatte ich auch so ausgerechnet. Dazu kommen natürlich noch die 
Ausleseroutinen. Ich hatte rein rechnerisch auch mit einem etwas 
schnelleren Zugriff gerechnet. Ich habe allerdings auch den Verdacht, 
dass evtl. der Trigger da mitmischt und eine Verzögerung bewirkt, obwohl 
eigentlich nicht getriggert werden sollte.

Hayo

von Blue F. (blueflash)


Lesenswert?

Die Timersteuerung läuft allerdings jetzt auch etwas anders als bei 
meinen Tests, evtl. läßt sich da jetzt noch was rausholen, muß ich mal 
prüfen.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Guido

Durch Dein hartnäckiges Nachfragen hab ich nochmal diverse Tests 
durchgeführt und festgestellt, dass ich auf dem Holzweg war...

Das begrenzende Element ist tatsächlich nicht die ADC-Routine (hatte 
mich auch gewundert aber nicht gleich zum Nachdenken gebracht) sondern 
(hätte ich auch gleich drauf kommen können) die Graphikausgabe.

Ich habe jetzt mal testweise mehrere Ausgaben pro Durchlauf ausgelassen 
und - oh Wunder - die machbaren Zeitbasen wandern weiter nach unten.

Werde also noch ein wenig tricksen und mal sehen was so geht.

Danke für die Anregung

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo,

hört sich gut an. Ich habe gestern mal mit der Umsetzung der
Assemblerroutinen in C angefangen. Bei dem Transfer der Daten
kann man wohl nicht sparen, da es sich um eine FIFO-Struktur
handelt. Es müssen daher immer alle Samples ausgelesen werden,
damit der FIFO wieder leer ist. Andererseits konnte man doch
mit einer der Testfunktionen sich ADC-Daten aufs Terminal
holen. Könnte man mal schauen, was da gemacht wird.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

Prima, dass Du Dich da reinhängst. Ich denke es wird heute eine neue 
Beta geben mit erweitertem USTB-Support. Ich würfel gerade das Timing 
neu aus. Bis jetzt geht es bis 500mS - mehr wird auch schon etwas 
anstrengend für die Augen.


@Hannes

Nochmal eine kleine Rückmeldung zum GERMSloader 1.1.2 - läuft super 
stabil unter Windows und Linux. Bislang hab ich schon ca. 20 - 30 
Uploads gemacht.

- Linux RAMload       180 S
- Linux Flashload     200 S
- Windows Flashload   136 S

Alles mit echter RS232.

Linux auf Athlon 2000 PC, Windows auf Intel Dualcore Lappy.

Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

@ Hayo:

Ich habe jetzt READADC_ALL2 und EXTRACTADCVAL umgeschrieben. Wird
schön kompakt und von der Geschwindigkeit her merke ich bisher
keinen Unterschied (bei EXTRACT... hatte ich schon Bedebnnken).

Sagt dir der Stil zu? Noch kann ich mich umgewöhnen.

Klar, die Grafik braucht ja über 0,1 s, hätte ich auch dran denken
können. Wunder sind damit wohl nicht möglich.

Gruß, Guido

von André (Gast)


Lesenswert?

Hm ich haette 2 Sachen, die mir an der Benutzeroberflaeche aufgefallen 
sind:

Ist nur ein Kanal aktiv, so laesst sich dieser nicht abschalten,sondern 
erst nachdem man einen andern eingeschaltet hat. Ich meine aber mich 
erinnern zu koennen, dass das nicht immer so war. Wenn das eine 
Verbesserung sein sollte, so finde ich sie eher unpraktisch, da dem 
Benutzer so die Reihenfolge der notwendigen Tastendruecke zum Wechseln 
eines Kanals vorgegeben wird. Klar ist es logisch sinnlos, jedoch 
druecke ich z.B. meist auf die Taste, die dem Finger grad am naechsten 
ist :D

Mein Oszi will nach jedem Einschalten auf Pusweite triggern, auch wenn 
ich vorm dem letzten Abschalten auf Edge gestellt hatte. Das war bis vor 
2-3 Versionen auch noch nicht so. Allgemeines Problem oder spinnt mein 
Config-Bereich auch?

Gruessle und danke fuer die tolle Arbeit
André

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab mal (im Anhang ein Bild davon) die Flanke vom Rechteckgenerator 
in 10ns /div aufgelöst. Ein Sample dürften also ca. 5 Pixel sein? 
Jedenfalls, schaut es sehr hässlich aus. Wenn man sich jetzt die Zacken, 
die so stark nach unten ausreißen, gedanklich um eine Zacke nach links 
verschiebt, würde es scheinbar perfekt passen! ADC und DAC-Abgleich habe 
ich frisch davor gemacht. Werden die Kanäle vielleicht verkehrt 
ausgelesen?

von Guido (Gast)


Lesenswert?

Hallo Stefan,

mach das doch bitte gleich noch mit Kanal 2, damit man sieht ob
es kanalabhängig ist. Bruno W. hatte das auch schon mal gezeigt,
aber ich kapiere erst jetzt die Zusammenhänge.

Gruß, Guido

von André (Gast)


Lesenswert?

Ich hab jetzt ein Weilchen mit dem Trigger herum gespielt. Speziell fiel 
mir auf, dass bei mir bei Zeitaufloesungen <= 100µs der Trigger auf 
Kanal 2 nicht funktioniert. Fuer die Tests habe ich den internen 
Signalgenerator benutzt.

Nach langem Herumspielen bemerkte ich dann auch noch, dass das Oszi 
gelegentlich die Triggerquelle "vergisst" und kurzerhand auf Kanal 1 
zurueck stellt.

Gruessle
André

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Nach einer kleinen Firmware-Änderung sieht es jetzt schon viel besser 
aus. Zumindest auf Kanal 1. Auf Kanal 2 hat sich die Situation dadurch 
verschlechtert, weil der scheinbar woanderst vertauscht ist. Werde 
gleich mal noch weng testen.

von Roberto (Gast)


Lesenswert?

Hallo Hayo
In FW1.2.BF.0.68_beta funktioniert der RollMode nicht mehr.
In 0.66 schon... Ist das bei Euch auch so?
Habe das TomCat.flash verwendet.
l.G. Roberto

von Peter (Gast)


Lesenswert?

Hallo zusammen,

den Thread verfolge ich jetzt schon eine Weile und muss erstmal meinen 
Dank rüberbringen an alle Beteiligten. Ich habe ein W2022A und die 
FW1.2.BF.0.68_beta drauf. Beim Testen ist mir aufgefallen, dass die 
Timebase 500ms/div als 1us/div angezeigt wird.

Danke und macht weiter so!
Peter

von Blue F. (blueflash)


Lesenswert?

Oha jetzt ist hier ja ordentlich was los. Bin zur Zeit bei der 0.69 
zugange, dehalb hab ich erst jetzt mal reingeschaut. Durch die kurzen 
Uploadzeiten kommt man ja zu nichts anderem mehr...


@Guido

Das sieht doch schon ganz geschmeidig aus. Der Stil ist erstmal nicht 
wichtig, Hauptsache es funktioniert, ist übersichtlich und dokumentiert 
(und natürlich schnell genug).


@Andre

Die Kanalsteuerung hab ich nicht geändert, da mir das so auch sinnvoll 
erschien. Das sollte also bei der originalen FW genauso sein.

Das mit der Pulsweitentriggerung ist bei mir noch nicht aufgetreten. 
Vielleicht mal das default Setup aufrufen und sonst mal bei Zeiten einen 
Configdump einspielen. Der Configbereich wird in der Tat anders beackert 
als im Original und hat sich auch zwischen den Versionen etwas geändert.

Die Sache mit der Triggersource muß ich mal checken.


@Stefan

Sehr interessant. Bin gespannt was Du rausfindest. Beachte aber dass Du 
da im interpolierten Bereich arbeitest. Nicht das sich da ein Fehler in 
meiner Interpol. Routine eingeschlichen hat. Also am besten immer mit 
dem 50nS Bereich nochmal eine Sicherheitsüberprüfung machen


@Roberto

Doch gerade bei der 0.68 sollte es sogar besser funktionieren. Heute 
kommt noch die 0.69 mit erweitertem Rollmode. Ach hier gilt erstmal 
default Setup dann weitersehen evtl. mal einen Dump einspielen (geht ja 
jetzt schnell).

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Hallo,

hab jetzt auch den Kanal 2 wie den Kanal 1 hinbekommen, dass die Flanke 
schön aussieht.

Könnt ihr mal bitte testen, ob bei euch das Signal auf Kanal 2, mit dem 
internen Rechteckgenerator, wie das oben gepostete verbesserte Signal 
von Kanal 1 aussieht. Es ist derzeit NUR Kanal 2 verbessert. Kanal 1 
dadurch vorrübergehend verschlimmert worden.

Außerdem ist bei 10ns/div die Interpolation deaktiviert. Also nicht 
wundern, wenn es eine leichte Klötzchenbildung gibt.

Vielleicht kann Bruno damit mal seinen Sinus messen.

Danke,
Stefan

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So hier schnell die 0.69 Beta mit erweitertem Rollmode.

Da die Signalausgabe als Zeitkonstante so stark eingeht, mußte ich für 
die Refreshrate auch noch eine Fallunterscheidung für die aktiven Kanäle 
einbauen. D.h. je weniger Kanäle gleichzeitig aktiv sind, desto höher 
die Refreshrate. Die Refreshrate ist noch nicht ganz ausgeknautscht, 
hatte ich keine Zeit mehr zu. Ebenso bei Timebase 500mS/Div und 3 + 4 
Kanalbetrieb, wo die Zeitbasis nicht ganz korrekt ist.

@Stefan

Hab leider heute keine Zeit mehr zu testen,

Gruß Hayo

von André (Gast)


Lesenswert?

Es ist mir ein absolutes Raetsel, was mein Geraet da macht.

Ich habe gerade eine Stunde(!) versucht, das Bild zu erzeugen, das 
Stefan da gezeigt hat. Der Trigger wollte auf allen Kanaelen einfach gar 
nichts tun.  Bis ich irgendwann wild auf Run und Single herumgedrueckt 
hab: ploetzlich funktionierte es.

Nach genuegend langem Herum drehen an allen an Zeitaufloesung und 
Triggerzeitpunkt habe ich es nun auch erreicht, dass der 
Triggerzeitpunkt sich von der linken Div bis nach links ausserhalb des 
Schirms schieben laesst. Weiter nacht rechts komme ich allerdings nicht 
:D. Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da 
echt? :D

@Hayo
Stimmt. Es war auch frueher nicht machbar, dass ALLE Kanaele 
ausgeblendet werden. Habs mit der OriginalSW getestet. Halte ich 
persoenlich fuer ein fragwuerdiges Verhalten.

Gruessle
André

von Gast (Gast)


Lesenswert?

Hallo André,

>Ist das ein verstecktes Feature, das ich nicht kenne oder hakts da
>echt? :D

Jepp, ist ein Feature, nennt sich PreTrig im Triggermenu. Wenn du
das hochdrehst, kannst du die Vergangenheit anscheuen.

Gruß, Guido

von Stefan (Gast)


Lesenswert?

@Andre
PreTrig im Edge-Menü schon ausprobiert?

von branadic (Gast)


Lesenswert?

Hallo Stefan,

die Verbesserungen mit deiner FW-Version konnte ich bei mir jetzt nicht 
nachvollziehen, sieht immer noch genauso wüst aus wie auf deinem ersten 
Photo.

Gruß, branadic

von André (Gast)


Lesenswert?

Die Funktion Pretrig ist mir natuerlich nicht unbekannt :). In diesem 
speziellen Fall hat sie jedoch nichts bewirkt. Irgendwie "hing" einfach 
alles, ich bekomms aber leider auch nicht reproduziert.

Viele Gruesse
André

von Stefan (Gast)


Lesenswert?

Hallo brandiac,

das habe ich befürchtet ;-) Wobei es bei mir wirklich super 
funktioniert. Vielleicht kannst du mal ein Foto machen, wie es bei dir 
genau aussieht? Also mit der Testfirmware und evtl. mit Hayos. Wäre echt 
super.

Stefan

von branadic (Gast)


Lesenswert?

Hallo Stefan,

ich hab jetzt noch mal Hayo's 0.69er aufgespielt, da sehen die Flanken 
so aus, wie auf deinem zweiten Photo.

Das mit der Pretriggerfunktion habe ich bisher immer als lästiges 
Hindernis gesehen, denn als Vorteil. Gerade wenn man eine Flanke schön 
auf Bildschirmmitte haben möchte ist das ein Krampf.

Beste Grüße, branadic

von Stefan (Gast)


Lesenswert?

Hallo branadic,

hab bei mir auch mal die 69er getestet und bei mir schaut es wie immer 
verschoben aus. Irgendwie kommen bei mir bei Kanal 1 die Daten von ADC4 
um eine Periode zu früh und auf Kanal 2 die von ADC2 um zwei Perioden zu 
früh.

Jetzt würde mich interessieren, bei wem das Problem überhaupt auftritt. 
Egal auf welchem Kanal. Nicht das ich der einzige bin ;-)

Gruß,
Stefan

von Michael (nocheiner) (Gast)


Lesenswert?

So, jetzt habe ich auch zum ersten Mal Eure Firmware (0.69) getestet. -> 
SUPERARBEIT!

Genial auch der Ram-Loader. Von einem Linux-Netbook über USB-Serial hat 
es etwa 210 Sekunden gedauert.

@Stefan:
Du bist nicht der einzige. Sieht bei mir ähnlich aus. Kanal 1 hat diese 
Verschiebungen, Kanal 2 ist in Ordnung (W2022A).

Keep on the good work!!!

Michael

von Blue F. (blueflash)


Lesenswert?

@Stefan

Komme vor morgen nicht zum Testen - sorry

Hayo

von Roberto (Gast)


Lesenswert?

Hallo
Habe jetzt auch 0.69 getestet.
Roll-mode geht jetzt wieder (ab500ms). Leider ist die Anzeige nicht 
kontinuierlich sondern es werden immer so ca. 2 Kästchen nacheinander 
gezeigt.
Bei der 0.66 zeigte er die Linie kontinuierlich an. (ab 5s)
(Geladen mit dem .flash - FW)
l.G. Roberto

von branadic (Gast)


Lesenswert?

Hallo,

nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der 
Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja 
bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den 
unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs 
ausgelesen werden, vertauscht worden ist?

Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt, 
dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich 
vielleicht leichter eine Schlussfolgerung ziehen.

Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

@Roberto

Ja das ist korrekt, wie ich schon angedeutet habe geht die 
Graphikroutine als Zeitkonstante sehr stark in das Gesamttiming mit ein. 
Daher war ich gezwungen die Graphikausgabe je nach Zeitbasis und Anzahl 
der aktiven Kanäle solange auszusetzen zwischen den einzelnen 
Meßwerterfassungen, dass in den etwas schnelleren Zeitbasen bis zu 400 
Punkte ohne Ausgabe erfaßt werden. Dieses Refreshtiming ist noch nicht 
ganz ausgereizt sondern erstmal konservativ ausgelegt um ein stabiles 
Timing zu garantieren. Zur nächsten Version werde ich das in Richtung 
kontinuierliche Ausgabe optimieren.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

branadic schrieb:

> nur mal so eine Idee: Kann die unterschiedliche Darstellung bei der
> Flanke vielleicht mit den verschiedenen "Hardware-Versionen", die ja
> bereits im FPGA-Design vermutet worden sind, zusammenhängen? Das in den
> unterschiedlichen Hardware-Versionen die Reihenfolge, in der die ADCs
> ausgelesen werden, vertauscht worden ist?

Das ist in der Tat nicht auszuschließen und sollte auf jeden Fall näher 
untersucht werden.

> Vielleicht sollten wir, zur FW-Version mit der dieser Effekt auftritt,
> dazu schreiben welche Hardware-Version zugrunde liegt, dann ließe sich
> vielleicht leichter eine Schlussfolgerung ziehen.

Das macht mich jetzt auch neugierig, denn ich hab bei meinen beiden 
Geräten die HW-Version noch garnicht verglichen.

> Ich kann es nur leider gerade nicht, da ich auf Arbeit bin.

Dito, werde mich morgen dazu äußern.

Hayo

von branadic (Gast)


Lesenswert?

Hallo zusammen,

ich habe im Trac eine Seite eingerichtet, wo der Gerätetyp, die 
Hardware-Version, die FW mit der getestet wurde und ob die Darstellung 
der Flanke in Ordnung ist festgehalten ist. Ich wäre euch dankbar, wenn 
sich freiwillige finden würden und mir an

branadic (ät) users (pünktchen) sourceforge (pünktchen) net

ihre Daten zukommen lassen würden.
Die Übersicht findet ihr unter:

http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument

Dies könnte entscheidene Aufschlüsse über Unterschiede bringen und alle 
können davon nur profitieren.
Wir haben uns zu dieser Seite vor allem entschlossen, damit nicht jedes 
mal neu nachgefragt werden muss welches Gerät und welche 
Hardware-Version zugrunde liegt. Die Seite kann jederzeit beliebig 
erweitert werden, sodass Rückschlüsse schneller getroffen werden können.
Wenn ihr euren µC-Nickname und/oder euren Sourceforge-Nickname ebenfalls 
mit preisgeben wollt, so werde ich auch dies mit einpflegen.

Ich werde nachher auch meine Info's dazu dort festhalten.

Beste Grüße, branadic

von Stefan E. (stefan_e)


Lesenswert?

Hallo,
das mit den Hardware-Revisionen habe ich mir auch schon gedacht.
Meines (W2022A 8C7.0L) ist mit der 1.3 FW ausgeliefert worden. Habe aber 
die 1.4 FW aus dem Forum hier mal installiert. Evtl. liegt da noch etwas 
im Config-Flash, das der FPGA selbst ausliest und bei mir jetzt falsch 
eingestellt ist?
Meine 1.3er kann ich leider nicht mehr aufspielen um das zu testen ;-) 
Vielleicht hat ja noch jemand eine 1.3er mit gesichertem Config-Bereich 
für mich? Dann könnte ich das mal ausprobieren.

Der Effekt ist absolut reproduzierbar. Auch nach Aus- und Einschalten. 
Sobald die ADCs zeitlich verschoben sind in der FW, passts.

von Stefan E. (stefan_e)


Lesenswert?

Servus branadic,
super Idee. Ich kann die Bilder auch kleiner machen, wenn du willst ;-) 
Dann wirds etwas übersichtlicher.

Wichtig ist evtl. auch, welche Kanäle betroffen sind und welche Firmware 
im Original drauf war.

von branadic (Gast)


Lesenswert?

Hallo Stefan,

hab deine Daten mal mit aufgenommen. Welche FW im Original mal drauf war 
sollte keine Rolle spielen.

Ein komplettes Backup vom Protected Bereich und vom Config Bereich 
findest du hier in diesem Thread auch irgendwo. Das hatte Hayo mal 
hochgeladen.

Welche Kanäle betroffen sind kann man natürlich hinzufügen. Ich hab es 
bei mir auf allen Kanälen probiert und mit Hayo's FW ist das in Ordnung.

Gruß, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

bei meinem W2012A mit HW 8C7.0F ensteht dieses Problem mit
Hayos Betas auch nicht (beide Kanäle o.k.). Original war die
FW 1.4 drauf, falls da jemand Statistik führen möchte.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

ja wir führen Statistik-s.o.
und weil es mit Fotos gleich viel offensichtlicher ist, anbei meine 
Version.

Bei wem tritt das im Foto gezeigte/ beschriebene Problem mit den Probes 
noch auf?

Gruß, brunowe

von Stefan (Gast)


Lesenswert?

>Welche FW im Original mal drauf war sollte keine Rolle spielen.

Eben da bin ich mir nicht sicher. Es gab ja auch Probleme mit der ersten 
Serie und der Firmware der A-Serie. Da gingen die Drehknöpfe nicht mehr. 
Vielleicht gabs ja zwischenzeitlich wieder ein kleines Update im FPGA. 
Und der neue Config-Bereich, den ich mir mit den Update auf 1.4 
aufgespielt habe, bringt mein Oszilloskop durcheinander. Wäre doch auch 
ein Grund, warum die 1.4 nie im Internet veröffentlicht wurde.

von Blue F. (blueflash)


Lesenswert?

Hi branadic,

ich hoffe es ist ok, dass ich ebenfalls nicht maile sondern hier poste. 
Ich kann gleich beide Varianten anbieten. Übrigens für alle die auch 
testen wollen aber den Trigger nicht hinkriegen - bei mir hat der 
Trigger nur gegriffen wenn ich auf Normal Mode geschaltet hab.

- W2022A / 8C7.0L gekauft 10.2008 mit FW1.3 getestet mit 1.2.BF.0.69
  Kanal 1 - Flanke völlig vermurkst
  Kanal 2 - Flanke ok

- W2014A / 8C7.0L gekauft 03.2009 mit FW1.4 getested mit 1.2.BF.0.70
  Kanal 1 - 4 Flanke ok

Foto spar ich mir, da es im Fall 1 genauso aussieht wie auf den hier 
veröffentlichten. Meinen Nickname kennst Du ja ;-)

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Es ist definitiv irgendwann in der Modellreihe einmal etwas an der ADC 
Reihenfolge vertauscht worden. wer sich da noch dran erinnern kann- das 
von Stefan beschriebene Problem hatte ich auch. Bei mir kam es 
folgendermaßen dazu: Ich hab mir bei meinem W2022A mit 8C7.0E den config 
Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl 
ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein 
eigenes Flash-config wieder drauf hatte, war alles wieder ok.

Bei den Flanken- Messungen ist uns aufgefallen das es gravierende 
Unterschiede zwischen den einzelnen Probes im x1 Bereich gibt. Die 
Anstiegszeit des Cal. Signal unterscheidet sich damit tw. gewaltig von 
Probe zu Probe (wohlgemerkt im x1- Bereich). Deshalb hier nochmals der 
Tip, wenn's um Signale über 10MHz geht, oder um die Messung von 
Anstiegszeiten- dann unbedingt im x10 messen.

gruß, brunowe

von Roberto (Gast)


Lesenswert?

Hallo
Habe jetzt auch mal probiert.
Zuerst waren alle Signale nicht gut.
Dann öfters. Calibrate ADC /DCA gemacht.
Dann Flanke gemessen.. Flanken waren nicht sehr schön..
(Was ist das eigentlich für eine komische 3mm Buchse für die Probe..?)
Habe dann den Taskopf mit den zwei CO.Trimmer (neben CNC-Buchse) 
eingestellt.
Da kriegt man dann die Flanke so hin, dass dieser Spike nur noch ca. 
alle 3-4 sek aufblitzt. (Bei allen Kanälen komme ich da so hin)
Wenn der Tastkopf schlecht einstellt ist, werden genau diese Spikes 
gößer.
Also dürfte es sich da um Störsignale von Außen handeln?!
Es mach auch schon was aus, wenn man die Masseleitung beim Tastkopf 
anschließt und neben der Probe-Buchse, auf Masse legt!

l.G  Roberto  ( W2024A; HW.:8C7.0L ; FW.: 0.66)

von Stefan E. (stefan_e)


Lesenswert?

>Ich hab mir bei meinem W2022A mit 8C7.0E den config
>Flash.- Bereich zerlegt und dann eine config von Hayo (welche wohl
>ursprünglich von Markus stammt) drauf gespielt. Erst als ich mein
>eigenes Flash-config wieder drauf hatte, war alles wieder ok.

@Bruno
Genau so wird es bei mir auch passiert sein. Beim sichern gab es bei mir 
allerdings ein Problem und die Datei ist futsch. Ich hab mal deine 
W2000.flash von GoogleGroups probiert (V1-10-03). Hat aber nichts 
geholfen. Hast du zufällig noch eine andere?

Nachdem das Problem jetzt ja wohl eher nur bei mir liegt, will ich euch 
nicht weiter mit dem Testen von meiner Firmware nerven. Trotzdem Danke 
für alle Rückmeldungen. Notfalls muss ich das bei mir halt irgendwie mit 
einbauen einbauen ;-)

Muss keiner hier demnächst eine Diplomarbeit schreiben und sucht noch 
ein Thema? Wie wärs mit "Neuentwicklung der FPGA-Software für W2000" g

Gruß,
Stefan

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Damit unseren Programmierern die Arbeit nicht aus geht...
Es gibt unter: 
http://apps.sourceforge.net/trac/welecw2000a/wiki/FWwishlist
eine Wunschliste für SW Erweiterungen.

Im Rahmen der Flanken- Messung ist mir aufgefallen wie praktisch die an 
jedem analogen Oszilloskop vorhandene variable Verstärkung ist. Um die 
Höhe eines Sprungsignals exakt auf 5 Div einstellen zu können, und damit 
leichter die 10%-90% risetime ablesen zu können, ist so eine Streckung 
in der y-Achse sehr praktisch.

Das Ganze ist in SW bestimmt mit mittleren Aufwand machbar. Allerdings 
muss ein neuer Menüeintrag erzeugt und bei Anwendung der nicht 
normierten Verstärkung klar darauf hingewiesen werden. Vielleicht fasst 
sich ja mal ein Berufener ein Herz?

Gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

Und nochmal ich ;-)

Mir ist gerade noch aufgefallen, dass Hayo und ich die selbe 
Hardware-Revision haben. Das ist schon komisch, vorallem weil Hayos 
Geräte unterschoedlich alt sind und scheinbar viele verschiedene 
Revisionen gibt. Ich gehe davon aus, dass wir beide die selbe Sicherung 
verwendet haben (die hier im Forum irgendwo liegt.) Da wird wohl die 
Revision mit abgespeichert sein. Also auch nur bedingt aussagekräftig.

von branadic (Gast)


Lesenswert?

Einspruch,

ich habe mir auch mal meine FW zerschossen. Hatte seinerzeit mal meine 
Sicherung meines W2014A hier eingestellt und diese hat Hayo, dem Chaos 
auf dem eigenen PC sein dank, mir wieder zur Verfügung gestellt. Diese 
habe ich bei mir auch wieder eingespielt. Demnach müsste ich die gleiche 
Hardware-Revision haben. Hab ich aber nicht.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Hi, die Hardwareversion wird nicht aus dem Flash geladen sondern aus dem 
FPGA. Es gibt eine eigene Funktion dafür  Read_Version().

Wie viele gibt es denn jetzt mit vermurkster Flanke außer Stefan und 
mir?

Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Lass mir doch mal Deine Korrektur zukommen, eventuell kann ich eine 
Funktion einbauen die über einen Testschalter die Geräteversion (mit 
vermurkster Flanke oder ohne) ins Flash schreibt und dann die Korrektur 
aktiviert oder nicht. Dann haben wir da auch wieder Gleichstand.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Ehe man weiß, wie es zusammenhängt und was der Grund ist, ist so ein 
"Ausgleich" für einen Fehler keine gute Idee. Das verleitet dazu, die 
Ursache nicht weiterzusuchen.

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Bruno

Die Idee mit der variablen Verstärkung ist nicht schlecht, die fand ich 
an meinem analogen Oszi auch ganz praktisch. Muß mal sehen wo ich das 
ich die Prioliste einsortiere...

Hayo

von Blue F. (blueflash)


Lesenswert?

@Hannes

Ich denke Stefan ist an der Sache dran. Wenn er da nähere Erkenntnisse 
hat können wir weitere Maßnahmen einleiten. Zudem scheint mir die 
Ursache soweit ich das verstanden habe zu sein, dass die FPGA-Logik die 
ADC-Daten in der falschen Reihenfolge einsortiert, oder?

Hayo

von Johannes S. (demofreak)


Lesenswert?

Mein Einwand war eher genereller Natur. Ich hatte das nicht so 
verstanden, als wenn schon Einigkeit darüber bestünde, was der Grund für 
das Problem mit der verdrehten Auslesereihenfolge der ADC ist bzw. woran 
man es festmachen kann, ob es besteht oder nicht. Aber vllt hab ich da 
nur was überlesen.

Lass dir mal von mir nicht reinreden. :D

/Hannes

von Stefan E. (stefan_e)


Lesenswert?

So,
Bruno hat mir sein Backup zugeschickt. Mit dem sind die Flanken jetzt 
wieder "schön" ;-)


Übrigens hab ich jetzt mit dem Config die Hardware-Revision 8C7.0E 
(vorher L) und, soweit ich mich erinnern kann, wieder eine andere 
SerienNr.
Muss also doch letztendlich irgendwo im Flash stehen.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

@Stefan

- die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im
  Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface
  ermittelt.

- Die Seriennummer wird aus dem Flash gelesen

- hab ich das richtig verstanden, das Du nur durch das Einspielen eines
  anderen Flashdumps das Gezackere wegbekommen hast??? Dann würde ich
  den Dump auch gern mal ausprobieren.


Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump 
eingespielt, muß ich mal checken wenn ich zuhause bin.

Hayo

von Guido (Gast)


Lesenswert?

Hallo,

da fehlt uns noch Einiges am Verständnis. Dass der Config-Bereich
mir die Buttomplane versaut hat ist ja leicht einzusehen. Aber dass
auch die Fehler bei der Invertierung hieraus resultierten?

Ich denke, die (und andere) werde ich bald wieder sehen, wenn ich
READOUTADC_ALL in C teste. :-)

Gruß, Guido

von Stefan E. (stefan_e)


Lesenswert?

>die Hardwareversion wird nicht aus dem Flash gelesen, kann man sich im
>  Coding ansehen, die wird durch einen Zugriff auf das PIO-Interface
>  ermittelt.

Glaube ich dir ja auch sofort. Nur der FPGA kann sie ja auch wieder aus 
dem Flash lesen. Sie hat sich bei mir halt definitiv geändert nach einem 
kompletten Neubeschreiben mit einem anderen Backup.

>Ich war der Meinung ich hätte in beiden Geräten den gleichen Dump
>eingespielt, muß ich mal checken wenn ich zuhause bin.

Kann durchaus sein. Wenn das eine etwas älter ist (so wie meines), 
scheint es mit nen Einstellungen eines neueren Config-Bereiches Probleme 
zu geben.

Vielleicht gibt hier ein Diff des Config-Bereichs genauer etwas 
Aufschluss. Außerdem kann ich mal probieren, meinen FPGA temporär zu 
updaten und mit einem 1.4er Config-Bereich zu betreiben.

Wenn also jemand sowiso schon ein Backup von seinem FPGA zu Hause 
rumfliegen hat, weil er mit slogs Software experimientiert hat UND bei 
ihm ab Werk die 1.4er Firmware drauf war, würde ich mich über die Datei 
sehr freuen ;-)

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Ich bin gerade dabei für den Rollmode/Shiftmode das Timing und die 
Refreshrate genau zu kalibrieren.

Dabei mußte ich feststellen, dass das Timing für die 500mS TB so stark 
von der Zeichenroutine beeinfußt wird, dass die Funktion hier nicht 
sinnvoll einsetzbar ist. In der nächsten Version werde ich also auf TB 
1S zurückrudern mit der dann der USTB-Modus automatisch einsetzt. Die 
500mS TB wird dann wieder konventionell ausgegeben.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Das wäre jetzt mein nächster Ansatz gewesen, nämlich den FPGA auf einen 
aktuellen Stand zu bringen um dadurch das Gezackere wegzukriegen. 
Allerdings habe ich mich mit der FPGA-Thematik noch nicht weiter 
auseinandergesetzt, so dass ich mich da erst einarbeiten müßte um zu 
wissen wie man das macht und welche Tools man dazu braucht. Wenn Du da 
weiter bist gib doch mal eine Kurzanleitung raus.

Hayo

von Michael W. (slackman)


Lesenswert?

@ Stefan:
Wenn ich's schaffe, werde ich am Wochenende meinen FPGA sichern. Hab ein 
2024A, die Firmware war wohl 1.4...

Bin dieses Wochenende leider ausgebucht (heute Hochzeit, morgen Umzug), 
wird wohl erst morgen Nacht was. Hatte beim letzten Öffnen vergessen, 
den kleinen Widerstand für das JTAG zu brücken :-/

Außerdem wollte ich gerne noch den Lüfter tauschen. Der nervt mich 
langsam...

Michel

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

eine Anleitung über das dumpen/ flashen des FPGA- Config Flash findet 
ihr hier:
http://apps.sourceforge.net/trac/welecw2000a/wiki/FPGAConfigFlash
Die Sicherungsdatei eines W2022a EPCS16 findet ihr bei den Google 
Groups. Die Datei heißt: EPCS16_W2022A.JIC.rar

gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

@Michael

Super. Mach dir keinen Stress. Bin vor Montag auch nicht mehr zu Hause.

@Bruno

Die Tastkopf-Geschichte habe ich nicht vergessen. Werde ich mal testen.

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

@ Hayo: Ich bin dann mal soweit mit den 4 C-Funktionen. Habe den
Eindruck, der ADC-Abgleich ist vermurkst, aber vllt. siehst du
das viel schneller als ich. Auch der 5 ns/div Bereich scheint
noch etwas Nacharbeit zu benötigen.

Viel Spaß damit, Guido

von Stefan (Gast)


Lesenswert?

Hallo Guido und Hayo,

PREPARE_READADC ist dann überflüssig. Die hat der Entwickler nur 
gebraucht, weil die Übergabe von mehr als 8? (bin mir nicht ganz sicher) 
Parametern in ASM nicht ganz trivial ist. Da hat er die Übergabe einfach 
auf zwei Funktionen aufgeteilt. Einfach löschen,weil du die 
Korrekturwerte ja direkt aus dem Array ausliest.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Hi,

komme heute nicht mehr dazu, hab mir das aber mal runtergeladen. guck 
ich mir morgen mal an. Wenn ich soweit komme bastel ich das in die 
Wochend-Beta mit rein.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

keine Hektik, da sind bestimmt noch genügend Fehler drin. Bei
hohen Frequenzen sieht es ganz schlimm aus.

Was anderes: wo finde ich floatstr_t.h?

Gruß, Guido

von Guido (Gast)


Lesenswert?

Oops,

sorry in der Beta 0.68 gefunden.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Im Anhang ein BackUp vom FPGA eines W2024A mit Hardware 8C7.C9 und 
Firmware 1.4.
Die Checksumme ist 0706BCDF.

von Blue F. (blueflash)


Lesenswert?

Moin, moin,

danke Kurt, werd ich mal ausprobieren. Inzwischen habe ich ausgiebig mit
diversen Config-Files die ich noch rumliegen hatte experimentiert, alles
am W2022A, mit folgendem Ergebnis:

- Erstmal muß ich Stefan Recht geben - die Hardwareversion wird
offensichtlich über Umwege doch aus dem Flash gelesen. Bei mir wechselte
die Hardwareversion mit jedem Config-Dump den ich eingespielt hab.

- 8C7.0L Flanke vermurkst (1.2.BF.0.70)
- 8C7.00 Flanke vermurkst (1.2.BF.0.70)
- 8C7.0G Flanke ok!! (1.2.BF.0.70) (stammte von einem Gerät das
                                    ebenfalls wie meins etwa 10.2008
                                    ausgeliefert wurde)
- 8C7.00 Flanke vermurkst (aus einem W2014A als Komplettdump mit FW1.3)

Was mir dabei völlig unklar ist: Wie kann der Config-Bereich das
Auslesen des ADC beeinflussen??? Greift die Flashkonfiguration in den
FPGA-Ablauf mit ein?? Ist das evtl. auch der Schlüssel für die
Beseitigung der Schwingungen und Störungen die ja im anderen VHDL-Design
nicht auftreten?

Fragen über Fragen...

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Wir haben hier ja schon eine Aufstellung der Flanken-integrität und der 
EPCS16-Checksum einiger Geräte gesammelt:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
Da sich die Checksum der dort aufgeführten W2022a und W2012a nicht 
unterscheidet, ist es eigentl. auch nicht möglich das dort irgendwelche 
gerätespezifische Daten (Seriennr., HW-Version usw.) abgespeichert ist.
Es wäre hilfreich wenn noch mehr Leute ihre Checksum dort eintragen, 
vielleicht hilft uns das die Zusammenhänge besser zu verstehen.
Der FPGA liest auch Daten aus dem Config Flash des AM29LV. Ohne den VHDL 
Code wird es allerdings sehr schwierig werden das genau zu ergründen.

gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

Danke Kurt,
werde ich am Montag mal mit rumspielen.

Die Checksumme wird dann auch nachgeliefert.

von Roberto (Gast)


Lesenswert?

Hallo
Wie wird die Checksumme ermittelt?
Wie kann man die Daten in die Liste eintragen ?
l.G. Roberto

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Roberto,


Die Checksum wird von Quartus bzw. dem standalone programmer automatisch 
beim erstellen des EPCS16 Backup erzeugt.
Wie dieses dumping funktioniert ist unter:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
ausführlich beschrieben.
Man benötigt dazu aber etwas Vorarbeit, man muss im Prinzip erst einmal 
die Toolchain für VHDL installieren. Also Quartus bzw. den standalone 
programmer, den USB Blaster driver für Cypress FX1 oder man benötigt den 
Altera USB Blaster. wie das genau geht ist ebenfalls unter SF 
beschrieben.

Um die Checksum eintragen zu können benötigt man einen SF- Account.
Dann einfach bei dieser Seite:
http://apps.sourceforge.net/trac/welecw2000a/wiki/usersinstrument
unten links auf editieren und eigene Werte eintragen.
Wer keinen SF-Account hat darf seine Checksum natürlich auch gern hier 
posten.

Gruß, brunowe

von Michael W. (slackman)


Lesenswert?

Hi,
wo bekomme ich denn den originalen USB-Treiber für das Scope her? Bei 
mir findet Windows (XP SP3) den Treiber nicht ('Unbekanntes Gerät'). Ich 
dachte, der ist in der Winpows Anwendung integriert - war aber leider 
nix. Oder läuft die nur mit dem Seriellen Port (nicht der Updater)?
Auch ein Einbinden des USB-Blaster Treibers funktionierte nicht :-(

Nu' hab' ich extra die Brücke am JTAG-Interface gelötet und kann da sgar 
nicht nutzen... :-(

Michel

von Michael W. (slackman)


Lesenswert?

Ach ja, noch 'ne Frage zum Triggermode:
Zum Messen der Anstiegsflanke für das Userinstruments - Form habe ich 
gemerkt. dass der Trigger im Auto-Modus nur funktioniert, wenn 
mindestens 1,5 Perioden auf den Schirm passen (ca.). Im Normal-Modus 
ließ sich die Flanke dann korrekt messen. Allerdings blieb die Anzeige 
stehen (eingefroren!), wenn ich das Signal vom Probe genommen hatte. Das 
ist doch sicherlich nicht gewollt, oder?

...und zur Firmware:
Wenn ich die gesamten Abgleiche gespeichert habe, bleiben die beim 
Firmwareupdate erhalten oder muß ich die jedesmal wieder neu 
durchführen? vom Gefühl her bleiben sie aber ich lass' mich gerne 
belehren.

Ansonsten habe ich das Gefühl, dass man mit dem Teil mittlerweile 
richtig arbeiten kann. War schon kurz davor es wieder zu verkaufen und 
ein Rigol oder so zu ordern.

Mit dem Max038 wollte ich mir einen simplen Funktionsgenerator aufbauen 
und ein wenig rumspielen. In einem Youtube Video hatte ich gesehen, dass 
die Amplitude des gemessenen Signals bei steigender Frequenz immer 
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich 
so?

Michel

von André (Gast)


Lesenswert?

Dass die Flanke im Normal-Mode stehen bleibt, ist normal. Dabei wird der 
Schirm nur dann neu geschrieben, wenn das Triggerereignis auch wirklich 
eingetritt.

Im Auto-Mode dagegen wird zuneaechst aktualisiert, wenn das 
Triggerereignis eintritt. Allerdings auch dann, wenn es NICHT 
eingetreten ist, aber eine gewisse Zeit vergangen ist (ca 0.3s).

Den Eindruck, dass Auto ein bissl spinnt, hab ich auch :).

Gruessle

von Kurt B. (kurt)


Lesenswert?

Hallo Michael,
bitte poste nochmal deine genau Vorgehensweise.

http://apps.sourceforge.net/trac/welecw2000a/wiki/USBBlaster

Ich nehme an, diese Seite kennst du. Nach welchem Schritt tritt das 
erste Problem auf?

von branadic (Gast)


Lesenswert?

Michael schrieb:

In einem Youtube Video hatte ich gesehen, dass
die Amplitude des gemessenen Signals bei steigender Frequenz immer
kleiner dargestellt wurde (verglichen mit einem Tek). Ist das wirklich
so?

Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D

Selbstverständlich ist das so, ansonsten hätten wir das nicht 
eingestellt. Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und 
nicht auf 10:1.

@ Hayo

Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei 
Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen 
kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.
Ich glaube weniger, dass das auf ein Problem der Hardware zurückzuführen 
ist, als vielmehr auf ein Problem in der VHDL oder FW. Möglicherweise 
ist es die besagte Assembler Routine?

Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility" 
einer der frei gewordenen Softbuttons die Funktion bekommen würde das 
Probe-Signal an- bzw. abzuschalten. Die Frage ist, wie tiefgreifend die 
Abschaltung machbar ist. Eigentlich müsste man einen direkten Zugriff 
auf die Signalerzeugung im FPGA haben. Hintergrund ist es 
herauszufinden, inwieweit dieses Probesignal Störungen auf den Kanälen 
produziert.
Lässt sich hier etwas derartiges realisieren?

Beste Grüße, branadic

von Kurt B. (kurt)


Lesenswert?

branadic schrieb:
> Nein, das Video habe ich gefaked, weil ich Langeweile hatte... :D

>Wobei man sagen muss, dass der Tastkopf auf 1:1 stand und
> nicht auf 10:1.

Also doch gefaked ;-)

von branadic (Gast)


Lesenswert?

Hallo Hayo,

ich bin gerade noch ein wenig am Testen mit der aktuellen FW. Dabei sind 
mir noch ein paar Dinge aufgefallen.

Mein Messaufbau besteht aus einem DDS-10 Board. Auf Kanal 1 hab ich ein 
50-Ohm-Kabel mit 50-Ohm Abschlusswiderstand. Auf Kanal 2 einen Tastkopf 
eingestellt auf 1:1 und auf Kanal 4 einen Tastkopf 10:1.
Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt 
auf einen der Kanäle triggert sollte man meinen, dass die Flanken 
halbwegs sauber übereinander liegen. Dem ist aber nicht so.

Durch den Spannungsteiler im Tastkopf von 10:1 sind mir wieder diese 
Schwingungen aufgefallen. Diese liegen in der Tat nicht auf dem internen 
Probesignal, sondern werden irgendwo nach dem Tastkopf erzeugt.
Im konkreten Fall mit einem Testsignal von 1kHZ Rechteck kann ich einen 
Sinus-Anteil auf meinem Rechtecksignlal von etwa 100MHz feststellen, der 
zusätzlich noch einmal mit einem Sinus von etwa 6,66MHz 
amplituden-moduliert ist.

Weiterhin ist mir aufgefallen, dass der Trigger bei der 
Spannungsbereichumstellung nicht nachgeführt wird. Soll heißen, trigger 
ich bei 200mV/div auf dem Wert 100mV, dann sollte das auch noch so sein, 
wenn ich den Bereich auf eine höhere oder niedrigere Spannungsbasis 
umstellen. Tatsächlich bleibt der Triggercursor aber auf dem Bildschirm 
an exakt der gleichen Stelle stehen. Das wiederum heißt, stelle ich den 
Spannungsbereich um, Trigger ich plötzlich auf ein anderes Event. Das 
ist natürlich nicht korrekt.

Der manuelle Trigger funktioniert nur bis zur Spannungsbasis 10ns/div, 
bei 5ns/div leider nicht mehr.

Weiterhin habe ich mit einem 1kHz-Dreiecksignal getestet. Mir ist 
aufgefallen, dass das Gerät zum Teil echten Quark anzeigt, wenn ich die 
Zeitbasis verstelle. Erst wenn ich dann die Triggerquelle abziehe und 
erneut anklemme wird das Signal auf der neuen Zeitbasis wieder richtig 
angezeigt. Auch funktioniert hier der Trigger irgendwie nicht richtig?? 
Mit Dreiecksignalen überfordert?

Vielleicht aber nicht nur Negatives. Ganz gut finde ich, dass der 
Trigger-Level für jeden Kanal einzeln einstellbar ist.

Gruß, branadic

von branadic (Gast)


Lesenswert?

Auch auf die Gefahr hin das das hier ein Monolog wird. Mir ist noch 
etwas grundsätzlich bei der Menu-Darstellung aufgefallen.
Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen 
Menuleiste nicht mehr zu lesen ist, sonder schwarz ist. Drücke ich dann 
Default Setup, passt die Darstellung wieder und Kanal 3 ist als Zahl 
auch wieder lesbar. Weiterhin ist mir aufgefallen, dass die Zahlen im 
oberen Menu zum Teil ein blaues Shining haben. Kann das jemand 
bestätigen? Irgendwie scheinen die Planes da auch nicht korrekt zu sein.

Gruß, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

dann störe ich mal deinen Monolog etwas. Vermutlich muss sich Hayo erst
erholen, von meinen C-Funktionen. Wenn er aus dem Lachen wieder raus
ist, wird er sich melden.

Mit den Planes gibt es in der Tat größere Probleme, die könnten auch
vom FPGA-Design kommen (Adresslinien vertauscht?). Wenn ich etwas
mehr Zeit habe schau ich mir das noch mal an.

In dem Bereich um 5 µV/div passieren noch mehr Merkwürdigkeiten.
Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster
an und weiter kann auch nicht gescrollt werden (es werden aber
immer noch 16 kB pro Kanal verarbeitet). Vllt. finden wir das mit
den C-Routinen, da kann man mal schnell was ausprobieren.

Die Probleme mit dem Dreiecksignal kann ich nicht nachvollziehen.
Ich habe zwar nur 2 Kanäle aber mit denen klappts (Triggerung o.k.,
keine Mist wird dargestellt). Das mit den Schwingungen muss ich
mal probieren. Ist das überlagerte 6,88 MHz-Signal nicht etwa ein
Alias?

Gruß, Guido

von Michael W. (slackman)


Lesenswert?

@ branadic

Das mit den falsch dargestellten Kanalzeilen in der Titelzeile kann ich 
bestätigen, speziell bei Kanal 3.

Da ich noch relativ wenig Messequipment habe, sind die Tests, die Ihr so 
durchführt für mich schwierig nachstellbar.

@ Kurt
Ich dachte, dass in der PC-Anwendung von Wittig ein USB-Treiber 
enthalten ist. Als ich das Gerät angeschlossen hatte, zeigte mir Windows 
erst ein neues Gerät an und sogar die Meldung, dass ich es jetzt 
benutzen könnte.

Nach ein paar Sekunden kam aber die Meldung, dass das Gerät nicht 
korrekt funktioniert und jetzt ein Treiber von Nöten sei. Das alles noch 
VOR der Installation des USB Blaster.

Teufel auch: gerade habe ich's nochmal getestet und jetzt zeigt der 
Rechner keine Probleme an und die Anwendung scheint das Teil auch 
steuern zu können, nur ein Signal sehe ich nicht auf dem Schirm (der 
Anwendung). Ich hab' nix gemacht, war nur mit'm Hund zwischendurch 
spazieren ;-)

Ok, jetzt werde ich mich weiterhangeln bis zu den FPGAs...

Michel

von Blue F. (blueflash)


Lesenswert?

Hi,

war heute unterwegs - daher keine Rückmeldung von mir. Dafür aber schon 
eine Ankündigung: Es gibt gleich das nächste Wochenendrelease u.a. mit 
Guidos C-Routinen.


@Branadic

> Ich habe nach wie vor ein gewaltiges Problem mit meinem Kanal 3. Bei
> Zeitbasen >5µs hab ich gewaltige Spikes auf dem Kanal. Bei Zeitbasen
> kleiner gleich 5µs sind diese wie von Geisterhand verschwunden.

Konnte ich bei mir nicht nachvollziehen. Bei mir ist auf allen Kanälen 
das ganz normale Rauschen zu sehen. Nur auf Kanal 4 habe ich bei 
warmgelaufenem Gerät starke Störungen.


> Was ich mir sehr wünschen würde ist, wenn unter dem Menü-Punkt "Utility"
> einer der frei gewordenen Softbuttons die Funktion bekommen würde das
> Probe-Signal an- bzw. abzuschalten.

Ich weiß leider nicht ob eine Abschaltung via Software möglich ist, oder 
ob der Signalgenerator einfach in Hardware realisiert ist. Wenn es dazu 
nähere Infos gibt baue ich das gerne mit ein.

> Alle drei Signale hängen an der gleichen Signalquelle. Wenn man jetzt
> auf einen der Kanäle triggert sollte man meinen, dass die Flanken
> halbwegs sauber übereinander liegen. Dem ist aber nicht so.

Muß ich mal prüfen. Einen derartigen Testaufbau hatte ich bislang noch 
nicht - interessant!


> Weiterhin ist mir aufgefallen, dass der Trigger bei der
> Spannungsbereichumstellung nicht nachgeführt wird.

Da gebe ich Dir recht. Das ist ein weiterer Punkt der 
verbesserungswürdig ist. Evtl. ein Fall für die Wishlist.

> Auch funktioniert hier der Trigger irgendwie nicht richtig??
> Mit Dreiecksignalen überfordert?

Hab bislang nur mit Sinus und Rechteck getestet - muß ich mal prüfen

> Bei Kanal 3 passiert es mir regelmäßig, dass die Kanalzahl in der oberen
> Menuleiste nicht mehr zu lesen ist, sonder schwarz ist.

Ja das ist bei mir auch so, allerdings auch bei der FW1.4 - da scheint 
ein Fehler zu sein der sich durch alle FW-Versionen zieht. Da mir das 
aber nicht so tragisch erschien hab ich das erstmal in der Prioliste 
weiter hinten einsortiert.

> Weiterhin ist mir aufgefallen, dass die Zahlen im
> oberen Menu zum Teil ein blaues Shining haben.

Bei mir nicht


@Guido

> Z.B. zeigt der Browsebalken hier nur noch etwas mehr als ein Fenster
> an und weiter kann auch nicht gescrollt werden (es werden aber
> immer noch 16 kB pro Kanal verarbeitet).

Ein Blick in die Timebasetabelle meiner Programming Maps bringt die 
Lösung: Die Zeitbasen 1µS/2µS/5µS werden nicht über eine entsprechende 
reale Abtastrate erzeugt, sondern (warum auch immer) durch einen 
entsprechenden Faktor von 20 bzw. 25. Da bleiben dann nur noch 819 bzw. 
655 Werte von den 16K übrig - da ist dann nicht mehr viel mit browsen.


@Michael

Die USB-Übertragung zum PC sollte ohne Treiber funktionieren, ist aber 
in der Beta FW völlig ungetestet - heißt ich hab es noch nie 
ausprobiert.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Bevor ich in die Wanne steige hier die 0.71 beta.

Wesentliche Änderungen:

- Der USTB-Bereich fängt jetzt ab 1S/Div an, darunter ist kein stabiles 
Timing machbar

- Guidos C-Routinen sind implementiert und können per Testschalter 1 
(shift + S) an bzw. ausgeschaltet werden. Defaultmäßig sind die 
Assemblerroutinen aktiv. Leider sind die C-Routinen noch deutlich 
langsamer als die Assemblerroutinen und haben auch noch kleinere 
Abweichungen in der Null-Lage.

Hayo

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Oje was ist denn da geschehen?
Neue 0.71 Version -mit bzw. auch ohne C-Routine.
Diese hässlichen Spikes kommen mir doch irgendwie bekannt vor.
Es gibt übrigens gravierende Unterschiede in der Darstellung mit und 
ohne C-Routinen bei höheren Freq. ... aber richtig gut sieht keine aus- 
nicht nur wegen der Spikes.

Gruß, brunowe

P.S.: morgen teste ich ausführlich

von Guido (Gast)


Lesenswert?

Hallo Bruno We,

in den C-Routinen sind ganz offensichtlich noch Fehler. Mit
höheren Frequenzen sehe ich nur noch Murks. Keine Ahnung was
schuld ist, aber das werden wir schon noch rauskriegen. Z.B.
stimmt bei mir der ADC-Abgleich nicht mehr ...

Gruß, Guido

von Michael W. (slackman)


Lesenswert?

Uuups,
nach einem kurzen Test habe ich die .69 Version wieder eingespielt. Die 
Rauschpegel der Kanäle 2 und 3 waren erheblich höher als bei den letzten 
Versionen. Die 5er Bereiche waren ja schon fast glatt, jetzt ist bei 
Kanal 2 der Rauschteppich ca. doppelt so hoch wie bei 1 und bei Kanal 3 
nochmal höher (etwa 4x wie bei Kanal 1). In den 1er und 2er Bereichen 
ist das Rauschen allgemein höher geworden (mein Empfinden), die 2er 
Bereiche fast nicht nutzbar... :-/ Schade

Michel

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Nachtrag:
also mit der 0.69 Version sind diese Spikes definitiv nicht da.
Das mit dem Rauschpegel kann ich so eigentlich nicht bestätigen- der 
sieht bei mir nur deshalb höher aus weil ich definitiv den einen 
Ausreißer ADC habe (auf beiden Ch).
Aber irgendwo ist da noch grob der Hund drin...
Was aber interessant ist- die C-Routine hat massiven Einfluß auf das 
festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja 
doch was?
Ich seh schon... das Projekt wird immer umfangreicher... und 
interessanter.

Gruß, brunowe

Als Anhang noch ein kurzer, 500kB großer Videoclip, der das Rauschen mit 
Hayo 0.71 und Abschirmung wie im HW Thread beschrieben, zeigt.

von Guido (Gast)


Lesenswert?

>Was aber interessant ist- die C-Routine hat massiven Einfluß auf das
>festgestellte oszillieren bei höheren Frequenzen. Vielleicht geht ja
>doch was?

Genau meine Meinung. Ich habe versucht die Assembler-Routinen
1:1 in C zu übersetzen. Gut möglich, dass ich dabei Fehler
produziert habe. Das müssen wir noch prüfen, ich brauche dazu erst
etwas Abstand.

Falls aber logische Fehler im Programm stecken, lassen sich die
dann halt in C viel leichter erkennen.

Gruß, Guido

von Michael W. (slackman)


Lesenswert?

Hi,
kann mir vielleicht jemand mit dem ByteBlaster helfen? Ich bekomme immer 
das USB HID angezeigt. Einmal kurz hatte ich ein NIOS mit Fragezeichen 
im Gerätemanager aber das bekomme ich nicht mehr hin. Als Nicht PNP wir 
der Altera ByteBlaster aufgelistet (versteckte/nicht sichtbare 
Komponenten).

Installiert habe ich den Quartus II 9.0sp1 Programmer und der findet 
logischerweise keine Programmierhardware...

Kann ich alles wieder in den Urzustand versetzen und von vorne beginnen? 
Mit der Sourceforge-Anleitung bin ich nicht weitergekommen... :-/

Michel

von Blue F. (blueflash)


Lesenswert?

Moin, moin,

die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch
die C-Routinen verusacht. Ich habe diese einfach per Fallunterscheidung
mit in die gleiche Subroutine gepackt. Die Assemblerroutinen arbeiten
mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger
Register unterschiedliche Auswirkungen hat. Durch das zusätzliche Coding
in der Subroutine wird der Ablauf hier offensichtlich gestört. Das läßt
sich nur durch getrennte Routinen entkoppeln. Ich werde mal sehen, dass
ich heute oder morgen eine neue Version zur Verfügung stelle.

Hayo

von Guido (Gast)


Lesenswert?

Hallo,

>Die Assemblerroutinen arbeiten
>mit dem PFX-Befehl, der allerdings je nach Ausgangszustand einiger
>Register unterschiedliche Auswirkungen hat.

unwahrscheinlich.PFX als Immediate-Befehl ist unabhängig von
Registerinhalten. In manchen Funktionen wird C-switch mit asm
kombiniert, das könnte dann auch nicht funktionieren.

>die Störungen auf den Signalen im Assemblerbetrieb werden indirekt durch
>die C-Routinen verusacht.

Durch eine leicht verändertes Timing? Ich kann mir langsam alles
vorstellen.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Guido wrote:
>Ich kann mir langsam alles vorstellen.
Prima, dann sind wir ja schon zu Zweit.

Sind alle aktuellen Assembler -> C Umsetzungen in readadc.cpp enthalten?
So umfangreich sind diese Funktionen gar nicht (hätte ich mir schlimmer 
vorgestellt) Will damit sagen- so auf die Schnelle sehe ich keinen Grund 
wieso der C-Code solche massiven Änderungen hervorruft- ADC Fehlabgleich 
etc...

Bin gespannt was die nächsten Tage diesbezüglich zum Vorschein bringen.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

@Guido

wie ich schon sagte - alle Assemblerroutinen arbeiten mit dem PFX-Befehl
und dieser ist, wie Du ja auch schon sagtest, registerabhängig.

Daher werde ich das in separate Routinen verpacken, dann kann ich auch
gleich sinnvollere Namen vergeben.

Hayo

von Guido (Gast)


Lesenswert?

@ Hayo,

PFX ist wie ich schon sagte unabhängig von Registerwerten. ;-)

@ Bruno We: Ja, schön kompakt ist es in C schon, das war der
Grund für die Mühe. Fehler können leicht entstehen, wenn ich
den Assemblercode falsch interpretiert habe. So war ich mir
z.B. ganz sicher, dass für Timebase >= 7 nur 1024 Longwords
bearbeitet werden. Dann wurde dort nur ein Viertel des
Schirms aktualisiert und ich habe nicht mehr gefunden, wie
ich auf die Idee gekommen bin.

Die Verzögerungen sind zum Teil leicht zu erklären: Schleifen
statt aneinandergehängten Code. Wenn es soweit ist, kann das
leicht optimiert oder sogar wieder in Assembler umgesetzt
werden.

Gruß, Guido

von Guido (Gast)


Lesenswert?

@ Hayo. Was mir gerade noch einfällt: Wir könnten doch die
Variablen in meinen Funktionen alle als static deklarieren.
Das könnte schon etwas beschleunigen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Guido

Hab nochmal die PFX Sache nachgeschlagen, da hatte ich wohl was in den
falschen Hals bekommen. Aber irgendwie beeinflußt das C-Coding den
Assemblerablauf.

Und zwar kann man die Auswirkungen des C-Codings ganz gut sehen wenn man
in READADC_ALL2() (Zeile 18880) die Reihenfolge von C-Coding und
Assembler ändert. Ich habe nämlich das C-Coding hinter die
Assemblerroutine gepackt weil sonst der Nullpunkt des Signals komplett
um die halbe Gridhöhe verschoben wird.

Kannst ja mal ausprobieren. Evtl. kann man das Ganze auch dadurch
stabilisieren, dass man in den anderen Funktionen ebenfalls die
Reihenfolge ändert.

Gruß Hayo

von Guido (Gast)


Lesenswert?

@ Hayo: Tja, wenn wir verstehen, was da passiert, sind wir wohl
schon ein gutes Stück weiter. Ev. werden in READADC_ALL globale
Register verwendet, das werde ich mal anschauen.

Ich habe mal alle C-Variablen static deklariert und auch stat.
Kopien von DataArray1 verwendet. Das scheint etwas schneller zu
gehen, aber immer noch deutlich langsamer als der Assemblercode
(hoffentlich bilde ich mir das nicht nur ein).

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Warum hast Du eigentlich die Funktion EXTRACTADCVAL() umgesetzt? Die 
wird nirgends verwendet, und ich habe sie jetzt auch komplett 
rausgelöscht.

Hayo

von Guido (Gast)


Lesenswert?

>Warum hast Du eigentlich die Funktion EXTRACTADCVAL() umgesetzt?

Fingerübungen, erstmal mit einer kurzen Funktion anfangen.

Gute Nachrichten: Die Störungen bei hohen Frequenzen stammen
aus READADC_ALL2. Das sollte die Fehlersuche erleichtern.

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So liebe Leute, nach dem Aufschrei der Empörung jetzt die überarbeitete 
Version mit gekapselten C-Routinen, die Euch hoffentlich wieder milde 
stimmt.

Die Umschaltung zur C-Routine geht wie gehabt via shift + S - allerdings 
nur für Kanal 1.

Hayo

von Stefan (Gast)


Lesenswert?

Hallo,

habe heute probiert den FPGA zu updaten. Leider ohne Erfolg,da das 
Backup von Kurt von einem 4-Kanal-Gerät ist ich aber nur 2 habe :-( Muss 
also noch warten, bis mir jemand ein passendes Backup schickt.

@Bruno
Das mit den Unterschieden der Tastköpfe kann ich nicht bestätigen.
Ich warte sehnsüchtig auf deine Abschirmanleitung ;-)


Momentan versuche ich die ganze ZPU-Geschichte bei mir zum laufen zu 
bekommen. Das klingt interessant.

Gruß,
Stefan

von Michael W. (slackman)


Lesenswert?

Hi,
bei mir sind in der .72 FW die Kanäle 2 und 3 wieder besser geworden. 
Danke Hayo ;-)

So'n Schönheitsfehler hab ich noch beim Grid gesehen:
Wenn man unter Display -> Grid das Grid auf 100% dreht (nur zur besseren 
Sichtbarkeit), sieht man im unteren Rahmen so im mittleren Drittel ein 
paar Unterbrechungen/schwarze Pixel. Hier scheint es auch noch Probleme 
mit den verschiedenen Panes zu geben. Mit der Zeit füllen sich die 
Löscher im Rahmen (die Unterbrechungen schließen sich)... Strange, Stört 
allerdings nicht großartig, nur Kosmetik.

Dann werde ich jetzt mal weiter versuchen den ByteBlaster zum Laufen zu 
bringen.

Gerade habe ich am PC den USB-Blaster installiert bekommen. Vielleicht 
schaff' ich's ja gleich endlich auf meinem T41... :-/

Michel

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

anbei ein paar Fotos mit der aktuellen FW 0.72. Die Assembler- Routinen 
laufen jetzt wieder so wie vor 0.71er Zeiten, die C-Routinen sind so 
noch nicht zu gebrauchen- irgendwie überschreiben diese C-Routinen sogar 
meine ADC- Kalibrierung so dass ich auch nach Umschalten auf Assembler 
erstmal wieder kalibrieren muss. Noch sehr seltsam was da abgeht...
Hoffe meine Fotos helfen etwas bei der Klärung des Mysterium.

@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir 
darunter bitte vorstellen? Was für ein Backup brauchst du denn?
Abschirmanleitung- ich hab mir heute nochmal ein Stückchen Alu- Blech 
besorgt, werde das morgen? mal ordentlich hinbiegen und dokumentieren- 
es kann zumindest nix schaden.
Und... das mit den Tastköpfen sieht bei dir also nicht so aus?
du meinst diese (eins- zwei) zusätzlichen Schwingungen?

Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn 
genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte 
(Test-) Versionen habe.

Gruß, brunowe

von Michael W. (slackman)


Lesenswert?

... irgendwie bin ich zu blöd für den ByteBlaster...
Wenn ich das Scope vom Rechner nehme (USB) und dann wieder verbinde, 
meldet der Gerätemanager wieder ein unbekanntes Gerät :-/ Sehr 
unbefriedigend diese USB-Geschichte :-(
Michel

von Guido (Gast)


Lesenswert?

Hallo,

dass mit den C-Routinen die ADC-Kalibrierung nicht mehr stimmt ist
klar, habe ich auch schon geschrieben. Dass sie aber diese
überschreiben? Ich muss mir die Speichermap nochmal anschauen. Die
Fehler zu finden wird durch die Grafik fast unmöglich gemacht. Wenn
ich auf 5 ns/div schalte erwarte ich ohne Vektoren 5 Pixel/div.
Angezeigt werden aber ca 25. Kommen die Fehler vllt. einfach daher?

Gruß, Guido

von Michael (Gast)


Lesenswert?

@Stefan:
was genau benötigst du für ein Backup?
Ich habe ein 2 Kanal 200 MHz Welec Oszi,
gekauft ca. 07/2008, original FW 1.3.
Leider bin ich erst jetz hier hinzugestoßen.
Wenn Du mir sagst, was Du genau brauchst, wär ich gerne bereit Dir 
weiter zu helfen.

Gruß,
Michael

von Stefan E. (stefan_e)


Lesenswert?

@Michael
>was genau benötigst du für ein Backup?

Ich bräuchte zum Testen ein Backup des FPGAs von einem 2-Kanal-Gerät mit 
Original-Firmware 1.4. Aber trotzdem Danke für das Angebot.

@BrunoWe
>@Stefan: du versuchst gerade den FPGA zu updaten? was soll ich mir
>darunter bitte vorstellen? Was für ein Backup brauchst du denn?

Ich würde ausprobieren, ob sich die Software des FPGAs von einem neueren 
Gerät in ein älteres übertragen lässt. Evtl. sind ja Verbesserungen im 
FPGA durchgeführt worden. Das es Unterschiede gibt, zeigt ja das Problem 
mit dem nicht passenden Config-Bereich.

>Und... das mit den Tastköpfen sieht bei dir also nicht so aus?
>du meinst diese (eins- zwei) zusätzlichen Schwingungen?

Nein, keine zusätzlichen Schwingungen im 10x-Bereich. Sind die beiden 
zusätzlichen Einstellschrauben in den dicken Gästen auch zur Anpassung 
des 10x-Bereichs an das Oszi? Hab ich sonst noch nirgens gesehen. 
Vielleicht ist ja da was verdreht.

>Du versuchst die ZPU- Geschichte zum Laufen zu bringen? Wo hängt's denn
>genau? Du kannst dann auch gern von mir noch so 5-15 unveröffentlichte
>(Test-) Versionen habe.

Genau die Geschichte: Ich fass mal zusammen, wie ich es versuche:
- Kompilieren
- Mit dem Programmer den Ram updaten
- Oskar startet mit schwarzem Bildschirm
- Mit dem "In-Memory-..."-Tool die gerade erstellte "zpu" mit einem 
Programm laden.

Bin ich soweit richtig?

Für die Zpu-Software brauche ich noch die Zpu-Toolchain. Da habe ich 
gestern aufgehört. Gibts da keine einfache Zip-Datei oder so? Ich finde 
die Dateien nur in einem Repository auf opencores.org

Verwendet zum Kompilieren habe ich die Dateien aus SourceForge.

Gruß,
Stefan

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

@Guido: Die von mir auf den Fotos
(http://www.mikrocontroller.net/attachment/52204/Hayo072.pdf) gezeigten 
Fehler lassen sich selbstverständlich auch im 50ns- Bereich und auch mit 
Vektordarstellung "off" nachvollziehen. Ein Fehler in der Interpolation 
schließe ich deshalb eigentlich aus.

@Stefan: Das in den letzten 12 Monaten Verbesserungen im FPGA Design 
durchgeführt wurden, halte ich eher für unwahrscheinlich. Deshalb denke 
ich auch nicht, das du durch so ein Update viel gewinnst, aber man kann 
es versuchen, da hast du natürlich recht.

Ehrlich gesagt ist mir nicht so ganz klar, wo es im Moment bei dir hängt 
(bzgl. ZPU- Design).
1.) Schaffst du es ein vorkompiliertes SOF- File zu programmieren (via 
Quartus Programmer)? Zu Testzwecken kannst du z.B. von den Google-Groups 
das Hello_W2000_v0_1_4.zip ausprobieren.
2.) Kannst du das in SF abgelegte ZPU- Design erfolgreich kompilieren?
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/zpu/quartus.tar.gz?view=tar
3.) Gehst du nach folgender Beschreibung vor:
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor

Derzeit ist das unter SF abgelegte Design nicht sonderlich interessant. 
Viel besser ist es, wenn du dich aktiv am FPGA- Neuaufbau beteiligen 
willst, dich mit der aktuellen, inoffiziellen Testversion zu 
beschäftigen.
(Z.B. das, welches ich für das Youtupe Video: 
http://www.youtube.com/watch?v=Ma7Yoz7AHhI verwendet habe.)
Wenn du Frage 1.) mit Ja beantworten konntest, dann sollten auch unsere 
Testversionen laufen. Schreib mich einfach an, wenn du diese Version 
haben willst, offiziell ins SF wollen wir es erst stellen, wenn noch ein 
paar Fehler ausgemerzt sind.


Gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

Hallo BrunoWe,

also das HelloW2000... von slog läuft bei mir. Außerdem kann ich den 
Code aus SF kompilieren. Also zweimal ja bei 1 und 2.

Danach ist mir nicht ganz klar, was ich machen muss. Ich laden die 
kompilierte W2000.sof mit dem Programmer in den Ram. Das klappt auch. 
Danach bleibt der Bildschirm schwarz.
Jetzt gehe ich in den In-Content-Manager (wie in dem Link unter 3. 
beschrieben), sehe als einzige Instanz die ZPU.

An dem Punkt hänge ich jetzt. Welchen Code muss ich da hochladen? Ich 
dachte, ich muss eine Art Firmware hochladen, die dann in dem im 
FPGA-erstellten ZPU-Core läuft.

Ich glaube, es wäre hilfreich, wenn du mir eure Testversion mal 
schickst.
Ich bin absoluter Neuling in VHDL. Interessiert mich aber brennend. 
Deshalb möchte ich halt einfach mal damit ein bisschen rumspielen und 
den Einstieg damit schaffen.

Gruß,
Stefan

von Crazor (Gast)


Lesenswert?

@stefan: du musst während des uploads des programms die ZPU im reset 
halten. dazu hälst du die linken beiden softbuttons (f1/f2) gedrückt, 
während du im mem editor auf hochladen drückst. Siehe auch hier: 
http://apps.sourceforge.net/trac/welecw2000a/wiki/InSystemMemoryContentEditor

solche kurzfristigen dinge können wir am besten per skype klären. mein 
skype name: crazor01

@hayo: ich habe jetzt zwar gerade noch 0.63 drauf und werde sicher auch 
nochmal mit der aktuellen testen, sobald das flashen wieder klappt, aber 
mir ist aufgefallen dass die samples scheinbar immer ein pixel links von 
der jeweiligen gridline dargestellt werden, sowohl mit als auch ohne 
aktivierter vektordarstellung...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

...und noch zwei Fragen an die Programmkundigen:
1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?
Eigentlich sollte man erwarten das keine interpolierten Werte 
dargestellt werden, dem ist aber offensichtlich nicht so. Es scheint so 
als ob nur die schrägen Verbindungen fehlen.
Gerade für Testzwecke wäre es gut, wenn wirklich nur die gemessenen ADC 
Werte dargestellt werden.
2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie 
kann ich da leider keinen Unterschied in der Darstellung erkennen. Eine 
optische Rückmeldung via via Display wäre natürlich gut, damit man auch 
weiß was man denn eingestellt hat, sofern die Fkt mal geht.

Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht 
unterbinden? Ich wundere/ ärgere mich jedes mal über eine 
Frequenzanzeige über 250MHz.

Gruß, brunowe

von Crazor (Gast)


Lesenswert?

Ich hab ein Problem mit dem aktuellen GERMSloader. Und zwar ist ja wie 
bereits erwähnt mein serieller Port etwas flaky, ab und an wird ein 
Zeichen verloren oder doppelt übertragen. Nun seh ich ab und zu mal 
einen Punkt in die Statusanzeige reinhüpfen und wieder verschwinden. 
Soweit läuft dann alles weiter. Irgendwann bekomme ich aber:

Writing line 004277 of 023377: .X............0 sec / 134 sec left
Error: Timeout while reading response from DSO!
Response was: 'S219815B3D34<#33><#13>
'
Firmware update was NOT successful!
Please fix the connection issue and retry!

Momentan funzt aber auch der von mir neulich gepatchte 
flashloader-with-retries nicht, das Problem scheint zu sein dass bei 
einem Retry keine Antwort vom Gerät mehr kommt.

Hilfe!

von Blue F. (blueflash)


Lesenswert?

Bruno We schrieb:
> ...und noch zwei Fragen an die Programmkundigen:
> 1.) Was macht eigentlich der Button- "Vektor off" bei Timebase <50ns?
> Eigentlich sollte man erwarten das keine interpolierten Werte
> dargestellt werden, dem ist aber offensichtlich nicht so.

Ich gebe zu, dass das vieleicht ganz hilfreich wäre, allerdings ist es 
nicht im Sinne der eigentlichen Funktion und auch nicht ganz einfach zu 
realisieren.

Der Sinn der Funktion ist es keine Vektoren (Verbindungslinien) 
darzustellen sondern nur die einzelnen Punkte. Im Falle der TB < 50nS 
sind das die Werte die bei der Interpolation errechnet werden.
Die Interpolation ist nicht Bestandteil der Grafikroutine sondern findet 
separat statt. Die Grafikroutine "weiß" also nicht einmal ob sie jetzt 
gerade interpoliert darstellt oder nicht.

> 2.) Was macht der Button- "Switch Drawing" am Oszilloskop? Irgendwie
> kann ich da leider keinen Unterschied in der Darstellung erkennen.

Na er schaltet halt den Zeichenmodus um (im Vektormodus) zwischen 
Ausgabe via Line() Funktion und Connect_Pixels() Funktion. Die Line() 
Funktion verbindet zwei aufeinander folgende Meßwerte miteinander, also 
ein echter Vektor. Connect_Pixels() ist eine der alten Funktionen der 
orig. FW und zeichnet (um Zeit zu sparen) im Prinzip nur nebeneinander 
liegende senkrechte Linien. Dadurch ist die Darstellung etwas grober, 
besonders in den Spitzen (man schon etwas genauer hinsehen).
Der Geschwindigkeitsvorteil der Connect_Pixels() Funktion ist 
mittlerweile nicht mehr vorhanden seit ich die Line() Funktion mit dem 
Bresenham Algorithmus ordentlich aufgebürstet habe. Daher ist die Line() 
Funktion auch die Default-Einstellung.


> Lässt sich die Anzeige "unmöglicher Werte" im Quick Measure Menü nicht
> unterbinden? Ich wundere/ ärgere mich jedes mal über eine
> Frequenzanzeige über 250MHz.

Die Funktion benutze ich zur Zeit nicht, da ich an anderen Baustellen 
zugange bin -> ich implementiere gerade die neue FFT. Das neue Grid ist 
schon fertig. Daher hoffe ich dass es sich verschmerzen läßt wenn das 
erstmal so bleibt.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Crazor

Schon den WELEC-Updater von Marcus als Not-Fallback probiert?

Hayo

von Blue F. (blueflash)


Lesenswert?

@all

Ich bin übrigens auf eine interessante Routine beim Trigger gestoßen. 
Das Triggerweitenregister wird mit dem - jetzt haltet Euch fest - 
Farbwert des Grids geladen!?!?

Fragt mich nicht was das soll, das kann nicht im Sinne der Funktion 
sein, daher werde ich das mal ändern. Ihr könnt das ja mal testen, 
theoretisch müßte sich die Triggerung ändern je nach Gridintensität.

Sachen gibts...

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,
Zusammenfassend kann man als Antwort auf meine Fragen also sagen:
1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das wird 
auch so bleiben.
2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht nur 
ich) da keinen Unterschied erkennen kann und man nie weiß in welcher 
Stellung man sich gerade befindet.
3.) Wird im Rahmen der neuen FFT bereinigt.

trotzdem noch frohes Schaffen,
brunowe

von Blue F. (blueflash)


Lesenswert?

Bruno We schrieb:
> Hallo Hayo,
> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:
> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das
> wird auch so bleiben.

Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass 
es Sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das 
natürlich. Wäre dann ein Punkt für die Wishlist.

> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht
> nur ich) da keinen Unterschied erkennen kann und man nie weiß in
> welcher Stellung man sich gerade befindet.

Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas 
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige 
oder ein Popup beim Umschalten?

> 3.) Wird im Rahmen der neuen FFT bereinigt.

Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der 
Zwischenzeit Hand an, dann baue ich das mit ein.

Hayo

von Blue F. (blueflash)


Lesenswert?

Bruno We schrieb:
> Hallo Hayo,
> Zusammenfassend kann man als Antwort auf meine Fragen also sagen:
> 1.) Für TB<50ns ist die Fkt "Vektor off" praktisch sinnlos- und das
> wird auch so bleiben.

Sinnlos finde ich das nicht. Wenn aber die Mehrheit der Meinung ist dass 
es sinnvoller ist nur die realen Stützwerte darzustellen ändere ich das 
natürlich. Wäre dann ein Punkt für die Wishlist.

> 2.) Die Fkt "Switch Drawing" bleibt so wie sie ist, auch wenn (nicht
> nur ich) da keinen Unterschied erkennen kann und man nie weiß in
> welcher Stellung man sich gerade befindet.

Also ich kann da schon einen deutlichen Unterschied sehen wenn ich etwas 
dichter rangehe. Was soll es denn sein? Eine dauerhafte Zustansanzeige 
oder ein Popup beim Umschalten?

> 3.) Wird im Rahmen der neuen FFT bereinigt.

Nein, komme ich nicht zu. Vielleicht legt einer der Anderen in der 
Zwischenzeit Hand an, dann baue ich das mit ein.

Hayo

von Kurt B. (kurt)


Lesenswert?

Hallo Hayo,
in ramloader.bat und flashloader.bat fehlt das -w

von branadic (Gast)


Lesenswert?

Hallo miteinander,

ich möchte an dieser Stelle erst einmal allen danken, die sich bisher an 
unserer Umfrage zum Gerät beteiligt haben.
Ich würde es begrüßen, wenn noch weitere ihre Gerätedaten schicken 
würden, unabhängig davon, ob der Flankentest durchgeführt wurde oder 
nicht.

Gern sind auch Leute gesehen, die ein W20xx ohne "A" haben. Diese sind 
scheinbar ganz in der Versenkung verschwunden, weil man von ihnen gar 
nichts mehr hört.
Um so mehr würde ich mich auch darüber freuen, wenn gerade diese Leute 
mal versuchen würden das veröffentlichte Slog-Design aufzuspielen und 
Aussagen darüber zu treffen, ob ihr Oszi damit läuft oder nicht.

Beste Grüße, branadic

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Hallo Hayo,
> in ramloader.bat und flashloader.bat fehlt das -w

Ups, da ist mir wohl eine alte Version reingerutscht - sorry

Hayo

von Crazor (Gast)


Lesenswert?

So, ich glaube das lag an der Temperatur. War 2 Stunden weg, nun hat's 
Flashen auf Anhieb geklappt. Zwar mit meinem alten Skript, aber bei der 
nächsten FW teste ich mal das neue ;)

Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je 
einen für den 1er, 2er und 5er-Bereich? oder muss man tatsächlich auch 
durch alle 1V/100mV/10mV-Bereiche durchgehen? Zumindest kommen bei mir 
für die verschiedenen Größenordnungen die gleichen Kalibrierwerte 
heraus. Oder sind das nicht die Werte, die beim Kanalwechsel als 
CH*_DAC_Offset angezeigt werden?

von Blue F. (blueflash)


Lesenswert?

Crazor schrieb:

> Hab aber mal ne Frage zum neuen DAC-Abgleich. Gibt es nur drei Werte, je
> einen für den 1er, 2er und 5er-Bereich?

Genau, und das jeweils für jeden Kanal

Hayo

von Johannes S. (demofreak)


Lesenswert?

Crazor schrieb:
> Writing line 004277 of 023377: .X............0 sec / 134 sec left
> Error: Timeout while reading response from DSO!
> Response was: 'S219815B3D34<#33><#13>
> '

Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn 
der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt 
reagieren und dann ginge es weiter.

/Hannes

von Odic X. (odic)


Lesenswert?

Hallo zusammen,

zwar besitze ich derzeit (noch) kein Welec- Scope, verfolge eure 
Entwicklungen aber bereits eine Weile. Leider bin ich beruflich im 
Moment ziemlich im Stress, als kleine "Entspannungsübung" habe ich aber 
mal einen Blick auf eure Veränderungen, genauer gesagt auf die neuen C- 
Routinen von Guido geworfen.

Vielleicht hilft euch ja folgender Denkanstoß weiter:

In ADC_ReadData() wird ein Puffer 4096 * 4 Byte gefüllt. In 
ADC_ProcessData() sollte dieser - wie ich vermute - in der inneren 
Schleife byteweise ausgelesen werden. Der Code dazu sieht folgendermaßen 
aus:

byte_data = *(chan_addr + i);    //load one byte

Mal abgesehen davon, daß hier ein (sinnvoller) cast fehlt (wie an 
anderen Stellen in der Funktion auch), könnte euch in dem Fall die 
Endianess einen Strich durch die Rechnung machen. Falls die Werte little 
endian im Speicher liegen, wird statt  0, 1, 2, 3, 4, 5, 6, 7, 8, ... 
die Reihenfolge  3, 2, 1, 0, 7, 6, 5, 4, ...  ausgelesen.


Beste Grüße,
odic

von Guido (Gast)


Lesenswert?

Hallo odic,

auf die Idee mit der Endianess bin ich auch schon gekommen und
habe das vorhin probiert.

Aber der Tip mit dem cast ist richtig gut, da werde ich nochmal
mit beiden Änderungen probieren müssen.

Gruß, Guido

von Odic X. (odic)


Lesenswert?

Was je nach µC (oder Softcore) auch noch problematisch ein könnte wäre 
das alignment. Vielleicht schaffst du es überhaupt nicht, mit einem 
ULONG-pointer auf die gewünschten Werte zuzugreifen...

Falls du statt dessen einen UBYTE-pointer verwendest und zudem noch eine 
andere Lösung für die Fallunterscheidung bzgl. highspeed findest, 
könntest du dir diese Problem und zudem auch die geschachtelten for()- 
Schleifen sparen...

Viele Erfolg noch,
odic

von michaelk (Gast)


Lesenswert?

So, hier meine Daten:

W2024A - HarwareRev 1C9.0L - 1.2BF0.68 - ausgeliefert mit SoftwareRev 
1.4
Bis auf Kanal 3 alle OK

von Martin H. (martinh)


Lesenswert?

@Hannes

Ich habe mir mal den Assembler des GERMS angeschaut (vom nios forum), 
das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen 
die zeile wo das '!' auftrat noch einmal zu senden.

Martin

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, zur Mitte der Woche (Mittag quasi) hier die 0.73 als 
Zwischenversion. Wesentliche Änderungen:

- Ich habe, was eigentlich schon lange mal fällig war, einen 
Testsignalgenerator eingebaut den Ihr im Utility-Menü findet. Auf allen 
vier Kanälen werden unterschiedliche Signale generiert. Damit kann man 
z.B. die Cursor prüfen und Ähnliches (und nicht ganz zuletzt auch die 
bald verfügbare FFT).

- Für die FFT habe ich schon einiges vorbereitet. Es gibt ein neues Grid 
mit einer Breite von 512 Pix und eine neue FFT-Graphikroutine. beides 
kann man sich schon ansehen, nur das noch kein echtes Spektrum 
ausgegeben wird. Als Demo ist es aber schon ganz ok denke ich.

Übrigens die Sache mit dem Triggerweitenregister geht noch weiter. 
Nachdem ich mich ja schon gewundert hatte, dass dieses Register mit der 
Gridintensität geladen wird (in SetupADC()), habe ich jetzt 
rausgefunden, dass über dieses Register tatsächlich die Gridhelligkeit 
(Gridfarbe) gesteuert wird. Schon etwas obskur oder?

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Odic X.,

danke für die Tips, die laufen ja schon auf Optimierung hinaus.
Eine Änderung von "chan_addr" auf "unsigned char" hat den erhofften
Erfolg gebracht. Probleme mit der Endianess gibt es wohl nicht,
ich bin aber nicht sicher, ob die ADC-Korrekturwerte richtig
zugeordnet werden. Das teste ich weiter, es ist aber recht schwer
zu erkennen.

Die doppelte Schleifenstruktur lasse ich vorerst, sie ist zwar
ganz sicher nicht optimal für die Geschwindigkeit, aber ich kann
damit sehr schnell kleine Tests durchführen. Zu diesem Zweck
mache ich mir ja die ganze Arbeit.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Achso Odic X.,

ganz vergessen: Möge die Macht mit dir sein. ;-))

Gruß, Guido

von Odic X. (odic)


Lesenswert?

Hallo Guido,

wußte gar nicht, daß mein Nick irgendeine Bedeutung hat...
Wieder was gelernt...

Ein paar Fragen noch zu der Funktion:

1.) Das Thema Averaging handelst du in folgenden Zeilen ab:

temp_int = temp_byte + ((byte_data - temp_byte)  >> averageval);
if (temp_int < 0) temp_int = 0;    //limit to byte ???
else if (temp_int > 255) temp_int = 255;
byte_data = temp_int;

Funktioniert das korrekt? Wenn ich es richtig verstehe, dürfte 
"byte_data - temp_byte" nur in jedem zweiten Fall das gewünschte 
Ergebnis bringen. Da averageval maximal 1 ist (soweit ich gesehen habe), 
sollte folgendes genügen:

byte_data = (unsigned char)(((unsigned short)byte_data + (unsigned 
short)temp_byte) >> 1);

2.) Die Zeile "temp_int = (zero << 1) - byte_data;" erschließt sich mir 
nicht ganz, kannst du mir da auf die Sprünge helfen?

3.) Was ist der Hintergrund der unterschiedlichen Ablage im Zielpuffer 
in Abhängigkeit von highspeed?

4.) Wie groß ist int in eurem core eigentlich?

5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche 
Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...

Fragen über Fragen.... ;-)

Beste Grüße und einen schönen Abend,
Odic

von Johannes S. (demofreak)


Lesenswert?

Martin H. schrieb:
> das '!' scheint ein checksum error zu sein. Ich glaube es sollte reichen
> die zeile wo das '!' auftrat noch einmal zu senden.

Alles klar, danke. Das werd ich mal schnell reinbauen.

/Hannes

von Blue F. (blueflash)


Lesenswert?

Odic X. schrieb:
> Hallo Guido,

> 4.) Wie groß ist int in eurem core eigentlich?

4 byte (d.h int = long int)

> 5.) Nutzt ihr noch irgendeine andere Kommunikationsplattform für solche
> Entwicklungsdetails? Dann müßte ich hier nicht den Thread zumüllen...

Das ist hier der Thread für genau diese Themen, Du bist hier schon ganz 
richtig. Für Hardwarelastige Angelegenheiten gibt es extra den 
Hardware-Thread.

Hayo

von Guido (Gast)


Lesenswert?

Hallo Odic X.,

1.) Da habe ich mich noch garnicht drum gekümmert, es passiert nichts
katastrophales wenn ich den Button drücke. ;-)

So wie ich das sehe, ist es Geschmacksache: deine Version wichtet den
alten Wert ebenso stark wie den neuen, die Originalversion wichtet
den neuen Wert nur halb so stark wie den alten Mittelwert.

2.) Zur Invertierung wird die Differenz zwischen Zerolevel und
Signal zum Zerolevel addiert. Ergibt insgesamt
2 * Zerolevel - Signal.

3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase
die Daten im FIFO unterschiedlich angeordnet sind. Von
READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL
werden sie dann so sortiert, dass sie für die Grafik immer in
gleicher Reihenfolge stehen.

4.) Größer als ein Byte, das reicht. ;-) (Hayo weiß das besser,
s.o.)

5.) Nö, das sind wir zu altmodisch zu. Es sollen ja auch alle
mitlesen und, so wie du auch, ihre Meinung äußern können. Je
mehr Leute sich das anschauen, umso leichter werden die Fehler
entdeckt.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> 3.) Großes Rätsel. Mir scheint, dass abhängig von der Timebase
> die Daten im FIFO unterschiedlich angeordnet sind. Von
> READADC_ALL2 werden sie noch 1:1 übertragen und in READADC_ALL
> werden sie dann so sortiert, dass sie für die Grafik immer in
> gleicher Reihenfolge stehen.

Ohne mir das Coding angesehen zu haben: Mit scheint es ganz logisch, 
dass abhängig von der Timebase die Reihenfolge variiert. Denn es kann 
gut sein dass je nach gewünschter Abtastrate 1, 2 oder 4 ADC verwendet 
werden. Entsprechend müssen die Daten dann in der richtigen Reihenfolge 
zusammengestellt werden.

Gruß Hayo

von odic (Gast)


Lesenswert?

Hallo Guido,

1.) So ich die bisherige Implementierung verstehe, wird die Differenz 
zwischen altem und neuem Wert halbiert und zum alten Wert hinzuaddiert. 
Dabei sind beide Werte gleich gewichtet. Am Ergebnis sollte sich also 
durch die andere Implementierung nichts ändern, nur an der Performance.

Wenn es bei byte_data < temp_byte tatsächlich nicht zu extremen Fehlern 
aufgrund des Überlaufs kommt, könnte ich mir höchstens vorstellen, dass 
die Differenz bereits in einem signed int gebildet wird und das shiften 
des Vorzeichens in diesem Fall ja kein Problem darstellt. Das 
funktioniert dann aber nur "zufällig" problemlos. ;-)

4.) Für die Funktion reichts, für die Performance heißt unnötig groß 
eben oft auch unnötig langsam. Außerdem möchte ich ja nicht, dass sich 
short diskriminiert fühlt... ;-)

Beste Grüße,
odic

von odic (Gast)


Lesenswert?

Das würde bedeuten, daß man sich die Weiterverarbeitung der Daten, die 
keine sind, sparen könnte. Das war auch der Hintergrund meiner Frage.

Wenn man an der Stelle eine pauschale Fallunterscheidung machen könnte, 
wären evtl. die vielen relativen Speicherzugriffe unnötig, die 16384 Mal 
ausgeführt werden...

von Guido (Gast)


Lesenswert?

Hallo odic,

1.) Du hast Recht, die Gewichtung ist in beiden Fällen gleich.
Manchmal hilft es doch, wenn man es sich arithmetisch hinschreibt.
Dann kann ich die Rechnung ja gleich im Byte machen und spare den
cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)

4.) Das ist völlig richtig und das habe ich auch vor, sobald ich
kapiere welche Werte tatsächlich zur Anzeige kommen. Ich vermute
grundsätzlich die ersten 4096, tatsächlich werden in dem Bereich
(Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss
ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> tatsächlich werden in dem Bereich
> (Timebase = 7) aber nur wenige hundert Pixel angezeigt. Das muss
> ich mal mit Hayo klären, der weiß das wahrscheinlich auswendig.

In den Programing Maps in der Timebasetabelle findest Du die benötigten 
Werte. Ich werde mal eine aktualisierte TB-Tabelle mit den neuen 
Rollmode-Werten rausgeben.

Hayo

von odic (Gast)


Lesenswert?

> Dann kann ich die Rechnung ja gleich im Byte machen und spare den
> cast (data_byte = (data_byte >> 1) + (temp_byte >> 1);)

Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst 
du den Übertrag, wenn die untersten beiden Bits 1 sind...

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

freue mich schon auf die FFT. Meinst du es ist möglich in allen 
Zeitbereichen die "Zoom"-Möglichkeit bereitzustellen? Z.B. im 
2us-Bereich ist es schon dürftig.

@Guido,
vielleicht läuft die ADC_readdata schneller, wenn du unten den 
Feldzugriff durch einen Byte-Zeiger austauscht?

Nur so eine Idee.

Gruß,
Stefan

von Guido (Gast)


Lesenswert?

Hallo odic,

>Wäre natürlich besonders elegant, geht aber leider nicht. So verlierst
>du den Übertrag, wenn die untersten beiden Bits 1 sind...

Da hast du natürlich auch wieder recht. Naja, im Moment komme ich
sowieso nicht dazu viel zu ändern (das wird ja da Einfachste, weil
ich es von oben kopieren kann. :-)  ).

@ Stefan: das erledigt sich von selbst, wenn ich nach odics
Vorschlag die Fallunterscheidung "richtig" mache. Besteht denn
Interesse an einer optimierten C-Funktion?

@ Hayo: Mit der Timebase-Table komme ich nicht gut klar, da mir
die Spaltenüberschriften zum Teil nichts sagen. Auch die Werte
in der Klammer bleiben mir schleierhaft.

Gruß, Guido

von Odic X. (odic)


Lesenswert?

Hallo Guido,

bevor du weiter Zeit investierst wäre es vielleicht mal interessant zu 
sehen, wie die Darstellung hochfrequenter Signale jetzt aussieht. Soweit 
ich verstanden habe war ja einer der Gründe für deine Mühe ein 
vermuteter Fehler in den ASM- Routinen....

Grüße,
odic

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

in Zeile 19362, hardware_t.cpp habe ich in der if-Abfrage das erste 
Argument (timebase<7) entfernt. Gibt es einen Grund, warum das da 
drinnen steht? Solange das da drinnen steht, trifft bei mir der Trigger 
nicht sauber bei größeren Zeitbasen. Und ohne klappts einwandfrei. 
Bemerke keinen Unterschied.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Hi Stefan,

wie so einiges in diesem Coding ist dieses Statement anscheinend 
ziemlich sinnbefreit. Wenn Du sagst dass es ohne besser läuft werde ich 
das mal einfach übernehmen. Falls es da Probleme geben sollte werden 
wohl schon entsprechende Rückmeldungen kommen. Ich hatte das bislang 
unverändert gelassen, da sich mir der Sinn nicht direkt erschlossen hat 
(zumal die Timebase 7 selbst überhaupt nicht verwendet wird).

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

So hier die aktualisierten Programming Maps.

Unter die Timebasetabelle hab ich für die bessere Verständlichkeit eine 
Legende geschrieben. In Kürze hier nochmal:

- Ta     = Abtastrate
- Factor = Schrittweite in der for() Schleife über die 16384 Werte,
           also der wievielte Wert tatsächlich verwendet wird.
           Bei den interpolierten TB ist dieser Wert zwar 1, aber
           da hier zusätzliche Werte eingefügt werden gibt es einen
           Pseudofaktor in Klammern
- Sample Depth = Anzahl der tatsächlich verwendeten Werte, ergibt sich
                 aus 16384 / Factor. Bei den interpolierten TB stehen
                 die vollen 16384 Werte zur Verfügung, allerdings auf
                 dem Bildschirm immer nur Gridbreite * Pseudofaktor
                 d.h. bei TB 5ns - 600 * 1/10 = 60 reale Werte
- TB-Idx = der Index mit dem die Registerwerte aus dem Array gelesen
           werden. Das entspricht dem Wert der Variablen
           Selected_Timebase.
- TB-Register = das sind die Werte die aus dem Array gelesen
                werden und ins TB-Register geschrieben werden.

Übrigens habe ich festgestellt, dass in Open Office die schraffierten 
Flächen (interpolierte TB) nicht dargestellt werden.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Hm, irgenwie wollte er die Datei nicht...

also hier nochmal

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Gibts doch nicht, ich nehme mal einen anderen Browser, scheint am 
Sicherheitszertifikat zu liegen.

Hayo

von Kurt B. (kurt)


Lesenswert?

Ich habe jetzt ein W2024A abzugeben.
Hardware 8C7.0H
Firmware 1.4

Das Gerät hatte einen Kurzschluss zwischen Main/Delayed und 
Mode/Coupling Taste den ich beseitigt habe. Außerdem wurde der JTAG 
0-Ohm Widerstand eingelötet.

Das Zubehör ist Orginalverpackt. Preis 350,50€ + 5,90€ Versand.

Bezahlung per Überweisung, PayPal möglich. Wenn der Käufer verspricht 
sich an der FPGA Entwicklung zu beteiligen, entfallen die Versandkosten!

von Michael W. (slackman)


Lesenswert?

Hi Kurt,
was willst Du mit so vielen Oszis? Einen Laden aufmachen ? ;-)

Im Ernst:
Ich hab einige Probleme den FPGA auszulesen (s.o.). Kannst Du mir einen 
Tipp geben? Für einen Moment bekomme ich die Treiber für den USB-Blaster 
installiert und wenn ich das Gerät vom USB nehme und wieder verbinde, 
geht nix mehr. Im Gerätemanager steht immer: Unbekanntes Gerät und ich 
bekomme keine Verbindung mehr hin, die Altera-Software findet dann 
natürlich keinen Programmer. Normalerweise habe ich keine Probleme 
solcher Art aber diesmal sind sie wirklich hartnäckig.

Irgendwas fehlt noch und ich krieg's nicht raus...

Meine Config: Windows XP SP3, Thinkpad T41 Laptop

Michel

von Kurt B. (kurt)


Lesenswert?

Hallo Michael,
hast du schon ein anderes USB Kabel probiert?

Wieso viele Oszis? Ein 2022A und ein 2024A. Das zweite 2024A stammt aus 
einem Deal mit Wittig und wird jetzt verkauft. ;-)

von Blue F. (blueflash)


Lesenswert?

@Kurt

Ein faires Angebot, davon kosten ja allein schon die 200 MHz Tastköpfe 
80 Euronen. Wenn ich das eher gewußt hätte, wären wir ins Geschäft 
gekommen. Jetzt hab ich ja das 2014A schon seit ein paar Wochen und kann 
es nicht mehr zurückschicken.

By the way, hatte nicht vor einiger Zeit ein netter WELEC-Besitzer 
angeboten praktische Taschen herzustellen? Da hab ich seit dem nichts 
mehr von gehört.

Hayo

von Kurt B. (kurt)


Lesenswert?

Die Zusage dass ich das Gerät behalten kann habe ich erst vorgestern 
bekommen.

von Crazor (Gast)


Lesenswert?

@Kurt: Die Zusage kann ich geben ;) Hat jemand Interesse an meinem 
2012A?

von Michael W. (slackman)


Lesenswert?

@ Hayo

Wegen der Taschen:
Ich such' immer noch ein Muster im Netz. Wenn Ihr Vorschläge habt: Immer 
raus damit. Ich wollte eigentlich nur eine oder zwei Versionen nähen und 
nicht soviel rumexperimentieren.

Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach 
für das Scope, oben mit Reißverschluß und an einer Längsseite zwei 
aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die 
Schmalseite Verbindungen/Ösen für einen Schultergurt?

Michel

von Crazor (Gast)


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

Michael W. schrieb:

> Daher jetzt konkret die Frage: Was soll denn alles dran sein? Hauptfach
> für das Scope, oben mit Reißverschluß und an einer Längsseite zwei
> aufgenähte Taschen mit Klettverschluß für die Kabellage. Über die
> Schmalseite Verbindungen/Ösen für einen Schultergurt?

Das wäre ja schon mehr als ich zu hoffen wagte - echter Luxus quasi. Das 
würde mir schon gefallen!

Wenn ich da nicht jemandem eine Tasche "wegschnappe" würde ich sogar 
zwei nehmen.

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

danke für die Legende. Bei mir sieht es unter OpenOffice
eigentlich ganz gut aus. Jetzt verstehe ich das besser und
kann schon erste Schlüsse ziehen. Ganz offensichtlich kann
die Zeitbasis auf alle benötigten Teilfaktoren eingestellt
werden. Dies wird aber nicht immer so gemacht und stattdessen
z.T. auf Samplingtiefe verzichtet. D.h., es muss bei der
Entwicklung schon klar gewesen sein. dass es Probleme mit
der Kombination der ADCs gibt. Diese wurde nur dort eingesetzt,
wo es wg. Geschwindigkeit unausweichlich war.

@ odic: Klar will ich die Fehler finden. Ich habe auch schon
einiges probiert (das geht gut nebenher ;-) )aber bisher ohne
Erfolg. Ich werde jetzt erstmal die innere for-Schleife
auflösen, dann kann ich gezielt ADCs ausblenden. Mal sehen.

Gruß, Guido

von Kurt B. (kurt)


Lesenswert?

@Crazor,
kann ich das schon als konkretes Interesse deuten? Wenn ja, schicke mir 
bitte eine PN damit wir die Details klären können.

Mfg,
Kurt

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi Folks,

für die HF-Freaks hier schon mal ein kleiner Vorgeschmack auf die 
morgige Wochenend-beta 0.74.

Was Ihr seht ist ein 64 MHz Signal von einem Quarzoszillator an einem 
10:1 Tastkopf. Achtet mal auf die Zeitbasis :-)

Zur Zeit arbeite ich noch an einer besseren Interpolation, die nicht so 
stufig ist.

Guats Nächtle

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

Timebase = 0 ist also auch vergeben? ;-)

Wie sieht das mit 1 V/div aus?

Gespanntes Abwarten, Guido

von Blue F. (blueflash)


Lesenswert?

Das möchtest Du nicht sehen...

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

macht es ernsthaft Sinn 24 Werte mit Interpolation auf dem Bildschirm 
anzuzeigen? Was man da sehen kann ist doch kaum noch aussagekräftig 
oder? Ich würd es verstehen, wenn man mit 5GS/s daherkommen würde, dann 
kann man auch in den ps-Bereich vorstoßen. Verstehen würd ich es auch, 
wenn man nicht real-time, sondern equivalent-time darstellt.

(http://www2.tek.com/cmswpt/tidetails.lotr?ct=TI&cs=Application+Note&ci=14295&lc=EN)

Wie schaut es eigentlich mit der Interpolation aus? Momentan wird doch 
noch linear interpoliert, wenn ich das richtig sehe. Sollte nicht die 
Sin(x)/x eines der nächsten Ziele sein?
Möglicherweise auch die Wahl zwischen keiner, linear und Sin(x)/x im 
Display-Menu. Nur so als Vorschlag.

Beste Grüße, branadic

von Blue F. (blueflash)


Lesenswert?

Also 24 Werte zu interpolieren ist noch im völlig normalen Bereich und 
wird von anderen DSO-Herstellern auch angeboten. Zur Zeit verwende ich 
eine sehr einfache an die lineare angenäherte Interpolation, die jedoch 
bei größeren deltas schlechter wird und Stufen erzeugt. Daher habe ich 
sie jetzt durch eine echte Linearinterpolation (nach Bresenham - hatten 
wir ja schon in der Line() Funktion) ersetzt - sieht erheblich besser 
aus jetzt.

Die Sin(x)/x macht erst Sinn bei erheblich weniger Abtastwerten, da dann 
ein natürlicherer Verlauf ohne Ecken interpoliert wird - mit einem 
erheblichen Nachteil:

Die Sin(x)/x Berechnung ist sehr Zeitaufwändig, d.h. die Signalausgabe 
würde extrem verlangsamt.

Du siehst ich hab mir da auch schon Gedanken in diese Richtung gemacht, 
aber die Linearinterpolation ist für diese kleinen Deltas der beste 
Kompromiss zwischen akkurater Darstellung und Bildwiederholrate.

Ich stelle gleich mal ein Bild mit dem Signal von Gestern ein allerdings 
mit neuer Interpolation, dann hat man den direkten Vergleich.

Hayo

von Cra Z. (crazor)


Lesenswert?

Also ich finde Interpolation in jedem Fall legitim, da es dem Auge dann 
in jedem Fall erleichtert wird, den Signalverlauf schnell zu erfassen. 
Punktwolken sind da viel schwieriger ;)

Natürlich sollte jeder wissen, was das Gerät gerade macht und wie viel 
von den Daten denn nun echt und was interpoliert ist, aber evtl. wäre es 
sinnvoll, die tatsächlichen Messwerte z.B. heller darzustellen als die 
interpolierten.

Bzgl. der sinc-Interpolation (und auch für den Bresenham) suche ich noch 
eine anständige Beschreibung der Mathematik dahinter, habe bisher 
zumindest im Netz immer nur Beispielimplementierungen gefunden. Infos 
über günstige Hardware-Realisierungen wären natürlich auch toll, aber 
die kann ich notfalls auch selbst ersinnen ;) Ich glaube ich muss mal 
wieder in die Uni-Bib gehen...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

Crazor schrieb:
> aber evtl. wäre es sinnvoll, die tatsächlichen Messwerte z.B. heller
> darzustellen als die interpolierten.

Na also... da haben wir's wieder! Hatte ich das nicht schon vor 4-5 
Monaten angeregt? Vielleicht findet sich ja doch noch eine Möglichkeit 
der Umsetzung?

Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem 
Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen 
FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...


Gruß, brunowe

von Guido (Gast)


Lesenswert?

Hallo,

uih, dann muss ich mich irgendwann auch noch mit dem Altera-Kram
auseinandersetzen.

@ Hayo: der 2-ns-Bereich ist natürlich immer sinnvoll. Auch wenn
er ev. keine weitere Information bietet, erlechtert er unter
Umständen das Kästchen-Zählen. Lass dich nicht beirren.

Gruß, Guido

von branadic (Gast)


Lesenswert?

Nicht falsch verstehen, wollt den Hayo weder bekehren noch beirren. Als 
Wissenschaftler liegt es in meiner Natur erst einmal alles in Frage zu 
stellen, that's it.

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Ist auch völlig korrekt. Man muß nicht alles was machbar ist auch
umsetzen. Die Fragen nach Sinn und Unsinn ist durchaus gerechtfertigt
und stehe dazu auch gerne Rede und Antwort. Es wäre auch nicht das erste
Mal das man sich da in etwas verrennt, das keinen Sinn macht. In diesem
Fall muß ich aber sagen, das es wirklich gut aussieht und hilfreich ist.
Auch die anderen interpolierten Bereiche profitieren von der neuen
Interpolationsroutine, sieht schon deutlich besser aus.

Foto kommt gleich.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier mal das bekannte 64 MHz Signal von gestern - alle Einstellungen 
gleich.

Ich finde es ist schon ein deutlicher Unterschied.

So und im nächsten...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...für Guido das Ganze bei 100mV an 1/10 Tastkopf.

Man kann deutlich den zusätzlichen Schwinger erkennen der anscheinend 
von der Eingangsstufe erzeugt wird.

Hayo

von Cra Z. (crazor)


Lesenswert?

Bruno We schrieb:
> Doch noch was Anderes: Hans und Crazor konnten das Problem in unserem
> Softcore endlich lösen. Das bedeutet das die Weiterentwicklung des neuen
> FPGA Design jetzt in großen Schritten vorwärts gehen kann....FREUDE...

Ok, eigentlich wollte ich die Ankündigung zusammen mit der Herausgabe 
eines neuen Testdesigns machen, aber wenn's nun schonmal soweit ist, 
vielleicht noch ein paar Informationen:

Das Problem war ja, dass die ZPU, die wir als Softcore einsetzen, 
partout nicht aus dem SRAM heraus booten wollte. Lesen/Schreiben bei 
Programmausführung aus dem FPGA-internen Blockram war allerdings OK. 
Letztlich hat Hans durch viel Simulation einen Bug in der ZPU entdeckt, 
der bei Back-To-Back-Writes auf langsamere Speicher zum Überspringen von 
Instruktionen führte. Der Bug ist mittlerweile behoben.

Aktuell gibts also das altbekannte Slog-Design mit einem Open Source 
Softcore (statt des NIOS, den wir ja nicht ohne weiteres nutzen dürfen), 
der die Benutzerschnittstelle implementiert. Die Signalerfassung und 
-darstellung erfolgt also nach wie vor ausschließlich in Hardware, der 
Softcore legt quasi die Benutzerschnittstelle mittels eines 
Zeichengenerators oben drüber. Der Prozessor führt anfangs einen 
Bootloader ähnlich dem GERMSmonitor aus, der es erlaubt, die Software 
aktuell per serieller Schnittstelle zu übertragen (später wird die 
Software dann aus dem Flash geladen werden können, aber den rühren wir 
bisher noch nicht an).

Da die Softwareentwicklung bis zur Behebung des Bugs nicht wirklich 
voranschreiten konnte (so ein FPGA hat verdammt wenig Blockram), habe 
ich in der Zwischenzeit große Teile der Signalerfassung neu geschrieben, 
da Slogs Code doch etwas schwer nachvollziehbar war (hauptsächlich die 
Signalbenennung war sehr unintuitiv, was ich mal auf die Sprachbarriere 
schiebe, außerdem keine Hinweise über Unzulänglichkeiten der aktuellen 
Implementierung usw.). Die Signaldarstellung liefert nun 
nachvollziehbare Time Bases, der Downsampler ist neu geschrieben und ein 
neuer Trigger ist im Ansatz vorhanden.

Ich hoffe, in den nächsten Tagen eine Programmierdatei zum "Spielen" 
veröffentlichen zu können, damit man sich ein Bild vom aktuellen Zustand 
machen kann.

Viele Grüße

Daniel

von Kurt B. (kurt)


Lesenswert?

Das 2024 ist schon verkauft. Da war der Preis wohl doch zu niedrig. ;-)

von Guido (Gast)


Lesenswert?

>Da war der Preis wohl doch zu niedrig. ;-)

Sehr ärgerlich. :-))

Hast du etwa eine Geschäftsidee entwickelt?

Gruß, Guido

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, hier ist sie die Wochenend Beta.

Diesmal habe ich viele kleine Baustellen beackert. Gleich vorweg, die 
FFT ist noch nicht dabei, ich wollte erstmal weiter aufräumen.

Dafür sind für Bruno gleich zwei Sachen dabei ;-)

- bei der Umschaltung des Zeichenmodus wird jetzt ein Popup angezeigt
- bei interpolierten TB werden im Pixelmodus die interpolierten Werte 
unterdrückt und nur die echten Werte angezeigt

Weiterhin gibt es Folgendes:

- die neue TB 2ns (wie angekündigt)
- ich habe die Steuertabellen für den Triggeroffset korrigiert. Für TB 
5nS und 2nS wird jetzt korrekt getriggert
- geändertes Scrollverhalten für Pretrigger und Memorybrowsing für 
komfortableres Bedienung (sonst kurbelt man sich ja nen Wolf)

Spaßeshalber hatte ich bei der Interpolation mal die alte 
FIR-Interpolation von vorher eingebaut - gruselig. Könnt Ihr ja mal mit 
der originalen FW vergleichen :-)))

Viel Spass

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja, einen hab ich noch,

für den Testsignalgenerator habe ich unterstützung für Signalkopplung
(AC/DC/GND) eingebaut.

Hayo

von Blue F. (blueflash)


Lesenswert?

Oh, ich sehe gerade es ist mir noch ein kleiner Bug im 
Testsignalgenerator auf Kanal 3+4 durchgerutscht. Kommt weil ich auf dem 
2022A getestet habe. Ich reiche morgen ein Update nach.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok Fehler schon gefunden, war nur ein falsch gesetztes Semikolon.

Daher jetzt schon das Update

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

kurze Frage, welchen Nutzen haben die Testsignale eigentlich? Sind ja 
keine Signale, die am ADC anliegen. Daher die Frage.

Gruß, branadic

von branadic (Gast)


Lesenswert?

Noch eine kurze Meldung Hayo...
Die ADC werden aktuell offensichtlich sequentiell ausgelesen, weswegen 
es eine zeitliche Verschiebung zwischen den Kanälen gibt, legt man an 
alle Kanäle das gleiche Signal. Hier wäre eine zeitliche Kompensation 
notwendig. Angenommen man schaut sich verschiedene Signale einer 
Testbench an, dann sollte allen der gleiche zeitliche Nullpunkt zugrunde 
liegen, um eine Aussage treffen zu können. Ließe sich das in einer 
zukünftigen FW hinzufügen?
Hier hat das neue FPGA-Design klare Vorteile, da gibt es "keine" 
zeitliche Verschiebung zwischen den Kanälen, da die ADC der einzelnen 
Kanäle parallel ausgelesen werden.

Beste Grüße und guten Morgen ;)
branadic

von Michael W. (slackman)


Lesenswert?

Oh
und ich dachte schon, ich bin der Einzige, dem sich der Nutzen der 
Testsignale nicht schließt. Kann man ja auch gleich ein paar Animationen 
zeigen. Praktischer fände ich eine Selbstdiagnose oder einen 
automatischen Nullinien/ADC/DAC Abgleich durch alle Bereiche...

Heute habe ich endlich auch meinen USB-Seriell Adapter zum Flaschen zum 
Laufen gebracht: Ich hatte das serielle Kabel dazwischen immer 
weggelassen. So kann's kommen ;-)

Die Signale sehen jetzt wirklich deutlich besser aus, gerade in den 
starken Vergrößerungen ... Die Firmware macht wirklich große 
Fortschritte.

Jetzt muss ich nur noch in den FPGA kommen...

Michel

von Blue F. (blueflash)


Lesenswert?

Zum Testsignal:

Ich hatte ja schon mal geschrieben wofür man das gebrauchen kann. Es 
handelt sich nicht nur um bunte Bildchen, sondern an der Stelle wo sonst 
die Signale aus dem ADC-Register gelesen werden, generiert der 
Testsignalgenerator Ersatzwerte. Für den Rest der Firmware ist es also 
genauso als wäre das Signal aus dem ADC ausgelesen worden. Man kann 
damit z.B die Cursorfunktion testen, die QM-Funktion, die 
Autoscalefunktion, die Übertragung zum PC und so weiter. Unter Anderem 
hatte ich den Generator auch geschrieben um die FFT zu Testen, da ein 
sauberes Testsignal die Möglichkeit gibt genau zu kontrollieren ob die 
FFT korrekt arbeitet. Beim direkten Vergleich zwischen Testsignal und 
realem Signal kann man z.B. sehen ob man am ADC ein Interleaving-Problem 
hat.


Zum Auslesen der ADC:

Das die ADC zeitlich versetzt ausgelesen werden ist völlig egal. Wichtig 
ist nur, dass sie parallel die Signale abtasten. Wenn dann der AQU_READY 
Interupt ausgelöst wird ist das quasi wie ein Schnappschuß dieses 
Zeitpunkts der in den ADC-Puffern liegt. Ob die dann gleichzeitig 
ausgelesen werden oder nicht ist dann unerheblich, ein gemeinsames 
Signal liegt dann auf jeden Fall im gleichen Nullpunkt.

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

danke für deine Erklärung zu beiden Themen. Wie aber erklärst du dir 
dann den zeitlichen Versatz zwischen den Kanälen, der ja nicht ganz 
unerheblich ist? Oder bin ich der einzige bei dem das so ist?

Gruß, branadic

von Blue F. (blueflash)


Lesenswert?

Also der zeitliche Versatz ist mir noch nicht aufgefallen. Müßte ich mir
mal genauer ansehen, gebe aber zu dass ich da außer bei der
XY-Darstellung noch kein so großes Augenmerk drauf gelegt habe.

Sollte es tatsächlich einen zeitlichen Versatz geben, so ist das jedoch
nicht auf das zeitlich versetzte Auslesen zurückzuführen, vielmehr gibt
es hier zwei andere Erklärungen:

- die Signalwerte werden in der falschen Reihenfolge aus dem Buffer
gelesen

- die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch
sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen
 -> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.
Wenn das nicht richtig umgesetzt wurde hat man natürlich einen
zeitlichen Versatz - das wäre allerdings ziemlich übel.

Gruß Hayo

von Cra Z. (crazor)


Lesenswert?

Hayo W. schrieb:
> - die Hardwareansteuerung der ADC ist falsch ausgelegt. Theoretisch
> sollten jeweils die korrespondierenden ADC auf einer Taktflanke liegen
>  -> (Channel.ADC) 1.1/2.1/3.1/4.1 und 1.2/2.2/3.2/4.2 usw.
> Wenn das nicht richtig umgesetzt wurde hat man natürlich einen
> zeitlichen Versatz - das wäre allerdings ziemlich übel.

Das wäre garnicht so übel wie es scheint. Von nichtdeterministischem 
Verhalten mal abgesehen wäre so der Fehler ein für alle Mal bestimmbar 
und aus der Welt schaffbar. Wenn es am Auslesecode-Timing läge, dann 
müsste man den Versatz nach jeder Änderung der Ausleseroutinen erneut 
anpassen.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

also Hayo es gibt definitiv einen zeitl. Versatz. Bei meinem Scope 
beträgt dieser delay ziemlich genau 7ns. Ch2 ist immer um diesen Versatz 
"später dran", unabhängig von der gewählten TB und vom Signal. Man kann 
diesen Versatz sogar mit dem internen 1kHz Rechteck entdecken, wobei da 
evtl. unterschiedl. Probes zu Verfälschungen führen (untersch. 
Flankensteilheit).
Bei höherfrequenten Signalen ist dieser delay natürl. noch 
augenfälliger.
wäre interessant ob dieser delay bei jedem 7ns beträgt, oder ob's da 
Unterschiede gibt. Evtl. können wir da auch einen SW- Abgleich dafür 
basteln, bzw. diesen delay von vornherein rausrechnen.
Im neuen VHDL Design tritt dieser delay nicht auf. Also liegt es wohl 
entweder am Welec VHDL, oder doch an der SW.

Gruß, brunowe

von Stefan E. (stefan_e)


Lesenswert?

Bei mir hängt Ch2 immer ca 9ns hinten dran. Bei Vertauschen der Probes 
kommts das gleiche raus.

Gruß,
Stefan

von Jürgen (Gast)


Lesenswert?

Hallo zusammen,

Ch1 ist ca. 10ns voraus, Ch2-Ch4 sind etwa gleichauf.

Gruß Jürgen

von Guido (Gast)


Lesenswert?

No sorry,

so genau kann ich nicht messen. Schon 1 m Kabel bedeutet ja
ca. 6 ns Verzögerung.

@ Hayo: Was ganz interessantes: die Grafik bremst garnicht so
stark wie befürchtet. Bei meinen Spielereien habe ich durch
Programmierfehler schon knapp Screens/s geschafft. Ich glaube
ich werde mal timebase in READADC_ALL genauer auswerten.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Nachtrag: knapp 20 Screens/s.

Uups, Guido

von Jürgen (Gast)


Lesenswert?

@Guido

Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)

@Hayo

Hatte gestern irgendwie Probleme mit dem Ch3 und der 
Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW 
gesucht und in der Funktion "Hardware::SetSwitches(..)" eine 
Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die 
KOmmentare? Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon 
"tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!

Gruß,Jürgen

von Kristian T. (krissy1983)


Lesenswert?

Hallo,

ich habe mal die Kanäle meines W2014A mit den mitgelieferten Tastköpfen 
und den Signalen eines 10 MHz und eines 25 MHz Quarzoszillators 
vergliechen. Bei mir ist Kanal 2 8ns hinter Kanal 1, Kanal 2 4 ns hinter 
Kanal 3 und Kanal 4 3 ns hinter Kanal 3.
Auch das Vertauschen der Tastköpfe hat nichts geändert.

Gruß Kristian

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

> Na wenigstens sind die ausgelieferten Tastkopfkabel gleich lang! ;-)

DANKE Jürgen - das war Guido offensichtlich nicht bewusst ,-)

Man kann also auf jeden Fall nen Trend erkennen. Scheint also überall 
so, das Ch2 ca. 6- 10ns hinter Ch1 liegt. (und ggf. Ch4 hinter Ch 3)
Mal sehen was wir diesbzgl. noch für Erkenntnisse gewinnen (VHDL oder 
SW- Problem)

Gruß, brunowe

von Guido (Gast)


Lesenswert?

Hallo,

ich fürchte, ich muss noch deutlicher werden: Bei einem
Eingangswiderstand des Tastkopfes von 1 MOhm diskutiert ihr
über eine Kapazität von ca. 10 fF. Macht das wirklich Sinn?

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Hmm,

wenn ich das hier so lese (ohne selbst nachgemessen zu haben - muß ich
mal nachholen) dann scheint es ja tatsächlich ein Timingproblem bei der
ADC-Ansteuerung zu geben, oder unser WELEC-Programmierer hat einen
kapitalen Bock beim Sortieren der ADC-Werte geschossen (also einer von
den Jungs hat sich da jedenfalls nicht mit Ruhm bekleckert).

Eigentlich müßte das ja im XY-Modus zu sehen sein, denn der
Laufzeitunterschied verursacht ja eine Phasenverschiebung die sich dann
als Oval (bei Sinus) zeigen müßte wenn man auf beide Eingänge das
gleiche Signal legt - schon ausprobiert?

Zur Zeit kämpfe ich selbst mit einem Stack-Overflow oder einem
Buffer-Overflow in der FFT und bin deswegen nicht so richtig in Stimmung
das ADC-Timing zu prüfen, aber interessieren würde es mich ja schon.

Übrigens wenn die FFT durchläuft sieht es schon richtig gut aus, war
zwischendurch schon mal am überlegen ob ich einen Screenshot einwerfe -
mußte dann aber zugunsten eines Besuches beim Griechen verzichten.

Gruß

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

nein Guido, wir sprechen nicht von 10fF. Wir sprechen von einem delay 
von 7ns welche uns ein tiefer gehendes Problem (wo auch immer das 
steckt) offenbart. Da es keinen technologischen Grund für so eine 
Verschiebung gibt (unser VHDL zeigt das es auch ohne delay geht), 
sollten wir doch versuchen dieses Problem auszumerzen. Evtl. erledigt 
sich damit auch noch das Ein oder Andere?  Die Oszillation bei höheren 
Frequenzen z.B.- das konnte ich ja im VHDL auch nicht nachweisen.

Gruß, brunowe

von Martin H. (martinh)


Lesenswert?

Hallo,

Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo 
nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe 
ist der Versatz weg! Scheint also ein SW problem zu sein.

Martin

von Cra Z. (crazor)


Lesenswert?

> Auch ich kann den Versatz von ca. 8..10ns mit der SW von hayo
> nachvollziehen (Tastkopf unabhängig). Wenn ich zu der FW 1.3 zurück gehe
> ist der Versatz weg! Scheint also ein SW problem zu sein.

Ich meine mich auch zu erinnern, dass ich mal (Google Sprachtools sei 
dank) im russischen Forum eine Diskussion über Phasenverschiebungen 
zwischen den Kanälen gesehen habe. Die Quintessenz damals war dass es 
zwischen 1+2 und 3+4 keine gibt, aber zwischen 2+3 ein kleiner 
"Restoffset" vorhanden war. Vermutlich ist also in der Originalfirmware 
wirklich schon eine Kompensation der Verzögerungen drin gewesen und 
(möglicherweise im Zuge der Umstellung auf die in C geschriebenen 
ADC-Routinen?) verloren gegangen.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Da gibt es jetzt wieder mehrere Möglichkeiten:

- Stefan hatte die Assemblerroutinen wegen der Invertierung und der 
Averageberechnung geändert. Die Änderungen sind seit der 0.63 aktiv.
Wäre interessant ob bei den davor liegenden FW-Versionen auch dieser 
Versatz auftritt.

- Eine weitere Möglichkeit ist die Grafikroutine. Ich hatte ja die 
Graphikroutinen komplett neu geschrieben, weil das Ganze ein so kruder 
Haufen unüberschaubarer Codeaneinanderreihungen war, dass eine Wartung 
völlig unmöglich war. Es ist durchaus möglich, dass da versteckt hart 
codiert eine Korrektur drin war die den zeitlichen Versatz wieder 
geradegebogen hat (von hinten durch die Brust ins Auge quasi).
Auch das läßt sich prüfen indem man eine Uraltversion testet. Ich hab 
mal die 0.17 angehängt, da sind noch die alten Routinen aktiv.


Ich bin z.Zt. in der Firma und komme nicht zum Testen, aber vielleicht 
hat ja einer von Euch die Gelegenheit.

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Ich glaube nicht, dass es mit den Assemblerroutinen zu tun hat. Außerdem 
ist dort auch nichts versteckt, was einen Delay erzeugt oder ausgleicht.

Ich tippe auf einen Bugfix, der ab der 1.3er FW das Delay ausgleicht. Da 
wir ja von der 1.2er ausgehen wird er da wohl noch nicht enthalten sein. 
Ist eigentlich gerade jemand dabei die "Quick Measurment"-Funktionen zu 
überarbeiten? Sonst schau ich da mal drüber.

Stefan

von Martin H. (martinh)


Lesenswert?

@hayo

Vermutlich hat Stefan recht, leider hängt die 0.17er Version bei mir 
(W2012A) aber bei der 0.48 ist der Versatz schon drin.

Martin

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

In der 0.48 sind auch schon die neuen Grafikroutinen aktiv. Zwischen 
0.28 und 0.33 habe ich die wesentlichen Routinen umgestellt.

Anbei die Ausgangsversion 1.2.AF von Andreas Fellnhofer. Damit könnte 
man nochmal testen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Grundsätzlich besteht natürlich die Möglichkeit eine solche Korrektur in 
unsere Open Source FW mit einzubauen. Dazu müßte man das aber genauer 
untersuchen und folgendes klären:

- welche Kanäle sind betroffen?
- ist es immer der gleiche Laufzeitunterschied oder variiert das von
  Gerät zu Gerät?
- gibt es Unterschiede zwischen den 2 Kanalgeräten und den 4 
Kanalgeräten?


@Stefan

Also ich komme erstmal noch nicht dazu die QM und Cursorroutinen zu 
korrigieren, da ich erstmal die FFT fertigmachen möchte bevor ich mich 
an die Bugliste mache.

Außerdem wollte ich dann die Cursor gleich für die FFT erweitern.

Wenn Du da weiterkommst ist das doch schon mal ein großer Fortschritt.

Hayo

von Blue F. (blueflash)


Lesenswert?

Jürgen schrieb:

> Hatte gestern irgendwie Probleme mit dem Ch3 und der
> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW
> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine
> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die
> KOmmentare?

Ja solche Unregelmäßigkeiten finden sich in der originalen Source zu 
Hauf. Da scheint an etlichen Stellen einfach mit verschiedenen Werten 
experimentiert worden zu sein und dann wurde das einfach vergessen.

> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon
> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!

Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her 
damit.


Hayo

von Martin H. (martinh)


Lesenswert?

@hayo

Ok die Version geht (kein Vergleich zu den fortschritten die du gemacht 
hast!)
In dieser Version ist bei mir der Versatz besser (Kanal 2 ca. 2ns 
voraus, vorher war Kanal 2 ca. 8..10ns hinterher!)
Vermutlich wurde da wirklich was in den Grafik-Routinen korrigiert.

Martin

von Blue F. (blueflash)


Lesenswert?

Eine Korrektur würde sich dann ja als Ergänzung für Guidos C-Routinen 
anbieten. Hier müßte dann abhängig von der Time-base der Array-Index des 
betroffenen Kanals mit einem Offset versehen werden.

Bei 8nS wäre das in den 1GSa/S Bereichen ein Index-Offset von 8, in den 
500MSa/S Bereichen ein Index-Offset von 4 usw.


Gruß Hayo

von branadic (Gast)


Lesenswert?

Hallo liebe Gemeinde,

auch wenn es ein kurzer Themenbruch ist, so denk ich doch, dass er hier 
am besten platziert ist.
Ich hatte heute ein sehr informativess Gespräch mit einem Mitarbeiter 
von Altera. Die "NIOS-Lizenzfrage" ist geklärt. Demnach gibt es seitens 
Altera keinen Grund dafür, dass Wittig/Welec seine FPGA-Sourcen nicht 
veröffentlicht. Der Embedded Softcore liegt nicht in Form von Sourcen, 
sondern einer Netlist vor und ist damit für uns quasi nicht brauchbar.
Einziger Grund die Sourcen nicht zu veröffentlichen besteht also seitens 
Welec selbst, dass sie ihren Sourcecode schlichtweg nicht hergeben 
möchten.

Weitere Einzelheiten des Gespräches kläre ich dann in den nächsten Tagen 
mit Bruno und Daniel.

Beste Grüße,
branadic

von Blue F. (blueflash)


Lesenswert?

Wenn wir das FPGA-Design von WELEC bekämen hätte das natürlich den 
Vorteil, das wir das vorhandene Design in kleinen Schritten verändern 
könnten und dann auch gleich FW-Seitig nachziehen könnten. Dann hätten 
wir nicht so einen abrupten Übergang und es gäbe für die geänderten 
FPGA-Designs auch immer eine passende FW.

Das könnte interessant werden, aus zwei Richtungen parallel zu 
entwickeln.


Gruß Hayo

von Kurt B. (kurt)


Lesenswert?

Hat denn schon jemand bei Welec nachgefragt? Soll ich das übernehmen?

von Stefan (Gast)


Lesenswert?

Brunowe wollte heute fragen...

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

Das war wie ein Déjà-vu, ich hab heute 5 mal versucht einen von WELEC zu 
erreichen, ohne Erfolg....
Ich bleib weiter dran.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Die sind bestimmt alle in Italien...   ;-)

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hier nochmal schnell vor dem Schlafen gehen ein kurzer Blick auf den 
Zwischenstand:

Was Ihr seht ist das Spektrum eines 500Hz Rechtecksignals bei einer 
Abtastung von 25 MSa/S. Die Gridbreite entspricht der halben Abtastrate 
- d.h. ganz links ist der Gleichanteil 0 Hz (DC-Offset) und ganz Rechts 
die Frequenz 12,5 MHz.

Das ganze bei Vollaussteuerung im Zeitbereich und einer 512 Punkte FFT.

Im nächsten Bild...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...seht Ihr die gleiche Situation mit einer 1024er FFT. Man sieht schon 
die etwas feinere Auflösung.

Die Routine habe ich damals für ein System mit mathematischem 
Coprozessor geschrieben. Die vielen Fließkommaberechnungen waren da kein 
Problem. Auf unserem NIOS liegt die Wiederholrate z.Zt. bei 2 - 4 S pro 
FFT.

Da muß ich mal die Berechnungen auf Integer umstellen, das dürfte 
einiges bringen.

Gruß Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

aus dem Bauch raus würde ich sagen das ist sogar schon
gefenstert?  Ob die vertikale Skalierung linear oder
Logarithmisch ist, erkenne ich so schnell nicht.

Auf alle Fälle ist es schön anzusehen.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

Das Fenster hatte ich für diese Bilder abgeschaltet, da das von WELEC in 
der tc_vars.cpp definierte Fenster Störlinien verürsacht. Ich werde da 
meine eigenen Fensterdefinitionen einbauen (habe da noch von meinem 
damaligen Projekt etliche 1024er Fensterdefinitionen).

Die Darstellung ist linear, die logarithmische Darstellung erkennt man 
daran dass die Linien nicht so schmal sind, sondern eher bauchige 
Buckel.

Es gibt allerdings noch viele Details die ich noch programmieren muß 
bevor das Ganze rund genug für die nächste Beta ist. Ich halte Euch auf 
dem Laufenden.

Wie sieht es denn an den anderen Fronten aus?

@Guido

Was machen die C-Routinen? Es sieht so aus, dass wir eine Korrektur für 
die Signalverschiebung einbauen müssen, da böte es sich an das mit in 
die C-Routinen einfließen zu lassen.


@Jürgen

Hast Du da mit der Umschaltung was rausgefunden?


@Stefan

Wie sieht es an der QM-Front aus?

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Zum Thema Signal-Delay zwischen den Kanälen:

Ich habe mal bei meinen Geräten nachgemessen und war doch ziemlich 
erstaunt. Es gibt da erhebliche Delays zwischen den Kanälen. Und wie 
einige von Euch auch schon festgestellt haben scheint in der original 
WELEC FW eine Korrektur eingebaut zu sein (vermutlich in der alten 
Graphikroutine).

Damit wir eine einigermaßen gemeingültige Korrektur durchführen können 
bräuchten wir möglichst viele Daten von Euren Geräten. Ich habe mal eine 
Excelliste erstellt und angehängt in der ich mal meine Werte eingetragen 
habe. Tragt einfach Eure Werte dazu und stellt die Liste dann wieder 
hier ein. Ich trage dann die Ergebnisse zusammen in eine Gesamtliste.

Gruß Hayo

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

@ hayo

wie ungewünscht meine offset's
(-2ns bedeutet Kanal 2 ist 2ns früher als Kanal 1)

Martin

von Niklas O. (nevm)


Lesenswert?

Hallo,

erstmal Danke fuer eure tolle Arbeit an der Firmware,
bin seit einem halben Jahr Besitzer eines W2024A und
beobachte schon eine Weile die Entwicklung.

Waere es moeglich, den Bildschirminhalt als einfache
Bitmap ueber RS232 (oder USB) auszugeben, damit das
Abfotographieren des Bildschirms entfallen kann?

(Entsprechendes Programm auf PC-Seite zum Auslesen
kann ich selbst schreiben.)

Das waere nicht nur fuers Debugging interessant sondern
auch bei der normalen Benutzung und wesentlich einfacher
als ueber die Originalsoftware von Wittig/Welec.

Gruss,
Niklas

von Blue F. (blueflash)


Lesenswert?

@Martin

Ja genauso wars gedacht. Danke.


@Niklas

Willkommen in der Gemeinde ;-)

Tja, grundsätzlich gibt es ja ein entsprechendes Programm von WELEC, mit 
dem die Bildschirminhalte angezeigt werden können. Allerdings habe ich 
noch nicht ausprobiert ob das auch mit der Beta FW funktioniert. Es 
kursierten mal Gerüchte, dass bei der FW 1.2 die ja der Beta FW zugrunde 
liegt genau diese Übertragung buggy war.

Das wäre also ein Punkt an dem z.Zt. jegliche Erkenntnisse fehlen und 
wenn sich da jemand (Du??) berufen fühlt Hand anzulegen, dann haben wir 
wieder eine Ecke abgedeckt (zumindest könnte man das mal testen). Man 
kann sich da natürlich auch zu zweit zusammentun - einer auf PC-Seite 
und einer
auf DSO-Seite.

Mir selbst fehlen Windows Programmierkenntnisse, also wäre es eine 
willkommene Hilfe.

Mein eigenes Fernziel war es eigentlich mal nach schon vorhandenen 
PC-Programmen von renomierten Herstellern zu suchen, und dann das 
WELEC-Protokoll so anzupassen, dass man diese Programme nutzen kann 
(z.B. von Agilent/HP/Tektronix etc.).

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Martin

wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da 
eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW 
eingebaut hat.

Hayo

von Guido (Gast)


Lesenswert?

Hallo,

also ich bin immer noch völlig ratlos, wie ich die Verschiebung
messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
1 V/ns. Das aber kann das Welec doch garnicht darstellen?

Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
betroffen sind, dann bleibt mir das erspart.

Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
ob es da eine Einheilichkeit gibt.

@ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
C-Routine mal etwas auf und poste dann den aktuellen Stand.

Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
möglich sein, nach Druck auf den Button "Quick-Print" die
Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
würde man ja sehen, was der eine oder andere damit anfängt.

Gruß, Guido

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

im Anhang noch die Delays von Ch zu Ch bei meinem Geraet.

@Hayo:

Das Programm von Welec importiert soweit ich das sehe
die Rohdaten vom Oszi und bastelt sich dann (wenn
man die Scope Ansicht aufmacht) wieder nen Oszillogram
daraus.

Direkt aus dem Utility-Menue heraus "Save to..." passiert
auch nicht wirklich das, was man (ich) erwarten
wuerde, naemlich dass die Bildschirmausgabe, inkl.
gesetzter Cursor, gemessener Werte usw., genau wie
angezeigt gesichert wird.  Da wird auch nur wieder ein
Dump der Rohdaten gezogen.

Das Protokoll so anzupassen, dass es mit gaengigen Programmen
funktioniert waere wie Du schon sagst ein gutes Fernziel,
fuer meine Belange waere eine reine 1:1 Screenshot Funktion
und einfacher Datenexport schon ausreichend.

Ich habe auch gerade mal das Welec-Programm mit Deiner Firmware
getestet (die 0.75), es erkennt dass das Oszi am USB haengt und
verbindet sich, der Datenimport dauert aber ewwwwig (noch viel
laenger als mit der Originalfirmware) und am Schluss scheint
das Programm zu haengen, jeweils werden die Daten nicht angezigt,
das Oszi ist jedoch wieder "verfuegbar" (waehrenddessen lahmgelegt).
D.h., wie Du schon vermutest hast, funktioniert so nicht.

Ich habe schon gesehen das auf RS232 Testroutinen verfuegbar sind,
die die ADC Werte ausgeben, zudem hat Jochen Schaeuble mal das
USB-Protokoll reverse-engineered und auch eine LabVIEW Bibliothek
angelegt, mit der schonmal Importe funktionieren sollen:
http://schaeuble.info/de/category/jochen/w2000a

Auch liegt ja bei der Google Groups Gruppe ein C-File was
mit libusb unter Linux die Daten dumpt, was ich bei mir
allerdings noch nicht zum Funktionieren gebracht habe (ich muss
auch gestehen das ich mit USB noch nicht gearbeitet habe).

Ich denke, den Export der Kurven ueber RS232 und darstellen
mit Hilfe von evtl. gnuplot und die 1:1 Screenshot-Funktion
sind gute Erstziele.  Zu letzerem weiszt Du sicher mehr.

BTW: Komme nicht wirklich aus der Windows-Ecke, bin eher
im Unix-Bereich zu Hause.

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:

> also ich bin immer noch völlig ratlos, wie ich die Verschiebung
> messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
> kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
> 1 V/ns. Das aber kann das Welec doch garnicht darstellen?

Nein es geht viel einfacher. Man nehme eine Signalquelle mit 
BNC-Ausgang, dann ein Stückchen BNC-Kabel und am Ende ein T-Stück drauf. 
Dann zwei Tastköpfe hergenommen und auf die Enden die mitgelieferten 
BNC-Adapter aufstecken. Jetzt die Tasstköpfe in das T-Stück einführen 
und man hat exakt gleichlange Signalwege. (die Tastköpfe sollten nat. 
abgegl. sein)
Verwendet habe ich ein 5 MHz Rechtecksignal.

Bei der Messung kann man dann auch gleich die Vorzüge der interpolierten 
Zeitbasen der Beta FW nutzen. Im Vergleich dazu läßt sich das mit der 
originalen FW relativ schlecht ablesen.

> Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
> betroffen sind, dann bleibt mir das erspart.

Falsch! Ein Blick ins Excelfile und Du bist schlauer.

> Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
> ob es da eine Einheilichkeit gibt.

Eher einen Mettelwert denke ich.

> @ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
> TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
> C-Routine mal etwas auf und poste dann den aktuellen Stand.

Steht in "Selected_Timebase".

> Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
> möglich sein, nach Druck auf den Button "Quick-Print" die
> Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
> würde man ja sehen, was der eine oder andere damit anfängt.

Könnte man machen, ist nur eine Frage der Prioritäten.

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

Hayo W. schrieb:
> @Martin
> wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da
> eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW
> eingebaut hat.

Das wuerde auch den Bug bestaetigen, den ich mit der originalen 1.4 FW
hab', wenn ich bei nem Snapshot (unerlaubterweise vmtl.) die
Zeitbasis aendere.  Dann verschiebt sich Ch2 zu Ch1 nochmal um ~10nS.

Schalte ich wieder auf die Zeitbasis, mit der ich den Snapshot gemacht
habe, ist der zusaetzliche Versatz im Snapshot wieder weg.

von branadic (Gast)


Lesenswert?

Halllo Hayo,

ließe sich das nicht "dynamischer" gestalten? Ich könnte mir dazu einen 
"Routine" im Utility-Menu namens "Zeitversatz" vorstellen, mit einer Art 
Untermenu, in der man den zu korrigierenden Kanal wählt.
Kanal 1 dient als Referenz, nun wählt man einen der anderen Kanäle (2 
bis 4) und gleicht über Drehen des Menu-Encoders solange, bis der 
gewählte Kanal zeitlich mit Kanal 1 übereinstimmt.
Das hätte den Vorteil, dass jeder den Zeitversatz an seinem Gerät 
individuell einstellen kann.

Beste Grüße, branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

@branadic:
Bravo, ganz meine Meinung. So viel Flexibilität wie möglich, 
Beschränkungen nur wo nötig.

Gruß, brunowe

P.S.: Natürlich hab ich heute wieder niemanden telefonisch bei Welec 
erreicht. Es ist einfach ein Trauerspiel!

von Blue F. (blueflash)


Lesenswert?

Sag ich ja - sind in Italien!


@branadic

Das mit dem Individuellen Delay-Abgleich können wir natürlich machen, 
das wäre sicherlich die eleganteste Lösung


@Niklas

Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232 
Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das 
wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur 
Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick 
Print Button legen. Wäre Dir das recht?

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

an der QM-Front hat sich die Erkenntnis ergeben, dass es möglich eine 
einzigen Funktion über 2423 Programmzeilen zu erstrecken, ohne einen 
einzigen Kommentar zu hinterlassen. g

Die FFT wird wohl früher fertig ;-)

Gruß,
Stefan

von Niklas O. (nevm)


Lesenswert?

Hallo,

Hayo W. schrieb:
> @Niklas
> Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232
> Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das
> wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur
> Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick
> Print Button legen. Wäre Dir das recht?

Jau, das passt.  Ich werd' auch am WE mal schauen, dass ich
CDK4Nios bei mir zum Laufen bekomme, dann kann ich evtl.
auch selbst Hand anlegen.

von Kristian T. (krissy1983)


Angehängte Dateien:

Lesenswert?

Hallo,

hier die Werte von meinem Gerät. Bei mir scheint es mit dem 10 ns 
Korrekturwert in der Originalsoftware nicht zu passen.

Gruß

Kristian

von Blue F. (blueflash)


Lesenswert?

@Stefan

Dann weißt Du ja auch warum ich da bislang noch nicht rangegangen bin. 
Das mit den nicht vorhandenen Kommentaren zieht sich durch die Ganze 
Software. Ungefähr 95% der Kommentare die Du jetzt in der Software 
findest sind von mir nachträglich eingefügt für besseres Verständnis.

@Kristian

Hm, die Werte weichen ja ziemlich ab. Na mal abwarten was noch so kommt.



Gruß Hayo

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

hier mal die aktuelle Version. Die Geschwindigkeit ist jetzt
ganz akzeptabel, bisschen was geht wahrscheinlich noch.

Es wäre jetzt interessant für den Rollmode nur noch die
benötigte Bytezahl zu lesen, da dieses insgesamt schon recht
lange dauert.

Gruß, Guido

von Michael W. (slackman)


Angehängte Dateien:

Lesenswert?

Hier meine Delayzeiten.

By the way: mit hohen Frequenzen (50 & 60 MHz Oszillatoren) hatte ich 
einige Probleme mit dem Triggern. Das Signal steht dann nicht still und 
springt hin und her.

Michel

von Kurt B. (kurt)


Lesenswert?

Ich hatte gestern mal Verucht Wittig per Mail zu ereichen. Heute kam 
folgende Antwort:



Lieber Kurt,

vielen Dank auch nochmal für Ihre Anfrage zur Veröffentlichung
des Chip-Designs. Wir haben kein Problem von seitens Altera.
Unser Problem besteht bei einer Veröffentlichung, dass wir
eine Gemeinsamentwicklung mit einem namhaften Oszilloskophersteller
hatten, die auch einiges an IP zugesteuert hat. Deshalb konnten
wir keine Unterstützung in diesem Fall beibringen.

Bitte haben Sie Verständnis, dass wir nicht weiterhelfen können.
Wir selbst hätten auch keine Probleme die Veröffentlichung vorzunehmen.
Es sind also rechte an Dritten, die wir verletzen würden...
Das können Sie auch so an Ihre Gemeinschaft weiterleiten, so dass
bekannt wird, dass wir deshalb nicht weiterhelfen können.

Viele Grüße
Thomas

von branadic (Gast)


Lesenswert?

Zwei Doofe ein Gedanke...
Ich hatte gestern ebenfalls eine Mail an Wittig geschrieben. Hab exakt 
die gleiche Mail als Antwort bekommen. Man hat sich noch nicht einmal 
die Mühe gemacht die Anrede auf meinen Namen hin anzupassen. Ab heute 
heiße ich also Kurt.

Beste Grüße, branadic alias Kurt

von Stefan E. (stefan_e)


Lesenswert?

Dann gibts da draußen noch weitere Oszilloskope mit dem Design? Oh je

Oder sollten wir uns lieber freuen, dass es im FPGA nicht so schlimm 
sein kann, wie allgemein angenommen?

von branadic (Gast)


Lesenswert?

So würde ich das nicht unbedingt formulieren, zumindest noch nicht. 
Anscheinend ist man da aber an einer neuen Sache dran. Zumindest die 
Website und ein Blick auf die Bildchen über dem Site Menu lassen darauf 
spekulieren:

http://www.wittig-technologies.com.br/company.php

Beste Grüße, branadic

von Kurt B. (kurt)


Lesenswert?

Genau, siehe auch Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

@Stefan,
Es ging ja auch nicht nur darum den FPGA zu debuggen, sondern auch Teile 
der Hardwareansteuerung einzubauen, damit diese den Softcore nicht mehr 
belasten.

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Die Delays scheinen aber auch vom Tastkopf abzuhängen. In die Lösung des 
Problems sollte man meiner Meinung nach jetzt nicht viel Energie stecken 
weil es für langsamere Signale keine Rolle spielt und das Oszi für HF 
zur Zeit noch nicht zu gebrauchen ist.

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Kurt,

man kann auch richtig schnelle Signale messen, solange man nicht über 
einen best. Signalpegel (am ADC) kommt.
In der Anlage siehst du einen 140MHz_Sinus von meinem selbstgebauten DDS 
Signalgenerator. Wenn ich den Signalpegel aber nur etwas erhöhe, bzw. in 
den 1V/Div Messbereich runter schalte, fängt das Oszillieren an und 
macht eine sinnvolle Darstellung absolut unmöglich.
Eine Schwebung oder Aliasing konnte ich auch nicht feststellen.

Gerade weil die Delays etwas von den Tastköpfen abhängen, halte ich eine 
individuelle, einstellbare Anpassung für so wichtig!

Gruß, brunowe

von Kurt B. (kurt)


Lesenswert?

Hallo Bruno,
so gesehen hast du natürlich Recht. Da brauchen wir aber bald schon 
Untermenüs weil die Softkeys knapp werden. ;-)

Gibt es irgendwo eine Beschreibung von deinem DDS?

Mfg,
Kurt

von Blue F. (blueflash)


Lesenswert?

Kurt Bohnen schrieb:
> Die Delays scheinen aber auch vom Tastkopf abzuhängen.

Nein bei mir nicht. Ich habe extra die Tastköpfe bei jeder Messung 
getauscht - mit dem gleichen Ergebnis

> In die Lösung des Problems sollte man meiner Meinung nach
> jetzt nicht viel Energie stecken
> weil es für langsamere Signale keine Rolle spielt und das Oszi für HF
> zur Zeit noch nicht zu gebrauchen ist.

Meine Messungen habe ich mit einem 5MHz Rechteck durchgeführt. Selbst 
bei dieser Frequenz fand ich das schon recht störend. Der Aufwand für 
eine Mittelwertkompensation (wie in der originalen FW) ist recht gering 
und reduziert das Problem schon ziemlich. Nur für den manuellen Abgleich 
müßte man einen etwas höheren Aufwand betreiben.

Gruß Hayo

von Cra Z. (crazor)


Lesenswert?

An die GERMSloader-Bastler:

Es wäre schön, wenn beim Dumping des Flashes auch die Prüfsummen 
berechnet und vergleichen würden. Im Falle eines Fehlers kann dann die 
Zeile einfach nochmals angefordert werden. Einerseits würde ich damit 
die Funktion überhaupt erst nutzen können (mein toller Port), 
andererseits ist somit für alle sichergestellt, dass der Dump 100% 
korrekt erfolgt ist.

von Cra Z. (crazor)


Lesenswert?

Oha, so wie ich das sehe, spuckt der GERMSmonitor gar keine Prüfsummen 
aus?

von Blue F. (blueflash)


Lesenswert?

Genau so ist es.

von Cra Z. (crazor)


Lesenswert?

Dann werden wir mal kräftig Gas geben mit der Implementierung des 
Flash-Controllers, so geht das ja nicht weiter!

von Blue F. (blueflash)


Lesenswert?

Kurzer Zwischenstand:

Ich habe die letzten Tage damit zugebracht die FFT komplett auf Integer 
umzustellen und das letzte an Performance herauszukitzeln. Ich denke es 
kann sich sehen lassen. Der Geschwindigkeitsgewinn liegt bei etwa Faktor 
8 bis 10. Das ist schon recht anständig wenn man bedenkt dass die 
Routine an sich ja eigentlich schon auf Geschwindigkeit optimiert war. 
Die Geschwindigkeit liegt jetzt bei 2 bis 3 FFTs pro Sekunde gegenüber 2 
bis 4 Sekunden pro FFT vorher.

Jetzt werde ich mal das Drumherum programmieren, damit man das auch 
anständig benutzen kann.

Gruß Hayo

von drusius (Gast)


Lesenswert?

lechtz...

(ist als Aufmunterung und Dank gedacht!!)

von Blue F. (blueflash)


Lesenswert?

Hallo liebe Gemeinde,

dieses Wochenende wird es mal kein neues Release geben, die Menüführung 
und Einstellmöglichkeiten für die FFT im Menü sind noch zu unausgereift. 
Ich denke da ist es besser erst einen etwas runderen Zwischenstand 
abzuwarten. Vielleicht kann ich bis dahin ja auch außer den Neuerungen 
von Guido auch noch weitere Verbesserungen von Euch mit einbauen.

Gruß Hayo

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

bin momentan etwas knapp mit der Zeit. Weiß noch nicht, obs deshalb von 
mir was neues gibt. Aber ich habe gerade deinen "Shift Mode" im Einsatz. 
Ist gerade echt nützlich.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Hi Stefan,

das höre ich gerne. Ja bei mit wird es auch etwas dauern, ich habe 
gerade mal eine To Do Liste gemacht was ich so für eine komfortable 
Bedienung alles noch einbauen muß, da gibt es ordentlich was zu tun.

Guten Start in die neue Woche

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

>Jürgen schrieb:
>
>> Hatte gestern irgendwie Probleme mit dem Ch3 und der
>> Vertikalauflösung/Verstärkungsumschaltung. Habe deshalb in der SW
>> gesucht und in der Funktion "Hardware::SetSwitches(..)" eine
>> Unregelmäßigkeit gefunden: Entweder stimmen die Adressen oder die
>> KOmmentare?
>> Ch3 tanzt aus der Reihe! Vielleicht hast Du dort schon
>> "tiefer gebohrt". Scheint aber trotzdem zu funktionieren?!
>
>Nein, da war ich noch nicht dran, wenn Du da Hinweise findest immer her
>damit.
>
>Hayo

habe mal versucht die Sache anhand der Sourcen und des Stromlaufplanes 
nachzuvollziehen. In der o.g. Funktion ist also nur der Kommentar bei 
Ch3 bezüglich der Adresse falsch! Für die Ch-Switches ergeben sich 
folgende Adressen:
Ch1 = adr 7, Ch2 = adr 5, Ch3 = adr 1, Ch4 = adr 3, ext.Trig = adr 2, 
DAC1+2 = adr 6, DAC 3+4 = adr 4. Diese Belegung sieht man auch im 
Stromlaufplan IC U25( 74HC238). Die dort unbezeichneten Ausgänge Y0-Y7 
entsprechen diesen Adressen und Bezeichnungen können ergänzt werden.

Noch eine Eränzung der Bugliste ist mir dabei mit dem Probe-Ausgang 
aufgefallen: Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und 
Ch4 nur jeder zweite Screen korrekt dargestellt. Dazwischen wird für 
CH3+4 immer eine gerade Linie gezeigt. Ch1+2 werden richtig 
dargestellt.Die Triggerung wird aber nicht ordentlich ausgeführt (bleibt 
immer Auto Mode?).

Beste Grüße,
Jürgen

von Blue F. (blueflash)


Lesenswert?

Hi Jürgen,

> In der o.g. Funktion ist also nur der Kommentar bei Ch3 bezüglich
> der Adresse falsch!

Immerhin haben wir jetzt wieder weitere Details geklärt und können davon 
ausgehen, dass zumindest hier alles funktioniert wie es soll. Ich werde 
mal die Kommentare in der Funktion überarbeiten (immerhin sind überhaupt 
irgendwelche Kommentare drin!).


> Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und
> Ch4 nur jeder zweite Screen korrekt dargestellt.

Danke für den Hinweis das werde ich mal näher untersuchen. Interessant 
wäre, ob das ein Bug ist den ich eingebaut habe, oder ob der bei der 
originalen FW auch auftritt.

Gruß Hayo

von Jürgen (Gast)


Lesenswert?

Ach so ja, der Bug ist auch in der Version 1.4 so enthalten. Ausserdem 
fällt mir jetzt noch ein, daß die Drehrichtung für die externe 
Triggerschwelle ev. entgegengesetzt der übrigen Einsteller ist (Soll: im 
Uhrzeigersinn drehen = erhöhen ? )

Gruß Jürgen

von Blue F. (blueflash)


Lesenswert?

Ok, gut zu wissen, dass das auch in der orig. FW auftritt.

Die Drehrichtungen sind zum Teil etwas durcheinander, und waren mir auch 
schon immer ein Dorn im Auge. Das wollte ich evtl. mal umstellen auf 
eine durchgängige Drehrichtung

- im Uhrzeigersinn erhöhen
- gegen den Uhrzeigersinn verkleinern

Gruß Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

ich hab' heute mal CDK4Nios eingerichtet und kann schon einzelne
Planes in S/W als Stream rausschreiben, ins PPM-Format wandeln
und darstellen.

Soweit ich den Aufbau bis jetzt verstehe besteht die GUI
aus etlichen Planes, die uebereinander gelagert schlieszlich
die sichtbare Ausgabe ergeben.

Um einen 1:1 Screenshot ueber "Quick Print->Save to BMP" usw.
rauszuschreiben muesste man also alle Planes in der richtigen
Reihenfolge aufeinander legen und kombinieren, d.h., Pixel
sichtbar/set oder nicht sichtbar/!set.

Dazu nun folgende Fragen an die Leute die schon laenger mit
der Firmware zutun haben:
* Ist mein Verstaendnis soweit richtig?
* Ist die Darstellreihenfolge der Planes bekannt?

Zudem noch die Frage, inwieweit der ganze Akt in der Firmware oder
einem PC-Programm erledigt werden soll, d.h., wieviel Flashspeicher
geopfert werden soll/kann.

Gruss,
Niklas

von Kurt B. (kurt)


Lesenswert?

Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man 
die Screenshots direkt auf den Stick speichern kann.

von Blue F. (blueflash)


Lesenswert?

Hi Niklas,

ich denke dass der Aufwand einen direkten Screenshot zu machen recht
hoch ist. Da ist es doch wesentlich einfacher nur die Signaldaten und
Parameter zu übertragen und dann das Signal zu rekonstruieren.

Ja Du hast das schon richtig gesehen mit den Planes. Es gibt eigentlich
für Alles und jede Ausgabe eine eigene Plane. Von der Plane abhängig ist
auch die Farbe, da die Farben immer pro Plane eingestellt werden. Welche
Planes da so auf den Schirm übertragen werden und in welcher Folge 
kannst
Du in TransferPlanes() sehen (in Hardware_t.cpp  Zeile 21245).

Flashspeicher ist knapp, da dort die ganzen Signale gespeichert werden,
siehe die von mir hier schon mehrfach veröffentlichten Memory Maps 
(gibts
auch in Google Groups). Ich habe jetzt schon Probleme die
trigonometrischen Tabellen für die FFT dort abzulegen.

D.h. dafür müßte man dann Signalspeicher hergeben.

Gruß Hayo

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

ich habe gerade fix mal meinen Code erweitert um "alle" Planes
zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
erstellt.  Dabei habe ich noch nicht die Reihenfolge in
TransferPlanes() beruecksichtigt, daher fehlen offensichtlich
einige Texte.

Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
im Code zurueck liegen, die clFarbe Konstanten sind definiert
und anscheinend nirgendwo referenziert.  Auch stoeren mich
bei dem bissl Code was ich bisher sah viele doppelte oder nicht
durchgehend benutzte Konstanten, wie auch fuer die Planes.

Da muesste mal aufgeraeumt werden.  Wie sieht da die Planung aus?
Ich waere natuerlich bereit da mit anzupacken.  Ich sehe, dass
ihr wohl bisher eher vorsichtig auskommentiert und teilweise
neu implementiert habt, um nicht gleich alles zu brechen.

Anbei der PoC-Screenshot.

von Niklas O. (nevm)


Lesenswert?

...und hier noch der Stueck Code mit dem ich den Output erzeuge:

1
void Display::SCREENSHOT(void)
2
{
3
        int x, y;
4
        int bit, pos, offset;
5
        unsigned long *planes[] = {
6
                Grid_Plane,
7
                UI_Plane1, UI_Plane2, UI_Plane3, UI_Plane4, UI_Plane5,
8
                Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4,
9
                Channel_Math_Plane,
10
                Memory_Plane1, Memory_Plane2, Memory_Plane3,
11
                Marker_Plane1, Marker_Plane2,
12
                NULL
13
        };
14
        unsigned long *plane;
15
        int i, set;
16
17
        (void)printf("Pixel printout follows\r\n");
18
19
        for (y = 0; y < 480; y++) {
20
21
                for (x = 0; x < 640; x++) {
22
                        offset = x >> 5;                // x div 32
23
                        pos = Display_Line_Adresses[y] + offset;
24
                        bit = x - (offset << 5);        // x - (offset mod 32)
25
26
                        set = 0;
27
                        for (i = 0; (plane = planes[i]) != NULL; i++)
28
                                if (*(plane + pos) & BitMasks2[bit]) {
29
                                        set = 1;
30
                                        break;
31
                                }
32
                        if (set)
33
                                (void)printf("1");
34
                        else
35
                                (void)printf("0");
36
                }
37
                (void)printf("\n");
38
        }
39
40
        (void)printf("Pixel printout DONE\r\n");
41
}

Um das ganze darstellbar zu machen hab' ich einen PPM-Header
hinzugefuegt und 0/1 fuer Pixel gesetzt/ungesetzt in erfundene
Farbwerte gewandelt.  PPM habe ich nur gewaehlt, weil ich mich
da schon auskannte ;)

Natuerlich fehlen da noch die Original-Farben und eine platzsparende
Ausgabe (sind ja so 307200+480 Bytes die geschrieben werden auf RS232),
aber es ist m.E. mit geringerem Aufwand als erwartet machbar.

Gruss,
Niklas

von Guido (Gast)


Lesenswert?

Hallo,

@ Niklas O. (nevm): Soweit ich das verstanden habe, wird nicht
alles in die Planes gezeichnet. Die sind ja nur ein Puffer, der
dann in den Videospeicher transferiert wird. Ich meine, dass z.B.
Pixelp direkt in den Videospeicher schreibt, weil da ganz andere
Adressen verwendet werden. Das solltest du vllt. mal anschauen.

Gruß, Guido

von Johannes S. (demofreak)


Lesenswert?

Niklas O. schrieb:
> ich habe gerade fix mal meinen Code erweitert um "alle" Planes
> zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
> erstellt.  Dabei habe ich noch nicht die Reihenfolge in

Super! Genau sowas will ich schon immer haben, das ewige Abfotografieren 
des Bildschirms geht mir gewaltig auf den Zeiger. Nun das ganze einmal 
für Linux bitte. :D

/Hannes

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab' noch fix RLE Kompression fuer die Datenuebertragung(*)
eingebaut und blende ein paar Planes(**) aus damit man bei der
S/W Version die Beschriftungen lesen kann.

Damit kann man nun schonmal ein wenig anfangen.

Das Ganze samt Ausleseprogramm in C und kurzer Beschreibung
im Anhang.

Falls ich heute Abend Zeit habe geht's dann weiter an die
farbige Ausgabe.  Dazu werde ich wahrscheinlich die Planes
einzeln exportieren und ausserhalb des DSOs wieder eingefaerbt
zusammensetzen.  Haette auch den Nebennutzen einzelne unwichtige
Sachen, etwa fuer Dokumentationszwecke, wieder ausblenden zu koennen.

@Guido:
Soweit ich sehe wird PIXELP() mit den selben Speicherstellen
aufgerufen die ich auch verwende. Genau angeschaut habe ich
mir das allerdings noch nicht.

Gruss,
Niklas

(*) Etwa 10-15kB Daten pro Screenshot.
(**) Jene Planes die die Softbutton-Beschriftungen 
einrahmen/untermauern.

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

...und hier noch ein Beispiel-Screenshot.

von branadic (Gast)


Lesenswert?

Hallo Zusammen,

für alle die es noch nicht mitbekommen haben, weil sie im 
Hardware-Thread zu selten vorbei schauen, ergeht hier noch einmal der 
Hinweis. Ab sofort könnt ihr euch für Schirmbleche vormerken. Wie und wo 
erfahrt ihr im entsprechenden Beitrag:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

Ich hoffe auf zahlreiche Meldungen.

Beste Grüße, branadic

von Blue F. (blueflash)


Lesenswert?

Hallo Niklas,

Du gehst ja mächtig zur Sache. Das sieht schon wirklich prima aus. Ich 
hätte nicht erwartet, dass da so schnell solche Ergebnisse zu erzielen 
sind. Echt super.

> Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
> im Code zurueck liegen, die clFarbe Konstanten sind definiert
> und anscheinend nirgendwo referenziert.  Auch stoeren mich
> bei dem bissl Code was ich bisher sah viele doppelte oder nicht
> durchgehend benutzte Konstanten, wie auch fuer die Planes.

Oh ja, wenn wir von etwas ausreichend haben, dann sind es Altlasten. Es 
sind leider so viele, dass wir nur Stück für Stück vorankommen.

> Da muesste mal aufgeraeumt werden.

Allerdings!

> Wie sieht da die Planung aus?

Zur Zeit gibt es im Wesentlichen folgende Hotspots:

- die Hardwareecke versucht Designfehler auf der Platine
  aufzuspüren und zu verbessern.

- ebenfalls der Hardwareecke zugeordnet sind die Kollegen
  die an anderen FPGA-Designs arbeiten.

- in der Softwareecke versuchen wir das Assemblercoding
  möglichst ohne Performanceverluste nach C zu portieren (Guido)

- an der Überarbeitung der Quick Measure Funktion ist Stefan dran

- einige der Forumsbesucher testen und schreiben Fehlerberichte

- einige sind auch einfach nur so im Coding unterwegs geben
  hier und da gute Hinweise auf mögliche Fehler.

- ich bin zur Zeit an der FFT-Implementierung dran

Du siehst es sind noch eine Menge Themen offen.

> Ich waere natuerlich bereit da mit anzupacken.

Das ist prima. Seit sich hier die Anzahl der Hilfswilligen so erhöht hat 
geht es deutlich schneller voran und wir können fast jede Woche ein 
neues Release mit zig Verbesserungen rausbringen.

> Ich sehe, dass ihr wohl bisher eher vorsichtig auskommentiert
> und teilweise neu implementiert habt, um nicht gleich alles
> zu brechen.

Ja, wir wollen das möglichst so machen, dass wir immer ein einigermaßen 
stabiles Release haben mit dem man auch richtig arbeiten kann. Bislang 
haben wir das so gehandhabt, dass ich die neuen Release rausgegeben habe 
und die Änderungen der anderen Entwickler mit eingebaut habe. Das läuft 
auch ganz gut und verhindert, das es zig Versionen mit unterschiedlichem 
Stand gibt. So können immer alle auf den gleichen neuen Stand wieder 
aufsetzen mit Ihrem nächsten Entwicklungsschritt. Auch bei den Tests ist 
das wegen der Vergleichbarkeit der Ergebnisse sehr Hilfreich.

Gruß Hayo

von Cra Z. (crazor)


Lesenswert?

Kurt Bohnen schrieb:
> Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man
> die Screenshots direkt auf den Stick speichern kann.

Hallo Kurt,

da muss ich dich leider enttäuschen. Im Gerät steckt ein Cypress EZ-USB 
FX1, der nicht als Hostcontroller taugt. Da müsste also eine 
Zusatzplatine entwickelt werden...

Wenn wir gerade schon dabei sind: Ich habe am Wochenende nach dem 
JTAG-Zugang zum 2. FPGA der 20x4er gesucht. Leider kam heraus, dass 
vergessen wurde, TCK an den 2. FPGA zu routen, aber das kennen wir ja 
nicht anders von den Wittigs.
Nichts desto trotz habe ich eine interessante Entdeckung dabei gemacht. 
Direkt oberhalb des 2. FPGA, neben dem Steckverbinder zum Frontpanel, 
sind 8 ungenutzte Pins des 2. FPGA auf Pads geführt. Hier könnte evtl. 
eine Art Erweiterungsschnittstelle realisiert werden für Nutzer der 
20x4-Geräte (die 20x2-Eigentümer müssten dazu leider schon direkt an die 
BGA-Bälle der Pins, die vom 1. FPGA kommen, ran. Haare spalten (der 
Länge nach) ist glaube ich einfacher).
Mindestens aber könnte dort z.B. ein SD-Cardreader angebracht werden.

Soviel zur Hardware, denn das ist hier der Softwarethread!

P.S. das nächste FPGA-Design zum "Spielen" lässt leider noch auf sich 
warten, da noch einige grundlegende Umstrukturierungen ausstehen, da ich 
mich mit einigen Fiesigkeiten lange aufgehalten habe. Sorry! Aber 
Downsampling und Timebases funktionieren, mittlerweile auch korrekt.

von Kurt B. (kurt)


Lesenswert?

Hallo Daniel,
das mit dem EZ-USB ist schon klar.

Für den VNC1L-1A (Vinculum) USB-Controller gibt es eine fertige Firmware 
(VDAP) die alle Aufgaben der Ansteuerung eines USB Sticks inkl FAT 
realisiert.
Man muss nur einige Parameter über SPI oder UART übergeben, und der 
Vinculum schiebt die Daten auf den Stick.
Siehe auch Beitrag "USB-Stick am Mikrocontroller VNC1L"

Ich selbst habe sowas noch nicht gemacht und hoffe es trotzdem richtig 
verstanden zu haben.

Der Hinweis im Firmware-Thread weil es vieleicht sinnvoll ist, einen 
kompletten Screendump inkl. Dateiheader im Oszi zusammenzusetzen. Aber 
darüber muss mann weiter nachdenken...

von elgodil (Gast)


Lesenswert?

Meine Wunschvorstellungen für den Screenshot:

-Farbe (ok, ist in Arbeit)

-Auslösen durch Tastenkombination(nen z.B. 1 x RAW (durch ext. Programm 
manipulierbar) 1x als BMP o.ä. (also gleich verwendbar)

-Ausgabe seriell als Z-Modem (also so, das gleich der "Abspeichern" 
Dialog aufpeppt

So ist ein Screenshot imho in der Praxis am schnellsten gemacht.

Was in den Flash passt, müssen nat. die Programmierer entscheiden.....

elgodil

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Auch wenn Abfotografieren bald nicht mehr State of the Art ist ;-)
(wenn Niklas da so weitermacht) hier ein Screenshot einer
Logarithmierten FFT.

Ich freue mich, dass ich es geschafft habe die Logarithmierung zu 
implementieren, ohne spürbaren Performanceverlust gegenüber der 
liniearen Darstellung.

Das war nicht von Anfang an so! Erste Versuche mit der originalen 
Bibliotheksfunktion log10() haben massive Performanceverluste nach sich 
gezogen und die Wiederholrate auf 5 S pro FFT runtergedrückt - trotz der 
optmierten FFT-Routinen.

Das sieht schon alles soweit ganz gut aus, so dass ich hoffe zum 
nächsten Wochenende die nächste Beta rausgeben zu können.

Gruß Hayo

von Stefan (Gast)


Lesenswert?

Bei mir gibts noch nix neues. ;-) Hab gerade wieder ne Stunde damit 
verbracht, denn Code zu verstehen. Aber der übersteigt mein 
Denkvermögen. Hundert Variablen, die irgendwie miteinander verknüpfts 
sind, Variablen die scheinbar nie gesetzt werden, hunderte 
Fallunterscheidungen,...

Ich glaube, es ist leichter den Code neu zu schreiben, als da 
rumzufrickeln.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Deswegen habe ich ja auch etliche Sachen komplett neu gemacht.

Hayo

von PIZZA-MAMPF (Gast)


Lesenswert?

@Hayo
Thema FFT log -> mit Tabelle??

von Blue F. (blueflash)


Lesenswert?

Jupp!

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

so, ich bin dann noch dazu gekommen die Screenshot-Funktion
auf farbige Ausgabe zu erweitern.  Wie angekuendigt exportiere
ich die Planes einzeln.  Das Programm speichert diese auch
einzeln ab, was vllt. auch fuer die Entwicklung interessant ist.
Was mir schon auffiel:  Die Plane fuer den Ch 4 wird "missbraucht"
um die roten Pfeile und das Stop(p)-Schild zu malen.

Diff, fertig kompilierte TomCat.ram und C-Programm wie beim
letzten Mal schon im angehaengten .tgz.  Alles weitere und
Changelog in der README-Datei.

Dem C-Programm steht btw. nichts entgegen, nicht auch mit Cygwin
oder MinGW fuer Windows kompiliert zu werden.  In der kurzen
Zeit hab' ich (auch mangels Windows mit installiertem Cygwin
oder anderem Environment) mich noch nicht darum gekuemmert.

Falls fuer Windows-User die PGM/PPM Bildformate ein Problem
darstellen laesst sich das sicher auch zu BMP umstricken, wie
schon gesagt, wird nur verwendet da ich mich damit schon
auskannte.

@elgodil:
> -Auslösen durch Tastenkombination(nen z.B. 1 x RAW
> (durch ext. Programm manipulierbar) 1x als BMP o.ä.
> (also gleich verwendbar)

Tastenkombination waere ' bzw. # derzeit.  BMP weisz
ich nicht was es da fuer Platzeinsparungsmoeglichkeiten
mit RLE und Paletten gibt und wie hoch da der jeweilige
Aufwand in der Firmware waere.

Generell bin ich auch fuer die Option der Ausgabe in einem
wohldefinierten und universellen Format.
Bei USB sehe das vmtl. schon anders aus da dort offensichtlich
die Uebertragungsgeschwindigkeit nicht so ins Gewicht faellt.

> -Ausgabe seriell als Z-Modem (also so, das gleich
> der "Abspeichern" Dialog aufpeppt

Die Idee finde ich gut und es waere ein Schritt dahin,
das DSO mit "Boardmitteln" wie HypterTerm oder
Minicom ueber RS232 ansprechen zu koennen, auch
hinsichtlich der Ausgabe und Speicherung von
Messwerten direkt in eine (CSV-)Datei.

Ich werde dann aber wahrscheinlich X-Modem-1K-(CRC16) benutzen.

Gruss,
Niklas

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

...und hier noch ein Beispielscreenshot mit der Ausgabe
von Hayos Test-Signal-Funktion.

Hinweis:  Auf dem Oszi uebermalt der lila Math-Channel
die Browse-Scroll-Leiste (wie heiszt die korrekt? ;)),
im Ausleseprogramm habe ich die Reihenfolge veraendert
damit die Ausgabe im Screenshot "korrekter" ist.

von Blue F. (blueflash)


Lesenswert?

Hi Niklas,

Du bist ja mächtig fix! Ich bin noch nicht zum Ausprobieren gekommen, 
aber ich denke ich werde das mal mit in die nächste Beta einbauen. Da 
bietet es sich ja an das ins Print-Menü zu integrieren, damit man nicht 
immer über das Terminal triggern muß.

Super!

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

Schöne Sache dein Screenshoot.

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi,

für diejenigen, die nicht so oft im Hardwarethread unterwegs sind hier 
die Anleitung wie man die Luftzufuhr im Gerät optimieren kann.

Gruß Hayo

von drusius (Gast)


Lesenswert?

Könnte man bei der Gelegenheit gleich einen Pabst oder Verax reinhängen 
und (da weniger Saugleistung benötigt wird) gleich noch die Drehzahl 
runtersetzen (oder regeln)....

mal schauen

von drusius (Gast)


Angehängte Dateien:

Lesenswert?

Hab schon mal das Datenblatt des verbauten Lüfters ergoogled (was für 
ein blödes Wort!)

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

tolle Beschreibung! Ich hab mir erlaubt das ganze in SF einzufügen.
http://sourceforge.net/apps/trac/welecw2000a/wiki/Modifications

Noch etwas aus meiner Wishlist:
Bei meinen Tests ist es mir schon häufiger aufgefallen, das mein 
HF-Signal von einer  NF-Schwingung überlagert ist. Sehr schwer 
gleichzeitig darzustellen- Man muss die Zeitbasis entsprechend verändern 
und verliert dadurch zwangsläufig die andere Schwingung aus dem Auge. 
Deshalb mein Wunsch nach einer zweiten Zeitbasis. D.h. es wäre doch 
wunderbar wenn ich z.B. den Ch1 mit 50ns/Div und den CH2 mit z.b. 
1ms/Div darstellen könnte. Gute, teure Oszis haben da ja eine echte 
zweite Zeitbasis, aber eine entsprechende Darstellung zweier Kanäle mit 
unterschiedlicher Zeitbasis sollte doch auch bei uns zu verwirklichen 
sein? Im neuen VHDL Design werden wir eine entsprechende Verwirklichung 
dieses Features auf jeden Fall anstreben.

Gruß, brunowe

P.S.: Meine Wunsch nach einer variablen Verstärkung (vertikales zooming) 
ist auch noch in der ToDo list? Nicht das das verloren geht...

von Blue F. (blueflash)


Lesenswert?

Hi Bruno,

wie soll denn die zweite Zeitbasis einzustellen sein? Der Einsteller für 
die eigentliche Zeitbasis ist ja schon vergeben.

Eine Möglichkeit wäre ein Umschalter oder sowas in der Art. Wie ist das 
denn an den besagten teuren DSOs realisiert?

Gruß Hayo

p.s. Hier geht nix verloren - letztlich werden alle Wünsche erfüllt 
(hoffe ich)

von PIZZA-MAMPF (Gast)


Lesenswert?

Ich würde den Focus erst mal auf Fehlerfreiheit der vorhandenen 
Funktionen legen-aber Bugs (anderer) zu suchen ist nun auch nicht das 
reine Vergnügen.

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

also ich kenne jetzt konkret das HAMEG 1508-2 (Mixed Signal combi 
scope), das HM 2005-2 (analog scope) und das Philips PM3092 mit 2 
Zeitbasen. Wie die Umsetzung bei den analogen Oszis funktioniert ist 
relativ einfach erklärt. Es gibt eine Haupt- Zeitbasis (die langsamere), 
mit dieser wird das Signal getriggert und dargestellt. Innerhalb dieser 
dargestellten Zeitspanne wird jetzt mit einem bestimmten, einstellbaren 
delay, dieses Signal mit einer schnelleren Zeitbasis dargestellt. Es 
kann damit also eine Ausschnittsvergrößerung dargestellt werden.

In unserem Fall müsste man das interessierende Signal auf zwei Kanälen 
sampeln um eine entsprechende Vergrößerung darstellen zu  können. Ich 
würde auf jeden Fall den Kanal 1 fix mit der Hauptzeitbasis koppeln. Den 
Ch2 dann, mit einer über das Menü (neuer Menüpkt. neben Probe), zu 
aktivierenden zweiten Zeitbasis belegen. Zugegeben ist das 
wahrscheinlich etwas komplexer zu verwirklichen (Trigger und delay 
Problematik...) und bestimmt gibt es noch einen ganzen Stapel anderer, 
wichtigerer Baustellen... Dennoch wollte ich dieses Feature einfach mal 
erwähnen.

gruß, brunowe

von Guido (Gast)


Lesenswert?

Hallo,

könnte man nicht den Delayed-Mode so aufbohren, dass er zweimal
hintereinader sampled: Erstes Sample langsame Timebase, oberes
Bild zeichen. Zweites Sample schnelle Timebase unteres Bild
zeichnen, Und wieder von vorne.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

@Guido,

das wäre wohl die einfachste und genialste Möglichkeit. Man würde sich 
damit sogar den zweiten Kanal einsparen. Guter Einfall!


gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Den verstehe ich nicht so ganz.

Wo ist da der Unterschied zum jetzigen Delayed Modus, wenn man mal davon 
absieht das es nicht mit zweimal sampeln realisiert ist sondern einfach 
mit unterschiedlichen Zoomfaktoren.

Oder hab ich da was falsch verstanden?

Hayo

von Guido (Gast)


Lesenswert?

Der Vorteil liegt einfach in den beliebig vielen Zoomstufen.
In den meisten Bereichen haben wir bisher ja nur eine.
Der Nachteil ist halt die halbierte Aktualisierungsrate.

Vllt. ginge es auch eleganter, ich würde gerne mal mit den
Werten des TimeBaseRegisters spielen. Die nächsten 3/4 Wochen
werde ich aber nicht dazu kommen.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo,

ich hab hier als Beispiel die Darstellung von einem Fernseh-BAS Signal 
angefügt. Mit unseren Mittel ist es derzeit nicht möglich, gleichzeitig 
das komplette BAS Signal für eine Bild-Zeile und das 
Trägerfrequenzsignal darzustellen... um solche und ähnlich komplexe 
Signaldarstellung geht es im Prinzip.

Vielleicht noch ein wichtiger Punkt zur Anmerkung. Die Nutzung des 
Delayed Modus hat natürlich den gravierenden Nachteil, das man für die 
zeitl. gezoomte Darstellung die Spannungsauflösung nicht unabhängig von 
der Hauptdarstellung einstellen kann. Ein echtes Manko meiner Meinung.


gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Hallo werte Gemeinde,

leider bin ich heute nicht mehr ganz fertig geworden, so dass es die 
neue Beta erst morgen geben wird. Schon mal soviel vorweg, das Warten 
hat sich gelohnt. In das neue Release sind zahlreiche Bugfixes und 
Korrekturen eingeflossen (Mathfunktion, Statusbar Kanalanzeige, 
Menü-Updatelogik etc.). Desweiteren habe ich die C-Routinen von Guido 
eingebaut und die neue Screenshot-Funktion von Niklas ins Quickprint 
Menü integriert. Und als Highlight verfügt das W20xxA jetzt über eine 
Spektralanalyse (FFT) die sich nicht vor der teurerer Geräte verstecken 
muß.

Bis morgen

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

ich hab' heute Nachmittag damit angefangen, eine minimale
ZModem-Implementation (derzeit ca. 290 Zeilen) fuer das DSO zu bauen. 
Eigentlich wollte ich ja, weil wesentlich einfacher, XModem, aber dann
haette man den Dateiempfang per Hand anstoszen muessen.

Das ganze laeuft schonmal "im Trockenen", ich muss allerdings
noch eine zusaetzliche ISR Routine fuer den UART schreiben, der
die empfangenen Bytes zwischenbuffert bis diese weiterverarbeitet
werden.

(Derzeit mache ich ungefaehr:
1
static int rd_char(void)
2
{
3
        while (!(puart->np_uartstatus & np_uartstatus_rrdy_mask))
4
                ;
5
        return nr_rxchar();
6
}
1
Hardware::DoDisableUARTInterrupt();
2
[Verarbeitung]
3
Hardware::DoEnableUARTInterrupt();
Was, im Schneckentempo ;), zum ersten Testen okay ist.)

Screenshots (und Messdaten) sollen dann wahlweise "roh" wie
gehabt oder per ZModem direkt in eine Datei uebertragen werden
koennen.

Nun stellt sich aber noch ein Problem:  Bei ZModem muss
ich dem Empfaenger den Dateinamen mitteilen.  Wenn der
Dateiname bereits existiert wird je nach Implementation
des Empfaengers unterschiedlich verfahren: HyperTerminal
ueberschreibt wohl ungefragt, lrzsz ueberspringt die Datei.
Immer den gleichen Dateinamen benutzen scheidet also aus.

Optimal waere es natuerlich, wenn wir einen Dateinamen
mit Uhrzeit und Datum generieren koennten, aber das scheidet
wohl auch aus.  Daher wuerde ich vorschlagen, eine mehrstellige,
aufsteigende Zahl anzuhaengen (also z.B. screen-nnnn.dat und
meas-nnnn.dat) aehnlich dem wie es Digitalkameras machen.
Dabei wuerde der letztverwendete Wert fest im Flash
gespeichert und so einen Reboot ueberdauern.

Vllt. hat jemand auch eine andere Idee?

Gruss,
Niklas

von Blue F. (blueflash)


Lesenswert?

Hi Folks, new 0.80 Beta out now!

Wie versprochen die neue Version vollgepackt mit Neuerungen.

Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
ganz perfekt, aber schon ganz ordentlich.

Ich bitte explizit um kritische Rückmeldungen.


@Niklas

Zu Deinem ZMODEM/XMODEM Problem kann ich leider nichts beitragen, aber
vielleicht kannst Du mir helfen. Ich habe Deine Routinen ins Quick Print
Menu eingehängt, aber das Programm scheint keine Verbindung zum DSO zu
kriegen.

Ich starte das Programm in einem Shellfenster und es signalisiert, dass
es wartet. Wenn ich dann den Screenshot starte friert der DSO-Bildschirm
kurz ein - und das war's. Das Programm reagiert aber nicht.

Stell ich mich da zu dusselig an oder hab ich was falsch verstanden?

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Jetzt noch die Datei...

von Blue F. (blueflash)


Lesenswert?

Ach ja,

nicht vergessen erstmal Default Setup zu drücken und dann die Timebase 
zu drehen, damit die neuen Flashwerte für die FFT initialisiert werden.

Gruß Hayo

von Johannes S. (demofreak)


Lesenswert?

Lässt sich das nicht irgendwie automatisieren? Man kann doch bestimmt 
die Firmwareversion irgendwo unter den Einstellungen ablegen, so dass 
sie bei einem Flash nicht überschrieben wird, und dann beim Boot die 
aktuelle gegen die Version im Configbereich prüfen und die ganze 
Initialisierung dann bei Bedarf starten.

Ok, wirr ausgedrückt, aber sicher kommt rüber, was ich meine?

/Hannes

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

ich vermute mal, dass Du vergessen hast dem Programm
stdin auf das serielle USB-Device umzuleiten, ansonsten
liest das Programm nur die Tastatureingaben auf der
Konsole und wartet ewig.

Wichtig ist auch, dass das tty richtig konfiguriert ist,
wichtig ist der raw-Modus, da ich ohne Ruecksicht auf
Verluste (etwa Software-Handshake mit XON/XOFF) 8bit binaer
rausschreibe.

Bei mir mit USB<->RS232 Wandler sieht das z.B. dann so aus:
1
$ stty -F /dev/ttyUSB0 raw 115200 
2
$ ./w2000a-screenshot < /dev/ttyUSB0
3
* Waiting for Screenshot...
4
[Quick Print->Save to PGM]
5
* Found Screenshot Start Marker
6
  - Receiving Plane #01...
7
    Read 12572 bytes.
8
    (another plane follows)
9
[..]
10
* End of Transmission
11
* Total bytes transferred: 62918
12
* Combining...
13
* Done

Ich hoffe es klappt dann bei Dir auch.

Niklas

von elgodil (Gast)


Lesenswert?

@Niklas O.

>ZModem-Implementation....XModem, aber dann haette man den Dateiempfang per Hand 
>anstoszen muessen.

Sach ich doch.... (sonst hättest du ja auch Kermit implementieren 
können...)

>also z.B. screen-nnnn.dat und meas-nnnn.dat

Finde ich super, das Datum + Uhrzeit kriegt die Datei doch eh vom BS...

@alle Entwickler

tolle Sache - so wird aus dem Fehlkauf doch noch ein Schnäppchen

Frohes Schaffen!!

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Niklas O. schrieb:
> Ich hoffe es klappt dann bei Dir auch.

Bei mir klappt es so auf jeden Fall, allerdings sind eine (bzw. mehrere) 
Planes verschoben und es werden Planes mit ins Endbild reinkombiniert, 
die gar nicht auf dem DSO angezeigt werden.

Auf dem angehängten Bild sieht man das verschobene Grid, das Signal 
dagegen ist nicht verschoben (hab es vorher mit dem Testsignal 
ausprobiert, nicht dass du denkst, ich hätte das Rauschen da im Anhang 
mit dem DSO verglichen :D). Und die Plane mit dem Quickmeasusre-Display 
war auf dem Scope selbst nicht sichtbar. Ich hatte vorher mal irgendwo 
Quickmeas kurz ein- und wieder ausgeschaltet, vllt liegt es daran?

/Hannes

von Niklas O. (nevm)


Lesenswert?

Hallo Hannes,

das sollte so natuerlich nicht sein, ich vermute mal, dass da
aus irgendwelchen Gruenden da andere, falsche, Speicheradressen fuer
die Pixeldaten ausgelesen werden -- oder es ist ein Fehler im
Ausleseprogramm.  Offene Menues usw. sind egal.

Ich schaue mir das morgen in Ruhe an, welche Firmwareversion hast
Du denn verwendet?

Niklas

von Johannes S. (demofreak)


Lesenswert?

1.2.BF.0.80

/Hannes

von Blue F. (blueflash)


Lesenswert?

So der Reihe nach:

@Hannes

Das ist eine nette Idee, aber das funktioniert leider nur rückwärts wenn 
überhaupt. Denn wenn ich neuen Speicherplatz für neue Variablen im Flash 
belege, dann steht da erstmal nur irgendein Zufallswert drin. Durch das 
Default Setup und das Verändern der Zeitbasis  werden dann definierte 
Werte ins Flash geschrieben und in Zukunft ist alles ok. Normalerweise 
verwende ich jedesmal neue Adressen, so dass bei Verwendung älterer 
Versionen keine Probleme auftreten. Nur in Ausnahmefällen ändere ich 
bestehende Belegungen (z.B. bei vorherigen Inkonsistenzen).


@Niklas

Ok, dann hab ich mich wohl dusselig angestellt. Ich gebe zu, dass ich 
nicht so der erfahrene Linux Kommandozeilenfreak bin. Zwar habe ich mich 
langsam mit meiner Suse Distribution angefreundet, aber eigentlich bin 
ich eher Windowsbenutzer und durch die FW-Programmierung auf die Vorzüge 
von Linux aufmerksam geworden.

Danke für den Hinweis, ich werde das mal ausprobieren. Grundsätzlich 
scheint es ja zu funktionieren wie ich dem Beitrag von Hannes entnehme.


@Elgodil

Wieso Fehlkauf? Ich hab mir die Teile gekauft weil ich wußte dass es da 
was dran zu optmieren gibt. Und bevor einer fragt: Ja ich habe auch eine 
Frau und Freunde und auch noch andere Interessen  ;-)


@all

Wer nicht so richtig was mit der FFT-Funktion anzufangen weiß - nicht 
verzweifeln, ich arbeite gerade an einer Anleitung mit 
Hintergrundinformationen, die hab ich aber heute nicht mehr 
fertiggekriegt, kommt aber in Kürze.

Gruß Hayo

von Bernd O. (bitshifter)


Lesenswert?

Hayo W. schrieb:
> Hi Folks, new 0.80 Beta out now!
>
> Wie versprochen die neue Version vollgepackt mit Neuerungen.
>
> Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
> ganz perfekt, aber schon ganz ordentlich.
>
> Ich bitte explizit um kritische Rückmeldungen.
Hallo Hayo,

super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was 
mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch 
mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der 
FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024) 
eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und 
rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten 
der beiden Kanäle ging über zunächst einschalten (LED an) und dann 
wiederum ausschalten - dann waren sowohl die LED aus als auch die 
Anzeige des Kanals auf dem Monitor aus.

Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert 
liegt an der fehlenden Anpassung an das neue Grid - oder?

Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin 
(vermutlich noch von der Welec-FW her): "Frequency" heißt dort 
"Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme 
- dafür aber auch in wenigen Sekunden gefixt :-)

Super Arbeit - ist schön zu sehen, wie immer mehr geht!

Gruß,
Bernd

von Niklas O. (nevm)


Lesenswert?

Hallo,

(siehe UPDATE unten)

ich hab' mal die Screenshot-Funktion in der aktuellen 0.80
bei mir getestet, im Verdacht, dass das von Hannes beobachtete
Problem etwas mit Aenderungen in der Firmware zutun hat.

Funktioniert allerdings weiter wie gehabt bei mir.  Ich tappe
auch ziemlich im Dunkeln, woran es bei Hannes liegen kann.

Daher mal frage an alle die es testen koennen:   Funktioniert es
bei euch korrekt?

@Hannes/demofreak:
Kannst Du mir ein Log der RS232 Ausgaben vom Oszi zukommen lassen?
(also stty ttyS0 115200 raw, cat /dev/ttyS0 > log,
Quick-Print->Save to PGM, warten bis Oszi wieder reagiert
und CTRL-C zum beenden von cat).
Dann koennte man eine Seite schonmal ausschlieszen.

UPDATE:  Ich hab' gerade mal frisch FW in RAM eingespielt,
keine Veraenderungen an Schaltern, keine Drehgeber bewegt
und auch kein Default-Setup vorgenommen und direkt Screenshot,
und das Oszi schreibt wild komische Speicherinhalte raus mit
Textausgaben aus dem Programmcode.
Ergab 180984 Bytes (!) (statt 60-65K).

Das ganze durch das C-Programm gejagt, und siehe da, es
sieht erschreckend aehnlich zu Hannes Ausgabe aus.

D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
usw. und nochmal Screenshot testen.

Den Effekt verstehe ich nicht so ganz, wo doch egtl. der RAM-Inhalt
ueberschrieben wird.  @Hayo oder jemand anderes eine Idee?

Gruss,
Niklas

von Niklas O. (nevm)


Lesenswert?

Mhm, nochmal kurz etwas im Firmware Code rumgeschaut:

In Hardware::Set_Vars_Default() werden zwar die von mir
verwendeten Konstanten mit den Speicheradressen der Planes
nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),
was mir doch spontan in Anbetracht der beobachteten
Effekte ziemlich wichtig erscheint nach dem Laden der FW
ins RAM und vor Screenshot ;)
(Installierte FW ist bei mir btw. die Original 1.4)

D.h., Frage an @Hayo damit wohl erledigt.

Mehr bzgl. ZModem und Messdaten vllt. heute Abend.

Niklas

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Niklas O. schrieb:
> D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
> usw. und nochmal Screenshot testen.

Hatte ich selbstverfreilich gemacht, direkt nach'm Boot unten rechts den 
Knopf "Default Setup" und danach oben einmal hin- und hergedreht. Hab 
ich jetzt eben nochmal gemacht, ohne Effekt.

/Hannes

von Niklas O. (nevm)


Lesenswert?

Hallo Hannes,

mhm, komisch...

Lass mir dann doch mal die RS232 Ausgabe vom DSO beim
Screenshot zukommen.

Niklas

von Blue F. (blueflash)


Lesenswert?

Bernd O. schrieb:
> super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was
> mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch
> mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ja, sowas ging mir auch schon durch den Kopf, allerdings ist das 
statisch nicht möglich, da ja die Frequenzachse je nach eingestellter 
Zeitbasis vatiiert. da müßte man also einen Refresh mit einbauen

> Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der
> FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024)
> eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und
> rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten
> der beiden Kanäle ging über zunächst einschalten (LED an) und dann
> wiederum ausschalten - dann waren sowohl die LED aus als auch die
> Anzeige des Kanals auf dem Monitor aus.

Danke für den Tip, ich habe alle Tests nur auf dem Zweikanalgerät 
gemacht weil es den leiseren Lüfter hat. Daher sind mir diese 
Eigenheiten noch nicht aufgefallen.

> Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert
> liegt an der fehlenden Anpassung an das neue Grid - oder?

Ja so ist es, da hab ich bis jetzt auch nichts geändert oder getestet. 
Stefan hatte sich das mal angesehen und war eher nicht so begeistert...

> Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin
> (vermutlich noch von der Welec-FW her): "Frequency" heißt dort
> "Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme
> - dafür aber auch in wenigen Sekunden gefixt :-)

Kann ich ich mal fixen für die nächste Beta.

> Super Arbeit - ist schön zu sehen, wie immer mehr geht!
>
> Gruß,
> Bernd

Danke,

Hayo

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Da ist definitiv noch was krumm.

Wollte direkt nach dem Erstellen des obigen Screenshots nochmal ein Log 
anfertigen, allerdings hat sich das Oszi nach Drücken von "Save to PGM" 
dann aufgehängt. Also rebootet und nochmal versucht, Log zu schreiben.
Dabei wuchs die Logdatei auf über 300kb an, hab das dann ebenfalls 
abgebrochen. Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und 
unten links war ein Softbutton "Cancel" zu sehen, als ich den gedrückt 
habe, bin ich im Quickmeasure gelandet (Cursor sichtbar und unten die 
Einblendung der Messwerte).
Also nochmals rebootet und wieder versucht, Log zu schreiben. Das hab 
ich dann ebenfalls bei reichlich 300kb abgebrochen und hier mal 
angehängt. Das Oszi reagiert nicht, komischerweise war Triggerung auf 
einmal auf PW statt auf Edge, das muss sich im Verlauf des 
Datentransfers irgendwie geändert haben. Musste also wieder rebooten.

Hab jetzt dreimal "Save to PGM" gedrückt, ohne auf der Rechnerseite das 
cat zum Logschreiben zu starten, dabei hängt sich das Oszi nicht auf.

[...]

Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt. 
Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht 
denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine 
Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim 
Rumdrücken auf dem Oszi mehrmals plötzlich im Quickmeasure-Menü 
gelandet, Math hat sich lustig ein- und wieder ausgeschaltet und auch 
die Triggerung war ab und an auf PW. Wenn cat nicht läuft, passiert 
sowas (natürlich) nicht.

Hat cat ein Echo?

/Han-"Der Ratlose"-nes

von Blue F. (blueflash)


Lesenswert?

Niklas O. schrieb:

> In Hardware::Set_Vars_Default() werden zwar die von mir
> verwendeten Konstanten mit den Speicheradressen der Planes
> nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),

Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz 
Bescheid sagen damit ich das einbauen kann.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Hannes

Das hört sich für mich definitiv danach an, dass Daten in die Serielle 
Schnittstelle (Richtung DSO) geschrieben werden. Denn was Du da 
beschreibst ist genau das was man sonst via Terminal und Tastatur 
fernsteuern kann.

Ansonsten hat es sich schon des Öfteren bei unerklärlichen 
Merkwürdigkeiten bewährt einen frischen Flashdump einzuspielen.

Gruß Hayo

von Günter J. (gjung)


Lesenswert?

Johannes Studt schrieb:
> Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt.
> Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht
> denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine
> Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim

ist da irgentwo noch das Echo eingeschaltet ?

Gruß,
Günter

von Johannes S. (demofreak)


Lesenswert?

Dass sich das so anhört, als wenn Daten in die serielle Schnittstelle 
geschrieben werden, ist mir klar. :D Und welches Echo soll wo 
angeschalten sein? Ich verwende cat, dass das echot, wäre mir neu.

stty -F /dev/ttyUSB0 raw 115200
cat /dev/ttyUSB0 > log

Desterwegen bin ich ja ratlos. ;)

Hab vorhin einen weiteren Logversuch bei ca. 300kb Dateigröße 
abgebrochen (das Oszi war noch nicht fertig, sprich: reagierte noch 
nicht) und einfach nicht weiter hingeschaut. Ein oder zwei Minuten 
später stand das Oszi wieder im Quickmeasure. :D

Es lebt.

/Hannes

von Günter J. (gjung)


Lesenswert?

Johannes Studt schrieb:
> stty -F /dev/ttyUSB0 raw 115200

ergänze das mal:
  stty -F /dev/ttyUSB0 raw -echo 115200

Gruß,
Günter

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo Hannes,

Dein Log sieht so aus als haette das DSO wie in einer
Endlosschleife immer und immer wieder Screenshots auf
RS232 ausgegeben.

Wenn ich hergehe, und den ersten aus der Log-Datei
wegwerfe, erhalte ich einen korrekten Screenshot
(siehe Anhang).

D.h.:
1
$ ./w2000a-screenshot < logalt
2
[..]
3
* Total bytes transferred: 59326
4
[..]
5
$ dd if=logalt of=logalt2 bs=1 skip=59326
6
[..]
7
$ ./w2000a-screenshot < logalt2
8
[..]
9
* Total bytes transferred: 61556
10
[..]

(Und das ist der angehaengte Screenshot als .png.
Genau so kann auch verfahren werden um die weiteren
zu extrahieren.)

Wenn man sich die Logdatei im (Hex)-Editor anschaut,
sieht man auch warum da der erste Screenshot bei
Dir kaputt ist.  Nach dem Start-Marker S 0xFF kommen
zwei vmtl. gueltige Bytes und dann die Textausgabe
einer Test-Funktion, gefolgt vom Rest des Screenshots.

Warum die da erscheint/erscheinen kann hab' ich noch
nicht geschaut, vmtl. aus einer ISR heraus.

---

Bzgl. "Oszi aufhaengen" gehe ich daher auch davon aus
das es damit beschaeftigt ist auf RS232 auszugeben.

Da dies nicht passiert wenn kein Programm die Schnittstelle
ausliest deutet tatsaechlich darauf hin, dass da irgendwas
"geschrieben" wird.  Aber cat kann es nicht sein, stdout
und stderr waeren ja die Konsole und nicht /dev/ttyS0.

Auch das unmotivierte Rumspringen in den Menues deutet
darauf hin, denn man kann ueber RS232 das Oszi fernsteuern.
(1-6 sind die Soft-Buttons, i,j,k,l sind die Kanaele usw. usf.)

Ich kann nur mutmaszen, wuerde aber auf falsche Konfiguration
des ttys tippen.  Schau mal nach ob das bei Dir anders aussieht:
1
$ stty -F /dev/ttyUSB0
2
speed 115200 baud; line = 0;
3
min = 1; time = 0;
4
-brkint -icrnl -imaxbel
5
-opost
6
-isig -icanon
7
$ stty -g -F /dev/ttyUSB0
8
0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

> Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und
> unten links war ein Softbutton "Cancel" zu sehen [..]

Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
aufrufe.

---

@alle:
Haben noch andere hier Probleme mit der Screenshot-Funktion?

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo nochmal,

ich hab' leider Eure Nachrichten in der Zwischenzeit
erst jetzt gesehen.

Das echo wie Guenter und Hayo vermuten wird's wohl sein.

@Hayo:
> Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz
> Bescheid sagen damit ich das einbauen kann.

Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
das am sinnvollsten anstelle.

Niklas

von Günter J. (gjung)


Lesenswert?

Niklas O. schrieb:
>
1
  $ stty -F /dev/ttyUSB0
2
  speed 115200 baud; line = 0;
3
  min = 1; time = 0;
4
  -brkint -icrnl -imaxbel
5
  -opost
6
  -isig -icanon
7
  $ stty -g -F /dev/ttyUSB0
8
  0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
9
>

das ist genau die raw Einstellung und da ist echo noch an,
d.h. der tty-Treiber echo(ed) einkommende Zeichen,
deshalb mein Vorschlag noch ein -echo beim stty Befehl anzuhängen.

Gruß,
Günter

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Kaum macht man es richtig, geht es plötzlich. Komisch. :D

@Günter: danke, wieder was gelernt. Das -echo hat's gebracht.

/Hannes

von Johannes S. (demofreak)


Lesenswert?

Niklas O. schrieb:
> Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
> aufrufe.

Ah, guter Hinweis. Das könnt ich sicher mit abfangen bzw. zumindestens 
versuchen, herauszubekommen, ob ich ins Menü oder wirklich in den 
GERMS-Monitor "reingucke".

Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...? 
grübel
Ich werd echt alt.

/Hannes

von Niklas O. (nevm)


Lesenswert?

Hallo Guenter,

Du hast absolut recht.

Ich nehme jetzt stark an, dass der Effekt den ich heute Morgen beim
eiligen Reproduzier-Versuch hatte genau darauf zurueckzufuehren ist,
ich hab' naemlich das ganze samt Dongle auch am Laptop getestet...

Niklas

von Blue F. (blueflash)


Lesenswert?

Niklas O. schrieb:

> Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
> ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
> im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
> das am sinnvollsten anstelle.
>
> Niklas

Jupp, das machst Du in flash_t.cpp:

- Funktion AMDFlash::Write_Config_Flash() Zeile 1408 schreibt Daten in 
den Konfigbereich. Da sind noch einige Plätze frei von buf[268] bis 
buf[299]. Da könntest Du Dir einen von greifen.

- Funktion AMDFlash::Read_Config_Flash() Zeile 1800 liest die Daten 
wieder ein.

Da ich mal annehme, das Du nicht jedesmal den gesamten Konfigbereich 
schreiben und lesen willst, könntest Du die Funktionen einfach als 
Vorlage für eigene Routinen nehmen mit denen Du dann Deine Daten ins 
Flash schreibst und sie wieder ausliest.

Gruß Hayo

von Cra Z. (crazor)


Lesenswert?

Johannes Studt schrieb:
> Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...?

Ja, bitte beim Dumping des Flashes einen Plausibilitätscheck einbauen: 
Falls die Anzahl der Zeichen in einer Zeile nicht stimmt (zu viele oder 
zu wenige), die Zeile erneut abfragen.
Ich hatte ja schon festgestellt, dass der GERMSmonitor leider keine 
Prüfsumme ausspuckt, aber mein konkretes Problem ist ja nicht die 
Verfälschung, sondern nur das Verschlucken oder Verdoppeln von Zeichen. 
Schade, dass nichtmal ein Parity-Bit verwendet wird.

> Ich werd echt alt.

Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein 
=)


@Hayo und co, bzgl. Flash:

Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das 
FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE 
Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn 
man auf Default Setup geht oder deine Firmware einspielt oder was auch 
immer. Falls das nicht der Fall ist, sollten wir uns bezeiten schonmal 
einen Up- und Downgrade-Weg zwischen deiner und unserer Firmware 
überlegen.

von Blue F. (blueflash)


Lesenswert?

Daniel H. schrieb:
> Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein

Genau meine Taktik!


> @Hayo und co, bzgl. Flash:
>
> Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das
> FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE
> Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn
> man auf Default Setup geht oder deine Firmware einspielt oder was auch
> immer.

- wenn eine neue Firmware eingespielt wird, dann wird auch nur der
  Progrmmbereich beschrieben. Alle anderen Bereiche bleiben unberührt.

- bei Default Setup wird überhaupt nicht auf den Flashspeicher
  zugegriffen, weder lesend noch schreibend, sondern es werden nur
  hart codierte Werte geladen.

- Der Flashspeicher wird eigentlich überhaupt nicht initialisiert.
  Es werden lediglich einige Konfigwerte hineingeschrieben bzw.
  ausgelesen. Desweiteren werden einige Bitmaps beim Start geladen.
  Es können Signal im Speicher abgelegt werden, das wars auch schon.

Gruß Hayo

von Cra Z. (crazor)


Lesenswert?

Okay, aber ich gehe eben von dem Fall aus, dass der Flash komplett von 
uns verwurstet wurde und jemand nun zurück zu deinem Branch wechseln 
will. Wir werden mit Sicherheit nicht die Config-Speicherbereiche 
unangefasst lassen (können|wollen), daher meine Anfrage was passiert, 
wenn dort "Müll" steht (oder Nullen oder so).

von Blue F. (blueflash)


Lesenswert?

Dann startet das DSO erstmal völlig undefiniert. Im ungünstigsten Fall 
hängt es sich auf -aarrgh, ansonsten hilft Default Setup und einmal an 
der Timebase drehen, dann ist der Konfigbereich wieder initialisiert. 
Das gilt allerdings nicht für den Bereich in dem die Bitmaps abgelegt 
sind, die lassen sich nur durch das Einspielen eines Flashdumps wieder 
restaurieren.

Gruß Hayo

von Stefan (Gast)


Lesenswert?

Hallo,

FFT funktioniert wunderbar. Wenn dann noch die Beschriftung kommt und 
evtl. ein Cursor ist es perfekt.

Hab heute was gesehen, was ich auch haben möchte ;-) Der Prof. hat sich 
letzten Signalverlauf gespeichert und im Hintergrund zum aktuellen 
Signal eingeblendet. Sehr praktisch, wenn man eine Veränderung 
visualisieren möchte. Hoffentlich reicht der Speicher dafür noch g

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Das hört sich gut an - gleich in die Wishlist eintragen!

Hayo

von Kurt B. (kurt)


Lesenswert?

Hallo Niklas,
mach die Dateinamen nicht zu lang. 8.3 muss reichen.

Hast du brauchbare und verständliche Infos zum ZMODEM?

Gute Arbeit!

Mfg,
Kurt

von elgodil (Gast)


Lesenswert?

für Telix unter DRDOS??  ;-))

von Kurt B. (kurt)


Lesenswert?

Nö, für den USB-Host oder das speichern auf SD-Karte. Viele fertige 
Routinen mögen nur die kurzen Namen.

von Blue F. (blueflash)


Lesenswert?

@Niklas

Nach Deinem Tip für die stty-Umleitung hat es dann auch bei mir 
geklappt. Sehr praktisch. Ich mache damit gerade die FFT-Doku.

Prima Arbeit!

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Kurt,

> Hast du brauchbare und verständliche Infos zum ZMODEM?

ich schaetze mal Du spielst auf die IMHO nicht sonderlich
gute Originalbeschreibung von Forsberg an:
http://pauillac.inria.fr/~doligez/zmodem/zmodem.txt
(was anderes habe ich auch nicht gefunden)

Wenn man sich dazu vllt. noch ein paar fertige Implementationen
anschaut (andere als (l)rzsz) blickt man dann schon durch.

Gruss,
Niklas

von Roberto (Gast)


Lesenswert?

Hallo
Habe die 0.80 probiert.
Funktioniert sehr gut :-) Auch das FFT :-)-- > Gratuliere!!
(Freue mich schon auf die Doku dazu :-) )
Was mir so beim Testen aufgefallen ist:
Das 1kHz Testsignal schaut mit 200-100ms/Dif fast genau so aus wie bei 
1ms/Dif. :-(
Bei einem Analogen Osci würde man bei 100ms/Dif nur einen großen Balken 
sehen...
Entsteht die falsche Anzeige durch das abtasten der ADC? Ist das 
DSO-bedingt?
Bei anderen DSO auch so?
Könnte man das Rechnerisch irgendwie besser auswerten?

l.G. Roberto ( W2024A)

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

ich teste gerade mit der 0.75 und auch da ist ein Fehler in der 
Zeitbasis, so wie Roberto es beschrieben hat.
Beim Test mit dem 1kHz Testsignal ergibt sich bei mir folgendes Bild:
Mit den Timebases bis 20ms/Div ist alles i.O. - Die Anzahl der 
dargestellten Schwingungen stimmt mit Periodendauer des Signals überein.
* Bei 50ms/Div wird mir eine Periodendauer von 250ms suggeriert- eine
  Periode geht über 5 Div!
* Bei 100ms/Div eine Periodendauer von 50ms.
* Bei 200ms/Div wieder eine Periodendauer von 250ms.
Bei noch langsameren Timebases zieht sich der Fehler konsequent weiter 
durch.

Einmal abgesehen davon, dass eine Darstellung mit TB > 20ms/Div bei 
unserer Auflösung nicht möglich ist (weniger Pixel zur Darstellung als 
Schwingungen des Signals), so liegt wohl doch irgendwo noch ein 
Berechnungsfehler bei den langsamen TB vor.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

@Roberto + Bruno

Danke für den Hinweis. Das muß ich mal ausprobieren. Ich gebe zu, dass 
die langsameren Zeitbasen nicht so oft zum Einsatz kommen und daher 
Fehler auch nicht so schnell auffallen.

Gruß Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, dafür hier etwas Lesestoff.

Ich weiß, dass viele von Euch mit dem Thema vertraut sind, aber es gibt 
wohl auch noch einige die sich damit noch nicht so beschäftigt haben 
oder bei denen es schon länger her ist. So oder so ist es aber wohl für 
alle ganz interessant die Theorie mal am eigenen W20xxA 
nachzuvollziehen.

Leider ist das Ganze doch etwas umfangreicher geworden, so dass ich 
erstmal nur eine deutsche Version fertiggestellt habe.

Sollte ich mich unverständlich ausgedrückt oder was falsches geschrieben 
haben - nur keine Hemmungen, immer raus damit.

Viel Spaß beim Lesen und Ausprobieren

Hayo

von Blue F. (blueflash)


Lesenswert?

Oh,

hab schon einen Fehler entdeckt! Auf Seite 8 ist natürlich das Doppelte 
von 24,414 nicht 48,414 sondern 48,828. Ich hoffe Ihr könnt damit leben.

Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Das klappt doch schon sehr gut! Die Cursor sind noch in Arbeit?

von Niklas O. (nevm)


Lesenswert?

Hallo,

kleines Update mal von mir:  Stellt sich raus, dass meine
schnelle Idee vom Montag mit dem ersetzen der ISR fuer
den UART (Hardware::ISR_UART()) so nicht funktioniert.

Liegt daran wie die Original ISR in der Firmware benutzt
wird:  Zeichen holen, Zeichen in Wust von if-Abfragen
in MenuKey Wert umsetzen, dann Buttonhandler() mit
MenuKey aufrufen.

Hardware::Buttonhandler() macht dann wiederum nen
select/switch-case-Konstrukt ueber MenuKey und ruft
evtl. darin noch weitere Funktionen auf.

Falls der Groschen noch nicht gefallen ist:  Die ISR
ist zu diesem Zeitpunkt immer noch nicht verlassen!

..und sie wird natuerlich auch so lange sie nicht
fertig ist nicht nochmal aufgerufen.

Das ist, gelinde gesagt, nicht die uebliche Art,
wie man ISRs benutzt.  Da ich nicht wirklich Lust
hatte den bestehenden Code weiter als noetig zu
lesen, ist mir das auch erst aufgefallen, als ich
mich wunderte, warum meine ISR nie zum Zuge kam.

Eine Loesung ohne den Original-ISR umzustricken
sehe ich im Moment nicht.  Da es, wenn ich das
richtig sehe, in TomCat.cpp eine Main-Loop gibt,
waere es das einfachste, wenn im ISR nur eine
Variable geschrieben wird und dann ein Handler
die Eingabe interpretiert (wie das mit mehreren
zwischenzeitlich eingegangen Eingaben und
Prioritaet aussehen sollte habe ich noch nicht
ueberlegt).

Um das gewohnte alte Verhalten beizubehalten
koennte man alle Interrupts fuer die Laufzeit
der jeweiligen Funktion deaktivieren.

Bevor ich jedoch da einen chirurgischen Eingriff
beginne moechte ich noch Eure Meinung und Ideen
einholen.

@Hayo:
Hab' mal kurz durchgeblaetter, schoene Anleitung!

Gruss,
Niklas

von Blue F. (blueflash)


Lesenswert?

Die nächsten Punkte auf der Roadmap sind:

- FFT Feinschliff - da warte ich mal auf Rückmeldungen
- Cursorfunktion an das neue Grid anpassen
- Cursor für die FFT nachrüsten
- Quick Measure komplett überarbeiten

Hayo

von Blue F. (blueflash)


Lesenswert?

@Niklas

Ich gebe Dir Recht, die Implementierung der ISR ist recht 
gewöhnungsbedürftig. Da es so viele andere Baustellen gab hatte ich mich 
darauf beschränkt den Buttonhandler (es gab früher nur einen einzigen!) 
aufzuteilen in einen Haupt-Buttonhandler und jeweils einen für die 
Funktionstasten. Dadurch kann man sich immerhin schon mal besser 
orientieren. Technisch gesehen hat das natürlich nichts geändert.

D.h. auch hier besteht noch Optimierungsbedarf, allerdings schien mir 
das bislang nicht so dringlich wie die anderen Themen.

Hayo

von Stefan (Gast)


Lesenswert?

Hallo Hayo,

Quick Measurement ist fast gefixt. Fehlt noch eine Kleinigkeit, dann 
müsste es soweit wieder klappen.

Stefan

von Blue F. (blueflash)


Lesenswert?

Ach ja noch einer:

Das mit der ISR hatte der Programmierer auch beim Rollmode so gemacht - 
weswegen das wohl auch nicht funktioniert hat. Ich konnte es zuerst gar 
nicht glauben als das erste Mal gesehen hab dass die komplette Logik im 
ISR des Timers abgefackelt wurde. Bei meiner Implementierung stehen 3 
Zeilen im ISR - das war's.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Cool! Ich hätte gedacht dass erst die Cursor geradegebogen werden müssen
bevor da ein sinnvolles Vorgehen möglich ist.

Hayo

von Stefan (Gast)


Lesenswert?

Jo, die Cursor zicken gerade etwas. Die waagerechten Cursor sind OK. Nur 
die senkrechten zicken gerade. Haben einen minimalen Versatz.

von Niklas O. (nevm)


Lesenswert?

Hallo,

als Ergaenzung noch, da das vllt. nicht deutlich
rueber gekommen ist:

ZModem geht aufgrund des Protokolls und der noch
fehlenden Moeglichkeit, (alle) vom Terminalprogramm
ueber RS232 reinkommenden Zeichen zu lesen, erstmal
ohne weiteres nicht.


Messdaten einfach rauswerfen geht natuerlich trotzdem,
analog wie dies beim Screenshot gemacht wird.

Diesbzgl. hatte ich mir schon ueberlegt, die Parameter,
also Kanal, Zeitbasis usw., in Plaintext gefolgt von
den Samples, je als Byte, zu uebertragen und wieder mit
einem Programm fertig interpoliert in CSV oder gnuplot
Script zu wandeln.

Um ein paar zu uebertragende Bytes zu sparen koennte
man vornehmlich Deltas zwischen zwei Samples uebertragen,
z.B. 4 Bit breit.  Inwieweit sich das ueberhaupt lohnt
muesste ich mal austesten -- in Anbetracht der maximal
16K*4 Samples die anfallen.

Meine Frage waere dann auch jetzt, was ihr Euch fuer
Ausgabeformate wuenschen wuerdet und ob das
Vorgehen insgesamt so in Ordnung ist.


Mein Plan sieht also dann so aus:
- Messdaten rausschreiben und Ausleseprogramm
- Screenshotprogramm: BMP-Dateien schreiben
  (evtl. auch PNG, falls ich eine einfache Moeglichkeit finde)
- Ausleseprogramme auch fuer Windows und fertig kompiliert
- Firmware anpassen damit ZModem geht

(in keiner festen Reihenfolge, vmtl. nun ZModem zuletzt)

Niklas

von Kurt B. (kurt)


Lesenswert?

Das Ausleseprogramm für Windows bastele ich gerade. Ist nicht schön, 
funktioniert aber und wird heute hoffentlich noch fertig.

von Blue F. (blueflash)


Lesenswert?

@Bruno + Roberto

Die langsamen Zeitbasen sind ok. Habe gerade noch mal geprüft. Was Ihr 
da gesehen habt ist Aliasing in seiner reinsten Form, d.h. 
Scheinfrequenzen pur (siehe meine Veröffentlichung von heute). Wenn Ihr 
in den Programming-Maps in der Timebase-Tabelle nachseht werdet Ihr 
fündig.

Die kleinste Zeitbasis mit der ein 1 KHz Signal noch dargestellt werden 
kann ist 20ms/div. Bei den langsameren Zeitbasen wird das Abtasttheorem 
verletzt (insofern hat Roberto schon Recht, dass es sich um eine 
DSO-spezifische Sache handelt). Und zwar müßt Ihr im Zeitbereich immer 
berücksichtigen das zu der angezeigten Abtastrate noch der 
Timebasefaktor kommt um das dass Signal reduziert wird.

Die tatsächliche Abtastrate ist dann also angezeigte Sa/s durch 
Timefaktor. Bei 50 ms/div liegt die Abtastrate aber nur noch bei 5KSa/s 
durch 5 = 1KSa/s also halb so viel wie eigentlich minimal nötig.

Bei den noch langsameren TB wird das natürlich noch extremer, so dass 
täuschend echte Signale mit einer völlig anderen TB angezeigt werden. 
Ihr habt ein wirklich schönes Beispiel dafür gefunden ;-)

Das Ganze gilt übrigens nicht für die FFT. Hier bleibt der 
Timebasefaktor unberücksichtigt, so dass nur die tatsächlich angezeigte 
TB maßgeblich ist.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

hab deine o.a. Roadmap gelesen. Du vergisst nicht das Fixing des zeitl. 
Versatz zwischen den Kanälen?

gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

@Bruno,

nein, das habe ich auf dem Zettel. Allerdings sind nicht allzuviele 
Rückmeldungen gekommen verglichen mit den Downloadanzeigen wenn hier was 
veröffentlicht wird.

Die Korrektur ist eigentlich auch nicht sonderlich dramatisch, ich 
wollte sie nur gleich in die C-Routinen von Guido mit einfließen lassen. 
Da weiß ich aber nicht ab wann diese tatsächlich die Assemblerroutinen 
ersetzen werden.

Ich könnte das natürlich, wenn starker Bedarf besteht, auch vorher 
anders implementieren.


@Bernd

Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke 
nochmal für den Hinweis

Hayo

von Stefan (Gast)


Lesenswert?

Also QuickMeasurment hat gerade in Grundzügen funktioniert. Auch die 
Cursor. Average, Pk-to-Pk und Frequenzbestimmung haben funktioniert. 
Damit müsste eigentlich auch der Rest gehen. Hat funktioniert, weil ich 
das ganze noch in eine Schleife für alle 4 Kanäle packe und dadurch 
einige Änderungen nötig sind. Weiß nicht, obs heute noch was wird. 
Schaut aber gut aus ;-)

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

ja ok, ich hatte die blöden Timebase- Faktoren in meiner geistigen 
Rechnung nicht berücksichtigt! Daran sieht man, wie ungünstig die 
Sample-Raten in den einzelnen TB's gewählt ist. Der geringe Prozentsatz 
mit dem der zur Verfügung stehende Samplespeicher (16384 Samples) 
ausgenutzt wird, ist ein anderes Zeichen dafür.
Vor dieser TB- Anpassung standen wir im VHDL Design auch vor Kurzem ;-).
Tja, das Aliasing lässt sich leider nicht vermeiden, ein typisches ADC 
Problem.
Die Korrektur des zeitl. Versatz kann aus meiner Sicht noch warten, 
sollte halt nicht in Vergessenheit geraten. Schade das es keine To-Do- 
und Bug- list mit öffentlicher Möglichkeit von Ergänzungen gibt- sieht 
man einmal von der Wishlist unter Sourceforge ab.

Gruß, brunowe

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.

Erklärung steht in der liesmich.txt.

Ich bräuchte eine Rückmeldung, ob die Farben korrekt wiedergegeben 
werden.
Wie gesagt, meine Ergänzungen sind etwas buggy und enthalten schwere 
Designfehler aber das Prog verursacht wenigstens keinen Bluescreen. ;-)

von Blue F. (blueflash)


Lesenswert?

@Kurt

Prima, leider komme ich erst übermorgen zum Testen da ich bis dahin 
etwas beruflich eingespannt bin. Hab's mir aber schon mal runtergezogen.


@Bruno

Ja das hatte ich vergessen auf meiner ToDo Liste aufzuschreiben, die 
Timebasesteuerung wollte ich mal komplett umstellen. Ich sehe nämlich 
keinen vernünftigen Grund, warum die Samlerate nicht besser genutzt 
werden sollte. Keine Ahnung was sich der Programmierer dabei gedacht 
hat. Zuerst vermutete ich dass da irgendein tieferer Sinn hintersteckt, 
den ich nicht durchschaue, aber mittlerweile nach längerem Umgang mit 
dem Coding weiß ich dass es wohl eher nicht so ist.

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

So Hayo,

habe dir unter SF meine aktuellen Änderungen für QuickMeasurment 
eingespielt. Viel Spass beim mergen. ;-) War doch sehr umfangreich. 
Dafür sind aber auch die 4 Kanäle in EINER Schleife zusammengefasst und 
nicht wie vorher jeder einzeln. Ich bin zufrieden ;-)

Bei mir geht derzeit auf beiden Kanälen (theoretisch auf allen 4, ich 
hab aber blos zwei, also fleißig Bericht erstatten) das Messen von 
Average, Duty Cycle, FallTime, Frequency, Maximum, Minumum, Peak-Peak, 
Rise-Time, +Width, -Width. Die Auswertung von einem Summen- oder 
Differenzsignal geht noch nicht.

Ich kenn mich mit dem Ändern der Menüsteuerung nicht aus. Aber wäre es 
möglich, die 3 Felder einzeln zu löschen?. Außerdem besteht prinzipiell 
jetzt die Möglichkeit die Genauigkeit einzustellen. (Auf kosten der 
Geschwindigkeit) Könnte man evtl. über das Menü ein und ausschalten.

Gruß,

Stefan

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Und für alle andern auch noch die Ram-Datei

von Kurt B. (kurt)


Lesenswert?

Nochmal @Niklas:
ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch 
ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze 
Pause einzulegen.

Zum Zielsystem:
Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die 
Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.

Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von 
einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte 
Ausgabe möglich?

Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den 
wichtigsten Parametern als txt File welches später mit einem PC Programm 
zu einem großen Bild zusammengesetzt werden kann.

PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet 
werden.

Tipps von einem Ahnungslosen:
BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte 
Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

von Bernd O. (bitshifter)


Lesenswert?

Hayo W. schrieb:
> @Bernd
>
> Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke
> nochmal für den Hinweis
Super! Ich hatte gestern Abend noch etwas gespielt und gemerkt, dass der 
Fehler nicht immer auftritt und schon überlegt was zuvor anders war...

Beim Trigger bzw. seiner Darstellung habe ich noch ein paar Dinge 
bemerkt, die man verbessern könnte:

1) Wenn man im "Aquire"-Menü (*) zwischen Normal und Averaging wechselt 
wird der Averaging-Modus wird mit einem Durchmessersymbol dargestellt. 
Dieses Symbol verschiebt den Triggerpfeil um ca. 1/2 Symbolbreite nach 
unten (ca. 10 % eines Div). Da die numerische Anzeige rechts oben 
unverändert bleibt gehe ich davon aus, dass es nur ein 
Darstellungsproblem ist.

(*) Richtig wäre "Acquire" - aber den Druck des Bedienpanels wird man 
wohl nicht per SW ändern können ;-)

2) Die Pfeilspitze des Triggersymbols ist auch im Normal-Mode um ca. 
zwei Pixel zu tief. Bei beispielsweise 1 V/Div liegt der Trigger erst 
bei 1.04 V optisch auf der 1 V Linie.
(Ich weiß, ist pedantisch - aber so etwas sticht mir leider direkt ins 
Auge).

3) Die numerische Anzeige des Triggerlevels ist bei 2 V/Div manchmal 
falsch:

Ausgangssituation: 1 V/Div mit Triggerlevel 500 mV. Beim Umschalten auf 
2V/Div wird rechts oben ein Triggerlevel von "1.00 mV" angezeigt. 
Optisch per Pfeil dargestellt sind 1 V (also Volt statt Millivolt). Wenn 
man auf 5V/Div weiterschaltet wird der Level korrekt mit "2.50 V" 
angezeigt. Wenn man nun wieder auf 2 V/Div zurückschaltet, dann wird 
auch in diesem Bereich nun korrekterweise "1.0 V" angezeigt.
=> Es macht also für die Anzeige des Triggerlevels einen Unterschied, ob 
man von "oben" oder von "unten" in den 2V/Div Bereich kommt. Die 
restlichen Bereiche waren soweit ich gesehen habe O.K.

4) Wurde so weit ich weiß schon einmal angemerkt und könnte auch ein 
Feature und kein Bug sein ;-):
Intuitiv hätte ich erwartet, dass ein eingestellter Triggerlevel von 
beispielsweise 500 mV erhalten bleibt wenn ich den V/Div-Bereich 
wechsle. Im Normal-Mode ist es für mich gewöhnungsbedürftig, wenn man 
die Y-Auflösung ändert und erst mal "blind" ist bis man am Trigger 
gedreht (oder in den Auto-Modus gewechselt) hat.

Freue mich schon auf die nächste FW.

Gruß,
Bernd

von Guido (Gast)


Lesenswert?

Hallo,

da ist ja eine Menge aufgelaufen. das macht Spaß!

@ niklas: Nach meiner Meinung reicht eine einfache binäre
Übertragung. Eventuell die Textübertragung konsequent als
Kommentar markieren (z.B. mit "#"), dann können zur besseren
Unterscheidung auch die Kanallisten durch kurze Kommentare
getrennt werden. Unsere Perl-Fans haben dann die Möglichkeit
alle denkbaren Filter zu implementieren.

@ Hayo: Zwei grundsätzliche Überlegungen.

1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
Nachteil erkennen, die Änderungen in Set_Switches sollten kein
Problem sein, nur die Grafik muss angepasst werden.

2.) Bei Timebase > 6 wird  nur jeder 4. Wert ausgewertet.
Wenn du eh an die Timebaseeinstellungen gehen möchtest,
solltet wir das gleich ändern. Dann werden unabhängig von
der Timebase immer 16k-Samples übertragen. Die Faktoren der
ProgrammingMaps werden dann vervierfacht, sonst ändert sich
nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
mit 16k-Samples ausgeführt werden kann, was nicht nur  die
zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
bringt,

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Stefan

Super, ich werde mir das mal übermorgen ansehen. Grundsätzlich kann ich 
Dir das Menü beliebig einrichten, Du müßtest nur genau beschreiben wann 
was wo gesetzt oder gelöscht werden soll (welche Variablen und so).



@Bernd


Das nenne ich einen detailierten Fehlerbericht. Nicht übel. Etliche 
Punkte fallen derzeit allerdings unter die Kategorie "minor problems". 
Daher denke ich werden sie entweder mal so zwischendurch behoben (was 
bei mir des öfteren vorkommt), oder es wird etwas dauern da es immer 
noch einige größere Baustellen gibt. Auf jeden Fall danke für die 
Hinweise.

Gruß Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Kurt,

> ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch
> ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze
> Pause einzulegen.

ZMODEM war ja nur dafuer gedacht um ein gaengiges Terminalprogramm
auf RS232 lauschen koennen zu lassen und automatisch Dateien vom
Oszi zu empfangen, ohne erstmal weitere Software zu installieren.
Mit XMODEM geht das leider nicht, weil da dummerweise im Protokoll
die Moeglichkeit fehlt auf Senderseite den Empfang direkt anzustoszen.

Mit dem XON/XOFF Software-Handshake geht es Dir primaer um die
Uebertragung an einen uC, oder?  Kann ich Dir einbauen, wie
beschrieben die UART ISR steht allerdings noch etwas im Weg.

> Zum Zielsystem:
> Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die
> Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.
>
> Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von
> einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte
> Ausgabe möglich?

Ja klar, das ist natuerlich moeglich.  Der Grund warum ich den Umweg
ueber die Planes mit RLE Kompression gegangen bin ist nur dass ich
dadurch auf ~15kB s/w und ~65kB Farbe komme (und mit minimalem
Programmcode).

Das DSO kann natuerlich auch gleich die Planes fertig ueberlagern
und eingefaerbt als PPM ausgeben, waeren auch nur geschaetzt nen
Dutzend Zeilen Code plus einige Konstanten mehr -- nur kaemen wir
da auf 640*480*3 = 900 kB. (Farbkomponenten kleiner als mit einem
Byte auszudruecken ist leider nicht spezifiziert bei PPM (setzt man
im Header < 255 muss man dennoch ein volles Byte ausschreiben pro 
Farbkomponente).)

Nehmen wir unkomprimiertes BMP mit 4 Bit Palette sind's noch ~150 kB.
Dazu kommt noch ein wenig Rechenzeit, Bufferung bei der Ausgabe fehlt
da auch noch...

Wenn Dir das nicht zu langsam ist ergaenze ich das gerne.  Kann
man ja so machen, dass das Ausgabeformat im Quick-Print Menue
und per RS232 fuer den Anwender/uC konfigurierbar ist.

> Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den
> wichtigsten Parametern als txt File welches später mit einem PC Programm
> zu einem großen Bild zusammengesetzt werden kann.

Mit txt File meinst Du also direkt Menschen-lesbar?  Auch kein
Problem, nur in welchem Format genau muesste man sich einigen.

> PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet
> werden.
>
> Tipps von einem Ahnungslosen:
> BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte
> Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

Ja, RLE geht optional.  Die Spec dazu hab' ich aber noch nicht
angeschaut.  Bei den Screenshots hatte ich schonmal verglichen und
Gimp erzeugte mir unter Verwendung einer Palette und Kompression
ein iirc. 48kB BMP File.  Da liege ich mit 65kB ziemlich gut dabei,
mit einem sehr simplen Algo wo sicher noch was rauzuholen waere.


Also, zusammenfassend:
 - fertiges PPM oder BMP (unkomprimiert erstmal) rausschreiben:
     kein Problem, nur wenige Zeilen zusaetzlicher Code plus
     gesteigerte Rechenlaufzeit
 - Software-Handshake mit Blockung:
     auch kein groszes Problem, beschriebene Problematik mit der
     jetzigen UART ISR steht nur bloed im Weg
 - Messdaten gleich fertig menschenlesbar raus:
     genauso, muessten wir uns nur auf ein Format einigen
     (z.B. CSV, welche Felder, Anordnung)


Mit Massenspeicher meinst Du sowas wie eine SD-Card, per SPI
angesprochen?  Das faende ich klasse.  Besonders wenn man dann
ein schoenes Gehaeuse dazu macht koennte das fast "nativ" zum
DSO gehoerend aussehen.

Gruss,
Niklas

von Kurt B. (kurt)


Lesenswert?

Richtig, XON/XOFF für den µC. Brauchst du aber noch nicht einzubauen, 
wir brauchen erstmal ein richtiges Konzept.

Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen. 
Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es 
nicht werden.
Also müsste man im Oszi ein PNG oder JPG basteln.
Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Massenspeicher als SD-Karte oder mein Favorit der USB-Stick.
Ganz verrückte könnten die Daten per RFM12 Modul durch die Gegend 
funken. ;-)

Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt 
vom FPGA aus. Das lässt sich aber vorerst nicht nachrüsten, außerdem 
fehlen ja den 2-Kanalgeräten die 5? herausgeführten Pins am FPGA.

PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz 
drin.

von Roberto (Gast)


Lesenswert?

Hallo Kurt
>Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.
Das Programm funktioniert bei mir.
(XP, W2024A, FW 0.80)
Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
Grösse der Dateien 901KB

Aber blöde Frage: Was kann ich jetzt mit den Files machen?
Kann es mit keinen meiner Programme öffnen ?
Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?

l.G. Roberto

von Niklas O. (nevm)


Lesenswert?

Hallo Kurt,

> Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen.
> Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es
> nicht werden.

Theoretisch sollte es ja von der Schnittstelle her bei den 115200
Baud wesentlich schneller gehen (im Prinzip grob 10 Sekunden).
Wieviel Anteil da Rechenzeit hat und etwaiges Warten mangels
fehlender Bufferung habe ich nocht nicht genau geschaut.
Bufferung kaeme ohnehin bei ZMODEM wg. Blocking.

Rechenzeit scheint mir schon enorm zu sein.  Wobei ich vllt.
mal explizit sagen sollte, dass ich mich da nicht besonders
klever anstelle und jeden Pixel einzeln aus einer Speicherstelle
zurueck fuehre.  Das laesst sich mit einer Portion Bitmask
Voodoo sicher optimieren, uebersteigt jedoch derzeit meinen
Horizont (Hilfe wird dankend angenommen :)).

> Also müsste man im Oszi ein PNG oder JPG basteln.
> Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Ne die Seite kannte ich noch nicht, gerade kurz bissl rumgeklickt,
sieht nett aus.  Schaue ich spaeter mal genauer.

> Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt
> vom FPGA aus. [..]

Das waere natuerlich noch besser wenn ihr das hinbekommt.

> PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz
> drin.

Oh, noch besser :)

@Roberto:
> Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
> Grösse der Dateien 901KB

Ja das passt, bei S/W werden die 16 Planes direkt auf dem Oszi
kombiniert.  ~900KB passt auch, sind unkomprimierte 640x480
Pixel mit 24 Bit Farbtiefe.

> Aber blöde Frage: Was kann ich jetzt mit den Files machen?
> Kann es mit keinen meiner Programme öffnen ?

Ja, unter Windows ist PPM leider kein gaengiges Format, aber
fuer (ohnehin meist faule ;)) Programmierer ein extrem
einfach zu erstellendes Format.

Daher laengst meine Ansage fuer Windows-User auch BMP
zu generieren (was das naechst einfache Format waere ;)).

> Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?

Ja, natuerlich.  Steht auch schon auf meiner Agenda.

Kurt oeffnet die PPM mit Ifranview, iirc.  Gimp sollte auch gehen.
Wobei ich natuerlich jetzt niemanden dazu bringen will nur
deswegen zusaetzliche Software zu installieren.

BMP-Ausgabe wird wie gesagt sicher in Kuerze folgen.

Gruss,
Niklas

von Blue F. (blueflash)


Lesenswert?

@Stefan

Nachdem ich jetzt eine halbe Stunde lang bei SFN rumgeklickt habe und in 
der Zeit nur zwei Sourcedateien geladen bekommen habe - kannst Du mir 
die Sourcen hier hochladen, ich hab keine Lust mehr mich damit weiter 
rumzuärgern. Das ist ja langsam und zäh wie Kaugummi mit dem Trac-Tool.

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

kann ich machen. Allerdings erst heute Abend.

Gruß,
Stefan

von Michael W. (slackman)


Lesenswert?

@Roberto & all,
ich werde mich um eine neue Win Applikation für das DSO kümmern (Anzeige 
und Steuerung des DSO), kann aber noch nicht sagen, unter welchem 
Framework. Lazarus vielleicht? Ist frei und auch für Linux/OSX 
verfügbar. Müsste mich aber erst einarbeiten.

Michel

von Niklas O. (nevm)


Lesenswert?

Hallo,

so, ich hab' jetzt mal getestet wo da egtl. die Minute herkommt,
die so'n 65kB Dump braucht.

Erst einmal ist es kein Problem nur unter Verwendung von putchar()
da volle 10kB/s rauszuschoeffeln.  Das ist schonmal gut.

Nicht so gut ist aber, dass die grob restlichen 50 Sekunden
tatsaechlich voll und ganz in den Pixelschleifen verbracht
werden.  Dazu hab' ich nur die putchar() entfernt, RLE
wird weiter gemacht.  Auch bei B/W braucht das Oszi noch
fast 15 Sekunden nur dafuer.

NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...
Bislang vermutete ich verschenkte Zeit indem ich ungebuffert
rausschreibe, ist aber irrelevant...

Wenn man sich mein diff (aus den geposteten .tgz) nochmal
anschaut sieht man, dass da quasi "nix" passiert.  Natuerlich
ist wie in meinem letzten Posting gesagt die Pixelwandlung
nicht optimal, aber auch nicht so schlimm.

Damit dann gar PNG mit Deflate auf dem NiosII zu machen
koennen wir m.E. gleich mal komplett vergessen.

Sollten wir vllt. einfach die Speicherbereiche unveraendert
binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
sind, und alles auf dem Computer erledigen?
(den Code dafuer haben wir ja schon...)

Und auch Fragen an die Leute die schon laenger mit NiosII
und/oder der Firmware zutun haben:

- Wuerde es helfen das in Assembler zu schreiben?
- Ist da etwas was ich da mache auf NiosII besonders ineffizient?
- Andere Datentypen verwenden?

Gruss,
Niklas

von Michael W. (slackman)


Lesenswert?

mal zum USB-BUS:
die UARTS des CY7C64713 können mit bis zu 230 KBaud kommunizieren. Gibt 
es das Board/die Firmware her? Aus irgendwelchen Dokus sehe ich, dass 
nur mit einem Viertel der möglichen Rate übertragen wird. Hier wäre noch 
Potential.

Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich 
möchte lieber den USB nutzen als die serielle Schnittstelle.

Vielleicht sollte man eine Möglichkeit bieten, den Firmwareupload via 
Auswahl in der Firmware (Menüpunkt) zu initiieren.

Wahrscheinlich ein wenig viel, oder ;-)
Neuer USB-Treiber, neue CY-Firmware, Anpassungen in der 
Scope-Firmware...

sorry

von Blue F. (blueflash)


Lesenswert?

@Niklas

Das Schreiben in Assembler könnte evtl. was bringen, ist aber eigentlich 
kontraproduktiv, da wir uns bemühen etwas plattformunabhängiger zu 
werden und daher die Assemblerroutinen durch c-coding zu ersetzen

> NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...

So ist es. Bei dieser Variante wurde auch noch auf das 
Multiplikationsmodul verzichtet. D.h. bei der Optimierung auf 
Geschwindigkeit sollte man folgendes beachten:

- Floating Point Operationen -> ganz schlecht, möglichst umstricken
                                auf Integer

- Integer Multiplikationen -> möglichst vermeiden

- Integer Additionen -> sind ok

- Shift Operationen -> möglichst oft verwenden da erheblich schneller

- komplexe Bibliotheksfunktionen -> ganz schlecht, möglichst durch
                                    eigene optimierte Funktionen
                                    ersetzen.

- oder noch besser -> durch schnellen indizierten Tabellenzugriff
                      ersetzen

Gruß Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Nach längerer Zeit habe ich mal wieder eine FW....80 eingespielt und bin 
begeistert.

Niklas O. schrieb:
> Hallo,
...
> Sollten wir vllt. einfach die Speicherbereiche unveraendert
> binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
> sind, und alles auf dem Computer erledigen?
> (den Code dafuer haben wir ja schon...)

Ich hatte mir auch mal eine Erweiterung geschrieben, mit der ich die 
rohen ADC-Daten seriell ausgegeben habe (USB habe ich totgespielt).

Auf dem Display werden doch sowieso nur 512 Bytes angezeigt. Bei vier 
Kanälen sind das maximal 512*4=2048 Bytes.

Wenn man im Header die Einstellung überträgt (Menü, Timebase...) und 
dann 512 Bytes/Kanal, sollte das ordentlich flott werden. Die "hübsche" 
Darstellung kann dann der PC übernehmen.

Aber auch die vollen 16kB/Kanal machen maximal 64kB, also ca. 6s.

Wenn man den PC-Teil in Qt schreibt, kann der auf allen gängigen 
Betriebssystemen laufen.

Ich hatte das mal angefangen. Es müßten sämtliche Parameter per RS232 
einstellbar sein. Auf Kommando könnten die Daten einmal oder dauernd 
gesendet werden.

Wenn sich ein Qt-Spezialist fände, würde ich die HW-Schnittstelle PC- 
und Scope-seitig implementieren. Wenn nicht, würde ich eine Oberfläche 
basteln können. Schön wird das aber nicht ;-)

Falk
P.S.: Wie läßt sich USB wiederbeleben, wenn sie absolut nicht mehr 
ansprechbar ist? Ich hatte mit ein paar Cypress?-Tools herumgespielt...

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Hayo:
Tja, ich mache ja egtl. nix anderes als Integer Additionen, Shift
und paar Array-Zugriffe...  D.h., damit ist dann wohl Ende der
Fahnenstange, da von 50s auf humane 10s oder so zu kommen steht
wohl auszer Frage.

@Falk:
Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
angezeigten 512(*4) Werte reduzieren bei der Implementation
der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
dann beinahe in Realtime den Output anzeigen.

Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
einfach nachmalt. Dennoch ist es IMHO schoen, wenn man die Option
hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
Measurements.  Koennte man natuerlich auch nachmalen mit Programm,
aber warum alles doppelt.  Ich moechte auf die Screenshot-Funktion
zumindest nicht verzichten und sie hat mir lange gefehlt.

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo Falk,

ich vergasz:
> [..] Es müßten sämtliche Parameter per RS232 einstellbar sein.
> [..] [HW-Schnittstelle PC- und Scope-seitig implementieren]

Ja alle Knoepfe sind wohl bereits auf RS232 gemappt.

Da ich ohnehin einen Eingriff an der Original UART ISR vornehmen
muss, sollten wir vllt. das (und die Routinen die da draenhaengen)
direkt mal aufraeumen und zusammen ein klares Interface
festschreiben.

Wenn jemand Material/Erfahrung zu Interfaces von anderen
professionelleren Scopes hat sollte er die dann einbringen.
Ich zumindest hab' da leider nichts vorzuweisen.

Niklas

von Blue F. (blueflash)


Lesenswert?

Niklas O. schrieb:

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das sehe ich genauso. Insbesondere für dokumentarische Zwecke sehr 
praktisch wie man auch in meiner Anleitung sehen kann. Die Wartezeit von 
einer Minute kann ich dabei locker verschmerzen. Mit der Kamera war ich 
auch nicht schneller und hatte auch noch diverse Fehlversuche wegen 
Verwackelung und Fehlbelichtung.

Für die FFT-Doku habe ich die Screenshot-Funktion statt ins QP-Menü 
direkt auf den QP-Button gelegt und noch zusätzlich den Popuptimer für 
die Dauer des Screenshots blockiert.

Hintergrund: Mit der Implementierung in der Version 0.80 läßt sich kein 
geöffnetes Popupmenü blitzen und auf den Screenshots ist dann auch immer 
das QP-Menü zu sehen, was aber für Dokumentationszwecke oft nicht so 
günstig ist, da man ja auch die aktuellen Menü-Einstellungen 
dokumentieren möchte.

Ich habe mir schon einige Gedanken gemacht wie man das lösen kann, dass 
man trotzdem das QP-Menü zur Verfügung hat. Mal sehen...

Hat einer von Euch eine spontane Idee?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo,

> Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
> angezeigten 512(*4) Werte reduzieren bei der Implementation
> der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
> dann beinahe in Realtime den Output anzeigen.
>
> Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
> einfach nachmalt.

Mit den Rohdaten kann man aber noch viel mehr anstellen. Beispielsweise 
mathematische Funktionen, die man im Scope nicht machen kann.

> Dennoch ist es IMHO schoen, wenn man die Option
> hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
> Measurements.

Natürlich ist das prima, keine Frage. Nur hat man dann keine Daten mehr, 
sondern ein Bild.

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das geht mir nicht anders. Aber auch ein Dump der Daten ist praktisch 
und eigentlich mit "Dump to XLS" schon vorhanden. (Ich halte .xls für 
zwei/vier Spalten mit je 16.000 Zeilen für unsinnig. CSV reicht.)

Falk

von Guido (Gast)


Lesenswert?

@ Hayo: QP-Button im Menu "scharfschalten", Einstellungen
nach Belieben und der nächste Druck auf QP macht die Hardcopy.
3. Druck auf QP: Menu erscheint wieder.

Sollte ohne großen Aufwand gehen.

Hast du mal meine 2 Fragen von gestern angedacht?

Gruß, Guido

von Roberto (Gast)


Lesenswert?

Hallo
Habe jetzt einen Betrachter für  "ppm" gefunden.
http://www.fine-view.com/en/download.html
l.G. Roberto

von Blue F. (blueflash)


Lesenswert?

@Guido

Ja, sorry hatte ich etwas verdrängt.

> 1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
> ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
> nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
> Nachteil erkennen, die Änderungen in Set_Switches sollten kein
> Problem sein, nur die Grafik muss angepasst werden.

Könnte man machen, allerdings könnte es schon etwas Aufwand geben, da 
die Skalierung in alle möglichen Routinen mit einfließt. Ich denke 
Stefan wird da bei QM auch mit zu tun haben. Vorteil wäre natürlich die 
bessere Ausnutzung der Wandlerauflösung und damit verbunden das 
geringere Rauschen in der Darstellung. Evtl. könnte es reichen die 
Skalierungsfaktoren anzupassen. Ich hab mir die Set_Switches() noch 
nicht so genau angesehen, ist die Umschaltung so ohne weiteres möglich?


> 2.) Bei Timebase > 6 wird  nur jeder 4. Wert ausgewertet.

Nein das ist nicht ganz richtig. Grundsätzlich ist die Situation zur 
Zeit so:

- es werden grundsätzlich immer 16k Werte gesampled

- die 1er und 5er Bereiche > 5µs nutzen jeden 5. Wert
- die 2er Bereiche > 5µs nutzen jeden 4. Wert
- der 5µs Bereich nutzt nur jeden 25. Wert

> Wenn du eh an die Timebaseeinstellungen gehen möchtest,
> solltet wir das gleich ändern. Dann werden unabhängig von
> der Timebase immer 16k-Samples übertragen. Die Faktoren der
> ProgrammingMaps werden dann vervierfacht, sonst ändert sich
> nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
> mit 16k-Samples ausgeführt werden kann, was nicht nur  die
> zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
> bringt,

Das habe ich nicht ganz verstanden. Wieso werden die Faktoren 
vervierfacht? Ich wollte die Faktoren eigentlich möglichst auf 1 oder 2 
bringen. Es stehen jedoch trotz allem für eine FFT immer die vollen 16k 
zur Verfügung, denn für die FFT ist nicht die eingestellte Timebase 
ausschlaggebend, sondern nur die indirekt damit verbundene tatsächliche 
Abtastrate. D.h. die Zeitbasen 2ns bis 1µs haben bei der FFT die 
gleichen Ergebnisse. Erst beim Wechsel auf 2µs verändert sich der 
Frequenzbereich durch die halbierte Abtastrate.

Für eine PC-Anwendung wäre es daher auch jetzt schon möglich die vollen 
16k zu nutzen, da die Werte ja vorhanden sind, nur bei der Grafikausgabe 
einfach übersprungen werden.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Niklas

Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab 
mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR 
auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Hayo

von elgodil (Gast)


Lesenswert?

Thema Screenshot:

ev. Tastenkombination (ähnlich GERMS-Aufruf), dann könnte man so 
ziemlich jede Situation "knipsen"

von Guido (Gast)


Lesenswert?

Hallo Hayo,

mit Set_Switches ist das kein Problem, ich muss mir nur wieder
klar machen, welches Bit für welchen Switch steht.

In den Bereichen mit Timebase > 6 werden 16k gesampled und im
FIFO abgelegt. In Readadc_all wird dann aber nur jeder 4. Wert
an den Anfang von DataArrayX geschrieben, in der
Assembler-Routine wird der Rest der Daten hinten angehängt, in
meiner C-Routine habe ich aus Geschwindigkeitsgründen darauf
verzichtet.

Besser wäre es unabhängig von der Timebase alle gesampleten
Daten hintereinander in DataarrayX zu schreiben, was für die
Grafik in den langsamen Bereichen die Faktoren vervierfacht.

Wenn man die (Hardware-)Timebase für alle Bereiche so
einstellen kann, dass immer korrekt gesampled wird, werden die
Faktoren natürlich 1. Das wäre optimal, ich habe aber nicht
verstanden warum das nicht so ist und vermute, dass da was in
der Hardware bockt (sonst hätten die das doch nicht gemacht).

Gruß, Guido

von Stefan (Gast)


Lesenswert?

Da ja eh' nur RAW gesendet werden soll, es also keinerlei Entscheidung 
bzgl. des Formats zu treffen gibt, kann man doch "Quick Print", ohne das 
nachfolgende Menü nehmen. Quick-Print trifft's doch auf den Kopf...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

@Guido

Das glaube ich nicht. Ich hab mir da schon so meine Gedanken gemacht 
(anbei der neue Entwurf des Timebasecontrollers) und werde mal eine 
Testversion bauen um das zu überprüfen. Allerdings muß man natürlich 
damit rechnen, das sich die Sampledauer entsprechend verlängert, was 
sich  in den langsamen Zeitbasen schon recht spürbar auswirken kann.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@elgodil

Keine schlechte Idee, aber per ISR läßt sich das gleichzeitige Drücken 
von zweei Tasten nur schwer ermitteln. Der Germsmonitor-Auslöser dagegen 
ist fest verdratet (siehe NIOS Doku).


@Stefan

Ja sowas in der Art dachte ich mir auch. Allerdings wenn weitere Daten 
Übertragen werden sollen (Excel etc.), wäre ein Menü nicht schlecht.

Hayo

von Stefan (Gast)


Lesenswert?

@Hayo
also kurz drücken und einen Quick-Print (Screenshot) bekommen - länger 
drücken und ein Menü für weitere Optionen erscheint. Quick-Print 
überschreibt somit keine angezeigten Settings, während die Anzeige der 
Softkey für das weiter führende Menü beim Excel-Export nicht relevant 
wäre.

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

@Kurt

Bei meine test's mit deinem screen.exe habe ich festgestellt, das die 
Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt 
das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die 
farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index 
umstellen!). Anbei meine Version die mit \r arbeitet.

Martin

von Cra Z. (crazor)


Lesenswert?

Michael W. schrieb:
> mal zum USB-BUS:

> Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich
> möchte lieber den USB nutzen als die serielle Schnittstelle.

Das sieht erstmal schlecht aus, ohne die Verbindungen im FPGA zu ändern. 
Der Germsmonitor wird vermutlich nur auf einer UART des Systems lauschen 
und nicht auf mehreren.

von Kurt B. (kurt)


Lesenswert?

Danke Martin,
das werde ich mir später nochmal ansehen. Ich wollte das Prog eh noch 
etwas aufräumen.

von Cra Z. (crazor)


Lesenswert?

Johannes Studt schrieb:
> Crazor schrieb:
>> Writing line 004277 of 023377: .X............0 sec / 134 sec left
>> Error: Timeout while reading response from DSO!
>> Response was: 'S219815B3D34<#33><#13>
>> '
>
> Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn
> der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt
> reagieren und dann ginge es weiter.
>
> /Hannes

Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein ! 
nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal 
in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht 
sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder 
nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon 
helfen!

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

anbei noch die v0.3 vom Screenshot Programm:
Jetzt auch fuer Windows und auch mit BMP-Ausgabe.

Kompiliertes EXE-File (unter MinGW), .BAT und README.txt sind
dabei.  Wenn sich jemand wundert warum sein Lieblingsprogramm
die BMP evtl. nicht oeffnen vermag: steht in der README.

Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
funktioniert alles richtig, habe nicht sonderlich lange testen
koennen.

@Hayo:
> Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab
> mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR
> auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Ja, mach das mal.

Niklas

von Roberto (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Martin
> Bei meine test's mit deinem screen.exe habe ich festgestellt, das die
>Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt
>das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die
>farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index
>umstellen!). Anbei meine Version die mit \r arbeitet.

Meinst Du damit den roten Schatten, rechts der gelben Linie ?
Habe das screen.cpp durch deines ersetzt.
Ist aber noch immer der gleiche Schatten ?
Muss man da noch was ändern?
l.G. Roberto

von Cra Z. (crazor)


Lesenswert?

Daniel H. schrieb:
> Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein !
> nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal
> in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht
> sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder
> nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon
> helfen!

Ok, habe nun Zeile 184 von
      while ($buffer !~ /\+/) {
nach
      while ($buffer !~ /[\+|\!]/) {
geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte 
ich dann .X.X.X.X. usw. in der Ausgabe, und nach dem 10. Versuch nen 
Abbruch. Dann hab ich mir gedacht baue ich in die Abbruchfehlermeldung 
auch die Ausgabe des Buffers mit ein, um zu sehen was der GERMSmonitor 
weiterhin antwortet, aber dann hat der Upload (leider ;) gerade mal 
funktioniert, sodass ich erst bei einem der nächsten Hayo-Releases 
weitertesten kann...

von Roberto (Gast)


Lesenswert?

@Nicklas
Das Programm funktioniert bei mir! :-)
Auch kein Schatten mehr :-)
Leider kann ich kein Englisch.... (Doku)
Was ist der Befehl "-b".
Warum speichert er jetzt so viele Files extra?
Das PGM BW macht jetzt BMP :-) (-->ok)
Warum nur in S/W?
In der Doku habe ich was von "png" gelesen.
Gehen jetzt auch .png Bilder?

l.G. Roberto

von Johannes S. (demofreak)


Lesenswert?

Daniel H. schrieb:
> Ok, habe nun Zeile 184 von
>       while ($buffer !~ /\+/) {
> nach
>       while ($buffer !~ /[\+|\!]/) {
> geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte

Ok, richtig wäre /[!+]/ (in Zeichenklassen hat das Plus wie auch das 
Ausrufezeichen keine Sonderbedeutung), aber es ist sicher prinzipiell 
keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich 
eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut 
übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und 
ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.

@Hayo: ich fände es ergonomisch, wenn der Druck auf QP einfach wie 
gehabt das Menü aufruft und ein längerer Druck die Übertragung 
stillschweigend auslöst. So würde ich das zumindestens bei meinen 
Applikationen machen.

/Hannes

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

@Robert

Meiner Meinung has du das ganze nicht new compiliert!

Desshalb hier auch das screen.exe (mit Visual C++ 2008 Express 
erstellt).

Martin

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

@Hayo

Hier sind die Sourceen. Hab in hardware.cpp, tc_vars.cpp, tc_vars.h, 
display.cpp was geändert. Woanderst glaube ich nicht ;-)

@Stefan, der zweite

Können wir uns darauf einigen, dass ich ab jetzt mich immer als Stefan 
E. oute und du dir auch noch nen Buchstaben gönnst? Sonst bin ich am 
Ende noch selbst verwirrt, was ich geschrieben habe ;-)

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo,

> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
> dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
> funktioniert alles richtig, habe nicht sonderlich lange testen
> koennen.

Mir ist aufgefallen, daß fast 2/3 des Outputs Sequenzen "7e 7e 7e 0a" 
sind.

Ich werde das rle_coding etwas verändern und hoffe, daß ich die 
Datenmenge nochmal halbieren kann.

Den Code stelle ich dann hier zur Abstimmung ;-)

Falk

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Johannes Studt schrieb:
> keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich
> eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut
> übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und
> ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.

Dummes Hannes. :D
Na klar war das so vollkommen korrekt. Einfach die Zeile 183 wie oben 
schon beschrieben auf

                        while ($buffer !~ /[+!]/) {

ändern und schon wird bis zu 10mal versucht, die Zeile neu zu 
übertragen. Dabei wird jedesmal ein X gemalt, damit man weiß, dass da 
was krumm war.

/Hannes

von Stefan (Gast)


Lesenswert?

Könnte man, bei all den Optimierungen, evtl. bei den Kanaleinstellungen 
einen Button aufmachen, der die Darstellung des jeweiligen Kanals auf 
50% Helligkeit setzt; ihn 50% transluzent zu machen ist ja wohl nicht 
drin :)
Oft hat man ein ein Signal vor dem Processing, und möchte es in bezug 
darauf auch nach dem Processing darstellen. Optimal ist es dann, wenn 
beide überlagernd liegen, aber da dominiert eben eine Farbe die andere 
immer sehr...

von Kurt B. (kurt)


Lesenswert?

@Niklas,
du solltest wieder in die main() eine Endlosschleife packen damit man 
das Prog nicht für jeden Screenshot neu starten muss.

von Kurt B. (kurt)


Lesenswert?

Wo kriege ich die ganzen fehlenden Includes her?

unistd.h
cdfes.h
features.h
...

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

> Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
> dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
> funktioniert alles richtig, habe nicht sonderlich lange testen
> koennen.

leider doch ein Fehler:  Unter Windows wurde immer com1 verwendet,
auch wenn mit -c ein anderer COM-Port definiert wurde.  Anbei
die behobene aber ansonsten unmodifizierte Version.

@Roberto:
> Was ist der Befehl "-b".
Der bewirkt das Schreiben von BMP statt PPM Dateien.

> Warum speichert er jetzt so viele Files extra?

Das war schon immer so im Falle von PPM.  Da wird jede
Plane (Darstellungsebene, z.B. Kanal1-4, Cursor, ...)
auch einzeln gespeichert.  Ist ganz nuetzlich wenn man
bei der Entwicklung Darstellungsfehler lokalisieren will.

Bei Kurts Version war das wohl abgeschaltet und es wurde
immer nur eine Datei geschrieben.

> Warum nur in S/W?
Wenn Du im Quick Print Menue vom DSO die Taste ohne BW
drueckst sollte das farbig rauskommen.

> Gehen jetzt auch .png Bilder?
Nein, noch nicht.  In der README ist hinten beschrieben
wie man unter nicht-Windows da ein PNG raus machen koennte.

Deutsche Kurzbeschreibung werde ich in den naechsten Versionen
beifuegen.  Kurz gesagt wird mit dem Parameter -c der COM-Port
festgelegt, also etwa -c 4 fuer COM4.  Mit -f kann man einen
Dateinamen-Prefix festlegen, bei -f fft -b wuerde dann eine
Datei fft.bmp geschrieben.  -h zeigt Hilfe in Englisch an.

@Kurt:
> [Main Loop]
Werde ich per Schalter -l oder so hinzufuegen in den naechsten
Versionen, schreibt dann [prefix][nnnn].[suf], wobei nnnn
aufsteigend.

> Wo kriege ich die ganzen fehlenden Includes her?

Was benutzt Du denn als Compiler?  Ich habe das unter MinGW
kompiliert.  Bei de(r|n) (keine Ahnung davon) Windows libc
scheint es ja nichtmal snprintf() zu geben, jedenfalls habe
ich gesehen dass Du das mit strcat() usw. emulieren musstest.

Niklas

von Kurt B. (kurt)


Lesenswert?

Hallo Niklas,
ich verwende das Visualstudio 6 bzw. 2008 Express.

Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er 
glaube ich nicht.

Die unistd darf bei mir nur unter Linux eingebunden werden.
Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)
Ersetzen von snprintf() durch sprintf_s().
Aus fopen wird fopen_s

Dann gibt es noch Probleme mit optarg und getopt()...

Die Frage ist ob die Änderungen auch mit Linux laufen. Sonst muss man 
mehr #ifdef einsetzen. Außerdem weiß ich nicht, was diese ganzen safe 
Funktionen sollen. Muss ein Feature von C++ sein.

Die Sache mit strcat() war nur eine Notlösung, weil ich vergessen hatte 
das es sprintf() gibt.

PS:
Mit MinGW geht es bei mir aber auch so. Ich musste erstmal googlen wie 
man damit kompiliert. ;-)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Das Wochenende ist gerettet!

Hier die neue 0.82 beta (hoffentlich werden wir den beta status los 
bevor wir die 100 knacken).

- für Niklas habe ich die UART ISR leergeräumt - hat jetzt nur noch 7 
Zeilen. Deiner Implementierung steht also nichts mehr im Wege.

- Stefans neue QM-Routinen sind auch mit dabei. Sieht nach den ersten 
Tests sehr vielversprechend aus. Dank des Redesigns ist das Flashfile 
wieder unter 1.3 MByte auf rekordverdächtige 1234 KByte geschrumpft!

- einige kleinere bugs sind gefixed.

- Der Screenshot liegt wie schon erwähnt direkt auf dem QP-Button, 
b/w-Screenshots sind daher zur Zeit nicht möglich.


Bei der QM-Funktion wird leider der untere Gridrand etwas zerbröselt, 
das wäre eigentlich was für unseren Plane-Spezialisten Guido. 
Interessanterweise tritt das bei der Cursorfunktion nicht auf.

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

QM ist denke ich soweit ganz brauchbar. Der Rest, der noch nicht 
umgearbeitet ist (Delay, Phase, Math-Kanal,...) kommt auch noch 
irgendwann...

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

@Niklas

Die neue 0.3 Screenshotversion arbeitet einwandfrei auch unter Windows. 
Das wird viele nicht-Linuxer freuen, da sie jetzt auch in den Genuss 
dieser praktischischen Funktion kommen.

Eine wirklich nützliche Erweiterung für unser W20xxA.

Hayo

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

Also bei mir laufen sowohl die BF.0.80, als auch die neue 0.82 nicht.
Die ganze Gruppe um 'Measure', 'Waveform' und 'File' geht einwandfrei; 
bei 'Trigger' reagiert kein einziger Button und die Channel-Buttons sind 
ebenfalls tot - 'Math' geht wiederum.
Es wird kein einziger Kanal angezeigt, bis auf die Menüs und die 
Cursor-Lines oder Quick-Measure -sofern aktiviert- ist der Bildschirm 
schwarz.
'Utility|Calibrate ADC/DAC' und 'Utility|Search Zero Lines' laufen 
ebenfalls durch - allein, ich hab' keine Signale...

Spiele ich die FW1.2.BF.0.75 beta zurück, geht sofort alles wieder.

Es ist ein E2024A. 'About' zeigt eine Hardware Version 8C7.0E

Was noch auffällt: unten links machen drei oder vier blaue Pixel 
permanent einen Mini-Night-Rider !?


Ist mir noch zu helfen ?

von Blue F. (blueflash)


Lesenswert?

Ja es ist Dir zu helfen.

Da die Variablen der FFT-Funktion jetzt auch im Flash abgelegt werden, 
kann es vorkommen, dass das DSO. in einem Zwischenzustand der FFT 
startet wenn der Flashspeicher vorher nicht initialisiert war. Da Du 
Dich im FFT-Modus befindest, ist das ganze Triggermenü deaktiviert.

Abhilfe: den Mathbutton mehrfach drücken bis der normale Main-Modus 
wieder aktiv ist, dann das Edge-Menü drücken und Default-Setup. Jetzt 
noch die Timebase verstellen und bei nächsten mal ist alles gut.

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

wollte eigentlich schon gestern ein paar Kommentare zu der neuen FFT 
loswerden. Hab das Ganze eben mit der Version 0.82 überprüft, meine 
Anmerkungen treffen soweit auch darauf zu.

1.) Überraschend gutes Ergebnis (wenn man bedenkt, daß die HW und die 
Rechenleistung dafür eigentl. nicht ausgelegt ist)- Respekt!.

2.) Mit dem Cal. Signal ist mir aufgefallen, daß mit 50mV/Div der Pegel 
der Grundschwingung mit ca. 160mV angezeigt wird (Probe x1,5ms/Div, 
Poisson3.0). Beim Umschalten auf 25mV/Div wird er zu ca. 80mV angezeigt. 
Bei den anderen Fensterfunktionen ist das Verhältnis entsprechend.

3.) Da du die Beschriftung der log. Skala an der linken Achse angebracht 
hast, frage ich mich ob man das nicht auch für die lin. Skala übernehmen 
könnte.

4.) Lecroy korrigiert die fft Darstellung so, daß die Spektralllinien im 
Pegel dem Level im Zeitbereich entsprechen s.h. Dokument, Seite C-5 
oben.
http://www.lecroy.com/tm/library/manuals/download.asp?id=784

5.) Da du bei der log. Darstellung ja nicht etwa dBm oder dBV 
verwendest, sondern dB, würde ich eine auf die Grundschwingung (=0 dB) 
normierte Darstellung erwarten. Oder ist die Anzeige so zu verstehen, 
daß die Summe aller Spektralllinien 0dB entsprechen?

6.) Leider fehlt die Beschriftung der Freq.- Achse noch...

7.) Mir war gar nicht bewusst, welch großen Einfluss die Fensterfunktion 
auch auf den Pegel der Grundfrequenz hat, umso stärker wäre eine auf 0dB 
normierte Darstellung anzustreben.

8.) Eigentl. müssten doch alle Informationen zur Unterdrückung von 
Aliasing zur Verfügung stehen (TB, TB-Faktor, Freq. der 
Grundschwingung). Will damit sagen, könnte man nicht die Darstellung von 
Frequenzen die das Nyquist- Kriterium verletzen, direkt unterdrücken?

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

p.s.

was ist denn ein E2024A? E wie Extended Edition? ;-)

Hayo

von Kurt B. (kurt)


Lesenswert?

Die 0.82 läuft hier auf einem 2024A 8C7.C9 ohne Probleme.

von Stefan (Gast)


Lesenswert?

Ging ganz genau so, wie Hayo beschrieben hat. Man, was bin ich 
erleichtert :)

Btw: vielen Dank Euch allen, dass Ihr Euch so reinhängt !

von Blue F. (blueflash)


Lesenswert?

@Bruno

Also grundsätzlich zur Scalierung ist anzumerken, dass sich die 
Performance bei der FFT unter anderem nur bewerkstelligen ließ, in dem 
auf Multiplikationen verzichtet wurde und stattdessen Shift-Operationen 
eingesetzt wurden. Dadurch sind die verfügbaren Skalierungen erstmal 
beschränkt. Man kann das sicher auch noch etwas feiner abstufen, wie bei 
der normalen Grafikroutine, aber auch das kostet zusätzlich Zeit. Hier 
muß man also abwägen.

Die Beschriftung für das Grid ist erstmal nur im Log-Modus verfügbar da 
diese sich ja wegen der Normierung nicht ändert. Wenn ich den Linearen 
Modus beschrifte muß ich jedesmal einen Refresh durchführen wenn der 
Messbereich wechselt. Ist aber durchaus machbar. Das Gleiche gilt für 
die Frequenzanzeige.

Ich habe auch schon überlegt was sich da an eleganten Lösungen so 
anbietet.

Die Beschreibung von Lecroy ist sehr interessant, die werde ich mir noch 
mal genauer ansehen. Ich lasse da gerne Anregungen von anderen Oszis mit 
einfließen.

> 4.) Lecroy korrigiert die fft Darstellung so, daß die
> Spektralllinien im Pegel dem Level im Zeitbereich entsprechen
> s.h. Dokument, Seite C-5 oben.

Das war ursprünglich bei mir auch so, aber ich fand es besser die volle
Gridhöhe zu nutzen. Spricht was dagegen?

OdB bezieht sich auf die Amplitude des Signals im Zeitbereich bei 
Vollaussteuerung. D.h. ein Sinussignal sollte eine Frequenzlinie mit 0 
dB Verlust haben, während ein Rechteck sogar mit der Grundschwingung H1 
ein wenig im +dB Bereich (Verstärkung) liegen sollte wenn im Zeitbereich 
der ADC-Wandler mit den vollen 8 Bit (255) ausgesteuert ist.


Zu 8: Die Aliasfrequenzen entstehen leider nicht erst bei der FFT, 
sondern schon direkt bei der Abtastung, so dass man einem Datensatz 
nicht ansieht ob die Frequenzen nun echt sind oder nicht. Wenn man die 
Auswirkungen kennt, kann ein Mensch das zwar auf dem Bild erkennen, aber 
der Rechner kann es nicht herausrechnen - schade, sonst könnte man sich 
Bandbegrenzungsfilter sparen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Bruno

Ich habe mir die LeCroy-Doku noch mal genauer durchgelesen. Mit der 
Skalierung der Amplitude auf die Amplitudenhöhe im Zeitbereich war hier 
nicht der Skalierungsmaßstab gemeint, sondern die Korrektur der 
Amplitude, wenn diese in einen gedämpften Frequenzbereich fällt. Siehe 
hierzu auch meine Anleitung Seite 10 Abb. 7 - Gewichtung im 
Frequenzbereich.

Eine solche Korrektur ist natürlich eine feine Sache, das wäre noch was 
für die ToDo-Liste, ebenso wie die Anzeige des Leistungsspektrums. Werde 
ich mir mal vornehmen...

Gruß Hayo

von Stefan (Gast)


Lesenswert?

@Niklas

Der Screenshot funktioniert ja, wie die Anderen ja auch bereits 
feststellten, prima; nur ist das Ergebnis auf dem PC doch sehr flau.
Besteht da eine Chance, dass die auf dem Scope dargestellten satte 
Farben auf dem PC ein ähnliches Niveau erreichen. Also Gelb ein FFFF00, 
Grün ein 00FF00 u.s.w.
Das Blassgrün in Verbindung mit dem Blassblau hat einen doch sehr 
niedrigen Kontrast.

Ich möchte nicht quengelig  erscheinen; das was Du hier abgeliefert 
hast, hilft mir sehr und ist weit mehr, als man eigentlich in so kurzer 
Zeit erwarten konnte - vielen Dank noch einmal !

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

zu 8.) hast du natürlich recht... war ein Schnellschuß- kann in meinem 
Alter schon mal vorkommen ;-)
Wenn das so einfach wäre, würden das renommierte SA Hersteller schon 
lange so machen.

Kannst du unter 2.) aufgeführtes Phänomen nachvollziehen?

zu 5.) Soweit kein Problem- wenn man weiß wo der Bezugspunkt, sprich 0dB 
liegt.

Gruß, brunowe

von Stefan (Gast)


Lesenswert?

Quick-Measure funktioniert prima - viel besser als erwartet.
Mir ist dabei aufgefallen, dass eine Umschaltung des Kanals via Softkey 
nichts bewirkt. Erst das Aus- und wieder Einschalten von Quick-Measure 
übernimmt den geänderten Kanal.
Wenn man einmal 'Measure Average' gewählt hat, wie kommt man wieder zur 
vorhergehenden Einstellung (?) ist das eine Einbahnstraße ?

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

@Stefan,
gefällt es dir so besser?

/* Channel_Plane2 */  { 0x00, 0xFF, 0x00 }, /* green */
/* Channel_Plane3 */  { 0x18, 0x35, 0xc2 }, /* blue */

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Ich habe die Datenkompression für Niklas' Quick-Print-Funktionen etwas 
überarbeitet.

Die Datenmenge ist deutlich kleiner, die Geschwindigkeit leider nicht so 
ganz. Ein SW-Dump dauert jetzt 10s, Farbe dauert 30s.

Bei Interesse stelle ich die Änderungen hier ein. (Oder zieht Ihr einen 
anderen Ort vor?)

Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.

Falk

von Stefan (Gast)


Lesenswert?

Hallo Kurt,

das macht es schon deutlich einfacher, die Darstellung der einzelnen 
Kanäle zu differenzieren. Auch wenn hier noch etwas Abstimmung in bezug 
auf die Wahrnehmung der einzelnen Farben (annähernd gleiche Helligkeit) 
erforderlich wäre. Ist das gleiche Problem, dass sich beim layouten 
darstellt. Grün und Gelb recht dominant gegenüber Rot und in diesem Fall 
besonders Blau.

von Kurt B. (kurt)


Lesenswert?

Weitere Möglichkeit zur Datenreduktion:

Die FFT läuft jeweils nur auf einem einzigen Kanal. Die Planes der 
anderen 3 Kanäle müssen nicht übertragen werden.

Das Grid, auch wenn es mehrere gibt ist immer gleich. Es reicht die 
Grids durchzunummerieren und die Nummer des jeweils aktiven Grid zu 
übertragen. Die eigentlichen Daten dieser Plane liegen im PC Prog als 
Tabelle vor.

Es muss nicht die Cursor oder Math Plane übertragen werden, wenn die 
garnicht benutzt werden...

Wenn man zuerst den aktuellen Betriebsmodus sendet und nur die nötigen 
Daten solle sich die Übertragungszeit um 15-20 sec. reduzieren lassen.

von Blue F. (blueflash)


Lesenswert?

@Bruno

Nein, bei mir sieht das völlig anders aus. Bei 25mV + 50mV mit 
Rechteckfenster werden 40mV angezeigt, mit Poisson-Fenster nur noch ca. 
12mv - Das ist ein durchaus nicht unerwartetes Ergebnis.


Hayo

von Blue F. (blueflash)


Lesenswert?

@Falk

Prima, einfach hier hochladen, ich baue das dann ein.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Stefan, du könntest auch diese Bild mit einem Zeichenprogramm ausmalen 
;-)
PaintNet zeigt direkt die HEX Werte der Farben an.

Die geraden Linien mit dem "Farbeimer", die diagonalen mit dem 
Linienwerkzeug.

Wenn du die schönste Farbkombination gefunden hast kann man die im Oszi 
und im Programm einbauen.

Ich bin leider Farbenblind. ;-)

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier als bmp. Das hat schärfere Kanten.

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Stefan:
> Besteht da eine Chance, dass die auf dem Scope dargestellten satte
> Farben auf dem PC ein ähnliches Niveau erreichen.

Ja, sicher.  Die Werte die ich genommen habe sind nur per Daumen
und Augenmass anhand meiner Wahrnehmung vom DSO Output von mir
geschaetzt, hab' da aber nicht wirklich Zeit fuer investiert.

Wie Kurt zeigt kann man die Konstanten aendern, sicher koennen
wir in zukuenftigen Versionen die Werte ueber z.B. eine .ini-Datei
direkt vom Benutzter anpassen lassen.

@Falk:
[Optimierung RLE Algo, Zeitreduktion]

Das klingt gut, ich finde wir sollten Deine Aenderungen direkt
uebernehmen.  Ich persoenlich finde das diff-Format dazu
( http://de.wikipedia.org/wiki/Diff ) am praktischsten.

> Bei Interesse stelle ich die Änderungen hier ein.
> (Oder zieht Ihr einen anderen Ort vor?)

Ob wir das immer alles hier in dieses Forum posten sollten weisz
ich nicht, fuer mich waere auch die Google Group i.O..  Das pflegen
des Codes ueber eine Versionsverwaltung waere auch in Ordnung, ich
hab' hier schonmal gelesen das wohl der Service von Sourceforge
nicht so prickeln ist und Leute Probleme damit haben.
Wenn Interesse besteht kann ich sowas aber auch selbst hosten
(habe eigene Rechner in RZ).

> Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.

Ja kannst Du wenn Du Zeit hast mit anfangen, ich hab' da diesbzgl.
auszer den geschilderten Vorueberlegungen nocht nichts gemacht.

Ich werde auch noch meine bereits geschriebenen ZModem Funktionen
einstellen, auch wenn da noch noch auf dem DSO die ISR Anpassung
fehlt um die verwenden zu koennen.

@Kurt:
[Nicht alle Planes uebertragen]

Daran hab' ich auch schon gedacht.  In der Tat sind ein paar der 16
Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst
noch weitere ausschlieszen.  Da das DSO ohnehin da "Ewigkeiten"
pro Plane braucht liesze sich da deutlich Zeit einsparen.

Es gibt allerdings ein paar Sachen zu beachten, ich hab' ja schon
die Beobachtung gemacht (im Sourcecode gibt's nen Kommentar dazu),
dass die roten Pfeile und das rote Stop(p)-Schild auf die Channel 4
Plane gelegt sind (weil die vmtl. gerade rot war, oder so...).

Ohnehin war mir zum Zeitpunkt als ich das schrieb' noch nicht klar,
welche Planes nun genau zu welchem Zweck genutzt wurden und habe
alle rausschreiben lassen, auch die Marker Planes, die gar keine
Einfaerbung erhalten.

Also ja.  Auch die Zeitersparnis die wir dadurch gewinnen koennen wir
bitter gebrauchen.  Vllt. noch fuer die Entwicklung die Moeglichkeit
offen lassen trotzdem alles zu uebertragen, um wie schonmal gesagt
Darstellungsfehler einfacher lokalisieren zu koennen.

@alle:
Sollten wir vllt. irgendwo eine stets aktuell gehaltene Liste haben
"wer arbeitet gerade woran" um doppelte Arbeit zu vermeiden?

Niklas

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

hier wie im letzten Post beschrieben die ZModem Routinen.
Sourcecode im Anhang, Header Inline:
1
#ifndef _zmodem_h_
2
#define _zmodem_h_
3
4
static void zm_send_hexhdr(int, char [4]);
5
static void zm_send_zdle(int);
6
static void zm_send_binhdr(int, char [4]);
7
static void zm_send_data(char, char *, int);
8
static int zm_get_hexhdr(void);
9
static int zm_get_binhdr(void);
10
static int zm_get_header(void);
11
static int rd_char(void);
12
void zm_test(void);
13
void zm_buf(int);
14
static int GETCH(void);
15
16
#endif

Niklas

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

Kurt,

Ich musste eben auch feststellen, dass es nicht ganz so trivial ist wie 
es auf den ersten Blick schien :-\
Ein paar Linien mit Corel auf einer schwarzen Fläche sind ähnlich blass, 
wenn nicht schlimmer; hingegen kommt ein Screenshot aus dem Layout doch 
deutlich "leuchtender" rüber - mir fehlt jetzt ein sich am Kopf 
kratzender Smiley ;)
Ich vermute mal, dass mein Bildschirm bescheiden abbildet oder meine 
Augen schlecht eingestellt sind...

von Kurt B. (kurt)


Lesenswert?

Ich glaube auch es sind deine Augen ;-)

Im Layout will man immer möglichst große Flächen haben, wohingegen im 
Screenshot die Linien möglichst dünn sein sollen. Das verbessert deren 
Sichtbarkeit natürlich nicht gerade.

von Niklas O. (nevm)


Lesenswert?

Hallo Kurt,

> Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er
> glaube ich nicht.

Ja, ich hab' die w2000a-screenshot.c nur zu nem .cpp gemacht weil
der Parser die ComTools.h sonst nicht fressen wollte.  Die benoetigten
Sachen die die ComTools machen koennen wir denke ich auch leicht
selbst neu bauen.

> Die unistd darf bei mir nur unter Linux eingebunden werden.
> Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)

sleep(1000) wuerde 1000 Sekunden warten unter allen mir
bekannten libc...  (Ist abgesehen davon auch POSIX)

> Ersetzen von snprintf() durch sprintf_s().
> Aus fopen wird fopen_s

Noch nie irgendwo implementiert gesehen, was machen die
anders als die n-Versionen?

http://netbsd.gw.com/cgi-bin/man-cgi?snprintf

Die n sind egtl. soweit ich weisz auch C99...

> Dann gibt es noch Probleme mit optarg und getopt()...

Zu erwarten...

> Die Frage ist ob die Änderungen auch mit Linux laufen.

Leider nicht.

> PS:
> Mit MinGW geht es bei mir aber auch so. Ich musste erstmal
> googlen wie man damit kompiliert. ;-)

Wollen wir bei MinGW bleiben, oder statt der n die ganz normalen
Versionen verwenden und getopt() selbst implementieren?
Statt fopen() geht ja auch open(), oder fehlt das auch?

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo, nochmal,

urgs, merke gerade das ich oben als ich von den Planes mit
(mir) noch nicht bekannten Funktionen sprach da die Marker
Planes erwaehne.  Da meinte ich natuerlich die Memory Planes.

Niklas

von Stefan (Gast)


Lesenswert?

Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre 
es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei 
Hardware | Software auch ganz gut.

Dieser hier würde dann für Rückmeldungen bzgl. eventueller Fehler, 
Usability und ggf. Wunschdenken aktiv bleiben, während sich ein neuer 
Thread in Richtung allgemeine Entwicklung, Tools, sowie konzeptionelle 
Ausrichtung und Strategien abspaltet... ich vermute mal, dass eine 
Abspaltung der überschaubaren Anzahl aktiver Entwickler disziplinierter 
vonstatten gehen würde, als die Vielzahl der hier mitlesenden auf einen 
neuen Thread umzubiegen.

Ist nur so eine Idee - bitte nicht kreuzigen :)

von Blue F. (blueflash)


Lesenswert?

Ich denke eine weitere Aufsplittung würde es eher unübersichtlicher 
machen, allerdings könnte man den Thread evtl. mal wieder neu aufsetzen 
damit die Beiträge überschaubar bleiben.

Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

ich habe folgendes Problem:
ich nehme ein Signal auf (5µs/div), drücke auf Stop. Signal bleibt 
stehen. Ich zoome rein auf 2µs/div, Signal wird kurz vergrößert 
dargestellt, so wie es gedacht ist. Aber dann wird auch schon ein neues 
aufgezeichnet.

Kannst du das mal fixen?

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Geht klar!

Hayo

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hi, anbei die diffs für die überarbeiteten Screenshot-funktionen.
Das diff für die Firmware ist für 0.82, kann aber einfach am Ende von 
src/display_t.cpp gegen die drei ursprünglichen Funktionen, 
tschuldigung, Methoden, is ja C++ ;-) ausgetauscht werden.

Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas 
den entsprechend einpflegen könnte?

@Hayo: Mein Vorschlag zur Bedienung der Screenschot-Funktion:
Quick-Print macht einen Screenshot wie in 1.2.BF.0.82.
Da die Screenshots und Rohdaten ohne ein Stück Software auf dem PC 
sowieso sinnlos sind, kann die PC-Soft einfach ein Kommand über RS232 
schicken, das die gewünschte Aktion startet.

Ich stelle mir das so vor, daß die bisherige Steuerung unverändert 
bleibt, abgesehen von dem Zeichen "starte spezielle funktion" STX, ASCII 
0x02.

Hardware::ISR_UART bekommt eine simple State-machine, die alles 
durchreicht, außer STX-LEN-Daten-ETX und nach ETX ein Flag setzt. Das 
könnte mit UART_NewData=2 realisiert werden.

In Hardware::Keyboard_Interface könnte dann etwa so aussehen:
1
switch (UART_NewData) {
2
  case 1: UART_NewData = 0;               //reset UART ISR flag
3
          if (UART_RXData == 'a' ) { lMenuKey = 0; }     // Acquire
4
  ....
5
  case 2: handle_remote_control(...)
6
  }
7
  UART_NewData=0

Ich würde das einbauen, wenn wir uns nicht gegenseitig dabei stören.

Gruß,
Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan schrieb:
> Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre
> es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei
> Hardware | Software auch ganz gut.

Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach 
HW, Software, Diskussionen etc. trennen.

Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.

Falk

von Cra Z. (crazor)


Lesenswert?

@BF.0.82: Läuft ziemlich gut. 3 Dinge sind mir aufgefallen:
 * About Oscilloscope: Auch hier gibts Artefakte, wenn man z.B. vorher 
im Quick Measurement Menü war
 * Quick Measurement: Wenn ich z.B. das Probe Comp Signal (bei 
200uS/div) anschaue, dann ist die Periode dauerhaft 1.00ms, aber die 
Frequenz flackert zwischen 995.0 und 999.0 Hz, ohne dass die 
Nachkommastelle mal ungleich wäre. Auch die Spannungsmessungen wie z.B. 
Pk-Pk ändern nie ihre Nachkommastelle.
 * UART: Wenn ich im Quick Measurement Modus bin, reden die 
Messfunktionen bei jedem Aufruf auf der UART. Solche Meldungen, die beim 
Entwickeln sehr helfen, solltet ihr unter Zuhilfenahme eines Makros 
ausspucken, damit die in den Releases still sind. Das kostet alles 
unnötige Zeit, wenn andauernd auf die UART geschrieben wird.

Falk Willberg schrieb:
> Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach
> HW, Software, Diskussionen etc. trennen.
>
> Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.

Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit: 
http://sourceforge.net/apps/phpbb/welecw2000a/
SourceForge-Handles haben eh' die meisten schon, und ihr könnt gern alle 
Mod- oder Admin-Rechte haben und eine beliebige Menge Foren und 
Kategorien anlegen. Würde mich freuen, wenn das Forum dort mehr genutzt 
würde.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:
...
> Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:
> http://sourceforge.net/apps/phpbb/welecw2000a/

Gefällt mir ;-)

Mal sehen, ob es ankommt...

Falk

von Blue F. (blueflash)


Lesenswert?

@Daniel

SFN könnte man natürlich machen, aber ich fand das immer recht zäh und 
langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit 
eigene Foren einzurichten ist natürlich nicht übel.


@Falk

Auch Dein Angebot einen Server zur Verfügung zu stellen ist recht 
reizvoll da dann die Kontrolle quasi "in unserer Hand" bzw. in Deiner 
läge. Vermutlich wären auch die Antwortzeiten attraktiver als bei SFN. 
Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in 
regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht 
immer neue Treads nötig sind.

Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr 
zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also 
am Besten mit Ihm abstimmen. Meine Baustelle ist nach wie vor die FFT, 
die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno 
und die LeCroy Broschüre).

Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im 
Hardwarethread, eigentlich müßte doch nur das Flash fur den 
USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da 
waren doch schon einige aktiv glaube ich.

Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist, 
nachdem ich einige Zeit nichts mehr von Dir gehört hatte.

Gruß Hayo

von Michael (Gast)


Lesenswert?

Hallo,

ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas 
kaputt mache, will ich vorher nochmal kurz nachfragen.

Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim 
nächsten Oszi Start dann wieder weg?
Kann ich das unter Windows einfach mit der WelecUpdater.exe machen? Oder 
muss ich mir vorher nen Perl-Interpreter zulegen, damit ich das mit dem 
Skript machen kann?


Danke! Gruß,
Michael

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hayo W. schrieb:
> @Daniel
>
> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und
> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit
> eigene Foren einzurichten ist natürlich nicht übel.

Ich habe da jetzt einfach mal einen Thread zum Thema screendump 
aufgemacht.

Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.

...

> Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr
> zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also
> am Besten mit Ihm abstimmen.

Ok. Ich denke, Niklas hat es mitbekommen. Ich brauche die ISR 
wahrscheinlich nicht, meine Erweiterung sollte sich in 
Hardware::Keyboard_Interface einbauen lassen.

> Meine Baustelle ist nach wie vor die FFT,
> die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno
> und die LeCroy Broschüre).

Sehr schön. Ich habe mal einen screendump von einer FFT angehängt. 
Eingang ist der Sonnenschirm als Antenne ;-)

> Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im
> Hardwarethread, eigentlich müßte doch nur das Flash fur den
> USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da
> waren doch schon einige aktiv glaube ich.

Werde ich mal machen. Mit RS232 komme ich aber gut aus. Schneller ist 
die sowieso...

> Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist,
> nachdem ich einige Zeit nichts mehr von Dir gehört hatte.

Ich habe mich jetzt wieder hineingefunden und werde das Scope eine Weile 
nicht zum Arbeiten brauchen.

Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
1
char    charTOlMenuKey[]={
2
//  0x0  0x1  0x2  0x3  0x4  0x5  0x6  0x7  0x8  0x9  0xA  0xB  0xC  0xD  0xE  0xF
3
      -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1, -11, -12, -10,  -1,  -1,  -1,  -1,  -1,
4
//  0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F
5
      -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1, -11, -12, -10,  -1,  -1,  -1,  -1,  -1,
6
//  ' '  '!'  '"'  '#'  '$'  '%'  '&'  '''  '('  ')'  '*'  '+'  ','  '-'  '.'  '/'
7
      -2,  80,  81,  -1,  83,  84,  85,  -1,  87,  88,  -1,  -1,  69,  71,  70,  86,
8
//  '0'  '1'  '2'  '3'  '4'  '5'  '6'  '7'  '8'  '9'  ':'  ';'  '<'  '='  '>'  '?'
9
      39,  30,  31,  32,  33,  34,  35,  36,  37,  38,  68,  67,-127,  89,-127,-127,
10
//  '@'  'A'  'B'  'C'  'D'  'E'  'F'  'G'  'H'  'I'  'J'  'K'  'L'  'M'  'N'  'O'
11
     -1,  50,  64,  62,  52,  42,  53,  54,  55,  47,  56,  57,  58,  66,  65,  48,
12
//  'P'  'Q'  'R'  'S'  'T'  'U'  'V'  'W'  'X'  'Y'  'Z'  '['  '\'  ']'  '^'  '_'
13
     49,  40,  43,  51,  44,  46,  63,  41,  61,  60,  45,-127,-127,-127,-127,-127,
14
//  '`'  'a'  'b'  'c'  'd'  'e'  'f'  'g'  'h'  'i'  'j'  'k'  'l'  'm'  'n'  'o'
15
     -1,   0,  10,  16,   5,  14,   7,  23,  55,   1,   2,   3,   4,  13,  22,  26,
16
//  'p'  'q'  'r'  's'  't'  'u'  'v'  'w'  'x'  'y'  'z'  '{'  '|'  '}'  '~'  DEL
17
     15,  19,   9,   8,  12,   6,  21,  20,  27,  17,  29,  -1,  -1,  -1,  -1,  -1};
Spart fast 100 Zeilen Code.

Gruß,
Falk

von Stefan E. (stefan_e)


Lesenswert?

>Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.
>Eingang ist der Sonnenschirm als Antenne ;-)

Coole Idee ;-)

>Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
>nächsten Oszi Start dann wieder weg?

Die ist beim nächsten Start wieder weg. Aber trotzdem vorsicht, da die 
Firmware trotzdem Einstellungen in den Flash speichert. Also vorher auf 
alle Fälle einen Backup ziehen. Da ist eine Sicherung der 
Config-Bereichs mit dabei.

Ich würde mir Perl installieren. Der WelecUpdater ist schnarch langsam. 
Ob .ram damit überhaupt geht, hat glaube ich, keiner mehr ausprobiert.

Gruß,
Stefan

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Falk Willberg schrieb:
...
> Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas
> den entsprechend einpflegen könnte?

Hier das diff-file für 0.3.

Falk

von Blue F. (blueflash)


Lesenswert?

Michael schrieb:
> ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas
> kaputt mache, will ich vorher nochmal kurz nachfragen.

Beides eine gute Idee... allerdings steht eigentlich so ziemlich alles 
in den Beipackzetteln die ich mit dazugetan habe. Trotzdem hier schnell 
noch ein Antwort auf Deine Fragen.

> Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
> nächsten Oszi Start dann wieder weg?

So ist es. Aber wie Stefan schon anmerkte - die neue Version verwaltet 
die im Flash abgelegten Daten etwas anders. D.h. beim nächsten Start der 
alten Software kann es merkwürdige Nebenwirkungen geben, die sich jedoch 
mit Default Setup beheben lassen sollten. Auf jeden Fall solltest Du Dir 
mit dem Welecupdater ein Backup Deines Flash machen - Anleitung dazu 
liegt im Doku Ordner der Betaversion.

> Kann ich das unter Windows einfach mit der WelecUpdater.exe machen?

Nein! Der Welecupdater kann es nicht, und zwar einfach deswegen nicht, 
weil er die Endung .ram nicht unterstützt. Du müßtest die TomCat.ram 
einfach nur umbenennen in TomCat.flash (aber nicht mit der Richtigen 
verwechseln ;-) ), dann sollte es gehen.

> Oder muss ich mir vorher nen Perl-Interpreter zulegen,
> damit ich das mit dem Skript machen kann?

Wenn Du das öfter machen möchtest, kann ich das nur dringend empfehlen, 
da
der Unterschied 20 Minuten zu 3 Minuten doch schon gewaltig ist.

Gruß und viel Spaß

Hayo

von Blue F. (blueflash)


Lesenswert?

@Falk

> Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:

Sehr schön, wenn wir so weitermachen schrumpft das File noch unter 1,2 
MByte trotz neuer Funktionen ;-)

Auf jeden Fall wird der Code langsam immer übersichtlicher und 
strukturierter.

Gruß Hayo

von Michael H. (stronzo83)


Lesenswert?

Hallo,
nachdem ich euren Thread jetzt eine Weile verfolgt habe, habe ich mir 
auch ein Welec bestellt, das nächste Woche eintrudeln müsste. Zur Zeit 
bin ich noch im Prüfungsstress, danach möchte ich mich aber auch an der 
Verbesserung des Gerätes beteiligen.

Achja, was mir noch aufgefallen ist: können die Dinger wirklich nur bis 
zu 5V/div nach oben? Mein jetziges Oszi lässt sich auf bis zu 50V/div 
schrauben und zumindest 10V/div und 20V/div habe ich auch schon 
desöfteren benutzt.
Mir fehlt noch der Überblick über Hard-/Software des Welec - kann man 
die Messbereiche noch hinzufügen oder steht dem etwas entgegen?

Viele Grüße,
Michael

von Karl (Gast)


Lesenswert?

Man nehme einen 10:1 Tastkopf und gut. So machen es auch die Agilents. 
Man kann im Menü auswählen, was für eine Probe dran ist (auch A/div 
usw...)

von Cra Z. (crazor)


Lesenswert?

Hayo W. schrieb:
> @Daniel
> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und
> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit
> eigene Foren einzurichten ist natürlich nicht übel.

Erstmal gehts ja nur um das Forum. Das ist ein phpBB und entspricht 
somit wohl dem de-facto-Standard für Forensoftware. Die Antwortzeit ist 
wesentlich besser als bei diesen Mega-Threads hier im Forum

> Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in
> regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht
> immer neue Treads nötig sind.

Das können wir bei SF auch. Da gibts vollen Zugriff auf die übliche 
phpBB-Administration. Allerdings sollte sowas garnicht nötig sein, denn 
meiner Meinung nach sollte für das, wofür hier Threads verwendet werden, 
im phpBB ein Unterforum angelegt werden, in dem dann für 
unterschiedliche Gedankengänge unterschiedliche Threads genutzt werden 
;) Aber das ist sicherlich Geschmackssache (des Moderators =)

> Ich habe da jetzt einfach mal einen Thread zum Thema screendump
> aufgemacht.
> Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.

Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das 
andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich 
(wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet 
werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen. 
Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit 
dem Google Groups Kram).

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Aktuelles:
- Die Option -c <serial-port> geht auch unter Linux
- Mit einer kleinen Firmwareänderung wird der Dump vom Programm
  gestartet
- Man kann die Option "-m" für einen monochromen screendump angeben 
(10s)
- Mit "-d" werden die Daten als CSV ausgegeben (7s).
- Ohne Optionen -c oder -m wird ein farbiger screendump ausgegeben (30s)
Die entsprechenden Patches kommen morgen...

Die Grafik zeigt die Ausgabe, die "kst" aus dem CSV-file erzeugt.

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:

> Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das
> andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich
> (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet
> werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.

Gute Idee. Ich werde meine Änderungen künftig in SFNET ablegen und hier 
darauf hinweisen.

Dieses Forum ist nicht schlecht, aber mit Themen, Unterthemen etc. ist 
SFNET einfach besser geeignet.

> Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit
> dem Google Groups Kram).

Ich werde den Google-Groups-Kram bald zumachen und einen Hinweis hierhin 
und nach SFNET anbringen (wenn ich herausfinde, wie das geht).

Falk

von Blue F. (blueflash)


Lesenswert?

@Stefan

Nur kurz zur Abstimmung, ich habe die vertikalen Cursordaten korrigiert, 
so dass jetzt alle Spannungen korrekt angezeigt werden
-> void Display::CALCCURSORDATA(void)


Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Nochmal kurz zur Abstimmung - ich schmeiße die bei einigen 
Anzeigefunktionen die sich wiederholenden switch() Anweisungen raus und 
ersetze sie durch indizierten array fetch. -> Display::MEASURETIME(), 
CALCCURSORDATA(), CALCPRETRIGGER(), CALCTIMEBASE()

Hayo

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Die Diffs für die Firmware und screenshot-0.3 findet Ihr hier: 
https://sourceforge.net/apps/phpbb/welecw2000a/download/file.php?id=8

Das Bild ist aus "kst" mit dessen FFT. Statt kHz sollte das MHz 
heißen...

von Bernd O. (bitshifter)


Lesenswert?

Niklas O. schrieb:

Hallo Niklas,

> @Kurt:
> [Nicht alle Planes uebertragen]
>
> Daran hab' ich auch schon gedacht.  In der Tat sind ein paar der 16
> Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst
> noch weitere ausschlieszen.  Da das DSO ohnehin da "Ewigkeiten"
> pro Plane braucht liesze sich da deutlich Zeit einsparen.

Im aktuellen Stand werden ja so weit ich das überblicke sämtliche Planes 
übertragen und dann auf dem PC genauso wie auf dem Oszi mit Farben 
versehen und übereinandergelegt. Bei der Übetragung der Planes geht viel 
Zeit drauf. Wäre folgender Weg nicht besser?

Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane 
ist:

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. Wenn der Pixel in Plane A nicht gesetzt ist 
wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält 
dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). Wenn der 
Pixel auch in Plane B nicht gesetzt ist, dann wird Plane C geprüft. Wenn 
der Pixel hier gesetzt ist, erhält dieser Pixel den Wert "3" wenn nicht, 
erhält der Pixel den Wert "0" (für transparent bzw. schwarz).

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.
RLE funktioniert hier natürlich immer noch, da man ja statt einzelner 
Bits auch 4-Bit Sequenzen zusammenfassen kann. Auch auf dem Oszi dürft 
sich auch einiges an Laufzeit sparen lassen. Für das Überlagern der 
Planes im Oszi geht zwar etwas Zeit drauf, aber statistisch müssen nur 
noch 50% der Plane-Daten gelesen werden, da die "hinteren" Planes nach 
einem Match gar nicht mehr gelesen werden müssen.

Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben, 
aber schnelle Screenshots sind noch schöner.

Gruß,
Bernd

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Bernd O. schrieb:
>
> Hallo Niklas,

Ich bin zwar nicht Niklas, habe aber seine Routinen bearbeitet.

...

> Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane
> ist:
>
> 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. Wenn der Pixel in Plane A nicht gesetzt ist
> wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält
> dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen).
...
Klingt gut! Sollte sich einfach implementieren lassen.

> Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,
> aber schnelle Screenshots sind noch schöner.

Auf 30s sind wir schon, mit Deinem Vorschlag könnte das noch schneller 
werden.

Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke 
ich mal...

Gruß,
Falk

von Stefan E. (stefan_e)


Lesenswert?

Hallo Hayo,

die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen 
ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick 
reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal 
eingestellt, auch mit SourceForge "relativ" fix.

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Hmm, wahrscheinlich oute ich mich jetzt als Trottel, aber was ist SVN?

Das VN steht vermutlich für virtual network oder?

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

SubVersioN, Versionsverwaltungstool, müsste unter Linux eigentlich 
installiert sein, unter Windows ist Tortoise momentan eine gute Wahl...

Michel

von Armin D. (ardiehl)


Lesenswert?


von Michael W. (slackman)


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

Danke, ich mach mich da mal schlau und guck mal was sich machen läßt

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich 
perfekten Client wie z.B. Tortoise unter Windows. Bei mit leistet "eSVN" 
noch am wenigsten Widerstand. KSVN geht bei mir mit SF nur sehr träge.

Gruß,
Stefan

von Günter J. (gjung)


Lesenswert?

Stefan E. schrieb:
> Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich
> perfekten Client wie z.B. Tortoise unter Windows.

Im alltäglichen Umgang braucht man eigentlich nur eine Handvoll
Kommandos:
  svn checkout
  svn update
  svn status
  svn commit
  svn add
damit sind 95% aller Tätigkeiten abgedeckt.
Dafür kann man gut, auch als nicht Kommandozeilen-Freund, mit
der Kommandozeile leben.

Gruß,
Günter

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Falk Willberg schrieb:

> Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke
> ich mal...

Leider hilft ein Flash-Update nicht gegen kalte Lötstellen oder 
Wackelkontakte. Jedenfalls startet die Firmware nur noch bis
1
+S80484AA00CD                                                 
2
beta firmware starting!                                       
3
                                                              
4
- Flash initialization                  - done                
5
2-Channels found Signatur : 98013000                          
6
Keyboard found                                                
7
Setup hardware                            - done
8
HW Version : 8c7  Channels : 2                                
9
Testing LEDs                                                  
10
Building trigonometric tables           - done                
11
Setup vars                              - done                
12
Setup vars to default values            - done                
13
Flash not loaded - setting standards                          
14
Read config from flash                     - done
15
Read protected config from flash        - done
16
Recalc vars                             - done
17
- Hardware initialization               - done
18
******************************************************************
19
calculating timebase...
20
timeoff = Timebase_Offset_Pos * tfactor  / 1000000
21
22
Timeoffset          = -0.000000300
23
Timebase_Offset_Pos = -300
24
tfactor             = 0.00000000100
25
******************************************************************
26
27
spurious interrupt number: .................

Ein wenig ans Gehäuse zu klopfen hat das Problem kurzfristig lösen 
können.

Der GERMS-Monitor funktioniert aber noch.

Schön, wenn man drei Jahre Garantie hat :-)

Falk

von Stefan (Gast)


Lesenswert?

Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für 
typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und 
oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da 
würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...

von Robert S. (razer) Benutzerseite


Lesenswert?

@Stefan, Ich habe das gerade im Hardware Thread gepostet =)

von Stefan (Gast)


Lesenswert?

Na geil.
Ich gebe zu, dass ich mich durch die Anfrage von Hayo inspiriert sah. 
Die Idee schwirrte mir schon so lange im Kopf rum, dass es wohl einfach 
nur eines Triggers bedufte.

von Roberto (Gast)


Lesenswert?

@Stefan
finde ich auch gut :-)

@
0.82 funktioniert bei mir (W2024A) :-)

Was mir auch noch aufgefallen ist:
Wenn ich "Search Zero Lines" drücke, wandern die Kanäle 3 und4 ein paar 
Pixel nach unten. ?!
erst nach "calibrate DAC" sind sie wieder in der Mitte ..
Ist das bei Euch auch so ?

Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei 
200ms/div
Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit 
man damit auch richtig messen kann .( "Quick Meas" zeigt dann 3,84Hz an 
)
Bei 1ms/div zeigt es mit "Quick Meas" richtig die 1kHz an :-)


Und ein Großes Lob und DANKE, an alle die hier so toll mitarbeiten!!

l.G. Roberto

von Martin H. (martinh)


Lesenswert?

@Roberto

Was du bemängelst (und misst) ist das typische Antialiasing das bei 
allen DSO's auftritt. Es ist dem Anwender überlassen die richtige 
Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit 
einer möglichst hohen sample-rate beginnen und runtergehen bis das 
Signal richtig dargestellt wird).

Martin

von Stefan E. (stefan_e)


Lesenswert?

>Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei
>200ms/div
>Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit
>man damit auch richtig messen kann

Das ist nur eine "optische Täuschung" (Aliasing), die durch das Abtasten 
bei zu geringer Frequenz entsteht.

von rowue (Gast)


Lesenswert?

Unter Linux habe ich die besten Erfahrungen mit "rapidsvn" 
(http://rapidsvn.tigris.org/) gemacht. Ist aber denke ich bei jedem
unterschiedlich.

Svn selbst ist ziemlich cool, hat aber den Nachteil, dass es auf 
Client-Seite das doppelte an Speicherplatz für die Sourcen braucht.

von rowue (Gast)


Lesenswert?

PS:

"svn diff" als Befehl auf der Kommandozeile ist auch sehr nett.
Damit kann mensch eine Projektbetreiber seine Änderungen schicken,
wenn mensch selbst keinen Schreibzugriff auf das Repository hat.

von Blue F. (blueflash)


Lesenswert?

Hat eigentlich noch keiner bemerkt, dass das XY-Grid nicht eingeblendet 
wird bei der 0.82?

Macht nichts ist schon gefixed.

Hayo

von Robert S. (razer) Benutzerseite


Lesenswert?

Hab gerade die 1.2.82 eingespielt. Funktioniert leider erstmal gar nicht 
gut.

Im Math Menü habe ich beim FFT-Softkey ein Rufzeichen drinnen. Wen ich 
in ein anderes Menü wechsle bleibt dieses Rufzeichen erhalten. 
Zusätzlich im Softkey "1+2" ein paar Artefakte.

Das Math-Menü reagiert bei mir gar nicht. Auf keinen Tastendruck.

Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht 
gar nichts mehr.

Die violette Math-Linie, die angezeigt wird sobald der Math-Modus aktiv 
ist, durchbricht Menüs. Zb das Quick-Measure Menü. Wobei das eher ein 
Minor Bug ist.

Ich denke, das Beste ist wenn ich den Komplett-Dump neu einspiele.

lg Robert

von Blue F. (blueflash)


Lesenswert?

@Robert

Wenn sich das Problem durch Default Setup, Drehen an der Timebase und 
Neustart nicht beheben läßt, ist das Einspielen eines Dumps in der Tat 
die beste Lösung. Bei mir war das auch schon mal nötig, danach ist dann 
aber alles wieder in Ordnung.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Robert S. schrieb:

...

> Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht
> gar nichts mehr.

Das ist normal, sollte aber nach ca. 30s vorbei sein.

Falk

von Blue F. (blueflash)


Lesenswert?

@Falk

> spurious interrupt number: .................

die gleiche Fehlermeldung hatte ich beim versehentlichen Überschreiben 
des Stacks als ich eine Assemblerroutine mit falschen Parametern 
versorgt habe. Bist Du sicher, dass es sich um einen Hardwarefehler 
handelt?

Hayo

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

Hallo,

Da ich auf meinem Windowsrechner keinen Platz für ein zweites 
Betriebssystem habe konnte ich bisher den Source nicht selbst 
compilieren.

Jetzt habe ich jedoch auf dem ftp server von altera die cygwin version 
des compiler's gefunden! (in der Version 3.2)

Mit dem ist es möglich auch unter Windows an der SW Entwicklung mit zu 
machen.

Anbei eine kleine Anleitung in englisch (sicherlich noch 
verbesserungswürdig).

Martin

von Blue F. (blueflash)


Lesenswert?

Hi Martin,

das ist cool, dann kann ich auch im Urlaub in Italien weiterentwickeln, 
mein Lappy hat nämlich nur Windows drauf (meine Frau wird mich 
steinigen).

Ich werde das mal nach Deiner Anleitung versuchen.

Gruß Hayo

von Michael H. (stronzo83)


Lesenswert?

Wenn deine Frau den ersten Stein aufhebt, dann mach' ihr klar, wie viele 
arme kleine Wittig User sie ins Unglück stürzen würde. Vielleicht lässt 
sie dich dann uns zu liebe am Leben und zielt nur auf Körperteile, die 
nicht zur Firmwareentwicklung benötigt werden...

von Stefan E. (stefan_e)


Lesenswert?

Hey,
trifft sich super. Mach mer doch gleich ne Session in Italien ;-)

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Kurze Anfrage zum Organisatorischen:

Nachdem jetzt Google.Groups geschlossen ist, wo kann ich außer hier noch 
das komplette Firmwarepaket hochladen? Gibt es da auf SFN eine 
Möglichkeit?

Hayo

von Cra Z. (crazor)


Lesenswert?

Ja, die gibt es. Ich habe dir mal die Berechtigungen gesetzt, damit du 
Releases erstellen kannst. Hier ist alles erläutert: 
http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download
Falls es nicht klappen sollte, können wir das ja mal zusammen 
durchgehen, Skype-Daten von mir sind ja überall zu finden. Bin 
allerdings erst morgen abend wieder richtig zugegen (Prüfungsstress). 
Konkrete Fragen kann ich sonst auch hier oder per Mail/PN beantworten.

von Blue F. (blueflash)


Lesenswert?

Hallo werte Gemeinde,

ab sofort gibt es die aktuellen Open Source Releases hier:

https://sourceforge.net/projects/welecw2000a/files/

Zur Zeit ist noch die 0.82 das aktuelle beta Release, aber das Nächste 
ist schon in Arbeit und kommt hoffentlich zum Ende der Woche.

Gruß Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

ist ja einiges in den letzten paar Tagen in meiner Abwesenheit
passiert :)

@Falk:
Hab' Deine Patches gesehen und werde die die naechsten
Tage migrieren, wohl gar direkt ins SourceForge SVN
Repository, wenn ich das richtig sehe das ihr euch
entschlossen habt dieses zu nutzen.

Schoen das wir jetzt auf 30 Sekunden sind.  Wobei sich mir
jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
ist ja an sich etwas gestiegen). Hast Du schonmal probiert,
aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
ungeprueft davon aus dass der GCC die Funktion nicht inlined)

@Bernd:
Das was Du beschreibst ist in etwa das was bei dem S/W Dump
passiert, nur wird dort dann gleich auch noch die Farbe/dominante
Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
iirc. 10-15 Sekunden allein an Rechenzeit.  Ansonsten gebe ich Dir
wie Falk auch Recht.  Die Frage ist, ob jetzt Falks
Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
schneller waere oder Dein Neuansatz.  Erstere (alte) Loesung
waere flexibler und bereits implementiert, von daher wuerde
ich, sollte letztere nicht schneller sein, dabei bleiben.
@Falk:  Hast Du da diesbzgl. in der Zwischenzeit schon
weiter gemacht?

Niklas

von Jürgen (Gast)


Lesenswert?

> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?

Aber sicher wäre das Klasse!!

von Blue F. (blueflash)


Lesenswert?

Jürgen schrieb:
>> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
>> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
>
> Aber sicher wäre das Klasse!!

Ich finde die Idee auch gut, aber das sollten wir erstmal auf der 
Wishlist unterbringen und die Realisierung erst dann vornehmen wenn wir 
vom beta Status weg sind.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Niklas

Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht 
kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da 
dann die alten Programme nicht mehr kompatibel sind zum Datenformat.

Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen nur 
jetzt mit der SFN Releaseverwaltung

Gruß

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
...
> @Falk:
> Hab' Deine Patches gesehen und werde die die naechsten
> Tage migrieren, wohl gar direkt ins SourceForge SVN
> Repository, wenn ich das richtig sehe das ihr euch
> entschlossen habt dieses zu nutzen.
>
> Schoen das wir jetzt auf 30 Sekunden sind.  Wobei sich mir
> jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
> Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
> ist ja an sich etwas gestiegen).

Das frage ich mich auch. Leider habe ich keine Informationen, welche 
Operationen, wieviel Last erzeugen. Im Standardfall (Sehr viele gleiche 
Bytes), passiert aber ca. 60.000-mal nicht anderes als ein increment und 
ein 16-Bit Vergeich.

> Hast Du schonmal probiert,
> aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
> ungeprueft davon aus dass der GCC die Funktion nicht inlined)

Das dürfte die Code-Größe gewaltig steigern (640*480-mal die 
RLE-Funktion...)

> @Bernd:
> Das was Du beschreibst ist in etwa das was bei dem S/W Dump
> passiert, nur wird dort dann gleich auch noch die Farbe/dominante
> Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
> iirc. 10-15 Sekunden allein an Rechenzeit.  Ansonsten gebe ich Dir
> wie Falk auch Recht.  Die Frage ist, ob jetzt Falks
> Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
> schneller waere oder Dein Neuansatz.

Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten 
Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist 
simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der 
Definition geändert werden.

>  Erstere (alte) Loesung
> waere flexibler und bereits implementiert, von daher wuerde
> ich, sollte letztere nicht schneller sein, dabei bleiben.
> @Falk:  Hast Du da diesbzgl. in der Zwischenzeit schon
> weiter gemacht?

Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.

Ich sage Bescheid, wenn ich weitermachen kann, bis dahin lasse ich den 
Kram in Ruhe.

Inzwischen mache ich mich auch mit SVN vertraut.

Vielleicht bastele ich inzwischen ein ppm2splashlogo.pl ;-)

Falk
P.S.: Ich finde es prima, daß wieder mehr Leute dazu beitragen, ein 
Scope so zu verbessern, daß Anwenderwünsche direkt berücksichtigt werden 
können.

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

> Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht
> kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da
> dann die alten Programme nicht mehr kompatibel sind zum Datenformat.

Ja das werde ich machen.  Den Sourcecode fuer die Tools wuerde ich dann
unter pc/screenshot/ einpflegen.

> Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen
> nur jetzt mit der SFN Releaseverwaltung

D.h., (noch) nicht den Sourcecode im SVN Repository pflegen?  Haette
den Vorteil das wir alle direkt Aenderungen committen koennten ohne
dass Du die selbst einbauen muesstest.  Damit man sich nicht in die
Quere kommt koennten wir noch Branches machen, aber im Moment sollten
wir auch ohne auskommen.  Oben wurden ja schon ein paar SVN-Clients
genannt.  Ich faend's super wenn wir uns darauf einigen koennten
das SVN zu nutzen.  Kleine Bugfixes und Verbesserungen wie zuletzt
das charTOlMenuKey Array von Falk waeren so sofort eingebaut und auch
von allen Interessierten noch vor dem naechsten offiziellen Release
getestet.  Ich koennte auch etwas wie einen automatischen
"Nightly Build" bereit stellen, also eine fertige Firmware die den 
aktuellen Stand im Repository wiederspiegelt.

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo Falk,

>> Hast Du schonmal probiert,
>> aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
>> ungeprueft davon aus dass der GCC die Funktion nicht inlined)
> Das dürfte die Code-Größe gewaltig steigern (640*480-mal die
> RLE-Funktion...)

Stimmt, bloede Idee. (auch wenn man das auf 640*480/8 runter
dreht noch...)

>> @Bernd:
>> Das was Du beschreibst ist in etwa das was bei dem S/W Dump
>> passiert, nur wird dort dann gleich auch noch die Farbe/dominante
>> Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
>> iirc. 10-15 Sekunden allein an Rechenzeit. [..]
>
> Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten
> Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist
> simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der
> Definition geändert werden.

Ja, stimme ich Dir zu.  Waere 'ne simple Modifikation der B/W Funktion,
baue ich mal ein.

> Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.

:/  Bin mal gespannt wie der Service bei Wittig ist.

Niklas

von Blue F. (blueflash)


Lesenswert?

Mit SVN muß ich mich erst noch näher auseinander setzen. Da ich momentan 
einiges zu tun hatte und gleichzeitig am nächsten Release dran war hatte 
ich da keine Zeit für. Deine Lösung mit dem Nightly Build klingt ganz 
Interessant, denn mir ging es in erster Linie darum nicht nur die 
Entwickler mit dem neuesten Stand zu versorgen, sondern auch den 
Benutzern die Gelegenheit zu geben die aktuellsten Versionen 
auszuprobieren.

Weiterhin möchte ich auch vermeiden meinen Verwaltungsoverhead zu groß 
werden zu lassen um möglichst viel Zeit für die Entwicklung zu nutzen.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hallo Zusammen,
ich arbeite gerade an einer "Hardwarelösung" für die Screenshots. Die 
Platine enhällt:
ATMega32/644, VNC1L, MAX232, 64kBit FRAM, SUB-D Anschlüsse für Oszi und 
PC, USB Anschlüsse für Stick und Oszi und eine Pinleiste um den Vinculum 
das erste mal zu programmieren. Größe ist 80x80mm einseitig mit einigen 
Brücken.

Ich werde noch Layout und Schaltplan etwas überarbeiten und dann hier 
reinstellen. Allerding befürchte ich, das der Vinculum etwas schwierig 
zu löten ist.

Sollte das Konzept funktionieren kann man aber immer noch auf ein 
fertiges Modul ausweichen. Der Flaschenhals ist definitiv nicht auf der 
Platine sondern die lahme RS232 vom Oszi.

Mfg,
Kurt

von Odic (Gast)


Lesenswert?

Moinsen allerseits,

wenn man hier ein paar Tage nicht reinschaut hat man ganz schön was zu 
lesen. Respekt vor dem Elan mit dem hier gewerkelt wird...

Noch eine Tipp zu Subversion-Clients: ich kann jedem nur aller wärmstens 
eclipse ans Herz legen. Nicht nur, dass es die Entwicklung massiv 
vereinfacht, es bringt auch einen sehr brauchbaren SVN-Client 
(Subversive) mit.

Viel Spaß weiterhin.

Beste Grüße,
odic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Kurt,

na deine Platine sieht ja echt gut aus. Vielleicht sollten wir, wenn 
feststeht das die Schaltung funktioniert, auch dafür eine professionelle 
Lösung in Betracht ziehen? Bei den meisten dieser "Produkte" drückt eine 
Herstellung von 30...50 Stck. ganz massiv den Preis.
Ich hätte da auf jeden Fall Interesse dran.

Gruß, brunowe

P.S.: mit Eagle3D gemacht?

von Kurt B. (kurt)


Lesenswert?

Hallo Bruno,
ja, mit Eagle 3D.

Auch ja zur Professionellen Lösung. Leiterbahnen mit 8mil und Abstände 
mit 11mil sind nicht für jeden einfach zu ätzen. Außerdem soll die 
Platine später kleiner und doppelseitig werden damit man die 
Versorgungsspannungen ordentlich routen kann.

von Blue F. (blueflash)


Lesenswert?

Sehr interessante Erweiterung, die dürfte weggehen wie warme Semmeln 
(ich bin z.B. ein Doppelabnehmer). Daher denke ich sollte eine größere 
Auflage zu Gunsten des Preises kein Problem sein.


Was Anderes: Um die ToDo-Liste zu komplettieren bin ich mal in Gedanken 
die wichtigsten Funktionen des DSO durchgegangen, dabei ist mir 
aufgefallen, dass ich noch nie die Speicherfunktion für die Signale 
benutzt habe. Hat das schon jemand ausprobiert? Ist das ein Feature das 
ausnahmsweise mal einfach so funktioniert, oder müssen wir da auch das 
Baustellenschild aufstellen?

Gruß Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

die Save/Recall Sachen funktionieren bei der Original-Firmware
einigermaszen, habe ich schon oefters benutzt wenn ich z.B. Signale
vergleichen wollte.  Dummerweise konnte ich die dann allerdings
nicht mehr mit der Welec Originalsoftware vom Oszi holen, da wurde
einfach eine neue Signalfolge aufgenommen.

Auch kann man die Funktion nutzen um Kanal- und Zeitachsen-
einstellungen zu sichern, die werden naemlich gleich mit
wiederhergestellt.

Bei der Beta-Firmware scheint da aber genau gar nichts zu
funktionieren. Habe da sehr absurde Effekte.  Genau genommen
ist wohl Reboot faellig nach einem Save gefolgt von Recall,
in benutzbaren Zustand habe ich mein Geraet zumindest nicht
wieder versetzt bekommen.

Waere schoen wenn wir das zum Laufen bekaemen, habe mich da aber
noch nicht umgeschaut.  Vermutlich werden die ADC-Daten samt
Parameter abgelegt und einfach neu gerendert, oder?  Die iirc.
80 Speicherplaetze die da Wittig vorgesehen hat sind aber IMHO
etwas uebertrieben.  Vllt. koennen wir das auch aufteilen, d.h.,
Recall Trace und Recal Settings.

BTW: Hast Du meine Nachricht auf SF wg. Devel schon gesehen?

Niklas

von Blue F. (blueflash)


Lesenswert?

Nein ich schau mal kurz rüber.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich kann da nichts finden, wo muß ich suchen?

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

mhm, muesstest egtl. die SF E-Mails an Deine Adresse
geforwardet bekommen.  Ging nur darum dass Du mich
(niklas_olmes auf SF) als Devel zum Projekt hinzufuegst.

Geht mit "Project Admin->Membership" eingeloggt unter
https://sourceforge.net/projects/welecw2000a/develop

Niklas

von Blue F. (blueflash)


Lesenswert?

Ist erledigt

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich hab mir die Save/Recall-Geschichte mal angesehen, ich glaube es 
liegt an den geänderten Parametern die im Flash abgelegt werden, da kann 
ich bei Gelegenheit mal beigehen.

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

wenn sich einer dranmacht an der Save/ Recall Funktion rum zu basteln, 
dann sollte man direkt den Vorschlag von stendres aus der SF Wishlist 
mit einfließen lassen. Halte ich für nen guten Vorschlag.
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWwishlist

Gruß, brunowe

von Niklas O. (nevm)


Lesenswert?

Hallo Bruno,

ja, das waere in der Tat sehr nuetzlich.  Koennte man dazu einfach
die (scheinbar) unbenutzten Memory-Planes hernehmen?  Sind allerdings
nur drei.

Wo ich gerade die Wishlist sehe finde ich den ersten Vorschlag
von michelwernersen auch wichtig.  Da ich (noch) die Original-Firmware
im Flash habe und die aktuelle Beta ins RAM lade bin ich staendig
am Justieren.  Das liesze sich sicher recht einfach realisieren,
ich werde da spaeter mal drueber schauen.

Niklas

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Hallo Hayo,
>
> die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen
> ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick
> reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal
> eingestellt, auch mit SourceForge "relativ" fix.

Ich hab's mal ausprobiert:
1
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/ improved

Jetzt finde ich in src/ die Sourcen, aber auch src/src und 
src/quickmeasure..

"make" in src/ übersetzt die "alten" Sourcen und faällt mit
1
src/hardware_t.cpp:427: invalid types `int[int]' for array subscript
 auf die Nase.

Wer kann einem SVN-Anfänger mal das Brett vom Kopf nehmen?

Außerdem scheint mir, daß es eine gute Idee wäre, die Dateien weiter 
aufzuteilen. So könnte der PC-Kommunikationsteil doch in 
"pc-comms.[cpp|h]" ausgelagert werden.

Gruß,
Falk

von Niklas O. (nevm)


Lesenswert?

Hallo Falk,

die doppelten/dreifachen Sourcen siehst nicht nur Du :)

Der letzte committete Stand scheint 0.80 zu sein.
Hayo hat selbst ja noch nichts eingepflegt.

Mit
1
$ svn log $file
kannst Du Dir die Commit Messages der Revisions anschauen, bei
der die angegebene Datei betroffen ist.

Mit
1
$ svn diff -r113 src/hardware_t.cpp
siehst Du die Aenderungen seit Revision 113 (und warum es
nicht kompiliert).  (Wenn Du die Datei hinten weglaesst
siehst Du den ganzen Diff.)

Warum da jetzt mehrfach Sourcen rumliegen weisz ich nicht,
die Logmessage dazu besagt "creating new brachn for QM".
Sieht fuer mich nach nem Unfall aus, da ich sonst aber mit
CVS und GIT vertraut bin will ich mich nicht festlegen, kann
auch nen Feature sein ;)

Wir sollten IMHO erstmal hergehen und den aktuellen Versionsstand
(0.82) einmal sauber importieren.

Ansonsten, nochmal Kurzeinweisung fuer Falk:
1
<0>[18:28]niklas@empire:/tmp/improved$ cat > src/newfile
2
Inhalt
3
<0>[18:28]niklas@empire:/tmp/improved$ svn add src/newfile 
4
A         src/newfile
5
<0>[18:28]niklas@empire:/tmp/improved$ svn diff
6
Index: src/newfile
7
===================================================================
8
--- src/newfile (revision 0)
9
+++ src/newfile (revision 0)
10
@@ -0,0 +1 @@
11
+Inhalt
12
<0>[18:28]niklas@empire:/tmp/improved$ svn status
13
A       src/newfile

Mit svn commit wuerdest Du den Kram abschicken, wirst dabei
noch um eine Logmessage als Beschreibung gebeten.
Die restlichen Kommandos erklaert Dir svn help gerne :)

Niklas

von Stefan E. (stefan_e)


Lesenswert?

Hallo,

jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen, 
wieder zu löschen.
Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die 
QM-Funktion ändere und dann später wieder in die anderen sourcen 
einpflege.

Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich 
schlagen ;-)

Vielleicht gibts ja hier einen, der das mal so aufräumt, wie es sich 
gehört.

von Robert S. (razer) Benutzerseite


Lesenswert?

@ Kurt: Falls du einen Prototyp bei LeitOn mach lassen willst, ich habe 
noch einen 10€ Gutschein. Den kannst du haben.

von sunny (Gast)


Lesenswert?

hat denn schon mal jemand das compilieren unter windows getestet? ich 
hab es nicht hin bekommen. es kommt folgende meldung
># 2009.07.08.19:37:21 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc >-I .
>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >-D_Debug_
> src/TomCat.cpp -o obj/TomCat.cpp.o
>process_begin: CreateProcess(NULL, nios-elf-gcc -I ./inc -I ./src -I ./inc >-I ..
>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >src/TomCat
>.cpp -o obj/TomCat.cpp.o, ...) failed.
>make (e=2): Das System kann die angegebene Datei nicht finden.
>make: *** [obj/TomCat.cpp.o] Error 2
er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch 
gar nicht existiert. hat jemand einen tip?

gruß sunny

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Hallo,
>
> jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,
> wieder zu löschen.

Könnte ich mit ksvn vielleicht schaffen. Die Dateien sind sowieso alle 
identisch.

> Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die
> QM-Funktion ändere und dann später wieder in die anderen sourcen
> einpflege.
>
> Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich
> schlagen ;-)

Schade, hatte den Knüppel gerade geputzt ;-)

Stattdessen habe ich Version 0.4 von w2000a-screenshot committed. 
Vielleicht hat das ja geklappt...

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

sunny schrieb:
> hat denn schon mal jemand das compilieren unter windows getestet? ich
> hab es nicht hin bekommen. es kommt folgende meldung
...

>>make (e=2): Das System kann die angegebene Datei nicht finden.
>>make: *** [obj/TomCat.cpp.o] Error 2
> er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch
> gar nicht existiert. hat jemand einen tip?

Er findet nicht die tomcat.cpp.o nicht (die will er ja gerade erzeugen), 
sondern die includes unter inc/. Die findest Du da: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/inc/

Hat mich auch eine Weile gekostet, das herauszufinden.

Falk

von sunny (Gast)


Lesenswert?

die .inc datein sind aber da. im \inc verzeichniss.
ich habe den kompletten build aus dem svn gezogen und nach c:\build 
entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.
wie genau (name,wert) hast du denn bei dir die umgebungsvariablen 
gesetzt?
gruß sunny

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

sunny schrieb:
> die .inc datein sind aber da. im \inc verzeichniss.
> ich habe den kompletten build aus dem svn gezogen und nach c:\build
> entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.
> wie genau (name,wert) hast du denn bei dir die umgebungsvariablen
> gesetzt?

Ich habe nichts setzen müssen. Ich hatte die gleiche Fehlermeldung wie 
Du, aber unter Linux. Da mußte ich nur das .../inc besorgen, make 
eingeben und es lief...

Vielleicht meldet sich noch ein Windows-User...

Falk

von sunny (Gast)


Lesenswert?

unter linux funktioniert es bei mir auch. ist nur unpraktisch weil ich 
linux nur af dem satreciver laufen hab.
vielleicht hat ja noch jemand einen tip zum compilieren windows.

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die
Umgebung liefern und dementsprechend müsste das Makefile geändert
oder Umgebungsvariablen gesetzt werden. Das wäre jetzt aber mal
wirklich ein Anlass für einen neuen Thread. ;-)

Gruß, Guido

von sunny (Gast)


Lesenswert?

>ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die
>Umgebung liefern
ja, tut sie auch die sind in einem unterverzeichniss
>dementsprechend müsste das Makefile geändert
>oder Umgebungsvariablen gesetzt werden.
da müsste man halt nur wissen wie und wo.
>Das wäre jetzt aber mal wirklich ein Anlass für einen neuen Thread. ;-)
ach, so wichtig ist es nun auch wieder nicht. hätte ja sein können das 
es schon einer hinbekommen hat.

gruß sunny

von Guido (Gast)


Lesenswert?

Hallo sunny,

suche halt die Standardheader und ergänze im Makefile unter
"INCLUDE_PATHS = \" noch
                -I /wo_sind_die Standardheader\

Das musste ich unter Ubuntu auch machen, da war es /usr/include.

Gruß, Guido

von Niklas O. (nevm)


Lesenswert?

Hallo,

so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber
in fpga/firmware importiert und Falks letztes Diff eingespielt.
Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.
Das obj/ Verzeichnis wird automatisch angelegt.

fpga/welec/official habe ich entsorgt.

Etwaige Aenderungen in fpga/welec/src und/oder fpga/welec/src/src
usw. ;) muessten noch manuell uebertragen werden.  Z.B. ueber
1
<0>[23:46]niklas@empire:/tmp/W/welecw2000a/fpga/welec$ diff -u ../firmware/src/ improved/src/ | less
schauen was noch relevant ist und uebertragen.

@Falk:
Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?
Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle
Angabe jeder Datei findet.

diff -uNr (u fuer unified, N fuer include new files, ggfls. weglassen,
r fuer rekursiv, auch ggfls. weglassen) ist ganz okay.

Andere Sache:  Wo wir jetzt schon mal das Format fuer die Ausgabe
geaendert haben und auch noch Messwerte rausschreiben koennen waere
IMHO nen kleiner Header nuetzlich, der besagt was kommt und in welcher
Version das ist.  Also statt 'S' 0xff am Anfang koennten wir machen
'S' p v 0xff, Rest beibehalten.

Wobei p Protokoll/Anwendung ist, z.B. 0x01 fuer Screenshot, 0x02
fuer Messdaten.  V waere die Version.  Das Ausleseprogramm koennte
dann entsprechend handeln.

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo nochmal,

@Falk:
Den selben Gedanken mit dem Header hattest Du schon sehe
ich erst jetzt gerade :)  Sorry.

Niklas

von Stefan E. (stefan_e)


Lesenswert?

>so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber
>in fpga/firmware importiert und Falks letztes Diff eingespielt.
>Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.

Sollte auch davor möglich gewesen sein, die Sourcen zu kompilieren. War 
eigentlich auf dem aktuellen Stand. Bis auf der zweite src-Ordner, der 
ein Versehen war.
Jetzt liegt es irgendwie bescheuert, da nich klar ist, für welches 
FPGA-Design die Firmware gedacht ist.

Gruß,
Stefan

von Roberto (Gast)


Angehängte Dateien:

Lesenswert?

Hallo (Martin)
>Was du bemängelst (und misst) ist das typische Antialiasing das bei
>allen DSO's auftritt. Es ist dem Anwender überlassen die richtige
>Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit
>einer möglichst hohen sample-rate beginnen und runtergehen bis das
>Signal richtig dargestellt wird).
Habe mal einen Freund gebeten, ein 1kHz Signal mit seinem
Agilent Infiniium 54831B, 4Kanal, 600Mhz, 4Gsa
aufzunehmen...
Schaut schon viel besser aus!
Bilder : links oben mit 200us/div bis rechts unten mit 500ms/div
Vermutlich schaut das durch den grösseren Speicher besser aus?!

Versuch gerade das mit der Abtastrate und dem Speicher zu verstehen...
Stimmen da meine Rechnungen?
Bei 1ms/div = 250kSa/s -> = 12ms pro Bild würde ich auf 3000 Samples 
kommen?
Bei 200us/div = 1MSA/s -> = 2,4mS pro Bild --> 2400 Samples?

Hat das Welec DSO nicht 16KB/ Kanal?
(oder denke ich da irgendwie falsch?)

l.G. Roberto

von Martin H. (martinh)


Lesenswert?

Hallo Roberto,

Ist etwas unfair einen Rolls Royce mit einem Fiat zu vergleichen!

Aber zu deiner frage:

Die Darstellung hangt von der Samplerate ab, beim Welec (das uebrigens 
nur 4KB Samplespeicher hat) ist die bei 500ms/div nur 
500Samples/Sekunde, bei dieser Samplerate kann ein 1kHz Signal 
natuerlich nicht mehr richtig dargestellt werden (niquist sagt das die 
sample rate mindestens doppelt so hoch sein muss wie die hoechste 
Eingangsfrequenz, und ein Rechtecksignal enthaelt nicht nur die 1kHz 
sondern auch oberwellen). Das Agilent hat 2MB Samplespeicher und kann 
daher bei 500ms/div mit 400kSamples/Sekunde samplen!

Martin

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo,
...
> @Falk:
> Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?
> Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle
> Angabe jeder Datei findet.

Ich hatte einfach "diff" benutzt und manuell nacheditiert. Mit svn 
brauchen wir das ja nicht mehr.

Ich habe übrigens den PC-Teil nach 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/ 
hochgeladen und ihn Version 0.4 genannt.

Falk

von Blue F. (blueflash)


Lesenswert?

@Roberto

Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe 
hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben 
schon mal im Zusammenhang mit Aliasing erklärt. Die genauen 
Zusammenhänge entnimmst Du der Timebasetabelle in den Programming Maps, 
die Du hier findest:

http://groups.google.com/group/welec-dso/files

Hayo

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hayo W. schrieb:
> @Roberto
>
> Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe
> hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben
> schon mal im Zusammenhang mit Aliasing erklärt.

Hatte ich nicht verstanden ;-)

Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer 
die 16KB auszulesen.

Mein letzter Dump ist hier zu finden: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/example.csv.gz

Was bei 500MS/s herauszuholen ist, sieht man hier: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/FFT-from-dump.png

Falk

von Blue F. (blueflash)


Lesenswert?

Sag mal Falk,

wie machst Du eigentlich diese schicken Bilder? Hast Du da ein 
Datenauswertungsprogramm das Diagramme erstellt?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Sag mal Falk,
>
> wie machst Du eigentlich diese schicken Bilder? Hast Du da ein
> Datenauswertungsprogramm das Diagramme erstellt?

Ja: http://kst.kde.org/

Damit mache ich die meisten Auswertungen von geloggten Daten.

Falk

von Blue F. (blueflash)


Lesenswert?

Falk Willberg schrieb:
> Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer
> die 16KB auszulesen.

Kommt drauf an was man damit machen will. Für die Rekonstruktion das 
Bildschirmbildes reicht weniger. Um selbiges zu rekonstruieren muß man 
verschiedene Parameter kennen:

- mit welchem Offset beginnt das aktuelle Memory Window
- welcher Faktor wird verwendet (Timebasetabelle)

Bsp.: der Offset liegt bei 400, mit dem Faktor 5.

Dann müßte die Übertragung beginnend beim 400sten Wert jeden 5. Wert 
übertragen und zwar so viele wie das Grid breit ist (600 char Werte)

D.h. ausgewertet wird der Bereich von 400 - 3400

Ein Sonderfall sind die Ultra Slow Time-Bases, und die interpolierten TB 
da die Daten hier in separaten Speicherbereichen abgelegt sind und auch 
ohne Offset mit Faktor 1 ausgewertet werden.

Gruß Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Stefan:
tut mir Leid, das mit Deiner Namensgebung erschlieszt sich mir
erst jetzt mit Deiner Erklaerung.  Wobei das irgendwie auch
bloed ist, dass da sowohl C Code fuer den Nios Softcore und
VHDL vermischt liegt.  Koennte man (wenn man nicht wuesste
dass Welec das Design nicht hergeben will/kann wegen fremder
IP) auch so intepretieren, dass fpga/welec/improved das
verbesserte Design enthaelt.  Der Pfad sagt ja nicht aus,
ob es sich da um Softcore Code oder VHDL-Design handelt.
"Firmware" erschien mir da logischer, ohne natuerlich wie
Du schon richtig klarstellst zu beachten, dass es ja
parallel eine zweite Entwicklungslinie gibt.

Ich stelle mal die Frage in den Raum was man da tun sollte.
Da die importierte 0.82 Deine (@Stefan) Aenderungen enthaelt
kann fpga/firmware/ jetzt als aktuell angesehen werden.  doc/
und tools/ von fpga/welec/improved/ kann noch uebernommen
werden oder, vllt. besser, die PDFs koennten (wenn nicht schon
getan) im Wiki verlinkt werden.

@Falk:
[PC-Teil]
Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
Conditionals ungefragt neu eingerueckt habe, da sich
die Ebenen fuer mich einfach nicht mehr entschlossen.

Was ich noch einbauen wollte war die -l Loop Funktion,
angeregt durch das Standard-Verhalten der Windows-Versionen
von Kurt, wo automatisch eine neue Datei mit aufsteigender
Nummerierung erzeugt wurde.  Zudem noch eine kurze
deutschsprachige Anleitung.  Dann kann Hayo den Sourcecode
und die Windows-.EXE ja vllt. kuenftig in seinen Releases
direkt mitfuehren.

kst ist btw. sieht ja wirklich schick aus, muss ich auch
mal ausprobieren.  Ich haette jetzt einfach das diesbzgl.
unhandlichere gnuplot hergenommen.

Niklas

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo,

...

> @Falk:
> [PC-Teil]
> Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
> Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
> Conditionals ungefragt neu eingerueckt habe, da sich
> die Ebenen fuer mich einfach nicht mehr entschlossen.

Kein Problem. Schön, daß Du die Fehlerbehandlung eingebaut hast.
Ich sollte vielleicht aufhören, nach dem Motto zu verfahren "wenn es 
kompiliert, gib's frei, wenn es nicht läuft, versuche -Wall" ;-)

Falk,
derzeit Sope-los...

von Blue F. (blueflash)


Lesenswert?

@Niklas

Da die ganze Versionsgeschichte hier im Augenblick etwas unübersichtlich 
ist eine schnelle Frage:

Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten 
gepatchten Stand, korrekt?

D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch 
korrekt?

Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.

Zur Windows .exe - klar, die kann ich mit ins Release-Package tun.

Gruß Hayo

von xCometz (Gast)


Angehängte Dateien:

Lesenswert?

@Sunny
ich hatte auch solches Problem bei Kompilieren unter Windows. Das 
Problem war nur falsche cygwin version. Ganze Quartus zu installieren 
ist ja mühsam nur für richtige cygwin version zum kriegen.

Als Anhang ist abgespeckte cygwin von Quartus II 41sp2 und registry 
patch


Gruß Ben

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

> Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten
> gepatchten Stand, korrekt?

Ja, genau.

Ganz konkret ist's:
  BlueFlash_Build_0_62.zip
+ FW1.2.BF.0.82_beta.zip
+ FW1.2.BF.0.82_beta-dl3daz.diff
  (aus Beitrag "Screendumps" )
- *~ (vi (u.a.) Backup Files), obj/,
  WelecUpdater (ist woanders im SVN), usw.

(GERMSloader.pl ist jedoch drin, kann Hannes entscheiden
 ob er das im SVN verwalten will, woanders hinschieben usw..
 Bzgl. der WelecUpdater.exe:  Die sollte in den Files/Releases
 Bereich, da sie ja aus den Sourcen erzeugt werden kann und
 statisch ist.  Gleiches fuer die Windows Screenshot.exe.
 Oder wir sparen das und wir tun sie allein in die
 Firmware-Releases.)

> D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen,
> auch korrekt?

Ja, genau.

Niklas

von Blue F. (blueflash)


Lesenswert?

Da die Screenshot.exe unter Umständen (so wie jetzt) nur zu dem 
jeweiligen Release passen, ist es eigentlich keine schlechte Idee sie 
mit ins Paket zu tun, dann gibts keinen Frust wegen inkompatibler 
Versionen.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Falk & Niklas

Wenn ich das so richtig mitverfolge, ist ja auch ein reiner 
Datendownload in Arbeit.

Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software 
zurückzugreifen und das Datenformat auf DSO-Seite entsprechend 
anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal 
erfinden müßte. Ich denke da sowohl an Open Source Programme für 
verschiedene andere DSOs als auch evtl. Programme von den 
DSO-Herstellern, sofern das Datenformat bekannt ist.

Wie ist denn da Eure Meinung?

Bzw. @all

Wer kennt denn evtl. entspechende Programme?

Hayo

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

>D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch
>korrekt?
>Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.

...und was ist mit dem XY-Grid - Patch? War nach der 0.82!
Oder hab ich etwa eine Beta verpasst?

Gruß
Jürgen

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Mal eine Frage an die Experten:
Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten, 
kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?

Ich denke, wir sollten die gigantischen Monolithen sinnvoll in möglichst 
kleine Files aufteilen. Ich würde das übernehmen, wenn ich damit nicht 
hintenherum etwas anderes umwerfe...

@Niklas:
was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
Beim kompilieren werden die nicht angefasst...

@Hayo:
Ich halte es für eine gute Idee, das Datenformat für die 
PC-Kommunikation von einem anderen Scope zu kopieren, wenn es dafür 
ordentliche Software gibt, die auch unter Linux läuft.
Ich habe nur keine Idee, welches geeignet sein könnte.

Falk

von Blue F. (blueflash)


Lesenswert?

@Jürgen

der XY-Grid Patch ist in der 0.83, die aber noch nicht released ist, da 
die neu aufgesetzte FFT noch unfertig ist. Mir ging es darum die 
gepatchte 0.82 mit meiner 0.83 abzugleichen bevor ich die jetzt zum 
Wochenende raushaue. Vielleicht sollte ich mit dem Abgleich auch noch 
bis zum Schluß warten falls noch Patches dazukommen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Falk

Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind, 
d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen 
Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es 
ein heilloses durcheinander von Versionen, die nicht zueinander passen.

Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt 
machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt 
ist.

Hayo

von Cra Z. (crazor)


Lesenswert?

Moin moin,

melde mich von der ersten Klausur des Semesters erfolgreich zurück ;)

Bzgl. SVN: Ich hatte hier: 
https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal 
angefangen, die Struktur des Repositories zu dokumentieren. Ist nicht 
ganz aktuell wie ich gerade sehe, aber vll könnt ihr euch auch dran 
halten bzw. eure Zweige dort grob benennen. Die Struktur könnte noch 
optimiert werden, da es ja mittlerweile euren Branch gibt der auf dem 
NIOS basiert und auch noch den Kram von Slog, wobei ich bezweifle, dass 
da mal wieder was passiert... Ach ja, und die Originalsourcen...

Was mir aufgefallen ist ist dass der ein oder andere Commit der letzten 
Tage gut hätte zusammengefasst werden können, statt pro Datei ein 
Changeset zu machen. Man kann also durchaus mehrere Dateien in einem 
Rutsch (und mit einer gemeinsamen Lognachricht) einchecken. Aber ich 
glaube das habt ihr nun auch bemerkt ;)

Was die Sache mit dem src/src/ Ordner angeht: Wenn ich die Logs richtig 
im Kopf habe, sollte das ne "Branch" zum Entwickeln werden. Dazu 
vielleicht noch ein paar Worte:

1) Wenns geht, würde ich persönlich das Branch&merge gebastel bei SVN 
lieber vermeiden. Hab schon diversen Kram mit SVNs versioniert und bin 
auch bei größeren Gruppen nicht in die Verlegenheit gekommen, sowas zu 
machen. Aber wenn's jemanden gibt, der das Merging am Ende voll drauf 
hat, nur zu ;)

2) SVN unterscheidet nicht zwischen Branching, Tagging und Kopieren. 
Alles geschieht mittels svn copy, also sowohl release-tags anlegen als 
auch branching ist letztlich nix anderes als ne Kopie. Wobei 
Serverseitig natürlich nix dupliziert wird, solange es keine Änderungen 
gibt. Das mal im Hinterkopf behalten, wenn gebranched wird. Es empfielt 
sich also, eine Struktur anzulegen, wie man das in vielen öffentlichen 
SVN sieht, also "branches/ tags/ trunk/"-Ordner, wobei Trunk natürlich 
der Hauptentwicklungszweig ist.
Da wir hier mehrere parallele Projekte in einem Repo haben, sollte jedes 
Unterprojekt in seinem Unterprojekt-Ordner sowas anlegen.

3) ... hab ich gerade vergessen. Naja Vortrag beendet ;)

LG

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> @Falk
>
> Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,
> d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen
> Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es
> ein heilloses durcheinander von Versionen, die nicht zueinander passen.
>
> Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt
> machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt
> ist.

Ok, ist das sinnvollste.

Siehe auch Daniels Beitrag.

Falk

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Falk:
> was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
> Beim kompilieren werden die nicht angefasst...

Die stammen offensichtlich aus dem 0.62.  fft/ habe ich glatt
uebersehen und ist dann wohl die alte FFT Implementation aus
der 1.2.  Beides kann dann weg.

> Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,
> kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?

Kann es, ja, in der Regel geht das aber gut wenn nicht gerade genau
dieselbe Stelle im Code von beiden Bearbeitern modifiziert wird.
Wenn die Software das Problem nicht selbst loesen kann (Im Falle
von "Bearbeiter haben an verschiedenen auseinander liegenden Stellen
was geaendert" kann sie das) wird der commit verweigert und man
muss selbst Hand anlegen.  Wie das bei SVN konkret ablaeuft kann ich
Dir jetzt allerdings nicht sagen.

Ich stimme Dir zu dass die Dateien teilweise wirklich gigantische
Ausmasze haben und unuebersichtlich sind.  Vom Standpunkt der
Revisionsverwaltung muss das aber nicht unbedingt zu schweren
Kollisionen fuehren wie gerade gesagt.  Ich wuerde Deinem Vorhaben,
da aufzuraeumen voll zustimmen.  Da gerade Hayo aber schon an
0.83 dran war waere es aber sinnvoll, dass Hayo nen Diff zieht
und wir (oder er) das direkt einspielen und Du erst dann aufteilst,
so dass Hayo da spaeter nicht ein groszes Chaos hat.

@Hayo:
> Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software
> zurückzugreifen und das Datenformat auf DSO-Seite entsprechend
> anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal
> erfinden müßte. Ich denke da sowohl an Open Source Programme für
> verschiedene andere DSOs als auch evtl. Programme von den
> DSO-Herstellern, sofern das Datenformat bekannt ist.

Das sehe ich genau wie Falk und Du auch.  Ich hatte auch schonmal
nach Ausgabeformaten gefragt, leider kam diesbzgl. kein Vorschlag,
ist vllt. auch unter gegangen in der Fuelle von Posts.

Leider kenne ich keine anderen DSOs bzw. Programme dazu.  Jeden
Hinweis und Dokumentation gehe ich da gerne nach.

Leider komme ich im Moment zeitlich noch nicht dazu die von mir
angepeilten Dinge (Auto-Setup/Kalibrierung, -l in Screenshot
Programm, usw.) zu realisieren.  Wir haben aber ohnehin genug
Baustellen.  Wie sieht es btw. da nochmal mit einer immer aktuell
gehaltenen Liste "wer arbeitet gerade woran" aus?  SF Wiki
waere da nun die praedestinierte Stelle.

(btw:  Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
in einer vorhanderen Unterseite eine neue Seite verlinken.
Kann man das der Software irgendwie abgewoehnen?)

Update/Edit: Hab' den Satz in Klammern bzgl. Kollisionen mal
ausgeweitet damit klar wird, dass ich dort den automatisch
loesbaren Fall meinte.

Niklas

von Blue F. (blueflash)


Lesenswert?

@Niklas

Der FFT Ordner stammt von mir. Da hatte ich mir mal einige 
Beispielsourcen reinkopiert und dann den Ordner vergessen zu löschen - 
kann also weg.

Ich hatte mal in der SFN Roadmap einige Entwicklungen eingetragen. 
Aktueller wärs natürlich wenn jeder seine momentanen Sachen selber 
einpflegt.

Hayo

von Cra Z. (crazor)


Lesenswert?

Niklas O. schrieb:
> (btw:  Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
> die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
> in einer vorhanderen Unterseite eine neue Seite verlinken.
> Kann man das der Software irgendwie abgewoehnen?)
Kann man, möchte ich aber nicht. Öfter mal bei letzten Projekt scheinbar 
automatisierten Frontpage-Vandalismus gehabt, deswegen die alte 
Gewohnheit, die Seite auf Read-Only zu sitzen. Wenn du mir dein Handle 
sagst, kannste gern die entsprechenden Bearbeitungsrechte bekommen.

Wär vll ne gute Gelegenheit, erstmal die Developer-Tabelle im Wiki zu 
aktualisieren, damit der Überblick erhalten bleibt ;)

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Hayo:
Roadmap habe ich gefunden :)

@Daniel:
Merke gerade auch, dass ich manche andere Seiten
auch nicht editieren kann (Developers, ...).
Mein Handle entspricht meinem vollen Namen.

Die Rechte beim Trac Wiki hab' ich noch nicht ganz
verstanden.  Kann man es so machen, dass alle
eingetragenen und aktiven Developer/Members
(die ja ohnehin manuell von einem Admin hinzugefuegt
werden muesen und damit "geprueft" sind) entsprechende
Rechte bekommen?  Im Repository konnte ich direkt
ohne weiteres "rumfuschen", btw..

Abgesehen davon, geht das nur mir so oder ist
das Webinterface bei SF irgendwie ziemlich lahm?
(hab' diverse Firefox Plugins (Ad-Blocker, NoScript, ...)
die das bei mir ausbremsen koennten, daher frage ich mal)

Niklas

von Blue F. (blueflash)


Lesenswert?

SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise 
mußte ich pro Seitenaufbau 10s - 20s warten.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise
> mußte ich pro Seitenaufbau 10s - 20s warten.

Ist hier auch so...

Einerseits gab es mehrere Angebote, einen eigenen Server aufzusetzen, 
andererseits gefällt mir, daß es nicht so viele verschiedene Orte gibt, 
an denen das Thema bearbeitet wird.

Noch was: Wie wäre es mit Unterverzeichnissen .../FW1.2.BF.0.82/ 
../FW1.2.BF.0.84/ etc?

Falk

von Cra Z. (crazor)


Lesenswert?

@Niklas: Rechte gesetzt.

@Antwortzeit SF: Das schwankt bei mir stark, ist aber im Mittel gerade 
noch erträglich. Aber der Server bei SF ist unabhängig. Im letzten 
Projekt war plötzlich der Mensch mit dem Server nicht mehr erreichbar, 
nachdem kurz vorher alle Daten weg waren und plötzlich kein Backup 
existierte. Ob er sich geschämt hat?

@Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter 
trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release 
herausgebracht wird, ist der erste Schritt, trunk/* nach 
tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das 
dient ausschließlich der Konservierung von definierten Ständen. Falls 
ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das 
erledigen, ohne dass History verloren geht.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:
...
> @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter
> trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release
> herausgebracht wird, ist der erste Schritt, trunk/* nach
> tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das
> dient ausschließlich der Konservierung von definierten Ständen. Falls
> ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das
> erledigen, ohne dass History verloren geht.

Ich sehe schon, ich werde mich mal näher mit SVN beschäftigen müssen.
Da ich derzeit kein Scope habe und anderes zu tun ist, halte ich mich 
aus der Software ein paar Tage lang heraus.

Falk

von Cra Z. (crazor)


Lesenswert?

http://svnbook.red-bean.com/

Edit: Die Antwortzeit von diesem Forum ist auch nicht kürzer als die bei 
SF.net ;)

von sunny (Gast)


Lesenswert?

@xCometz
danke für deine hilfe. leider hat es mich nicht weiter gebracht.
ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin 
folgenden fehler
# 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I 
./inc -I .
./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 
-D_Debug_
 src/TomCat.cpp -o obj/TomCat.cpp.o
Assembler messages:
 for reading.open
: No such file or directory
make: *** [obj/TomCat.cpp.o] Error 1
das einspielen deiner cygwin version hat da auch nichts daran geändert.
trotzdem danke.

gruß sunny

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

sunny schrieb:
> @xCometz
> danke für deine hilfe. leider hat es mich nicht weiter gebracht.
> ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin
> folgenden fehler
> # 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I
> ./inc -I .
> ./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32
> -D_Debug_
>  src/TomCat.cpp -o obj/TomCat.cpp.o
> Assembler messages:
>  for reading.open
> : No such file or directory

Mhhh, irgendwie hätte ich da mehr als ":" erwartet....

Kannst Du mal
1
nios-elf-gcc -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 -D_Debug_ src/TomCat.cpp -o obj/TomCat.cpp.o

versuchen? Mit "-v" sagst Du dem gcc, daß er mal erzählen soll, was er 
wirklich treibt.

Hier (Linux) sieht das so aus:
1
Reading specs from /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/specs
2
gcc version 2.9-nios-010801-20030923
3
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cpp -lang-c++ -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios) -D__EXCEPTIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp /tmp/ccI2Biu1.ii
4
GNU CPP version 2.9-nios-010801-20030923 (cpplib)
5
 (nios)
6
ignoring nonexistent directory `../inc'
7
ignoring nonexistent directory `../../inc'
8
ignoring nonexistent directory `../../../inc'
9
ignoring nonexistent directory `/opt/cdk4nios/nios-elf/sys-include'
10
ignoring duplicate directory `inc'
11
#include "..." search starts here:
12
#include <...> search starts here:
13
 inc
14
 src
15
 /opt/cdk4nios/include/g++-3
16
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/include
17
 /opt/cdk4nios/nios-elf/include
18
End of search list.
19
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cc1plus /tmp/ccI2Biu1.ii -quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o /tmp/ccIHjI1U.s
20
GNU C++ version 2.9-nios-010801-20030923 (nios-elf) compiled by GNU C version 3.3.1 (Mandrake Linux 8.2 3.3.1-4mdk_slz).
21
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/../../../../nios-elf/bin/as -m32 -o obj/TomCat.cpp.o /tmp/ccIHjI1U.s

Falk
P.S.: Wie wär's mit Linux in einer VirtualBox oder eigenen Partition?

von sunny (Gast)


Lesenswert?

hi falk

der gcc sagt folgendes

Reading specs from 
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-l
ib/nios-elf/2.9-nios-010801-20030718/specs
gcc version 2.9-nios-010801-20030718
 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf 
/2.9-ni
os-010801-20030718/cpp.exe -lang-c++ -v -I ./inc -I ./src -I ./inc -I 
../inc -I
../../inc -I ../../../inc -iprefix 
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/
bin/../lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/ -D__GNUC__=2 
-D__GNUG__=2
-D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios) 
-D__EXCEP
TIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp 
/cygdrive/c/DO
KUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
GNU CPP version 2.9-nios-010801-20030718 (cpplib)
 (nios)
ignoring nonexistent directory `../inc'
ignoring nonexistent directory `../../inc'
ignoring nonexistent directory `../../../inc'
ignoring nonexistent directory 
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/inc
lude/g++-3'
ignoring nonexistent directory 
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nio
s-elf/sys-include'
ignoring nonexistent directory 
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/include/g++-3'
ignoring nonexistent directory 
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/include'
ignoring nonexistent directory 
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/sys-include'
ignoring nonexistent directory 
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/include'
#include "..." search starts here:
#include <...> search starts here:
 inc
 src
 inc
 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/lib/gcc-lib/nios-elf/2.9-ni 
os-0108
01-20030718/include
 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/nios-elf/include
End of search list.
 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf 
/2.9-ni
os-010801-20030718/cc1plus.exe 
/cygdrive/c/DOKUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
 -quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o 
/cygdri
ve/c/DOKUME~1/op/LOKALE~1/Temp/ccaKz1Xj.s
GNU C++ version 2.9-nios-010801-20030718 (nios-elf) compiled by GNU C 
version 2.
9-cygwin-990830.
 /cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf 
/2.9-ni
os-010801-20030718/../../../../nios-elf/bin/as.exe
Assembler messages:
 for reading.open
: No such file or directory

ich glaub aber das führt jetzt hier zu weit. ich dachte es ist nur 
irgend ein kleines problem. wenn es unter windows nicht geht ist es auch 
noch so. ich kann ja immer noch meinen satreciever misbrauchen. auf 
meinem laptop will ich mir kein linux installieren. es reicht mir schon 
wenn ich mich bei meinem reciever mit diesem linuxmist rumärgern muß.
auf jeden fall danke für eure hilfe.

gruß sunny

von xCometz (Gast)


Angehängte Dateien:

Lesenswert?

@Sunny
Wie viele cygwin hast du im deinem PC? Bist du sicher dass du auf die 
richtige cygwin gelaufen hast?
Es sieht wie falsche cygwin version aus wahrscheinlich einen falsche 
path search.

Schau mal den Anhang

Gruß, Ben

von Kurt B. (kurt)


Lesenswert?

Ich habe den Eindruck, das SVN ist schwieriger zu verstehen als die 
Welec Firmware?

@Robert,
danke für das Angebot. Aber die Platine ist schon geätzt und bestückt.
Es wird aber bestimmt einen zweiten Prototypen geben...

Der Vinculum läuft auch schon einigermaßen. Jetzt muss ich mich etwas 
näher mit dem Befehlssatzt beschäftigen. Sobald die Kommunikation läuft, 
werden aus dem Schaltplan die letzten Fehler beseitigt und ich laden ihn 
hier hoch.
Ein erstes kleines Beispieprojekt wird es dann auch geben.

PS:
Später ist auch eine RTC geplant damit die Dateien ein vernünftiges 
Datum und eine Uhrzeit haben.

von sunny (Gast)


Lesenswert?

@xCometz

ich habe jetzt 2 cygwin auf meinem pc. einmal das was bei quartus mit 
dabei war und dann das von dir.
ich hab es jetzt aber hin bekommen. es funktioniert nur wenn ich zuerst 
cygwin starte, dann in der cygwin konsole in mein build verzeichniss 
wechsle und make starte.
danke noch mal

gruß sunny

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Kurze Info für die Screenshot-Spezis.

Im Rahmen einer Fehlersuche habe ich mal schnell eine Colordemo 
gebastelt. hier zu sehen sind alle angezeigten Planes (13 Stück, 
UI-Plane 2 ist schwarz). Die Memory-Planes werden in der Tat nicht 
angezeigt, ebenso wie die Buffer-Planes.

Leider sieht man den Fehler den ich gesucht habe hier nicht. Dafür muß 
man kurz aus dem nächsten Beitrag...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...die TomCat.ram laden. Dann Sieht man den Fehler deutlich. Und zwar 
hat die UI-Plane 1 eine Macke (hatte Guido ja auch schon vermutet). Die 
gesamte Plane ist um 32 Pixel nach rechts verschoben, was dazu führt, 
dass die ersten 32 Pixel nicht gezeichnet werden, aber dafür die letzten 
32 Pixel auf der rechten Seite durchgeschoben werden und um eine Zeile 
nach unten verschoben auf der linken Seite wieder rauskommen.

Daher auch die komischen Linien bei dem ganz linken Funktions-Button.


Hayo

von Blue F. (blueflash)


Lesenswert?

Nachtrag:

Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA 
liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem 
nicht haben??

Hayo

von Cra Z. (crazor)


Lesenswert?

Hayo W. schrieb:
> Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA
> liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem
> nicht haben??

Ich sehe keinen Grund, warum diese Plane-Geschichte in HW realisiert 
sein sollte... Das würde ja bedeuten, dass es sozusagen für jede Plane 
einen Framebuffern gäbe, also in getrennten Speicherbereichen? Ich hätte 
jetzt vermutet dass die in Software zusammengeführt werden, habe aber 
noch nicht in den Source geschaut.

Wo steckt denn überhaupt der Framebuffer? Im SRAM oder im FPGA-Blockram? 
Kann man das evtl. an der Adressaufteilung sehen?

von Blue F. (blueflash)


Lesenswert?

In der Firmware konnte ich den Fehler bislang noch nicht lokalisieren, 
in dem Bereich ist das Coding auch ziemlich unübersichtlich.

Kann gut sein, dass es auch eine reine Softwaresache ist. ich bin noch 
nicht dazu gekommen zu prüfen ob das Problem auch bei der originalen 
FW1.4 auftritt.

Wenn nicht, wäre die Frage geklärt.

Hayo

von Johannes S. (demofreak)


Lesenswert?

Du bist schuld! Bestimmt! :-P

duck

/Hannes

von Guido (Gast)


Lesenswert?

Hallo,

nö, ich glaube nicht, dass das von der Firmware kommt. Hab da ja schon
mal länger rumprobiert inkl. Neuschreiben von DrawRoundButton und
PixelP.

@ Hayo: Wenn es eine Verschiebung wäre, ließe sie sich leicht
korrigieren. Die 8, 16 und 32 Bit, waren es, wenn ich mich recht
entsinne, aber nicht. Mein Verdacht war eher, dass im VHDL-Code
zwei Adressbits für den Framebuffer vertauscht sind. Das war das
letzte womit ich rumprobiert habe, denn auch das müsste man
korrigieren können.

Gru0ß, Guido

von Blue F. (blueflash)


Lesenswert?

Ich hab jetzt erstmal in DrawRoundButton einen Workaround eingebaut, 
damit nicht die falsche Linie gezeichnet wird.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, für alle die um diese Urzeit auch noch vor dem Rechner sitzen ein 
kurzer Zwischenstand in Sachen FFT-Redesign.

Anzubieten hätte ich diese Version...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?

Die Cursorfunktion geht natürlich bei beiden.

Hat jemand Verbesserungsvorschläge oder eine Idee welche Daten z.B. im 
Bereich Magnitude noch von Interesse wären?

Gruß

Hayo

von Johannes S. (demofreak)


Lesenswert?

DIe erste find ich hübscher. Hat es was zu sagen, dass da oben rechts 
Blackman und unten Rechteck steht?

/Hannes

von Blue F. (blueflash)


Lesenswert?

Einige Zeilen sind noch statisch um die Position richtig einzustellen, 
also keine Sorge...

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

mir gefällt die zweite Version deutlich besser, nicht nur weil
sie auch mit übermüdeten Augen noch ablesbar ist ;-), auch das
Grid wirkt harmonischer.

Magnitude in dBm ist zu ehrgeizig, da der Abschluss ja nicht
gewährleistet ist. Besser db mit Bezugspunkt. Wenn aber Mag in
dB oder dBm angegeben ist, sollte Delta-Y nicht in mV sein.

Ich hoffe doch sehr, demnächst auch mal wieder einen Beitrag
leisten zu können, aber es geht wirklich super voran.

Gruß, Guido

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> ...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?
                        ^^^^^^

Diese (#2) erregt ähm, also, genau: mein Wohlwollen ;-)

> Die Cursorfunktion geht natürlich bei beiden.

Applaus!

Falk

von Alexis S. (seraptin)


Lesenswert?

Also ich finde die untere vorallem wegen der Lesbarkeit besser. Koennte 
man denn auch beide kombinieren ?? Also obere Version mit den Farben der 
unteren.

Ich finde das Subtile der schwarzen Version eigentlich auch nicht uebel 
aber das gelb halte ich fuer praktischer. Form follows function... ;)

von Blue F. (blueflash)


Lesenswert?

Die Skalierung ist noch nicht ganz fertig. Das untere Bild zeigt aber 
schon die korrekten Cursorwerte in Volt. Die Anzeige im Abschnitt 
Magnitude ist nur eine statische Zeile für Testzwecke.

So jetzt jetzt haben wir schon zwei Meinungen und natürlich genau 
gegensätzlich.

Meine Meinung dazu ist noch etwas schwankend. Die Anzeige im ersten Bild 
ist etwas technischer gehalten und hat den Vorteil, dass sie in der 
Helligkeit mit dem Grid zusammen verstellt werden kann. Die zweite 
Version ist dafür etwas angenehmer abzulesen, weil die schwarze Schrift 
auf dem hellen Untergrund mehr Kontrast bietet.

Nicht einfach zu entscheiden.

Gruß

Hayo

von Blue F. (blueflash)


Lesenswert?

Oh, in der Zwischenzeit gibt es doch noch mehr Meinungen. Tendenz 
Richtung Version 2 wie ich feststelle.

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

beide Versionen sehen echt gut aus! Top Arbeit.
Die Erste ist etwas unaufdringlicher, die Schrift etwas schwer zu lesen- 
das mag im Original natürlich besser sein. Die zweite Vers. ist dafür 
einheitlicher. Würde eher zur Version 2 tendieren.
Was noch an Info dazu sollte bzw. kann?
Evtl. mal bei den renommierten Herstellern nachsehen, so spontan fällt 
mir nichts ein.

Gruß, brunowe

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ja mir fiel so spontan auch nichts mehr ein. Sonst lasse ich das erst 
mal frei, da kommen bestimmt noch Vorschläge.

Angeregt durch Deine Kommentare und die LeCroy Broschüre habe ich auch 
die FFT-Modi etwas aufgebohrt. Wir wollen ja schließlich nicht hinter 
LeCroy zurückstehen...   ;-)


Hayo

von Alexis S. (seraptin)


Lesenswert?

Sehr schoen, ich warte schon gespannt auf den naechsten Release und 
werde dann gruendlich Testen. Jedenfalls wenn ich bin dahin alle meine 
Pruefungen geschrieben habe. ;)

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

ja Hayo du hast recht, wir sollten uns an der Spitze orientieren.
Wenn das nicht klappt, verfahren wir getreu dem Wahlspruch:

WO WIR SIND IST VORN...
   UND WENN WIR EINMAL HINTEN SIND, DANN IST HINTEN VORN!

Gruß, brunowe

von Michael H. (stronzo83)


Lesenswert?

Das sieht ja wirklich klasse aus!
Aufgrund der besseren Lesbarkeit finde ich die zweite Variante auch noch 
besser als die erste.

Gruß,Michael

von Blue F. (blueflash)


Lesenswert?

Es kommt wie es kommen muß:

Ich habe beide Varianten dringelassen. Default ist die Variante 2. Über 
Shift + X kann die Variante 1 ein und ausgeschaltet werden. So kann sich 
jeder selbst eine Meinung bilden und das dann entsprechend einstellen.

Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier schon mal der vorläufige Schaltplan des Vinculum Boards.

Über eine 3MBaud UART Verbindung zum Vinculum kann man mit ca. 
112kByte/s auf den Stick schreiben. Getestet vom PC aus.
Allerdings soll später der parallele FIFO zum Einsatz kommen.

PS: LED3 und LED4 sind natürlich falschrum drin.

von Martin H. (martinh)


Lesenswert?

Hallo Kurt,

Ich habe mir deinen Schaltplan angeschaut, und habe zwei kleine 
Anmerkungen:

1. Die last C's des 12MHz Quatz sollten 68pF sein (meiner Erfahrung nach 
ist der VNC1L hier recht empfiendlich).

2. Wenn du den FIFO mode nutzen willst ist es von Vorteil auch den PIN 
45 (DATAREQ# in FIFO und SPI mode) von der CPU aus steuern zu koennen.

Martin

von Stefan (Gast)


Lesenswert?

Muss es eigentlich sein, dass der Trigger automatisch auf einen anderen 
Kanal gelegt wird, wenn der momentan den Trigger führende Kanal 
deaktiviert wird ?  Ich finde das mehr als unpraktisch denn:

- es kommt vor, dass man auf einen Kanal triggern, diesen aber zwecks 
Übersichtlichkeit nicht permanent darstellen möchte. Der kleine 
Bildschirm ist schon so voll genug :\

- triggert man auf Kanal 1 mit einer hohen Impulsfolge und womöglich mit 
einem hohen Signalpegel, sieht man von den anderen Kanälen nahezu nichts 
mehr, da das Gelb doch sehr dominant ist. Schaltet man nun Kanal 1 kurz 
aus, um sich einen Eindruck von den anderen Signalen zu verschaffen, ist 
sofort der Trigger flöten und man steht erst mal im Regen; bzw. fummelt 
wieder am Trigger rum bis es passt.

Da die Triggermarke, bedingt durch die farbliche Darstellung am Rand, 
die Triggerquelle auch dann eindeutig anzeigt, wenn der Kanal 
deaktiviert ist, empfinde ich die Zwangsumschaltung als sehr lästig. 
Evtl. geht es ja dem einen oder anderen auch so...

Stefan

von Michael (Gast)


Lesenswert?

Hallo,

echt toll was ihr da Entwickelt.

Was mir noch fehlt ist das Umschalten des Sampleverhalten.

D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann 
gleich auf die benötigte Samplerate heruntergerechnet.

Professionelle Oszis können da:

Peak (min und max der ADs wärend eines Erfassungstaktes)
HiRes (Mittelwert der ADs wärend eines Erfassungstaktes)
Sample (Nur 1. Wert der ADs wärend eines Erfassungstaktes) so ist es 
jetzt immer
Average (HiRes und Mittelwert über mehrere Triger)

Mfg Michael

von Kurt B. (kurt)


Lesenswert?

Hallo Martin,
die Kondensatorgeschichte scheint sehr abhängig vom Quarz zu sein. Bei 
mir läuft es mit 10pF ohne Probleme.
Ich werde trotzdem im Schaltplan den Wert auf 22pF oder 47pF erhöhen.

Wofür brauche ich denn den DATAREQ# Pin? Ich dachte mit dem schaltet man 
nur zwischen Data und Command Mode um.

Kann aber auch angeschlossen werden. Der AVR hat noch genug Pins.

Mfg,
Kurt

von Martin H. (martinh)


Lesenswert?

Kurt,

Der Kondensator haengt sowohl von dem Quarz als auch von dem Treiber / 
Eingang des IC's ab. Ich habe mit dem VNC1L boese Erfahrung gemacht, der 
Prototyp lief mit einem zu kleine C ohne Probleme, aber in der Serie 
hatte ich dann einige Baugruppen wo der Oszillator nicht immer an lief.

Was DATAREQ# betrifft hast du recht wenn du nur den Pendrive verwenden 
willst ist er nicht noetig (wird fuer di Umschaltung von Kommandomodus 
in einen reinen Datenmodus verwendet, zum Beispiel fuer die Verbindung 
zu einem PC).

Martin

von Blue F. (blueflash)


Lesenswert?

Michael schrieb:

> D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann
> gleich auf die benötigte Samplerate heruntergerechnet.

Nein. es wird nicht immer mit der vollen Samplerate gemessen, sondern 
mit der angezeigten. Das weitere Herunterrechnen findet dann in der 
Firmware statt.

Hayo

von Andreas (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe die aktuelle Firmware und das Problem, dass sich -je nach 
Messbereich- der negative Bereich der gemessenen Spannung verschiebt.

Mache ich da etwas falsch oder kann ich dem Scope nicht mehr trauen ?
Anbei zwei Bilder, es geht mir um Kanal 4 (Rot, Kanal steht auf DC)

von Andreas (Gast)


Angehängte Dateien:

Lesenswert?

hier das Zweite.

von Stefan E. (stefan_e)


Lesenswert?

DAC-Abgleich für alle Spannungsstufen (1V, 2V, 5V) einzeln durchgeführt?

von Andreas (Gast)


Lesenswert?

Ist nicht Dein Ernst !?
Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem 
Schwung. Aber Danke, das erklärt so manches.

von Stefan (Gast)


Lesenswert?

Besteht evtl. die Möglichkeit, dass QuickMeassure im nächsten Update 
gefixed wird? Die Wahl des QM-Kanals via Menü wird leider erst 
übernommen, nachdem QM aus- und wieder eingeschaltet wurde.

Btw: QM läuft ganz prima - vielen Dank !

von Gast (Gast)


Lesenswert?

Hallo,

als frisch gebackener W2024A-Besitzer habe ich heute eure Firmware 
0.82beta getestet und gleich eine Frage dazu. Ich habe den Abgleich von 
ADC bzw. DAC nach Anleitung gemacht, komme aber was den Abgleich der 
Nullinien angeht nicht zum gewünschten Ergebnis. Ich kann zwar den DAC 
z.B. für 5V, 2V und 1V kalibrieren, wenn ich dann aber den 500mV Bereich 
kalibriere verschiebt es den 5V Bereich wieder, bei 200mV den 2V u.s.w.

Was mache ich falsch?

von Stefan E. (stefan_e)


Lesenswert?

>Die Wahl des QM-Kanals via Menü wird leider erst
>übernommen, nachdem QM aus- und wieder eingeschaltet wurde.

Kann ich so leider nicht nachvollziehen. Bei mir klappt das alles 
einwandfrei. Mit Ausnahme der weiter oben genannten funktionen.
Kannst du genauer beschreiben, was du nacheinander drückst und welche 
Einstellungen du verwendest?

>Btw: QM läuft ganz prima - vielen Dank !

Danke für das Lob!

Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen, 
werde ich versuchen den noch zu beheben. Ansonsten wird es 
voraussichtlich erst wieder Mitte August Neuerungen von meiner Seite 
geben.

Bis dahin wollen noch eine Reihe Klausuren bestanden werden und der 
Computer braucht dann so Anfang August mal zwei Wochen Ruhe ;-)

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

Andreas schrieb:
> Ist nicht Dein Ernst !?
> Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem
> Schwung. Aber Danke, das erklärt so manches.

Im Paket der Beta FW ist eine Beschreibung wie man den Abgleich in der 
richtigen Reihenfolge macht.

Die DAC-Kalibrierung läuft getrennt für die 1er 2er und 5er Bereiche. 
Hintergrund ist:

1. Ich wollte anfangs eine Möglichkeit haben das getrennt voneinander 
durchzuführen um nicht schon gut kalibrierte Bereiche wieder zu 
verschlechtern.

2. Die DAC-Kalibrierung ist als Ergänzung zu der ungenügenden original 
Kalibrierung zu sehen.

2. Jetzt funktioniert das eigentlich so gut, dass man auch alle in einem 
Durchgang kalibrieren könnte, hatte aber noch keine Zeit das zu 
implementieren. Wurde auch schon von anderer Seite angefragt. Werde ich 
mal mit den Prioritäten der anderen Baustellen abgleichen.

Für alle neu Dazugestoßenen - die original FW war leider so schlecht 
geschrieben, dass es bei den anfänglich geringen Entwicklerkapazitäten 
nur langsam voran ging. Ich bitte daher noch nicht so perfekt 
funktionierende Bereiche zu entschuldigen. Dafür geht es jetzt bei der 
starken Beteiligung hier erheblich zügiger voran.

Hayo

von Gast (Gast)


Lesenswert?

Hallo Hayo,

kannst du dir erklären, warum bei mir die bereits kalibrierten Kanäle 
wieder verschoben werden, wenn ich andere kalibriere? Bin genau nach 
Anleitung vorgegangen, bekomme aber Nullinien die bis zu mehreren DIVs 
abweichen...

von Alexis S. (seraptin)


Lesenswert?

Du brauchst dich doch nicht zu entschuldigen :) Ich habe mir ueberhaupt 
erst ein solches Scope gekauft als ich gesehen habe was ihr hier 
veranstaltet. So einen Aufwand kann bei gott keiner erwarten und ich 
moechte mich nochmal in aller Form bei euch fuer das bis jetzt 
geleistete bedanken.

Ich werde nach den Pruefungen auch sehen wie ich zu dem Projekt 
Beitragen kann. Leider hab ich noch 0 erfahrung mit Oszi-Programmierung, 
aber vielleicht kann man ja etwas Learning by Doing betreiben :) Ich 
schaue jedenfalls jeden Tag hier rein und fast immer wurde irgendwas 
verbessert. Wirklich super !!!

von Blue F. (blueflash)


Lesenswert?

Ohh! Nein das höre ich zum ersten Mal. Bei meinen Geräten klappt das 
einwandfrei und auch die Anderen hier hatten das Problem nicht.

Du sagst ja, Du hast das nach Anleitung gemacht und vorher alle Eingänge 
abgezogen oder kurzgeschlossen? Wenn nicht bekommt man nämlich genau 
diesen Fehler. Am besten macht man erstmal den ADC-Abgleich, da der nur 
einen relativen Vergleich der Pegel durchführt. Dann den originalen 
Search Zeros und zum Schluß als Feinschliff den DAC-Abgleich.

Ach ja, ganz zu Anfang am Besten noch Default Setup, dann ist man auch 
gleich in der günstigsten Timebase für den Abgleich.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Alexis

Das hört man gern.

Hayo

von Andreas (Gast)


Lesenswert?

>Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben.

Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal 
wählen, den QM auswertet. Wählt man hier während der Messung einen 
anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und 
wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert 
und dann wieder aktiviert.

von Odic X. (odic)


Lesenswert?

Mist, ich hasse solche Sonderrollen....

Also,

- FW 0.82beta (compiliertes HEX-File aus dem Release-Archiv) liegt im 
Flash
- Gerät ist warmgelaufen
- alle Probes sind abgezogen

Vorgehen:

- "Default Settings" im "Edge" Menü
=> alle Kanäle sind an und im 5V-Bereich

- einmal "Calibrate ADC"
- einmal "Search Zero Lines"
=> Abweichungen von max. 0,2DIV in den 5V-Bereichen

- "Calibrate DAC"
=> alles bestens im 5V Bereich

- alle Kanäle auf 2V
- "Calibrate DAC"
=> alles bestens im 2V Bereich

- alle Kanäle auf 1V
- "Calibrate DAC"
=> alles bestens im 1V Bereich

- Kontrolle
=> alles bestens in den Bereichen 1V, 2V und 5V

- selbes Vorgehen für 500mV, 200mV und 100mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis 
ca. 1 DIV verschoben

- selbes Vorgehen für 50mV, 20mV und 10mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis > 
8 DIV verschoben

Insgesamt sind die Verschiebungen auf Kanal 1+3 nur gering, auf Kanal 2 
ausgeprägt und Kanal 4 ist nicht benutzbar (Abweichung > 6 DIV).

Habe ich ein Montagsgerät erwischt??

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan schrieb:
> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
> Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und
> oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da
> würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...

Ich hab' mir mal Gedanken gemacht: 
https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14

Falk, derzeit scopelos

von Bernhard M. (boregard)


Lesenswert?


von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Bernhard M. schrieb:
> über:
>
> http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14
>
> gehts ohne user / passwort...

Wahrscheinlich nicht. Tip: Freemail-Account für solche Fälle besorgen 
und anmelden.

Falk

von Stefan E. (stefan_e)


Lesenswert?

>Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal
>wählen, den QM auswertet. Wählt man hier während der Messung einen
>anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und
>wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert
>und dann wieder aktiviert.

Na ja. Du kannst ja unterschiedliche Kanäle gleichzeitig messen und 
willst nicht für alle Messungen gleichzeitig den Kanal ändern. Ich 
glaube,das was du meinst ist, dass du einen der drei Mess-Slots 
auswählen und diesen dann geziehlt bearbeiten (Messfunktion, Kanal) oder 
gezielt löschen willst.
Das wäre auch mein Wunsch an die GUI. Bis jetzt kann man nur alle drei 
Slots gleichzeitig löschen. Um einen Kanal zu ändern kommt man nicht 
drum rum alle zu löschen.

von Guido (Gast)


Lesenswert?

@ Odic X,

willkommen im Club ;-)

Ich mache den DAC-Abgleich nur für 5-, 2- und 1-V-Bereich, für
die kleineren stimmt er dann automatisch. Durch die höheren
Störpegel in den empfindlicheren Bereichen kann der Abgleich
wohl schon ins Schleudern kommen.

Also: erst Search-Zero (ev. mehrmals), dann ADC-Abgleich und
dann dreimal DAC-Abgleich.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Odic

Ahh, verstehe, Du wiederholst die Kalibrierung zig mal bis in alle 
Unterdivisions. Das ist so nicht gedacht. Es gibt jeweils einen 
Korrekturfaktor für alle 5er Bereiche,  einen für alle 2er Bereiche und 
einen für alle 1er Bereiche (also nur drei Korrekturfaktoren). Du mußt 
also nur einmal für 5V, 2V und 1V kalibrieren, dann sollte es stimmen, 
auch in den kleineren Spannungsbereichen.

Hayo

von Odic X. (odic)


Lesenswert?

Funktioniert leider bei mir nicht. Wenn ich z.B. Kanal 4 im 5V-Bereich 
perfekt abgeglichen habe, liegt die Nullinie im 500mV-Bereich 0,5 DIV 
höher und im 50mV-Bereich 4 DIV höher.

Das ist so leider nicht zu gebrauchen....

von Odic X. (odic)


Lesenswert?

So, ich habe das Ganze nochmal lediglich in den 1-5V Bereichen 
durchgespielt. Bei den Kanälen 1 und 3 klappt es. Bei Kanal 2 kann man 
mit der sich ergebenden Abweichung von 0,3 DIV notfalls leben. Nur bei 
Kanal 4 funktioniert das Ganze leider überhaupt nicht:

5V: abgeglichen
500mV: +0,2 DIV
50mV: +1,8 DIV

2V: abgeglichen
200mV: +0,5 DIV
20mV: +4,6 DIV

1V: abgeglichen
100mV: +0,9 DIV
10mV: >+8 DIV

Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden 
Bereich einzeln ermitteln zu können?

von Blue F. (blueflash)


Lesenswert?

@Odic

Hmmm, da läuft aber bei Deinem Gerät was mächtig schief. Leider kann ich 
mir da so auf Anhieb auch keinen Reim drauf machen.


> Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden
> Bereich einzeln ermitteln zu können?

Erstens wäre es schon einiger Aufwand und außerdem ist es technisch auch 
eigentlich nicht nötig, da die jeweiligen Analogbereiche der Hardware 
immer für alle 5er  2er  1er Bereiche ausgelegt sind. Daher auch nur 
drei Korrekturfaktoren.

Meine Idee wäre zuerst mal einen Flashdump einzuspielen um sicherzugehen 
dass da nichts schief hängt.

Hayo

von Alexis S. (seraptin)


Lesenswert?

Also ich hab jetzt auch etwas getestet.

Gestern hat der abgleich auf allen Kanaelen noch wunderbar geklappt... 
als ich dann heute das Scope angeworfen habe war alles wieder voellig 
durcheinander, d.h. die Nulllinien wieder irgendwo. Als ich kann den 
Abgleich auf allen Kanaelen gleichzeitig durchgefuehrt habe (also 1-4 AN 
und dann die ganze Prozedur), trat genau das Problem das du beschrieben 
hast auf.

Jetzt habe ich mich dann nochmal Hayo's Hinweis, das man alle Kanaele 
auch einzeln abgleichen kann, erinnert und das durchgefuehrt. Also nur 
Kanal 1 an und dann 1V-5V abgeglichen. Dann das selbe nur mit Kanal 2 
an, alle andren aus usw. Nun habe ich in allen Bereichen schoene 
Nullinien und das Scope merkt sich die auch beim Neustart.


Woran das genau liegt kann ich mir so aber nicht erklaeren. Gestern 
dachte ich das das auf allen Kanaelen sauber funktioniert hat... war 
aber auch schon spaet.

von Alexis S. (seraptin)


Lesenswert?

Nach weiteren Tests habe ich jetzt bemekrt das das Scope sich die 
Offsets wohl nicht merkt. Nachdem das Scope jetzt laenger aus war und 
ich es angeschalten habe war erstmal alles durcheinander, nix hat 
gepasst. Nach ausfuehren von Default Setup:

5V Bereich: Alles in Ordnung, auch nach Neustart

2V Bereich: Abweichung um ca. 0.3Div nach Neustart

1V Bereich: Abweichung um ca. 0.3Div nach Neustart


Auffallend ist das die Offsets sich alle nach unten verschoben haben.

von Guido (Gast)


Lesenswert?

@Alexis Sch. (seraptin):

Nicht vergessen, wenn alles passt die Zeitbasis verstellen.
Erst dann werden die Korrekturwerte im Flash gespeichert.

von Odic X. (odic)


Lesenswert?

@Alexis

Durch Temperaturunterschiede (kaltes / warm gelaufenes Gerät) habe ich 
auf allen Kanälen auch Schwankungen der Nullinie von -0,2 bis -0,5 DIV. 
Das ist zwar lästig, aber erklärbar.

@Hayo

Ich versuche es mal mit dem Dump. Die FW hatte ich bereits nochmal neu 
eingespielt da ich vermutet habe, dass dabei etwas schief gegangen ist. 
Leider ohne Erfolg.

von Odic X. (odic)


Lesenswert?

Ok, nächstes Problem. :-(

Das Zurückspielen des Dumps bricht reproduzierbar an folgender Stelle 
ab.

Writing line 044014 of 071372: ............ 422 sec / 262 sec left
Error: Timeout while reading response from DSO!
Response was: 'S3150005247FFF<#33><#13>

Kann sich jemand einen Reim darauf machen??

von Johannes S. (demofreak)


Angehängte Dateien:

Lesenswert?

Odic X. schrieb:
> Writing line 044014 of 071372: ............ 422 sec / 262 sec left
> Error: Timeout while reading response from DSO!
> Response was: 'S3150005247FFF<#33><#13>

Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo 
beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der 
GERMSloader ab. Der Script (s.Anhang) ist bereits geändert, um das 
schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket 
integriert.

/Hannes

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Johannes Studt schrieb:
> Odic X. schrieb:
>> Writing line 044014 of 071372: ............ 422 sec / 262 sec left
>> Error: Timeout while reading response from DSO!
>> Response was: 'S3150005247FFF<#33><#13>
>
> Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo
> beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der
> GERMSloader ab.

Wenn ich mich recht erinnere, bedeutet "!", daß ein Fehler (beim 
Schreiben) aufgetreten ist. Das kann daher kommen, daß der zu 
schreibende Bereich nicht gelöscht wurde...

> Der Script (s.Anhang) ist bereits geändert, um das
> schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket
> integriert.

Ich würde den Fehler nicht ignorieren...

Falk

von Johannes S. (demofreak)


Lesenswert?

Ja, "ignorieren" ist falsch ausgedrückt. Es bricht nicht sofort ab (wie 
es dummerweise bisher war), sondern versucht bis zu 10mal die gleiche 
Zeile erneut zu schreiben. Erst dann wird mit einem Fehler wirklich 
abgebrochen. Man muss dann halt untersuchen, was der Grund für das "!" 
ist.

Und stimmt, weiter oben war der Grund für das "!" wohl eine etwas 
instabile serielle Verbindung, was hier offenbar anders ist, wenn der 
Fehler immer an derselben Stelle auftritt. Da wird also der geänderte 
Skript auch nicht helfen.

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Odic

Es ist nicht die Firmware, sondern der Configbereich der hin und wieder 
beim Rumexperimentieren mit unterschiedlichen FW-Versionen einen 
abkriegt.

Übrigens braucht man eigentlich nicht die Kanäle einzeln abzugleichen, 
das kann er auch gleichzeitig.

Hayo

von Blue F. (blueflash)


Lesenswert?

Hi,

gerade wollte ich die neue 0.84 Firmware mit dem neuen Screenshot 
ausrüsten,
aber bei SFN ist kein Durchkommen. Weder komme ich an die Sourcen heran, 
noch an die Screenshot.exe.

Daher werde ich gleich die 0.83 mit der alten Screenshot-Funktion 
rausgeben.

Hayo

von Blue F. (blueflash)


Lesenswert?

New beta release 0.83 out now!

Please pay attention to the release notes! You will find it here:

https://sourceforge.net/projects/welecw2000a/files/

Es sind zahlreiche Bugfixes und Neuerungen eingeflossen. Leider konnte 
ich die neue Version der Screenshot-Funktion nicht mit einbauen. Das 
wird dann in der nächsten kommen. Die passenden PC-Programme zur alten 
Version sind mit im Paket.

Die Statusanzeigevariante (gelbe Buttons oder "black edition") im 
FFT-Modus kann über ein Terminal mit shift + V umgeschaltet werden und 
bleibt dann auch nach dem Aus- und wieder Einschalten so eingestellt!

Die FFT-Sektion ist noch in Arbeit und an einigen Stellen nicht ganz 
fertig. Die Skalierung ist nur für die linearen Bereich korrekt und bei 
den logarithmischen FFT stimmt nur der 5V Bereich.

Da es mich bei der Cursorfunktion etwas störte, das die Deltaanzeige die 
kleineren Werte verdeckte, habe ich der Cursorfunktion eine zwei 
Stufenlogik verpasst (auch im Normalbetrieb).

- Einmal den Cursurknopf drücken -> Anzeige ohne Delta
- nochmal den Cursorknopf drücken -> Anzeige mit Delta
- nochmal drücken -> Cursor aus

Kritik und Anregungen sind wie immer ausdrücklich erwünscht.

Viel Spass

Hayo

von Cra Z. (crazor)


Lesenswert?

Habe auch schnell einen Test mit der Abgleichfunktion gemacht. Habe dazu 
alle vier Kanäle eingeschaltet gelassen, Default Setup aufgerufen, dann 
ADC, Zero Lines und DAC ausgeführt auf 5V, dann nochmal DAC auf 2V und 
auf 1V. Danach war bei mir über alle Spannungsbereiche alles im Lot. Das 
einzige, das mir aufgefallen ist, ist, dass die Nullliniensuche erstmal 
zig DIV's danebengehauen hat, was nach dem DAC Abgleich dann aber i.O. 
war.
Also bei mir gabs kein Problem mit dem gleichzeitigen Abgleich aller 
Kanäle.


Den neuen GERMSloader werde ich morgen testen, wenn ich dann die 0.83 
flashe. Aber ich befürchte fast, dass ein Retry nach einem ! nichts 
bringt. Außerdem denke ich, dass das ! nix mit der wackeligen seriellen 
Schnittstelle zutun hat. Wenn ein Zeichen fehlte oder zuviel war, 
scheiterte die Übertragung ja auf andere Weise, was dann dank der 
Retries ziemlich schnell vom Tisch war.

Gibt's eigentlich Sourcen vom GERMSloader irgendwo? Ich meinte mal 
gelesen zu haben, dass jemand den verändert hätte für eine neue 
Plattform. Eventuell lassen sich in den Sourcen ja Infos finden, was die 
Rückgabe des ! zu bedeuten hat? In diverser Doku von Altera bin ich 
jedenfalls nicht fündig geworden.

von Odic X. (odic)


Lesenswert?

@Hannes:
Besten Dank für das Skript, damit funktioniert es

@Hayo
Das Einspielen des Dumps hat keine Veränderung gebracht. Das Verhalten 
tritt auch mit der Orginal-FW auf. Damit würde ich ein SW-Problem 
eigentlich ausschließen.
Ach ja, ich mache den Abgleich für alle Kanäle gleichzeitig. Da habe ich 
mich vielleicht unklar ausgedrückt...


Hat irgendwer eine Idee, wie die HW diesen Effekt verursachen könnte?

von Blue F. (blueflash)


Lesenswert?

@Odic

Wenn sich die Nulllinien weder mit der beta FW noch mit der originalen 
FW einigermaßen einstellen lassen, ist das meines Erachtens ein 
Garantiefall. Schließlich ist die (zugesicherte) Funktion nicht 
vorhanden.

Hayo

von Cra Z. (crazor)


Lesenswert?

Daniel H. schrieb:
> Bzgl. SVN: Ich hatte hier:
> https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal
> angefangen, die Struktur des Repositories zu dokumentieren.

Ich dachte eigentlich, dass auf der Seite oben direkt ersichtlich wird, 
dass die verschiedenen Entwicklungszweige auf FPGA-Seite nach 
verwendetem Softprozessor geordnet sind... Mehrdeutigkeiten wie eure 
jetzige Location "/fpga/firmware/" wollte ich eigentlich vermeiden. Mal 
davon abgesehen, dass es sowas wie "Firmware" eh' nicht gibt (Entweder 
hard oder soft), wäre vermutlich alles andere im Repository im 
fpga-Ordner nach eurer Definition auch Firmware ;) Also, warum packt ihr 
eure Sourcen nicht lieber nach "/fpga/nios/*"? z.B. im NIOS-Ordner noch 
einen Unterordner "Blueflash" oder so anlegen? Dann könnte noch der 
offizielle Welec-Kram auch dort reingeschoben werden und alles ist 
wieder übersichtlich (ok, vielleicht nicht übersichtlich, aber dennoch 
nach einer Regel abgelegt. Deswegen ja die Wiki-Seite.)

von Blue F. (blueflash)


Lesenswert?

@Daniel

Du hast Recht, die von Dir vorgeschlagene Struktur ist logisch gesehen 
korrekt. Allerdings würde ich vorschlagen möglichst nicht so tiefe 
ordnerstrukturen anzulegen, denn ich finde die Navigation doch recht 
mühsam, da man bei Zurücknavigation immer zum Rootverzeichnis 
zurückspringt und sich dann wieder neu durchkämpfen muß.

Übrigens habe ich meine Probleme beim Zugriff auf SFN zu einem großen 
Teil auf den Browser zurückführen können. Mit Opera und Firefox komme 
ich an einige Stellen im Repository nicht heran. Nur mit dem IE klappt 
es dann. Den benutze ich aber eigentlich lieber nicht.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich bräuchte noch etwas Unterstützung.

Für die neue Screenshotversion fehlt mir noch die aktuelle Windows-.exe

Wo kann ich die finden, bzw. kann die jemand hier einfach mal posten?

Dann kann ich nähmlich kurzfristig noch eine aktualisierte Fassung 
rausbringen.

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

wie ich gerade feststelle kompiliert das ganze wegen der
Aenderungen von Falk nicht mehr unter Windows.  Zudem
muss noch eine generalisierte Write-Funktion her.

Ich versuche das gerade umzustricken, mehr in ein paar Minuten.
Bin allerdings nicht zu Hause, habe daher keine DSO da und
kann es nicht testen.

Niklas

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo nochmal,

okay, sollte laufen.  Win32 .EXE im Anhang.  Bitte sowohl unter
unixoid als Windows testen.  Aenderungen siehe SVN Log.

(und wenn Du die Sourcen dabei packen solltest nicht vergessen
die aktuellen aus dem SVN zu nehmen ;)

Niklas

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo Hayo,
>
> wie ich gerade feststelle kompiliert das ganze wegen der
> Aenderungen von Falk nicht mehr unter Windows.  Zudem
> muss noch eine generalisierte Write-Funktion her.

Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht 
man dazu?

Falk

von Niklas O. (nevm)


Lesenswert?

Hallo Falk,

> Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht
> man dazu?

ich nehme MinGW ( http://www.mingw.org/ ) dafuer.  Damit kann man
auch fuer Win32 crosscompilen.

Niklas

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

sorry, eine Sache vergessen.  Bei -c (Angabe Com-Port) musste
das Argument bei 0 starten (0 fuer COM1), entgegen der
dokumentierten und vorherigen Praxis.  Anbei korrigierte Fassung.

Niklas

von Blue F. (blueflash)


Lesenswert?

Alles klar, danke für die schnelle Reaktion.

Noch zwei Fragen (hatte nur kurz aufs Coding geschaut):

1. Werden bei der V 0.4 noch die nicht benötigten Memoryplanes 
übertragen, oder ist das schon optimiert? Ich habe nämlich im Coding 
gesehen, dass diese noch mit definiert werden.

2. Ist die Triggerung des Screenshots über das PC-Programm optional oder 
wird der ScrShot immer getriggert wenn das Programm aufgerufen wird?

Hayo

von Blue F. (blueflash)


Lesenswert?

Ah, zu 2. hab ich gerade gesehen dass mit der Option  -l wie gehabt 
gewartet wird.


Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

zu (1):  Die Memory-Planes werden noch uebertragen.  Auch andere
unbenutze Planes (abgeschaltete Channels, abgeschaltete Cursor)
werden noch weiter uebertragen.

Das ist alles noch nicht implementiert.

zu (2):  -l ist allerdings noch nicht implementiert.  Es wird
jetzt vom Programm aus immer getriggert (Falk moege mich korrigieren
wenn das nicht stimmt).  -l noch einzuauen waere aber nicht
schwierig.

Niklas

von Blue F. (blueflash)


Lesenswert?

denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter 
Linux nicht zum Laufen.

Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen -> 
hier kann noch optimiert werden!

Hayo

von Blue F. (blueflash)


Lesenswert?

@Niklas

wir haben uns hier gerade überschnitten. Ich hab noch mal schnell 
ausprobiert, man könnte zumindest für die neue Beta schon mal die drei 
Memory planes rausnehmen und die -l Option einbauen.

Ich bin gerade dabei für das QP-Menü eine zweistufige Logic einzubauen

Einmal drücken -> QP Menü
Zweimal kurz hintereinander drücken -> direkter Screenshot

Daher ist das Triggern über PC-Programm nicht unbedingt nötig. Praktisch 
wäre z.B.

- default ist warten
- optional ist externes Triggern des ScrShot

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

> denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter
> Linux nicht zum Laufen.

Unter Linux sollte das nun ungefaehr so ablaufen:
1
$ ./w2000a-screenshot -c /dev/ttyUSB0 -b

Triggert einen Farb-Screenshot auf dem ersten USB<->RS232 Adapter
und schreibt ihn als Bitmap raus.  (-c hat Falk fuer non-Windows
implementiert.  Unter Windows ist das -c 1 fuer COM1 wie gehabt.)

Dank Falks Optimierung dauert das ganze bei mir jetzt nur noch
iirc 37 Sekunden statt knapp unter einer Minute.

Die nicht-existente Option -l wuerde dann halt warten bis das
Scope etwas sendet (Screenshot oder Messdaten), im Falle von
Screenshot das ganze in eine Datei mit aufsteigendem Zahl als
Suffix schreiben und weiterlaufen.  Also so wie das einst bei Kurts
Windows-Port war.

> Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen ->
> hier kann noch optimiert werden!

Ja, das wissen wir :)  Die Entwicklung hat ja nur gestoppt weil Falks
Scope zur Reperatur ist und ich im Moment nicht so viel Zeit habe.

Wenn Du warten moechtest bis zu Deinem naechsten Release kann ich
versuchen das heute Abend und/oder morgen noch einbauen.

> wir haben uns hier gerade überschnitten. Ich hab noch mal schnell
> ausprobiert, man könnte zumindest für die neue Beta schon mal die drei
> Memory planes rausnehmen und die -l Option einbauen.

Ja das waere die einfachste Variante.

> Einmal drücken -> QP Menü
> Zweimal kurz hintereinander drücken -> direkter Screenshot

Das klingt gut.

> - default ist warten
> - optional ist externes Triggern des ScrShot

Ja, das waere auch das alte Verhalten.  -l wuerde dann zudem das
Programm am Laufen halten um so ohne Neustart mehrere Dinge
empfangen zu koennen.

Ist jetzt die Frage wie lange Du warten moechtest bis zum naechsten
Release?

Niklas

von Blue F. (blueflash)


Lesenswert?

Meine Bastelecke (FFT) bleibt erstmal unverändert. Ich wollte eigentlich 
nur die Screenshotfunktion nachreichen, damit wir einen kurzen Break 
machen können um auf einer gemeinsamen Sourcebasis die nächsten Schritte 
abstimmen zu können:

- weitere Aufteilung der Sourcefiles -> hatte Falk angestossen
- ordnen der SFN-struktur
- kurze Abstimmung wer macht wo weiter

Morgen habe ich ziemlich wenig Zeit, daher wäre es vielleicht am Besten 
den Stand so rauszugeben wie wir Ihn heute fertiggestellt bekommen.

Würdest Du die Änderungen denn heute Abend schaffen? Dann würde ich so 
lange warten.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
...

>> Einmal drücken -> QP Menü
>> Zweimal kurz hintereinander drücken -> direkter Screenshot
>
> Das klingt gut.
>
>> - default ist warten
>> - optional ist externes Triggern des ScrShot
>
> Ja, das waere auch das alte Verhalten.  -l wuerde dann zudem das
> Programm am Laufen halten um so ohne Neustart mehrere Dinge
> empfangen zu koennen.

Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV) 
wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den 
download?

Falk
P.S.: Ich hatte man eine Fernsteuerung mit QT angefangen. Damit kann man 
Knöppe drücken, sich die Ausgabe ansehen, Parameter einstellen etc. Das 
werde ich mal an die neue Firmware anpassen und mit SVN bei SFN 
einwerfen.
P.P.S.: Das scope ist Samstag bei Wittig angekommen. Ich bin mal 
gespannt, wie lange der Tausch dauert...

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Hayo:
> Würdest Du die Änderungen denn heute Abend schaffen?
Ich versuche es.

@Falk:
> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)
> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den
> download?

Mhm, verstehe ich gerade nicht ganz.  Soll das Programm eine gewisse
Zeit warten ob vom Scope etwas kommt und dann, falls nicht, den Vorgang
selbst anstoszen?

Faende ich dann ueberfluessig, m.E. will man etwas sofort abspeichern
oder man moechte alles bereit haben und dann auf Knopfdruck ein
oder mehrere (-l) Screenshots ziehen, wobei es egal ist ob der Mensch
am DSO sich da ne Minute oder mehrere Stunden Zeit laesst.

Niklas

von Blue F. (blueflash)


Lesenswert?

> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)
> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den
> download?

Das ist gut. Optional dann noch der Parameter -b für .bmp

Hayo

von Blue F. (blueflash)


Lesenswert?

Mal wieder überschnitten...

Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h. 
ohne Angabe läuft das Programm in einer Schleife. Nur wenn die 
zusätzlichen Parameter für das Format angegeben werden wird extern der 
Screenshot getriggert.

Hab ich das so richtig interpretiert?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Mal wieder überschnitten...
>
> Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h.
> ohne Angabe läuft das Programm in einer Schleife. Nur wenn die
> zusätzlichen Parameter für das Format angegeben werden wird extern der
> Screenshot getriggert.
>
> Hab ich das so richtig interpretiert?

So meinte ich das.

Falk

von Jürgen (Gast)


Lesenswert?

Hallo Hayo,

warum nicht, wie schon mal vorgesehen war, ein separates 3-er QP-Menü 
mit 3 Tasten ( Color,BW,CSV ) vom Oszi aus? Wenn die PC-SW unterscheiden 
kann was kommt... (Hab noch nicht getestet.) Fernbedienung vom PC ist da 
für mich zweitrangig.

Jürgen

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

@Niklas

Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die 
Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei 
geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon. 
Vielleicht kannst Du das ja mit einfließen lassen?

Hayo

von Blue F. (blueflash)


Lesenswert?

Jürgen schrieb:
> Hallo Hayo,
>
> warum nicht, wie schon mal vorgesehen war, ein separates 3-er QP-Menü
> mit 3 Tasten ( Color,BW,CSV ) vom Oszi aus? Wenn die PC-SW unterscheiden
> kann was kommt... (Hab noch nicht getestet.) Fernbedienung vom PC ist da
> für mich zweitrangig.

Hi Jürgen, hab mich wohl nicht so deutlich ausgedrückt weiter oben. 
Genauso wie Du sagst wird es sein, bzw. ist es sogar schon in der 0.84. 
Nur das zusätzlich die Möglichkeit besteht durch schnelles 2fach drücken 
des QP-Buttons einen direkten Print anzustoßen.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Da sich die 0.84 nicht mehr ändern wird hier schon mal vorab die 
Flashdateien für alle die sich die neue QP-Funktionalität mal ansehen 
möchten.

Das komplette Paket mit aktualisierter PC-Software wird es auf SFN geben 
wenn Niklas soweit ist.


@Niklas

Da kannst Du dann gleich sehen ob die 0.84 mit der PC-Software 
harmoniert.

Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Neues vom Vinculum:
Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas 
Demo Code.

Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema 
WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei 
ist "Hallo Welt!"

Jetzt dürfen die Profis ran: Vorhandene Funktionen optimieren, neue 
ergänzen, Lauflängendekomprimierung einbauen, Interrupts benutzen...
Ich werde natürlich auch weiter daran arbeiten, nur bei der ganzen 
Dekomprimierung usw. blicke ich nicht ganz durch.

Eigentlich sollte es möglich sein eine Byte vom Oszi zu empfangen, es zu 
verarbeiten und auf das Vinculum zu schreiben noch bevor das nächste 
Byte vom Oszi ankommt. So bräuchte man kaum RAM im µC.
Dafür muss aber die Oszi Firmware entsprechend umgeschrieben werden?

Die Hardware: Ist nicht wirklich zum Nachbau geeignet und versteht sich 
nur als Layout Vorschlag. Die Leiterbahnführung ist teilweise etwas 
ungünstig, es fehlen Elkos an den USB Buchsen, das Footprint für den 
MAX232 ist zu groß, die Steckverbinder sind auf einer einseitigen 
Platine kaum zu löten...

Wenn jemand noch einen Prototypen bauen will, kann er gerne die Platine 
neu routen. Ansonsten warten wir wie die Softwareentwicklung lauft und 
ich entwerfe Version 2.0 sobald die neuen Anforderungen bekannt sind.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Kurt Bohnen schrieb:
> Neues vom Vinculum:
> Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas
> Demo Code.
>
> Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema
> WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei
> ist "Hallo Welt!"

Kannst Du mich mal erleuchten, wie das Ding angeschlossen wird und was 
genau es tut?

Falk

von Kurt B. (kurt)


Lesenswert?

Naja, an die DC Buchse kommen 5V.
Der 9-Pol D-Sub Stecker unten links geht zum Oszi.
Die 9-Pol D-Sub Buchse dient für Debug Zwecke und geht zum PC.

Mit dem 10-Pol Wannenstecker wird der AVR programmiert und mit der 5-Pol 
SIL Buchsenleiste das Vinculum.
Die linke USB Buchse ist für den Speicherstick.

Und es tut genau das was ich oben geschrieben habe: Alle 2 Sekunden eine 
neue Datei erstellen und auf den USB Stick speichern. Das ist absoluter 
schwachsinn, zeigt aber wie man mit dem VNC1L kommuniziert und Dateien 
anlegen kann.

Oder habe ich deine Frage falsch verstanden?

PS: Der Rest sollte aus dem C-Code und den Datenblättern zum Vinc. 
ersichtlich werden. Oder habe ich noch essentielle Infos unterschlagen?

von Kurt B. (kurt)


Lesenswert?

Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als 
CSV) erstellen zu können ohne einen PC anschließen zu müssen.
Außerdem kann man bestimmt auch einen Drucker anschließen.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Kurt Bohnen schrieb:
> Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als
> CSV) erstellen zu können ohne einen PC anschließen zu müssen.
> Außerdem kann man bestimmt auch einen Drucker anschließen.

Ich glaube, ich hab's jetzt auch begriffen.

Damit wäre in der Firmware ja nur wenig zu tun.

Mit dem Drucker sehe ich Probleme. Selbst ein Postscript-File könnte die 
Firmware überfordern. Das überlasse ich gerne dem AVR ;-)

Falk

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

so, zusammengestrickt, einiges geaendert und committed.  Im Einzelnen
bekomme ich das jetzt nach dem langen Tag gar nicht mehr alles zusammen.
Bitte SVN Log (und diff) schauen :)

@Hayo:
> Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die
> Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei
> geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon.
> Vielleicht kannst Du das ja mit einfließen lassen?

Hab' ich gemacht und gleich noch ne Art generisches Framework
(in Ermanglung eines besseren Begriffs) drumrum, so dass man
die Ausgabe spaeter um diverse Formate erweitern kann.  Moeglich
derzeit: -t csv (default) und -t ascii (so wie Falk das im Original
gebaut hatte).

Neu ansonsten unter anderem -i (invertieren), -s (Screenshot, Farbe),
-n num (manuelle Startnummer fuer die notwendig geworde 
Dateinummerierung),
-o (One-Shot, -l (Loop) ist Default-Verhalten (den Switch gibt's daherE
nicht) und -o wuerde das alte Verhalten (einen Dump empfangen, beenden)
wiederherstellen.

Eigentlich wollte ich noch gerne die Faerbung fuer die Planes mit einer
INI-Datei anpassbar machen, das hab' ich aber wegen der Umstruktierung
nicht mehr geschafft.  Wer da bessere Farben raussuchen moechte muss
dies ueber Aenderungen der Sourcefiles tun (gibt oben eine Tabelle,
leicht auch fuer Laien zu machen).  Verbesserungen nehmen wir gerne
entgegen.

@Hayo:
Im Moment schreibt das DSO ja noch die 16 Planes raus.  Wenn die
drei Memory-Planes raus sollen kann das sehr leicht im Programm
angepasst werden.  Das kann ich gerne noch tun.  Vllt. kannst
Du auch noch ne ganz kurze LIESMICH.txt oder so dabei tun, fuer Leute,
die nicht so gut Englisch koennen und mit der README.txt nicht klar
kommen.

@Kurt & Hayo:
Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient
(im Vergleich zu vorher geworden (28k vs. 12-15k)).  Konsequenterweise
muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal 
verbessern).
duck

Win32 .EXE im Anhang.  Bitte nochmal testen.

Niklas

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:

...

> Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient
> (im Vergleich zu vorher geworden (28k vs. 12-15k)).

Huch, ist er das? Werde ich mir ansehen.

> Konsequenterweise
> muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal
> verbessern).

> *duck*

Da gibts nichts zu ducken. Wenn ich was verschlimmbessert habe, hilft 
Kritik doch nur, es besser machen zu können.

Der Dump der Rohdaten ist ja auch nicht RLE-komprimiert, weil klar war, 
daß kaum jemals mehrere identische Werte aufeinander folgen.

Hat eigentlich mal jemand versucht, die Baudrate zu erhöhen? Es gibt da 
ein Element np_uartdivisor in der puart-Struct. In excalibur.h steht 
allerdings
1
// Parameters for altera_avalon_uart named uart1
2
// baud             = 115200
3
// data_bits        = 8
4
// fixed_baud       = 1
. Das könnte ein Hinweis sein, daß im FPGA ein fester Teiler ist. Im 
USB-UART ist fixed_baud übrigens "0"...

Falk

von Jürgen (Gast)


Lesenswert?

Hallo Niklas O.,

nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist 
schon da!( Spart viel Tinte :-)
Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem 
Zusammensetzen der Screenshot-xxx-Datei?
Danke!

Gruß Jürgen

von Blue F. (blueflash)


Lesenswert?

Hi, echt super!

Bin gerade erst wieder zuhause. Werde mal alles einsammeln und als Paket 
ins SFN stellen. Zum Dokumentieren und Testen komme ich heute nicht 
mehr.

@Niklas

Gibts die Source auf SFN, oder stellst Du die eben noch hier mit ins 
Forum?

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo Jürgen,

> nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist
> schon da!( Spart viel Tinte :-)

Das war die Intention :)  Muesste man in zukuenftigen Versionen
egtl. auch erweitern koennen und direkt auf einem Windows-Drucker
drucken.

> Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem
> Zusammensetzen der Screenshot-xxx-Datei?

Das sollte nur bei dem (default) PPM/PGM-Output passieren und ist
bei BMP mit -b abgeschaltet.  Eine programmtechnische Notwendigkeit
dafuer gibt es nicht, die Daten sind im RAM.  Gedacht war das primaer
zum Debuggen von Fehlern in der Bildschirmausgabe.  Wenn irgendwo ein
Artefakt ist kann man so leicht rausfinden in welchem Plane.  In
zukuenftigen Versionen sollte man optional machen, das sehe ich
genauso.

@Falk:
> [Baudrate]
Da wir die Daten ohnehin nur im Schneckentempo verarbeitet bekommen
erreichen wir ja nichtmal 38400 Baud.  Nun wissen wir auch, warum
das Datendumping in der Original-Firmware mit der Welec-Software
auch schon ewig dauerte -- und das war via USB.  Bzgl. der Baudrate
hab' ich nur mal getestet ob man theoretisch mit dem Nios die
Leitung saturieren koennte, und das ging.  >=10kB/s sustained
mit putchar().  Ansonsten haben oben iirc. Crazor und andere schonmal
was zum im FPGA implementierten UART geschrieben.

> [Rohdaten Trace]
Ja, RLE bringt eher nix dort.  Hatte wie schonmal ausgefuehrt an
Ausgabe von Delta zwischen Messwert und Messwert n+1 gedacht
(was in der Theorie im Durchschnitt ein geringer Wert sein sollte)
aber die Idee fallen gelassen, da es eh nur max. 4*16kB sind und
jegliche Verarbeitung auf dem Nios die Sache vmtl. langsamer statt
schneller machen wuerde.  CSV Ausgabe ueber ZMODEM direkt an
beliebiges Terminalprogramm wuerde ich aber dennoch gerne hinzufuegen.

Niklas

von Niklas O. (nevm)


Lesenswert?

Hallo Hayo,

die Sourcen gibt's auf SF.  README.txt, retrieve.bat, ComTools.cpp, 
ComTools.h, w2000a-screenshot.cpp, Makefile und
http://www.mikrocontroller.net/attachment/54252/w2000a-screenshot-v0_4.exe
solltest Du in Dein Release dabei packen.

Niklas

von Roberto (Gast)


Lesenswert?

Hallo

Habe die letzten Screenshots mal getestet.
Leider finde ich bei keinem das File, das er wohl schreiben sollte ?
Die älteren Versionen haben das in das gleiche Verzeichnis geschrieben, 
in dem das Programm gestartet wurde.
Bei der letzte Version verschwindet das Programm beim auslesen ganz ?!


FFT:

Habe mit dem mal gespielt..
Schaut gut aus aber..
Nach FFT und dann Osci ausschalten (ein paar Stunden), hatte ich nach 
dem Wiedereinschalten das FFT im LCD und der ganze FFT-Bereich war 
gelb..
Wollte das dann mal nachstellen, ging bis jetzt aber nicht mehr...
Ab und zu beim zurück vom FFT durch "Math" sind die Kanäle 
durcheinander...

Wenn ich im FFT das Osci aus schalte und wieder ein, sehe ich das FFT 
Display aber die "Math" Taste leuchtet nicht aber die Lampe unter der 
Frequenzanzeige (zum Drehen)leuchtet.
Auch die Soft-Tasten sind nicht im FFT-Modus.

Versuche dann rauszukommen mit "Math"-Taste--> Softtasten werden zu FFT.
Dann wieder "Math"-Taste und komme dann aus dem FFT.
Leider sind jetzt alle Kanäle in der Mitte!
Mit "Default Setup" geht dann wieder alles.

l.G. Roberto

von Blue F. (blueflash)


Lesenswert?

@Roberto

Ja ich weiß - default Setup hilft in dem Fall.

-> Ist in Arbeit

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Ok folks, release 0.84 with new (late night) screenshot function from 
Falk and Niklas out now - available here:

https://sourceforge.net/projects/welecw2000a/files/


Hayo

von Roberto (Gast)


Lesenswert?

Hallo Hayo
0.84 funktioniert bei mir
Von "Quick Print" (Taste) bis zum Menue vergehen leider so ca. 3 
Sekunden.
Der Screenshot funktioniert jetzt in ein File :-)

Das aussteigen aus dem FFT funktioniert auch.
Nach dem Aus/Ein schalten vom DSO ist FFT auch weg :-)
Das FFT ist aber die 1er Version (2er ist schöner :-)
Könnte man die Umschaltung der FFT-Versionen im Soft-Menue machen ?

mmhh.. irgendwas spinnt da noch...
Einmal hatte ich wieder den ganzen FFT-Bereich in gelb und einmal nach 
FFT wieder die Kanäle durcheinander ?!
Gehe immer in FFT, DSO aus/ein schalten und dann wieder in FFT.
Jetzt hat er sogar die Version 2 vom FFT eingeschalten ?!
(Length auf 1024)


l.G. Roberto

von Blue F. (blueflash)


Lesenswert?

Wie schon gesagt, ist noch in Arbeit!

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

@ Roberto:
Danke, ich dachte schon, mein Scope ist defekt. Vor .83 hatte ich solche 
Probleme mit geänderten Einstellungen nicht...

Michel

von Blue F. (blueflash)


Lesenswert?

Ok Jungs keine Sorge,

angeregt durch die Diskussion im Hardwarethread habe ich ein wenig mit 
Rauschunterdrückung experimentiert. Das funktioniert so gut, das ich 
heute noch ein neues Betarelease rausgebe, da ist dann auch Euer Problem 
beseitigt.

Hayo

von elgodil (Gast)


Lesenswert?

Oh Gott man - geh doch auch mal in den Biergarten (mit Frauchen)...bei 
dem Wetter!!

elgodil

PS: Der Tipp dient natürlich nur dazu, deinen Programmierelan über 
möglichst lange Zeit zu erhalten ;-)

von Blue F. (blueflash)


Lesenswert?

Geht nicht - Frauchen sitzt auch am Computer und braucht meinen Support.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So, bin soweit. Hier das neue 0.85 beta Release.

Die neue Rauschunterdrückung arbeitet wirklich überzeugend. Dadurch 
werden die 2er und 1er Bereiche tatsächlich benutzbar!!! Die 
Rauschunterdrückung nutzt die sonst unbenutzten Samples bei 
Timebasefaktoren > 1. D.h. der Arbeitsbereich liegt zwischen 100ns und 
500ms. Keine Beeinträchtigung der Bandbreite!! Besonders überzeugend 
kommt die neue Funktion z.B. im 2V Bereich bei 500ns. Natürlich kostet 
die Funktion etwas Performance, aber das liegt denke ich, noch im grünen 
Bereich.

Wo kann man die Rauschunterdrückung anschalten?

-> im Acquire Menü.

Ansonsten gibt es für Roberto jetzt einen Button für das FFT-Layout im 
FFT-Menü und die undefinierten Startzustände sind beseitigt.

So bin mal gespannt auf die Reaktion.

Hayo

von Lothar M. (lme)


Lesenswert?

Ja wie geil ist das denn??
Wie mit dem Lineal gezogen! Super!

  Lothar

von Johannes S. (demofreak)


Lesenswert?

Hayo W. schrieb:
> So bin mal gespannt auf die Reaktion.

Alda!!!!

Plötzlich sieht es genau so aus, wie ich es von Anfang an gern gesehen 
hätte. Das ist ein Unterschied wie zwischen Tag und Nacht!

Super Sache!

/Hannes

von Stefan (Gast)


Lesenswert?

Kann's ja gar nicht erwarten das morgen früh einzuspielen :)
Wenn ich das vorhin im Hardware-Thread, beim kurzen Überfliegen, richtig 
mitbekommen habe, nimmst Du jetzt 5 Samples im einen Wert zu mitteln.
Evtl. wäre es für die Performance hilfreich, einen Wert fallen zu lassen 
und mit 4 Werten zu arbeiten; je nachdem wie der Compiler optimiert...

von Johannes S. (demofreak)


Lesenswert?

Nix da, hier wird kein Sample verschenkt! :-D

/Hannes

von Blue F. (blueflash)


Lesenswert?

@Stefan

Das war nur der Prototyp. Die jetzige Version ist auf shift optimiert.

D.h. der am wenigsten effektive Bereich ist der 100ns Bereich, da hier 
der Faktor nur 2 ist.

die Bereiche mit Faktor 4 und 5 (also die meisten) arbeiten mit 8 Werten 
d.h. shift um 3 nach rechts, die TB mit Faktoren >= 10 arbeiten mit 16 
Werten d.h. >> 4.

Hayo

von Robert S. (razer) Benutzerseite


Lesenswert?

Das Ergebnis ist super =)
Ein minor Bug, wenn man die FFT Ansicht ändert, wird das schwarze Layout 
hinter dem gelben gezeichnet. Nach nochmaligem de- und aktivieren wird 
das Menü richtig gezeichnet.

von Blue F. (blueflash)


Lesenswert?

@Robert

Danke für den Hinweis, hatte ich mit der heißen Nadel gestrickt und 
nicht geprüft. Beim nächste Release ;-)

Hayo

von branadic (Gast)


Lesenswert?

Hallo Hayo,

die neuen Änderungen, mein letztes aufgespieltes Release war die 0.75, 
schauen wirklich sehr interessant aus. Dies bezieht sich auch auf die 
Screendump-Funktion. Wirklich gute Arbeit!
"Wie mit dem Lineal gezogen!" kann ich so zwar nicht abkaufen, aber die 
Verbesserung ist deutlich zu sehen.
Mal eine Frage anderer Natur. Es wurde ja mal irgendwo schon 
angesprochen. Die Welec-Timebasetabelle ist ja etwas merkwürdig mit 
ihrem Sprung von 250MS/s auf 25MS/s. Erwarten würde man ja noch die 
Zwischenschritte 100MS/s und 50MS/s. Habt ihr dahingehend irgendwie 
Zugriff drauf, um eine Änderung zu erzielen?
Falls ja, so würde ich dies ziemlich weit oben in der Prioritätenliste 
sehen.

Beste Grüße, branadic

von Blue F. (blueflash)


Lesenswert?

Ja da hatte ich mir auch schon Gedanken zu gemacht. Wollte ich mir mal 
näher ansehen und gucken ob man das nicht verbessern kann...

Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo,

das sieht wirklich gut aus. Langsam wird das Welec so, wie ich
mir das beim Kauf vorgestellt habe. Fehlt nur noch die USB-
Anbindung für Screendump, und etwas Entwanzung (ich küümmere
mich in den nächsten Tagen um die Pixelfehler, kann ja nichts
Großes sein), dann wird aber die 1.00 fällig :-).

Gruß, Guido

von Lothar M. (lme)


Lesenswert?

@branadic

Du kennst meine Lineale nicht! ;)
Zugegeben - war leicht übertrieben. Aber die Begeisterung nach dem 
Flashen war groß und ist es immmernoch.
Dickes Kompliment an Hayo!

  Lothar

von Martin H. (martinh)


Lesenswert?

@Hayo

Gute Arbeit, ein bisschen beschneidest du mit der Mittelung die 
dargestellte Bandbreite (um das zu verhindern duerftest du in jedem 
Bereich max. Faktor Werte fuer die Mittelung verwenden), meiner Meinung 
nach kann das aber so bleiben, und zudem kann man die Mittelung ja 
abschalten.

Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)

Martin

von Blue F. (blueflash)


Lesenswert?

@Lothar

Ich war selbst überrascht als ich das Ergebnis sah. Deshalb auch noch 
das spontane neue Release.

Hayo

von Gast (Gast)


Lesenswert?

Wäre jemand so freundlich bei Gelegenheit einen Screenshot mit/ohne 
Mittelwertbildung im Vergleich einzustellen. Ich würde diese 
Verbesserung auch gerne sehen.

von Blue F. (blueflash)


Lesenswert?

@Martin

Ja, durch die Überlappung gibt es natürlich rein rechnerisch eine 
Bandbreitenverringerung. Praktisch ist diese aber außerhalb der 
darstellbaren tatsächlichen Signalbandbreite unseres DSO. D.h. bei einem 
realen Signal wirst Du beim Umschalten keinen Unterschied bemerken. Wo 
man es sehen kann, dass ist beim Testsignal. Da das Rechtecksignal hier 
unendlich steile Flanken hat und damit natürlich extrem hohe 
Frequenzanteile, sieht man beim Umschalten, dass die Flanken minimal 
flacher werden.

> Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)

Da bin ich schon längst bei. Ich habe aber Schwierigkeiten mir das 
vorzustellen wie sich das auswirkt, wenn ich mehrere Werte an eine 
X-Position schreibe. Dadurch wird doch eigentlich nur der Linienzug 
breiter und damit das Signal unschärfer - oder hab ich das 
mißverstanden?

Hayo

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

Ohne Mittelwert

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

Mit Mittelwert

von Martin H. (martinh)


Lesenswert?

@Hayo

Das die Linie breiter wird ist richtig, diese Darstellung hilft aber ein 
untersampling zu erkennen (es wird die angezeigte Samplerate dargestellt 
und nicht die durch den Faktor reduzierte).

Martin

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Einmal ohne Rauschunterdrückung...

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Guido schrieb:
> Hallo Hayo,
>
> das sieht wirklich gut aus. Langsam wird das Welec so, wie ich
> mir das beim Kauf vorgestellt habe. Fehlt nur noch die USB-
> Anbindung für Screendump,

USB für Screendump sollte kein Problem sein. Da hat man aber nur die 
halbe Gaudrate und auf der PC-Seite ist USB nicht so trivial wie RS232.

Mit Libusb habe ich schon etwas für Linux, wie das unter Windows 
aussieht, weiß ich nicht.

Gruß,
Falk
P.S.: Heute kam mein Scope zurück. Anscheinend wurde das Mainboard 
ausgetauscht. Über den Service kann ich mich nicht beklagen!

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Oh da läuft wohl was beim Screenshot etwas schief - also das war mit 
Rauschunterdrückung und hier ohne.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich benutze die neue Screenshotfunktion gerade das erste mal und stelle 
fest, dass bei mir immer zwei Screebnshots produziert werden statt einer 
(unter Windows getestet). Ist das bei Euch auch so?

Hayo

von Blue F. (blueflash)


Lesenswert?

Scheint die zweistufige Logik zu sein, anscheinend ist das Timing noch 
nicht ganz optimal.

Hayo

von Martin H. (martinh)


Lesenswert?

@Falk

Da hast du scheinbar eine bevorzugte Behandlung! Ich warte seit dem 
1.7.2009 auf das bei Ebay erworbene W2024A!

Martin

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

also bei mir wird nur ein Screendump erzeugt (screenshot-0000.bmp). Ich 
starte mit den Parametern -b-s. Schade allerdings das Screendump.exe 
nicht wartet bis ich einen Dump mit Quick Print anfordere, sondern 
direkt loslegt. Keine gute Lösung!

Sehr überzeugendes Ergebnis mit der Rauschunterdrückung. Hätte gedacht 
das dadurch die Performance stärker leidet, ist aber absolut im grünen 
Bereich ;-)

Jetzt müssen wir nur noch das Rauschen in den schnelleren Bereichen in 
den Griff bekommen... und die blöde Oszillation... und die Wishlist...

Gruß, brunowe

von egberto (Gast)


Lesenswert?

Andere scheinen das auch (standardmäßig) zu machen - bei meinem OWON 
sahen die Kurven bis jetzt deshalb auch besser aus (und ich glaube 
nicht, das der eine besonders edle Eingangsstufe hat ;-))

LG,

egberto

von Blue F. (blueflash)


Lesenswert?

@Bruno

-s ist der Parameter für externes Auslösen! Wenn Du den weglässt wartet 
das Programm auf das DSO.

Ich hab den Fehler für die "Doppelbelichtung" gefunden und beseitigt, 
gibts im nächsten Release.

Ebenso gibt es einen kleinen Bug im neuen Acquire-Menü. Die Buttonlogik 
wird beim Neustart hin und wieder durch alte (falsche) Flashwerte aus 
dem Tritt gebracht und blockiert dann. Hier hilft erstmal default Setup. 
Ist in der nächsten beta beseitigt.

Hayo

von Roberto (Gast)


Angehängte Dateien:

Lesenswert?

Hallo

Hier mal 3 Bilder mit den verschiedenen Einstelleungen.
Kanal 4 =10mV, Kanal 3 =20mV, Kanal 2 =50mV, Kanal 1 = 1kHz Signal
erstes Bild = Normal, zweites mit Averaging, drittes mit Denoising.
Die 1er und 2er Bereiche sind furchtbar, aber durch die neues Funktion 
jetzt schon besser :-)

Screenshot:
Beim Screenshot kommen bei mir auch immer zwei Bilder!
Einstellung -c1 -b
Warum kann eigentlich der Photoshop 5.0 das BMP nicht lesen?
Kann das jemand bestätigen ?

FFT:
Funktioniert soweit :-)
Probiert mal:
Default Setup, 1kHz Signal an Kanal1, 500mv und 500us (alle 4 Kanäle 
EIN)
dann auf Math,FFT,Settings,Length auf 1024, 3 Sekunden warten, Gerät 
AUS/EIN
Dann sehe ich nur mehr Kanal 1 in der Mitte!


Und wieder ein Kompliment und Dankeschön an alle Entwickler :-) :-)
l.G. Roberto

von Stefan E. (stefan_e)


Lesenswert?

Hallo,

kann mir einer die 0.85 hier reinstellen? SF liefert gerade einen Fehler 
beim Download.

Danke

von Robert S. (razer) Benutzerseite


Lesenswert?

0.85 hat Hayo schon oben reingestellt: 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

von Michael H. (stronzo83)


Lesenswert?

Ich warte auch seit 1.7. auf mein Scope, das mir bis 8.7. zugesagt 
wurde. Als es nicht kam wurde es bis gestern zugesagt und kam natürlich 
wieder nicht. Langsam bin ich ziemlich genervt, schließlich will ich 
hier auch endlich mitmischen können!
Außerdem ist das doch reichlich unprofessionell von den Wittigs, Zusagen 
zu machen und dann nicht einzuhalten. Naja, vielleicht ist 
Unprofessionalität ja ihre Firmenphilosophie? Dann müsste man zumindest 
große Konsequenz bei der Umsetzung in allen Bereichen bescheinigen.
Hat das bei euch auch so lang gedauert?

Gruß, Michael

von branadic (Gast)


Lesenswert?

Hallo zusammen,

zum Export von Samples in ein CSV oder ASCII File hätte ich noch ein 
paar Anregungen. Beim Tek gibt es die Möglichkeiten:

- Save Samples xxx to xxx
- Save Samples between Cursors
- Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im 
Delayed-Fenster)
- Save All

wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.

Darüber hinaus lässt sich auswählen, welcher Kanal exportiert werden 
soll:

- Channel 1  2  3 / 4
- Math 1  2  3 / 4
- Ref 1  2  3 / 4

Als Data Destination stehen zur Auswahl:

- Spreadsheet CSV
- Spreadsheet TXT
- Mathcad
- Matlab

Die Mathcad und Matlab Daten werden in einer .dat-Datei abgespeichert. 
In den ersten 5 oder 6 Zeilen stehen die aktuellen Oszi-Einstellungen, 
danach folgen mit Tabulator getrennt x-Werte [s] und y-Werte [V].

Ein Export der Daten mit Tabulatortrennung und in einer x-y-Auflistung 
wäre sicherlich auch in unserem Falle hilfreich. Als x-Wert wird der 
Triggerzeitpunkt zu NULL gesetzt, x-Werte vor dem Triggerereignis 
entsprechen dann negativen Zeitpunkten und x-Werte nach dem 
Triggerereignis entsprechend positiven.
Einen ähnlichen Datenexport gab es ja seinerzeit schon in der originalen 
FW. Hier wurden alle Werte der aktiven Kanäle folgendermaßen exportiert

Zeitpunkt - Samplewert CH1 - Spannungswert CH1 - Samplewert CH2...

Der Vorteil wäre, dass sich ein Ereignis zeitlich besser eingrenzen 
ließe.

Bezüglich des Aquisition Modes. Am Tek stehen hier ebenfalls 
verschiedene Einstellung zur Verfügung:

- Samples (schätzungsweise entspricht das der übereinander gezeichneten 
Darstellung von Samples, wie weiter oben schon erbeten, denn das 
vermeintliche Rauschen ist hier extrem hoch)
- Peak Detect
- High Resolution
- Average
- Envelope

Als weitere Anregung möchte ich noch die Window-Types der FFT aufzählen:

- Rectangular
- Hamming
- Hanning
- Black-Harris
- Gaussian
- FlatTop2
- KaiserBessel

Ich bin natürlich gern bereit euch mit weiteren Info's vom Tek zu 
versorgen, sofern dies gewünscht oder erfragt wird. Schaden kann es 
meiner Meinung nach nicht zu schauen, was andere Geräte können. Ob sich 
sowas dann auch im Welec realisieren lässt sein mal dahingestellt.
Nächste Woche bekomme ich übrigens eine Vorführung bei uns im Hause. 
Dann werden mir ein Tek der 4000er-Serie und ein vergleichbares Agilent 
vorgestellt. Nach Aussagen des Außendienstmitarbeiters heute arbeitet 
Agilent mit einer Aquisition von 100000, Tek dagegen nur mit der Hälfte. 
Hameg ist mittlerweile wohl von einem namenhaften Hersteller aufgekauft 
worden.

Nach wie vor bin ich übrigens der Meinung, dass der Triggerlevel nicht 
auf einen Pixelwert auf dem TFT eingestellt werden soll, sondern auf 
einen Spannungswert. Sobald ich also den Spannungsbereich meines 
Signales umstelle sollte der Triggerlevel nach wie vor auf den gleichen 
Spannungswert des Signales triggern.
Vielleicht lassen sich hier ja auch beide Möglichkeiten implementieren, 
dann wäre es für jeden individuell einstellbar.

Soweit erst einmal von hier.
Beste Grüße, branadic

von Cra Z. (crazor)


Lesenswert?

branadic schrieb:
> Nach wie vor bin ich übrigens der Meinung, dass der Triggerlevel nicht
> auf einen Pixelwert auf dem TFT eingestellt werden soll, sondern auf
> einen Spannungswert. Sobald ich also den Spannungsbereich meines
> Signales umstelle sollte der Triggerlevel nach wie vor auf den gleichen
> Spannungswert des Signales triggern.
> Vielleicht lassen sich hier ja auch beide Möglichkeiten implementieren,
> dann wäre es für jeden individuell einstellbar.

Das finde ich auch, allerdings wirst du kleinere Sprünge in der zu 
triggernden Spannung hinnehmen müssen, da ja (vermutlich auch im 
Originaldesign; definitiv aber bei mir) auf ADC-Rohwerte getriggert 
wird.

von Niklas O. (nevm)


Lesenswert?

Hallo Roberto,

> Screenshot:
> Beim Screenshot kommen bei mir auch immer zwei Bilder!
> Einstellung -c1 -b
> Warum kann eigentlich der Photoshop 5.0 das BMP nicht lesen?
> Kann das jemand bestätigen ?

Das Problem zum ersten Punkt hat Hayo ja schon gefunden und
ist Firmware-seitig.

Letzteres habe ich in der englischen README beschrieben.
Es haengt damit zusammen, dass die Standardvariante, die Pixel
im BMP Format abzuspeichern, entgegen der konventionellen
Reihenfolge geht.  Statt von oben links Zeilenweise bis unten
rechts geht's da von unten links bis oben rechts.  Aber es
ist durch Angabe einer negativen Hoehe auch vorgesehen in
"normaler" Reihenfolge abzuspeichern.  Wie sich fuer mich
erst nach Implementation heraus stellte ist dies anscheinend
manchen Bibliotheken und/oder Programmen nicht bekannt und
wollen mit der Datei nichts anfangen.

Niklas

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

@ Hayo,

ich hab da noch einmal ein paar prinzipielle Frage zu deiner FFT:

1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer 
Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt. sind 
ok. --known Bug?
2.) die Anzeige rechts bedeutet?
df = kleinster Frequenzauflösung bei der FFT- Berechnung (man erkennt 
schön wie bei Übergang von 512 zu 1024 dieser Wert halbiert wird)
_fn_: Hälfte der oben angezeigten Samplingfrequenz- wobei hier der TB- 
Faktor nicht berücksichtigt wird- Was bringt diese Anzeige also dann?
_div_: ??? das erschließt sich mir jetzt leider nicht.

Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die 
Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor 
gar nicht nutzbar ist und nur zu Fehlinterpretation führt)
Falls ich das soweit richtig verstanden habe, sollte man dann den 
angezeigten Frequenzbereich nicht auf den sinnvollen Wertebereich 
einschränken?
Das hatte ich oben schon mal angeregt, hatte mich diesbzgl. aber wohl 
missverständlich ausgedrückt.

Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

@Branadic

- Der Punkt mit dem Triggerlevel steht auch in meiner ToDo liste im 
Beipackzettel des Paketes. Wie so of gibt es allerdings so viele Punkte 
dass wir da nur Prioritäten sortieren können.

- Die FFT-Fenster stimmen ja schon fast überein, allerdings wollte ich 
noch einige hinzufügen (z.B. Flat Top ist noch in Arbeit, Hamming steht 
auch in der Pipeline und zu Poisson und Kaiser-Bessel hab ich noch 
Versionen mit anderen Koeffizienten parat).

- Der Datendownload ist nur ein erster Prototyp. Deine Anregungen sind 
schon mal sehr gut. An diesem Thema werden wohl Niklas und Falk (jetzt 
wieder mit Oszi) dran sein.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Sehr schöne FFT. Hut ab!

Auch die Unterordnung des Screenshot-Verzeichnisses unter die Firmware 
finde ich gut.

Zur Baudrate: Beim RS232-UART ist die anscheinend nicht zu ändern. Das 
könnte beim USB-UART anders sein. Das aber wäre nur sinnvoll, wenn man 
auch die des Cypress ändern könnte, und davon verstehe ich nix.

Bei mir dauert der BW-Screenshot übrigens 12s...

Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis 
und alle anderen Parameter in einem Header mitzusenden. Das kann ja 
nicht allzuviel sein.

Falk

von Niklas O. (nevm)


Lesenswert?

Hallo branadic,

> zum Export von Samples in ein CSV oder ASCII File hätte ich noch ein
> paar Anregungen. Beim Tek gibt es die Möglichkeiten:
>
> - Save Samples xxx to xxx
> - Save Samples between Cursors
> - Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im
> Delayed-Fenster)
> - Save All

Mhm.  Wahrscheinlich hat das Tek eine wesentlich groeszere 
Samplingtiefe,
oder?  Jedenfalls sind das IMHO bissl viel Einstellungsmoeglichkeiten.

Die Cursor-Werte usw. koennen wir mituebermitteln, so dass diese
entsprechend gekennzeichnet werden koennen.

Einbau von selektiver Speicherung ist sicherlich nicht schwierig, die 
Frage ist, was da bei unserem Geraet sinvoll ist und die Bedienung
nicht unnoetig verkompliziert.  Cursor, Screen und All z.B..  Bei nem
Delayed-Fenster waere Screen dann der untere "gezoomte" Teil.

> wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.

Siehe oben, bringt bei uns nicht so viel.

> Darüber hinaus lässt sich auswählen, welcher Kanal exportiert werden
> soll:
>
> - Channel 1  2  3 / 4
> - Math 1  2  3 / 4
> - Ref 1  2  3 / 4

Mhm, was ist denn Ref da?  Koennte man statt da nochmal die Kanaele
auszuwaehlen die ungewollten nicht einfach fuer den Export ausschalten? 
Waere intuitiver.
(Vorrausgesetzt natuerlich, man hat das Sampling bereits gestoppt.)

> Als Data Destination stehen zur Auswahl:
>
> - Spreadsheet CSV
> - Spreadsheet TXT
> - Mathcad
> - Matlab
> [Textuelle Beschreibung]

Kannst Du uns da mal fuer alle Moeglichkeiten reale Ausgaben
vom Tek zukommen lassen?

Niklas

von Blue F. (blueflash)


Lesenswert?

@Bruno

> 1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer
> Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt.
> sind ok. --known Bug?

Äh nein, war mir noch nicht aufgefallen - ist notiert

> 2.) die Anzeige rechts bedeutet?

df -> delta frequency - ist die spectrale Auflösung der FFT (Bandbreite 
einer Linie)

fN -> Nyquistfrequenz, entspricht der maximal darstellbaren Frequenz der 
FFT

div -> frequenzteilung des Grid, Bandbreite eines Gridrasters

> Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die
> Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor
> gar nicht nutzbar ist und nur zu Fehlinterpretation führt)

Der TB-Faktor wird bei der FFT nicht berücksichtigt. Entscheidend ist 
daher für die FFT nicht die TB in Zeit/div sondern die angezeigte 
Samplerate und dementsprechend auch der halbe Kehrwert nahmlich die 
Nyquistfrequenz

Hayo

von Blue F. (blueflash)


Lesenswert?

Noch einer zur Datenübertragung:

Der Math-Channel enthält nur redundante Daten, die zudem auch nur für 
den angezeigten Fensterausschnitt berechnet werden. Da diese Daten auch 
problemlos extern (in einem Excelsheet oder einem Programm) 
rekonstruiert werden können, muß man die nicht auch noch durch die 
Strippe quetschen.

Hayo

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Falk:
> Bei mir dauert der BW-Screenshot übrigens 12s..
Falls Du Dich auf meine "Kritik" von zuvor beziehst:
Ich meinte nicht eine verschlechterte Zeit sondern
die Verdopplung der Datenmenge :)

@Hayo:
Wo ich gerade am Testen bin:  Wir hatten mal das Thema
Save/Recall, was in unserer FW nicht mehr funktionierte.
Du meintest glaube ich, dass es an den geaenderten
Speicherstellen laege.  Hattest Du das schon gefixt?

Bin gerade zufaellig wieder drauf gekommen als branadic
die Ueberlagerung/den Vergleich von Samples erwaehnte.
Bei mir funktioniert Save/Recall bei 0.85 jedenfalls
noch nicht.

Ich hatte glaub' ich auch angeregt, fuer solche Vergleiche
unbenutzte Planes herzunehmen.  Wie sieht das aus technischer
Sicht aus, ist da was "hart verdrahtet" im FPGA oder koennen
wir auch eigene Planes fuer diese Zwecke erzeugen?

Niklas

von Michael W. (slackman)


Angehängte Dateien:

Lesenswert?

Hi,
kann man zu der FFT nicht noch 'ne Möglichkeit hiinzufügen, um das 
Originalsignal (meinetwegen auch skaliert) mit darzustellen? Hab hier 
mal einen Screenshot eines anderen scopes gefunden...
(nur so eine Idee, nicht das Hayo noch auf den Gedanken kommt, ein Bier 
trinken zu gehen...)
;-)

von Niklas O. (nevm)


Lesenswert?

Hallo Falk,

> Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis
> und alle anderen Parameter in einem Header mitzusenden. Das kann ja
> nicht allzuviel sein.

Ja, so hatte ich mir das urspruenglich auch vorgestellt.

Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
wolltest, sollten wir nicht gleich aus dem vorhanden Auslesecode
eine Library machen, die dann sowohl GUI und Konsolenprogramm
benutzen?

Wie sieht Dein Plan aus?  Wenn uns branadic die Beispielausgaben
liefert wuerde ich mich gerne daran machen das umzusetzen.
Du wolltest ja auch die Firmware handlicher machen.
(Ich habe die btw. die naechsten Tage wieder Zeit.)

Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation
des Repositories durch Daniel/crazor.

Niklas

von Blue F. (blueflash)


Lesenswert?

@Niklas

An der Save/Recall-Sache war ich noch nicht dran, da ich erst mal unsere 
Organisatorische Pause abwarten wollte, das Release gestern war nur eine 
Spontane Sache. Ich könnte allerdings die minor Fixes von heute noch
reinstellen bevor wir dichtmachen, soll ich?


@Michael

Ist machbar, erfordert aber eine neue bzw. stark überarbeitete 
Zeichenroutine. Daher wird das wohl kurzfristig nichts (bin in zwei 
Wochen erstmal im Urlaub zum Biertrinken ;-))
Ist aber im Hinterkopf.


Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo,
>
> @Falk:
>> Bei mir dauert der BW-Screenshot übrigens 12s..
> Falls Du Dich auf meine "Kritik" von zuvor beziehst:
> Ich meinte nicht eine verschlechterte Zeit sondern
> die Verdopplung der Datenmenge :)

"Size does not matter" ;-)

Ich kann mit 12s/30s gut leben, also lasse ich das vorerst so.

Interessanter finde ich ja ohnehin die Rohdaten. Die kann man 
schließlich auf dem PC beliebig weiterverarbeiten, während ein 
Screenshot nur ein Bild darstellt.

Die Übertragung der Daten aller vier Kanäle dauert ca. 7s, die ganzen 
Parameter sollten in unter einer Sekunde zu übertragen sein.

Dann hat man alle Informationen, um auf dem PC ein Bild zu malen, zu 
Drucken, Mathcad/Matlab-Files zu schreiben, wildeste Analysen 
anzustellen oder automatisiert einen Twitter-Eintrag zu schreiben ;-)

Als sinnvolle Verbesserung sehe ich eher, die Einstellungen zu 
übertragen und nur die ausgewählten Kanäle.

Eine Fernsteuerung mit dem PC könnte auch noch interessant sein.

Meine 2¢,
Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:
> Hallo Falk,

> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
> wolltest,

Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert 
genauso mit dem Scope, wie das screendump-Programm.

> sollten wir nicht gleich aus dem vorhanden Auslesecode
> eine Library machen, die dann sowohl GUI und Konsolenprogramm
> benutzen?

Ok, mach' ich.

> Wie sieht Dein Plan aus?  Wenn uns branadic die Beispielausgaben
> liefert wuerde ich mich gerne daran machen das umzusetzen.
> Du wolltest ja auch die Firmware handlicher machen.
> (Ich habe die btw. die naechsten Tage wieder Zeit.)

Im ersten Schritt fände ich es gut, die PC-Kommunikationsfunktionen in 
eine getrennte Datei auszulagern, also "Display::DUMPCSV", 
"Display::SCREENSHOT", Display::SCREENSHOT_BW, und "rle_enc" in 
pc_comm.cpp/h.

> Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation
> des Repositories durch Daniel/crazor.

Mein Vorschlag: Irgendwo unterhalb /
- firmware/FW1.2.BF.X.yy/src
- firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
etc.

Aber soll Daniel doch einfach einen Vorschlag machen (oder hatte er das 
nicht schon?)

Falk

von Cra Z. (crazor)


Lesenswert?

Mal ne Frage an die Spezis:

Die USB-Verbindung zum Rechner ist doch im Scope auch "nur" ne UART. Wie 
geht es denn ab dem FX1 dann weiter zum Rechner? Zumindest bei einem 
schnellen Test konnte ich nicht ausmachen, dass die Originalsoftware 
(+Treiber) einen virtuellen COM-Port anlegt, über den dann die 
Kommunikation erfolgt.

Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu 
reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob 
eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über 
USB machbar ist...

von Martin H. (martinh)


Lesenswert?

Habe etwas zu frueh geschumpfen: Das W2024A ist heute bei mir 
eingetroffen (und scheint auch in gutem Zustand zu sein), wieder 
erwarten sogar mit 4 Sonden!
Auf die Wittigs ist noch verlass.

Martin

von egberto (Gast)


Lesenswert?

wird wahrscheinlich als HID angemeldet und mit was handgefrickeltem 
ausgelesen....

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:
> Mal ne Frage an die Spezis:
...

> Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu
> reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob
> eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über
> USB machbar ist...

Ich hatte mit "usbmon" getraced und dann mit der "libusb" verschiedene 
Kommandos ausprobiert.
Das Ergebnis steht hier: 
http://groups.google.com/group/welec-dso/web/usb-commands?hl=en

Das scheint nicht einfach USB-RS232 zu sein, sondern etwas 
Capress-spezifisches. Deswegen nehme ich auch an, daß man per USP auch 
die Baudrate des Chips ändern kann.

Falk

von Michael W. (slackman)


Lesenswert?

Der Cypress ist im Grunde ein um den USB erweiterter 8051er.

Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang 
mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die: 
Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit 
der PC-Software die entsprechende Funktionalität in den Cypress nachlädt 
(ByteBlaster, UART, ... was auch immer).

Leider bin ich als 'Hochsprachler' noch nicht viel weiter gekommen und 
habe jobmäßig auch arg viel zu tun... Bin froh, wenn ich diese Woche die 
ersten Taschen raushauen kann ;-)

Michel

von Stefan (Gast)


Lesenswert?

Hab's nicht verstanden... was genau spricht gegen die momentan 
schnellere serielle Schnittstelle (?) evtl. der erforderliche 
usb-to-serial dongle für 3-4 Euro ?
Meiner Meinung nach gibt es noch so viele Baustellen, bei denen es keine 
funktionierende Alternative gibt.

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Falk Willberg schrieb:
> Niklas O. schrieb:
>> Hallo Falk,
>
>> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
>> wolltest,
>
> Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert
> genauso mit dem Scope, wie das screendump-Programm.

Ok, ich hatte es ja angedroht. Das tar-Archiv ist angehängt. Es 
kompiliert unter Linux, funktioniert aber nicht mit irgendeiner 
Firmware. Betrachtet es bitte als Qt-Übung.

Leider habe ich im SVN völlig die Übersicht verloren, daher hier als 
Anhang.

Jeder, der sich mit Qt auskennt, ist herzlich eingeladen, Verbesserungen 
einzubauen.

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan schrieb:
> Hab's nicht verstanden... was genau spricht gegen die momentan
> schnellere serielle Schnittstelle (?)

IMO nichts. Wenn wir es schaffen sollten, die Baudrate da zu 
vervierfachen (223400), könnte es sinnvoll sein...

Falk

von Cra Z. (crazor)


Lesenswert?

Michael W. schrieb:
> Der Cypress ist im Grunde ein um den USB erweiterter 8051er.
>
> Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang
> mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die:
> Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit
> der PC-Software die entsprechende Funktionalität in den Cypress nachlädt
> (ByteBlaster, UART, ... was auch immer).

Genau soetwas habe ich im Gespräch mit Hans auch schon ausgeheckt. Hans 
hat sich daraufhin auch schon mit der Materie auseinandergesetzt. Unsere 
Idee ist, die ByteBlaster-Firmware dahingehend zu erweitern, dass sie 
eben auch als virtueller COM-Port fungieren kann. Falls das nicht 
zeitgleich möglich ist, dann sollte die Umschaltung von der Seite des 
Softprozessors im FPGA aus realisiert werden. Man könnte dann ein 
kleines Powerup-Protokoll implementieren, das bei Ausbleiben einer 
Meldung von Seiten des FPGA einfach die ByteBlaster-Firmware startet, 
damit man den Zugriff auf den FPGA nicht verlieren kann.

Falls du oder jemand anderes mehr Erfahrungen mit den EZ-USB's hat, 
mache ich dich/euch gern mit Hans bekannt.

Edit: Bei der Gelegenheit sollte man den Humbug mit der "ReNumeration" 
auch sein lassen und solch eine Firmware direkt in das EEPROM packen, 
das am FX1 (gnädigerweise) dranhängt. Habe da momentan fest die 
ByteBlaster-Firmware drin, da es so keine Probleme mehr mit Quartus 
gibt.

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Niklas,

ich habe mal die vier Datenexportformate im Anhang. Signal ist das 
1kHz-Probesignal vom Oszi selbst. Exportiert habe ich in CSV, TXT, 
Mathcad und Matlab. Bei dem Mathcad-Export wird zusätzlich noch eine 
x_hdr.dat erzeugt, beim Matlab-Export ist es direkt eine x.hdr

> - Save Samples xxx to xxx
> - Save Samples between Cursors
> - Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im
> Delayed-Fenster)
> - Save All

> Mhm.  Wahrscheinlich hat das Tek eine wesentlich groeszere Samplingtiefe,
> oder?  Jedenfalls sind das IMHO bissl viel Einstellungsmoeglichkeiten.

Ich denke das ein Export der Werte zwischen den Cursorn bspw. sehr 
sinnvoll sein kann. Reduziert schließlich die Anzahl der zu 
exportierenden Daten.
Auch die erste Möglichkeit ist so abwägig nicht. Angenommen man hat 
500.000 Samples, dann besteht die Möglichkeit bspw. Sample 12.000 - 
120.000 zu exportieren. Auch diese Möglichkeit reduziert die Anzahl der 
zu übertragenden Daten.
Bei der Zoom Area liegen wir beide richtig, das entspricht den im 
Delayed-Fenster dargestellten Daten. Auch dies hat eine Datenreduktion 
zur Folge.
Save All bezieht sich lediglich auf den gewählten Kanal und bedeutet, 
dass die gesamten Samples, also die volle Fensterbreite an Daten, 
übertragen wird. Diese Einstellung bezieht sich allerdings beim Tek 
ebenfalls wieder nur auf einen gewählten Kanal, nicht auf alle.

Als Grafikformate stehen übrigens

24-bit Bitmap (*.bmp)
JPEG (*.jpg)
PCX (*.pcx)
Portable Network Graphic (*.png)
Tagged Image File Format (*.tif)

zur Verfügung.
Was es mit dem Ref 1 - 4 auf sich hat muss ich mal noch in Erfahrung 
bringen, hab ich bisher selbst noch nicht genutzt. Könnte aber ein 
früher abgespeichertes und zum Vergleich mit einem Signal herangezogenes 
Signal sein. Könnte bei uns dem Recall-Signal entsprechen. Das ist aber 
Spekulation meinerseits.

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

So, es hat mir gerade keine Ruhe gelassen und ich hab am Oszi mal etwas 
näher nachgeschaut.
Es ist so wie schon von mir spekuliert wurde. Man kann Signale 
aufzeichnen und abspeichern, um sie anschließend als Referenzsignal 
wieder hereinzuladen. Das Oszi kann dabei bis zu vier gespeicherte 
Referenzsignale gleichzeitig mit vier Messsignalen und vier 
mathematischen Signalen verarbeiten. Schon heiß, sag ich mal ;)
Das heißt auch, dass das Referenzsignal unserem Recall-Signal 
entspricht. Also alles genau so wie vermutet korrekt.

Beste Grüße, branadic

von Niklas O. (nevm)


Lesenswert?

Hallo,

ich hab' Falks Qt-GUI ins SNV importiert unter /pc/w2000a-qtgui/
(Namen koennen wir ja spaeter nochmal aendern) und einen Ordner
/pc/libw2000a/ fuer gemeinsam genutzten Code angelegt.
Wer sich dem Code annehmen moechte aber nicht mit SVN klarkommt
kann natuerlich auch die Aenderungen hier senden.

@branadic:
Danke fuer die Files.

@Hayo:
> [SVN Repository, Strukturierung, Firmware handlicher machen]
> Ich könnte allerdings die minor Fixes von heute noch
> reinstellen bevor wir dichtmachen, soll ich?

Ja waere vllt. nicht schlecht.  Stefan hat ja das Repository
bereits auf den Stand 0.84 und dann 0.85 gebracht.  Fehlt also
wirklich nur heute.

Der egtl. angedachte Platz von Daniel fuer die Firmware waere
dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und
/fpga/nios/welec fuer die 1.2.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

@Falk:
> Mein Vorschlag: Irgendwo unterhalb /
> - firmware/FW1.2.BF.X.yy/src
> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/

Das widerspraeche etwas dem Konzept von Versionssystemen :)
Was Du meinst kann man durch Tagging erreichen, also
einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"
auszeichnen.  Wenn jemand dann genau den Stand moechte kann
er diesen explizit auschecken.

Aber da muss ich bei SVN leider passen, wie das dort geschieht
muesste ich selber nachlesen.

> Aber soll Daniel doch einfach einen Vorschlag machen
> (oder hatte er das nicht schon?)

Ja hatte er, Link ist paar Zeilen hierueber.  Wenn also einer
der versierten SVN Nutzer des Amtes walten wuerde und das in
die Tat umsetzt :)

Niklas

von Cra Z. (crazor)


Lesenswert?

Niklas O. schrieb:
> Der egtl. angedachte Platz von Daniel fuer die Firmware waere
> dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und
> /fpga/nios/welec fuer die 1.2.
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Super!

> @Falk:
>> Mein Vorschlag: Irgendwo unterhalb /
>> - firmware/FW1.2.BF.X.yy/src
>> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
>
> Das widerspraeche etwas dem Konzept von Versionssystemen :)
> Was Du meinst kann man durch Tagging erreichen, also
> einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"
> auszeichnen.  Wenn jemand dann genau den Stand moechte kann
> er diesen explizit auschecken.
>
> Aber da muss ich bei SVN leider passen, wie das dort geschieht
> muesste ich selber nachlesen.

Wie ich oben schonmal geschrieben habe: SVN unterscheidet nicht zwischen 
Copy-, Branch- und Tag-Operationen. Wenn man in ein Tag-Verzeichnis den 
aktuellen Trunk kopiert, dann ist der Inhalt des Ordners einfach nur 
eine Referenz auf den aktuellen Stand. Arbeitet man am Trunk weiter, 
dann sind die Dateien im Tag-Verzeichnis quasi Zeiger auf die Versionen, 
von denen beim Erstellen des Tags kopiert wurde. SVN verhindert 
allerdings nicht, dass im Tag-Ordner herumgebastelt wird. Da ist dann 
die Disziplin der Nutzer gefragt. Falls es dennoch mal passiert, sieht 
man das schnell am Log und man kann mit nem Rückwärts-Diff die Lage 
wieder richten.
Branchen geht genau wie Taggen, nur ist anschließend das Modifizieren 
ausdrücklich erlaubt ;)

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.

Ich habe die heute gemeldeten Bugs gefixed und noch eine neue Kanalwahl 
für die FFT spendiert - man kann jetzt die Source auch direkt über die 
Kanalknöpfe anwählen.

Hayo

von Blue F. (blueflash)


Lesenswert?

Bevor es jemand anderes meldet: Eine Kleinigkeit hab ich jetzt bei der 
Nachlese noch gefunden, die Kanalanzeige oben in der Statuszeile wird 
nicht umgeschaltet wenn man die Source über das Menu einstellt. Da das 
nich wirklich wehtut werde ich das mal bis zum nächsten Release 
offenlassen.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ach ja, ich mach jetzt erstmal Entwicklungsstop. Wenn Ihr also 
Organisatorisch oder Sourcemäßig was ändern wollt ist jetzt der richtige 
Zeitpunkt. Die Sourcen sind noch nicht mit SVN eingepflegt, da ich mich 
mit dem Teil noch nicht angefreundet habe. Vielleich kann das jemand für 
mich übernehmen - danke!

Hayo

von Stefan E. (stefan_e)


Lesenswert?

hab mal Nägel mit Köpfen gemacht und das angepasst. Langsam werde ich 
war mit subversion

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.
>
> Ich habe die heute gemeldeten Bugs gefixed
......

Ich habe mal angefangen, eine neue Klasse PCComms mit
1
static void SCREENSHOT_BW(void);    // nevm
2
    static void SCREENSHOT(void);       // nevm
3
    static void DUMPCSV(void);      // #FW#
4
    static void handle_extended_command(unsigned char extended_cmd_buffer[EXTCMDLEN]); //#FW#
anzulegen.

In hardware_t.cpp habe ich (möglichst wenig) geändert. Ich würde gerne 
alles zwischen
1
    if (UART_NewData) {
2
        UART_NewData = 0;               //reset UART ISR flag
3
        switch (state) {
4
...
5
            break;
6
            }
7
        }
In die Klasse PCComms auslagern und mit PCComms::handleInChar(unsigned 
char c) behandeln....

Dann kann ich nämlich die rudimentären Fernsteuergeschichten ins GUI 
einbauen.

Allmählich müssen wir uns mit den Konzepten von SVN auseinandersetzen:
http://de.wikipedia.org/wiki/Subversion_(Software) und 
http://svnbook.red-bean.com/nightly/de/index.html

Falk

von Stefan E. (stefan_e)


Lesenswert?

Sodala,

SF ist jetzt abgeändert. Sourcen liegen unter fpga/nios/oss

Die aktuelle Version ist die .86

Wo finde ich die original Sourcen? Nur der vollständigkeit halber.

@Hayo

wenn du eine persönliche Einführung in subversion willst, dann kannst ja 
mal eine PM schreiben.

Gruß,
Stefan

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> hab mal Nägel mit Köpfen gemacht und das angepasst. Langsam werde ich
> war mit subversion

Wunderbar, wir haben einen Repository Manager ;-)

Nur, wo finde ich die aktuelle Version?
1
welecw2000a/fpga/firmware/src/flash_t.cpp
2
welecw2000a/fpga/welec/improved/src/flash_t.cpp
3
welecw2000a/fpga/welec/improved/src/quickmeasurement/flash_t.cpp
4
welecw2000a/fpga/welec/improved/src/src/flash_t.cpp

??

von Cra Z. (crazor)


Lesenswert?

Das sieht ja shconmal gut aus im SVN Repo. Ein Hinweis noch: SVN bietet 
auch einen Move-Befehl, der macht dann Copy&Delete in einem Schritt, mit 
dem Vorteil, dass alle Repository-Browser das dann korrekt darstellen.

von Niklas O. (nevm)


Lesenswert?

Hallo,

@Stefan:
> Wo finde ich die original Sourcen? Nur der vollständigkeit halber.

Ich bin erst seit kurzem dabei aber so wie ich das verstanden habe
hat Bruno urspruenglich
http://welec-dso.googlegroups.com/web/W2000A+Firmware+V1.2-+Sourcecode.zip
von Wittig erhalten.

Das sind aber nur ein paar C++ Dateien, es fehlt mind. die 
Buildumgebung.
(Das war auch bis r129 im SVN Repository unter /fpga/welec/original/,
habe ich dann etwas uebereilig geloescht da es fuer mich unvollstaendig
aussah.)

Da muessten die "alteingesessenen" Bruno, Hayo und Co. was zu sagen.  In
alten Threads habe ich Verweise auf Sourceforge gefunden die aber leider
nicht mehr funktionieren.

@Falk:
> Nur, wo finde ich die aktuelle Version?

Ich gehe mal davon aus, dass Du schon "svn update" gemacht hast.
Es sollte dann /fpga/firmware/ bis auf Deine lokalen Aenderungen
freigeraeumt sein.  Die musst Du dann noch manuell uebernehmen.

Die aktuell gueltige Location ist nun wie Stefan schon schreibt
/fpga/nios/oss/.  In /fpga/welec/improved/ wurde u.a. an
QuickMeasure gearbeitet und der Pfad wird momentan nicht
(mehr) verwendet.

Niklas

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Niklas O. schrieb:

> @Falk:
>> Nur, wo finde ich die aktuelle Version?
...
> Die aktuell gueltige Location ist nun wie Stefan schon schreibt
> /fpga/nios/oss/.

Da bin ich jetzt dran. Ich habe die Behandlung von Zeichen vom UART in 
die Klasse PCComms ausgelagert, ebenso unsere Screenshot-Funktionen.

Nach dem commit, werde ich diese Dateien auch wieder unlocken.

Damit ist praktisch alles, was mit der PC-Kommunikation zu tun hat, in 
PC-comms.cpp/h.

Wenn ich das richtig sehe, haben wir nur einen Trunk, in dem gearbeitet 
wird, aber keine Tags mit benutzbaren Zwischenreleases....

Falk

von Stefan E. (stefan_e)


Lesenswert?

Das siehst du richtig. Bis zu dem Kapitel bin ich noch nicht gekommen 
;-)

von Stefan E. (stefan_e)


Lesenswert?

Was ist eigentlich der Ordner "fft"? Ist das ein branch?

von Niklas O. (nevm)


Lesenswert?

Hallo Stefan,

> Was ist eigentlich der Ordner "fft"? Ist das ein branch?

Nein, siehe:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Niklas

von Stefan E. (stefan_e)


Lesenswert?

Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind, 
dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss' 
erstmal nur 'tags','branches' und 'trunk' erscheint?

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind,
> dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss'
> erstmal nur 'tags','branches' und 'trunk' erscheint?

Wegen mir gerne. Gearbeitet wird dann in Trunk? Und wenn ein Oberguru 
"OK" sagt, macht er daraus einen Tag?

Falk, nix offen momentan

von Stefan E. (stefan_e)


Lesenswert?

Nach dem wir die einzigen momentan sind, nutze ich gleich mal die 
Chance...

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Nach dem wir die einzigen momentan sind, nutze ich gleich mal die
> Chance...

Ich versuche das auch mit w2000a-qtgui.

Falk

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber 
nur aus fünf Dateien - schön unübersichtlich.

Die jetzige Aufteilung und das komplette Build mit SDK auf das meine 
Entwicklungen aufbauen stammt von Andreas Fellnhofer, der das Ganze 
freundlicherweise ausgetüftelt und zur Verfügung gestellt hat.

Zur Abschreckung und als Museumsstück kann man das ja mit reinstellen. 
Der FFT-Ordner kann weg, sind nur Test und Beispielsourcen aus meinem 
damaligen Projekt.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber
> nur aus fünf Dateien - schön unübersichtlich.

Hehe, die habe ich auch. Ich denke, über den Namen des Autors sollten 
wir angesichts der unbekannten Umstände den Mantel des Schweigens 
lassen.

Ich habe das mit dem SVN move auch mal probiert.

Wenn Du jetzt, statt ein ZIP-File zu bauen, "svn commit" eintippst, hat 
unser  CRO (Chief Repository Officer) auch weniger Arbeit ;-)

Schönen Abend,
Falk
P.S.: "Real Hackers don't do backups. They upload their sources and let 
the others do backups." Frei nach Linus Torwalds

EDIT: Hoffentlich hat's noch keiner gesehen...
EDIT2: Wie machst Du die RAM-Version? Könntest Du das ins Makefile 
einbauen?

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Nach dem wir die einzigen momentan sind, nutze ich gleich mal die
> Chance...

Mhhh.... Wo sind meine Änderungen PC-comms.cpp aus r150 hin?

Falk

von Blue F. (blueflash)


Lesenswert?

Hi Jungs, noch ein Vorschlag zur Aufteilung der Sourcen: Ich würde das 
gesamte Signalprocessing in eine eigene Klasse auslagern - als da wären:

Die Hauptsignalprozessorroutine, die Mathfunktionen, FFT, Interpolation, 
Filterroutinen und USTB-Routinen.

Dann wird die Display-Klasse etwas schlanker.

Hayo

von rowue (Gast)


Lesenswert?

Just btw:

Das trac welches auf dem Sourcefrosch angeboten wird, lässt sich auch
sehr gut zum Projektmanagement (Bugs, Features, etc) nutzen und spielt
auch sehr nett mit svn (subversion). Ein Beispiel ist (neben anderen):
http://trac.macports.org

@Hayo: Kommst Du aus HH? Dann könnten wir ggf. auch mal eine direkte 
Einführung in Subversion/Trac machen ;)

Grüße,

   Danke für die tolle Arbeit!


    rowue

von Stefan E. (stefan_e)


Lesenswert?

Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich 
habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn 
updte" gefehlt.
Sorry...

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich
> habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn
> updte" gefehlt.
> Sorry...

Passiert.... Mit
1
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/ -r 151
 hatte ich sie wieder und nach nochmaligem commit sind sie jetzt wieder 
da. EDIT: Im Trunk, wo die hingehören.

Zum editieren meines Beitrages war es schon zu spät.

Manchmal wäre IRC nicht schlecht ;-)

Falk

von branadic (Gast)


Lesenswert?

Hallo Zusammen,

ich hatte gerade wieder ein Gespräch mit Crazor, um das neue FPGA-Design 
weiter voran zu treiben. Dabei haben wir uns auch kurz über den 
aktuellen Code von euch unterhalten.
Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte, 
den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht 
noch Potential für Geschwindigkeitsoptimierungen?

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

@ Hayo: damit das hier nicht untergeht:

Schönen Urlaub, ich bin sehr, sehr neidisch!
Und das Notebook ist doch sicher dabei?

Gruß, Guido

von Wolle (Gast)


Lesenswert?

..und nicht vergessen, das Oszi mit in die Tasche zu schmuggeln .....

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

branadic schrieb:
> Hallo Zusammen,
...
> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,
> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht
> noch Potential für Geschwindigkeitsoptimierungen?

Im Grunde ist das doch reinrassiges C zuzüglich Klassen.

Ob es einen Vorteil brächte, alles auf C-Syntax umzuschreiben, 
bezweifele ich. Die zeitkritischen Sachen sind sowieso schon ziemlich 
optimiert.

Mir würde es eher helfen, wenn ich einen Überblick hätte, welche 
Variablentypen und Operationen wieviel Zeit kosten.

Falk

von Cra Z. (crazor)


Lesenswert?

branadic schrieb:
> ich hatte gerade wieder ein Gespräch mit Crazor, um das neue FPGA-Design
> weiter voran zu treiben. Dabei haben wir uns auch kurz über den
> aktuellen Code von euch unterhalten.
> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,
> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht
> noch Potential für Geschwindigkeitsoptimierungen?

Vielleicht nicht der Riesenbringer in Sachen Geschwindigkeit, aber da 
der Code ohnehin offenbar 95% C ist, könnte man sich zumindest die 
Laufzeitbibliothek von C++ schenken, was sicher einigen Gewinn in Sachen 
Codegröße bringen könnte. Eventuell werden Funktionen wie printf() oder 
so auch schneller, wenn kein C++-Quatsch mehr unterstützt werden muss...

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> @ Hayo: damit das hier nicht untergeht:
>
> Schönen Urlaub, ich bin sehr, sehr neidisch!
> Und das Notebook ist doch sicher dabei?

Also Urlaub geht erst in 2 Wochen los - dann aber für 3 Wochen in die 
Toskana. Notebook ist natürlich dabei, kann ich locker damit 
rechtfertigen dass wir die Urlaubsbilder Abends ansehen können ;-). 
Vielleicht finde ich ja den einen oder anderen WLAN-Spot, dann melde ich 
mich mal und schau mal was so abgeht...

@Wolle
> ..und nicht vergessen, das Oszi mit in die Tasche zu schmuggeln .....

Das wird schon schwieriger, ist mir aber auch schon durch den Kopf 
gegangen...


@rowue

> Kommst Du aus HH?
Jupp!

> Dann könnten wir ggf. auch mal eine direkte Einführung in
> Subversion/Trac machen ;)

Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu 
Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die 
wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot 
zurück.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Falk

In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab 
ich heute morgen auf dem Weg zur Arbeit mal angelesen. Ich werde das mal 
ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär 
ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen 
(auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten 
Alter legt man halt Wert auf Komfort ;-)...

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> @Falk
>
> In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab
> ich heute morgen auf dem Weg zur Arbeit mal angelesen.
> Ich werde das mal
> ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär
> ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen
> (auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten
> Alter legt man halt Wert auf Komfort ;-)...

Naja, ich finde bspw. svn auf der Kommandozeile sehr komfortabel.

Aber ich finde die Möglichkeit angenehm, alle Funktionen des DSOs am PC 
steuern zu können.

Und mit Qt kann man das auch für Windows kompilieren.

Eine Frage: Wie veranlasse ich das Scope dazu, eine neue Zeitbasis auch 
anzuzeigen? Ändern tue ich die mit
1
Display_Timebase = Selected_Timebase=(int)rxbuffer[1];
2
TimebaseChanged = 1;

Die Timebase ändert sich auch, aber die Statusanzeige nicht.

Sobald dieser erste Punkt funktioniert, werde ich einen commit im trunk 
machen.

Gruß,
Falk

von Blue F. (blueflash)


Lesenswert?

Hi Falk,

setzen der Timebaseeinstellung geht so:

timebase_reg = tb_value[Selected_Timebase];
Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;

if (Selected_Timebase > 7)
{ adc_change12_reg |= 0x01000000; }
else
{ adc_change12_reg &= 0xFEFFFFFF; }

ändern der Anzeige geht so:

Display::StatusUpdate();


Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon 
wieder? Oder teilst Du noch auf? Eine Info über den Stand der Dinge wäre 
ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit 
angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst 
überlassen?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Hi Falk,
>
> setzen der Timebaseeinstellung geht so:
>
> timebase_reg = tb_value[Selected_Timebase];
> Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;
>
> if (Selected_Timebase > 7)
> { adc_change12_reg |= 0x01000000; }
> else
> { adc_change12_reg &= 0xFEFFFFFF; }
>
> ändern der Anzeige geht so:
>
> Display::StatusUpdate();

Ok, werde ich mir mal ansehen.

> Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon
> wieder? Oder teilst Du noch auf?

Ich hatte zunächst den Teil für die PC-Kommunikation in eine neue 
Klasse/Datei verlagert.

Daran bastele ich auch gerade. (Und am GUI)

> Eine Info über den Stand der Dinge wäre
> ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit
> angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst
> überlassen?

Ich werde meine Änderungen committen, sobald die Änderung der Timebase 
funktioniert, damit auch andere Qt-Spezialisten einen Ansatz haben.

Dann werde ich weiter aufteilen. Dazu werde ich mit Sicherheit einige 
Fragen haben. Bevor ich damit anfange, gebe ich Laut.

Falk

von Blue F. (blueflash)


Lesenswert?

Ok, hattest Du meinen Vorschlag von gestern zur Auslagerung des 
Signalprocessing zur Kenntnis genommen?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Ok, hattest Du meinen Vorschlag von gestern zur Auslagerung des
> Signalprocessing zur Kenntnis genommen?

Ja, damit könnte ich anfangen.

Falk

von Blue F. (blueflash)


Lesenswert?

Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei 
Steuervariablen für die Timebase

- Selected_Timebase ist die führende Variable und läuft nicht linear 
hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle 
entnehmen.

- Display_Timebase dient nur als Index bei Arrayzugriffen und Ähnlichem, 
läuft aber linear hoch.

Wozu diese inhomogenität gut ist? Keine Ahnung! Da sollte man lieber 
nicht allzulange drüber nachgrübeln. Das wollte ich beizeiten auch mal 
vernünftig implementieren, ist allerdings recht aufwändig, da die 
Variablen in diversen Berechnungen mit drinstecken.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei
> Steuervariablen für die Timebase
>
> - Selected_Timebase ist die führende Variable und läuft nicht linear
> hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle
> entnehmen.

Danke für den Tip...

Jetzt tritt mir die langsame Verarbeitungsgeschwindigkeit des Teils auf 
die Füße: Mal eben sechs Bytes mit 115200 Baud zu schicken, geht einfach 
nicht. Dazu müßte diese Verarbeitung in der ISR stecken, und die wollte 
ich nicht anfassen.
Ich werde aber wohl nicht drumherumkommen.
Jetzt probiere ich erstmal mit einem ACK, das das Scope nach jedem 
empfangenen Zeichen nach Erkennung eines GUI-Kommandos sendet.

Jetzt weiß ich auch wieder, warum ich das GUI damals hingeschissen hatte 
;-)

Keine Atempause, es geht voran,
Falk

von Wolle (Gast)


Lesenswert?

> GUI damals hingeschissen hatte


Wie sagte schon mein Opa:

Was ist das wichtigste beim schweißen?? - das W!!!!

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Wolle schrieb:
>> GUI damals hingeschissen hatte
>
>
> Wie sagte schon mein Opa:
>
> Was ist das wichtigste beim schweißen?? - das W!!!!

Naja, das war ein echter Freud'scher Verbrecher. Erst habe ich es 
hingesch^Wzusammengestoppelt, dann hingeschmissen.

@Hayo:
Ich werde das doch über die ISR machen. Da wird ein kleiner 
Kommandopuffer gefüllt und ein Flag gesetzt, wenn der richtig gefüllt 
ist.

Die übrigen Funktionen wird das nicht beeinflussen.

Jetzt fange ich mal an, aufzuräumen. Alles im Trunk, mit Deinem 
Vorschlag werde ich anfangen.

Falk

von Blue F. (blueflash)


Lesenswert?

Ach ja, noch ein kleiner Nachschlag zum Setzen der Timebase, ich hatte 
da noch was vergessen:

Setzen der Variablen:

  timebase_reg = tb_value[Selected_Timebase];
      Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;

  if (Selected_Timebase > 7)
  { adc_change12_reg |= 0x01000000; }
  else
  { adc_change12_reg &= 0xFEFFFFFF; }

Neuberechnung der abhängigen Variablen:

    Recalc_Vars();
  config_changed = 1;

Setzen der Hardwareregister:

    SetupADC();

Danach ist dann die neue Timebase angeschaltet. Du solltest aber 
berücksichtigen das je nach aktuellen Einstellungen noch weitere 
Konfigurationen nötig sind.

Zum Beispiel die automatische Aktivierung des USTB-Modus, bei 
FFT-Betrieb, bei aktivierten Cursor.

Das findest Du alles im Timebasehandler ON_Timebase()

Am besten einfach nach der Umstellung den Timebasehandler aufrufen, dann 
must Du das nicht neu programmieren.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse 
angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.

Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in 
denen das nicht passt, ist es aber kein Problem, die entsprechende 
Funktion in die passendere Datei zu schieben.

Das Verzeichnis sieht jetzt so aus:
1
      7 src/display_t.cpp
2
     45 src/floatprintf.cpp
3
     65 src/CALCPRETRIGGER.cpp
4
     66 src/TomCat.cpp
5
    123 src/USTB.cpp
6
    172 src/RenderText.cpp
7
    297 src/PC-comms.cpp
8
    347 src/floatstr_t.cpp
9
    364 src/zmodem.cpp
10
    505 src/Display-misc.cpp
11
    587 src/TestAndDemo.cpp
12
    788 src/FFT.cpp
13
    797 src/Calculations.cpp
14
   1078 src/DrawSignals.cpp
15
   1381 src/BasicDrawing.cpp
16
   2715 src/flash_t.cpp
17
   2813 src/Measure.cpp
18
   3402 src/DrawMenusFunctions.cpp
19
   3403 src/Drawing.cpp
20
   4865 src/tc_vars.cpp
21
  15801 src/display_t_bak.cpp
22
  15927 src/display_t_bitop.cpp
23
  24157 src/hardware_t.cpp

Gruß,
Falk

von Blue F. (blueflash)


Lesenswert?

Falk Willberg schrieb:
> So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse
> angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.
>
> Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in
> denen das nicht passt, ist es aber kein Problem, die entsprechende
> Funktion in die passendere Datei zu schieben.

Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind, 
aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage 
gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur 
gehören.


> Das Verzeichnis sieht jetzt so aus:
1
 
2
>      src/display_t.cpp
3
>      src/floatprintf.cpp
4
War nur eine Datei für die verröffentlichung einer Erweiterung
5
-> kann weg
6
7
>      src/CALCPRETRIGGER.cpp
8
War nur eine Veröffentlichung einer frühen Fehlerkorrektur. Die aktuelle Version ist in display.cpp und auf einem neueren Stand
9
-> kann weg
10
11
>      src/TomCat.cpp
12
>     src/USTB.cpp
13
>     src/RenderText.cpp
14
War nur eine Veröffentlichung einer frühen Fehlerkorrektur. Die aktuelle Version ist in floatstr_t.cpp und auf einem neueren Stand
15
-> kann weg
16
17
>     src/PC-comms.cpp
18
>     src/floatstr_t.cpp
19
>     src/zmodem.cpp
20
>     src/Display-misc.cpp
21
>     src/TestAndDemo.cpp
22
>     src/FFT.cpp
23
>     src/Calculations.cpp
24
>    src/DrawSignals.cpp
25
>    src/BasicDrawing.cpp
26
>    src/flash_t.cpp
27
>    src/Measure.cpp
28
>    src/DrawMenusFunctions.cpp
29
>    src/Drawing.cpp
30
>    src/tc_vars.cpp
31
>   src/display_t_bak.cpp
32
Ist nur ein altes Backup -> kann weg
33
34
>   src/display_t_bitop.cpp
35
Ist nur ein altes Backup -> kann weg
36
37
>   src/hardware_t.cpp
38
>
>
> Gruß,
> Falk

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Falk Willberg schrieb:

> Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind,
> aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage
> gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur
> gehören.

>> Das Verzeichnis sieht jetzt so aus:
>> src/floatprintf.cpp
>> src/CALCPRETRIGGER.cpp
>> src/RenderText.cpp
>> src/display_t_bak.cpp
>> src/display_t_bitop.cpp

Sind weg.

Dann werde ich man die UART-Sachen aus der hardware_t.cpp auslagern.

Falk

von Sebastian B. (sebbra)


Lesenswert?

Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt 
werden würde. Ich schffe es gerade leider nicht den von google groups zu 
laden...
Es wäre dann möglich die ganze Buildumgebung aus dem Projektarchiv zu 
beziehen.

Gruß
Sebastian

von Cra Z. (crazor)


Lesenswert?

Sebastian B. schrieb:
> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt
> werden würde. Ich schffe es gerade leider nicht den von google groups zu
> laden...

Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch 
einige sinnvolle Daten von GGroups zu "retten"...

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Nimmst Du den!

Ist der aktuellste Build vor der Aufteilung. Wenn Du das SDK installiert 
hast reicht ein "make all" und alles geht von selbst.

Kann meinetwegen auch ins SFN Repository falls das Sinn macht.

Hayo

von Sebastian B. (sebbra)


Lesenswert?

Danke! Ich binn der Meinung, dass die Build-Umgebung genauso in die 
Versionsverwaltung gehört, um auf einen definierten Stand umschalten zu 
können. der Compiler könnte ja auch im laufe der Zeit geändert werden.
Sebastian

von Blue F. (blueflash)


Lesenswert?

Die eigentliche Entwicklungsumgebung gibt es in unterschiedlichen 
Varianten für die einzelnen Distributionen. Ich hab hier die 
Suse-Version, ist aber etwas zu groß um es hier reinzustellen (10 MB). 
Must also auf Google warten,  da hab ich das auch alles reingestellt.

Hayo

von Blue F. (blueflash)


Lesenswert?

@Sebastian

Sehe ich auch so. Es muß für Neueinsteiger möglichst leicht sein sich 
das einzurichten und die ersten Schritte zu machen. So kriegen wir eine 
größere Menge an Mitentwicklern und Interessierten.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:
> Sebastian B. schrieb:
>> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt
>> werden würde. Ich schffe es gerade leider nicht den von google groups zu
>> laden...
>
> Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch
> einige sinnvolle Daten von GGroups zu "retten"...

Ich habe vorerst nicht vor, die Gruppe zu löschen. Nur als weitere 
Diskussionsplattform war sie überzählig.

Falk

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Guido schrieb:
>> @ Hayo: damit das hier nicht untergeht:
>>
>> [...]
>
> @rowue
>
>> Kommst Du aus HH?
> Jupp!
Jarrestadt/Kampnagel ;)
>
>> Dann könnten wir ggf. auch mal eine direkte Einführung in
>> Subversion/Trac machen ;)
>
> Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu
> Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die
> wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot
> zurück.

Ack - ich persönliche bevorzuge RapidSVN/svnX (OS X), aber da hat jeder 
seine Präferenz (http://subversion.tigris.org/links.html#clients hat 
eine
nette Übersicht)

Wenn Du möchtest, setzte ich Dir 'nen Repository auf meiner Kiste auf. 
Mit dem kannst Du dann "rumspielen" ohne auf SourceForge "Rücksicht 
nehmen" zu müssen ;)

>
> Hayo

Grüße,

   schönen Urlaub,

         rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Ich habe gerade eine Firmware und die erste Version des GUI committed, 
mit der zumindest die Timebase verändert werden kann.

Freue mich über jede Kritik.

Damit sind meine größeren Änderungen vorläufig abgschlossen.

Jetzt werde ich ein wenig am GUI und an PCComms.cpp schrauben.

Falk

von xCometz (Gast)


Lesenswert?

Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter 
Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf 
rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.

Weis jemand wo ich hochladen könnte ohne Registrierung?

Gruß, Ben

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter
> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta).

Welche Variante von Hayos 0.86 ist das? Aus dem SVN oder eine ältere?

> Auf
> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.
>
> Weis jemand wo ich hochladen könnte ohne Registrierung?

Ich weiß nicht, ob ich ausführbare Programm da herunterladen würde, wo 
das ohne jede Registrierung hochzuladen geht...

Falk

von Stefan E. (stefan_e)


Lesenswert?

Den Stand er 0.84er hab ich mal als Tag hinzugefügt, damit das 
professionell aussieht ;-)

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter
> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf
> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.
>
> Weis jemand wo ich hochladen könnte ohne Registrierung?
>
> Gruß, Ben

Das ist nicht übel, wäre was für meinen Urlaubsrechner! Wo Du allerdings 
25MB so einfach hochladen kannst weiß ich auch nicht. Eine Registrierung 
braucht man eigentlich immer. Notfalls könnte ich meinen Server 
anwerfen, da könntest Du das dann draufspielen und ich reiche das dann 
weiter.

Hayo

von Blue F. (blueflash)


Lesenswert?

@rowue

Nördlicher Balkan (Harburger Berge)

Hayo

von xCometz (Gast)


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

Ok, danke!

Download hat geklappt. Wenn ich das richtig sehe gehen aber beide Links 
auf die selbe Datei, oder?

Hayo

von xCometz (Gast)


Lesenswert?

Ja richtig, ich hab 2 mal hochgeladen falls ein error hätte.
Hat funktioniert?

Ben

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

xCometz schrieb:
> @Falk
> von
> http://www.mikrocontroller.net/attachment/54374/FW1.2.BF.0.86beta.zip

Die ist nicht mehr aktuell! Bitte nicht an diesen Sourcen weitermachen.

Aktuell ist derzeit 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta 
oder der Anhang.

Falk

von Blue F. (blueflash)


Lesenswert?

xCometz schrieb:
> Ja richtig, ich hab 2 mal hochgeladen falls ein error hätte.
> Hat funktioniert?
>
> Ben

Hi Ben,

hat hervorragend funktioniert. Prima Beschreibung. Auspacken, zweimal 
klicken, fertig. Echt super!

Man muß nur drauf achten das nicht in ein Verzeichnis mit Sonderzeichen 
im Namen zu kopieren.

Danke

Hayo

von Rolf W. (rowue)


Lesenswert?

Falk Willberg schrieb:
> xCometz schrieb:
>> @Falk
>> [...]
> 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta
> oder der Anhang.
>

Hi Falk, (@all)

es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)
das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.


> Falk

Grüße,

   rowue

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Rolf Würdemann schrieb:

> Hi Falk, (@all)
>
> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)

Kein problem: make; gzip TomCat.flash; svn add TomCat.flash
"svn: This client is too old to work with working copy '.'; please get a 
newer Subversion client"
Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen 
Version des Versionshandlingtools? Was eine %$&%@€&§$ !!

Während ich also die Sourcen hole und mir ein neues svn baue, verschicke 
ich's mal im Anhang.

> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.

Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm 
Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist 
SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.

Gruß,
Falk
P.S.: Du kannst nicht zufällig QT ;-)
P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir 
das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal 
schicken.

von Armin D. (ardiehl)


Lesenswert?

die Makefile mit ram support steht weiter oben in diesem Thread


Autor: Günter Jung (gjung)
Datum: 16.05.2009 00:28
Dateianhang: Makefile.zip (3,9 KB, 52 Downloads)

eventuell geht auch: 
http://www.mikrocontroller.net/attachment/50963/Makefile.zip

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Armin Diehl schrieb:
> die Makefile mit ram support steht weiter oben in diesem Thread

...

> http://www.mikrocontroller.net/attachment/50963/Makefile.zip

Danke, das war ja einfach ;-)
1
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/FW1.2.BF.087beta/
hat jetzt das angepasste Makefile, TomCat.flash.gz und TomCat.ram.gz.

Falk
P.S.: Falls es jemanden interessiert: Subversion lies sich nicht 
übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime) 
haben wollte.
Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi 
Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht, 
ein commit zu machen.

von Cra Z. (crazor)


Lesenswert?

Falk Willberg schrieb:
> P.S.: Falls es jemanden interessiert: Subversion lies sich nicht
> übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime)
> haben wollte.
> Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi
> Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht,
> ein commit zu machen.

Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin 
oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem 
System. Ich würde mal eventuelle grafische Clients durchchecken, ob die 
nicht in der Lage sind, den Standard-Client deines Systems zu verwenden 
anstatt ihrer eigenen Executables.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel H. schrieb:

...

"svn: This client is too old to work with working copy '.'"

> Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin
> oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem
> System.

Ich habe zwei Systeme. Einen PC im Büro und ein Notebook im Garten. 
Subversion-Versionen 1.4 und 1.5. (OpenSuSE 10.3 bzw. 11.0)

> Ich würde mal eventuelle grafische Clients durchchecken...

Ich mag die "Kommandozeile" lieber. Die Klickerei in GUIs ist nicht so 
mein Ding.

Ich müßte nur SuSE 10.3 auf 11.0 updaten.

Falk

von Odic X. (odic)


Angehängte Dateien:

Lesenswert?

Hallo Falk,

ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW 
aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir 
sinnvoll erscheint....

- Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben 
wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei 
Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die 
Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt, 
könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei 
dargestellt aussehen.
(/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst 
werden.)

- Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der 
hinter einem Versionsverwaltungssystem steht.

- Die History sowie die netten Orginalkommentare von Wittig Technologies 
würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt 
auslagern.

Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion 
richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich 
irgendwo aktiv werden soll, bitte Bescheid sagen.

Beste Grüße,
Odic


PS: Zu deinem Subversion-Problem: ich nehme an, dass du versuchst, ein 
und die selbe working-copy mit unterschiedlichen Clients zu bearbeiten. 
Da sind leider alle SVN-Clients die ich kenne nicht sonderlich 
kompatibel in sich. Einfach auf beiden Systemen getrennt auschecken, 
dann funktioniert es auch ohne ein Update.

von Cra Z. (crazor)


Lesenswert?

@Falk: Ok, ich hatte irgendwie im Hinterkopf, dass du auf Windows 
unterwegs bist. Da ist das gern mal etwas unübersichtlich mit SVN.

@Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im 
A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet 
wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und 
wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten 
Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal 
mit einem Haken versehen. Man muss dann auch schon auf Averaging oder 
Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu 
kommen.

von Rolf W. (rowue)


Lesenswert?

Falk Willberg schrieb:
> Rolf Würdemann schrieb:
>
>> Hi Falk, (@all)
>>
>> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)
>
> Kein problem: make; gzip TomCat.flash; svn add TomCat.flash
> "svn: This client is too old to work with working copy '.'; please get a
> newer Subversion client"
> Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen
> Version des Versionshandlingtools? Was eine %$&%@€&§$ !!

Das reicht danach, als ob da einmal mit einer aktuelleren Version
ausgecheckt wurde. Sprich: entweder bearbeitest Du den gleichen 
Check-Out von zwei Seiten aus, oder Du hattest einmal ein aktuelleres 
Svn auf dem System (kenne ich z.B. von OS X (10.5) und MacPorts, wo 
letzteres aktueller ist)

>
> Während ich also die Sourcen hole und mir ein neues svn baue, verschicke
> ich's mal im Anhang.
>
>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.
>
> Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm
> Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist
> SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.

o.k. - dann versuche ich es mal mit "-f" ;)
>
> Gruß,
> Falk

Grüße,

   rowue
> P.S.: Du kannst nicht zufällig QT ;-)

Ne (habe mal etwas unter perl mit gtk gespielt), aber a) kann ich es mir 
mal ansehen und b) kenne ich Leute (http://qucs.sourceforge.net/) die 
schon länger was mit Qt (3) machen (und die mensch mal fragen kann
wenn es Probleme gibt ;)

> P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir
> das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal
> schicken.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Rolf Würdemann schrieb:
> Falk Willberg schrieb:

...

>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.
>>
>> Geht hier.
...
> o.k. - dann versuche ich es mal mit "-f" ;)

Bei mir ist
1
cdk-nios-binutils-3.1-20040329
2
cdk-nios-libstdc++-3.1-20040329
3
cdk-nios-gcc-c++-3.1-20040329
4
cdk-nios-base-0.3-20031111
5
cdk-nios-libgloss-3.1-20040329
6
cdk-nios-newlib-3.1-20040329
7
cdk-nios-gcc-3.1-20040329
8
cdk-nios-related-tools-3.1-20040329
 installiert. OpenSuSE 11.0 x86_64. Die NIOS-binaries sind aber für 
32-Bit kompiliert.

Falk

von Rolf W. (rowue)


Lesenswert?

Falk Willberg schrieb:
> Rolf Würdemann schrieb:
>> Falk Willberg schrieb:
>
> ...
>
>>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.
>>>
>>> Geht hier.
> ...
>> o.k. - dann versuche ich es mal mit "-f" ;)
>
> Bei mir ist[c]cdk-nios-binutils-3.1-20040329
> [...]

Das Problem lag zwischen den Ohren - ich hätte einfach

     dpkg --force-architecture -i PACKET

aufrufen müssen - so hat er (natürlich) rumgenörgelt, dass
die Packete nicht zu meinem System (Debian Lenny) passen.
Installiert, compiliert sauber durch ;)

Evtl. 'nen kleinen Kommentar in's Readme für die Debian
Packete (dann stolpert kein anderer drüber ;)

Btw: Könntest Du die Änderung des Makefiles (für das
RAM Image) noch in den Trunk übernehmen? Dann braucht
beim nächsten Release keiner dran zu denken ;)

>
> Falk


rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Rolf Würdemann schrieb:
> Falk Willberg schrieb:

> Evtl. 'nen kleinen Kommentar in's Readme für die Debian
> Packete (dann stolpert kein anderer drüber ;)

Nur zu ;-)

> Btw: Könntest Du die Änderung des Makefiles (für das
> RAM Image) noch in den Trunk übernehmen? Dann braucht
> beim nächsten Release keiner dran zu denken ;)

Erledigt. Dabei habe ich auch die angezeigt Version auf 0.87 gesetzt. 
Dabei fällt mir ein, daß der Trunk ja mal eine 0.88 wird.

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Odic X. schrieb:
> Hallo Falk,
>
> ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW
> aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir
> sinnvoll erscheint....

Danke für die Anregungen. Vorläufig beschäftige ich mich mit der 
PC-Kommunikation, wenn Zeit ist.

> - Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben
> wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei
> Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die
> Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt,
> könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei
> dargestellt aussehen.
> (/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst
> werden.)



> - Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der
> hinter einem Versionsverwaltungssystem steht.

Ich weiß. Ich meine aber, daß irgendwo ein Stand gespeichert werden 
sollte, bei dem die PC-Clients mit der zugehörigen Firmware 
zusammenspielen.

> - Die History sowie die netten Orginalkommentare von Wittig Technologies
> würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt
> auslagern.

Ok.

> Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion
> richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich
> irgendwo aktiv werden soll, bitte Bescheid sagen.

Bescheid ;-) Ich erhebe keinen Anspruch auf ein Monopol auf 
Hausmeistertätigkeiten im Repository.

Ich hoffe nur, daß niemand größere Änderungen an veralteten Sourcen aus 
irgendwelchen .zip-Files vornimmt.

Falk

von Cra Z. (crazor)


Lesenswert?

Daniel H. schrieb:
> @Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im
> A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet
> wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und
> wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten
> Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal
> mit einem Haken versehen. Man muss dann auch schon auf Averaging oder
> Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu
> kommen.

Passiert auch bei der 0.86. Die lag noch aufm Desktop herum, ganz 
vergessen einzuspielen schäm

von Odic X. (odic)


Lesenswert?

Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können?? 
(SF-Account habe ich)

von Rolf W. (rowue)


Lesenswert?

Odic X. schrieb:
> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??
> (SF-Account habe ich)

Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und 
Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan 
hast überlegen und diese eingeben.

Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf 
das Repository brauchst ;)

Ansonsten gäbe es noch die Möglichkeit (wäre aber vorher zu 
diskutieren), ob Du mit svn diff einen Diff erstellst und dieses an 
ein Ticket im Trac hängst. So wird das z.B. bei MacPorts gemacht, wo 
nicht alle Port-Maintainer auf das Repository committen können. (Die, 
die es können, machen das dann direkt ;)

Grüße,

  rowue

PS: Der Diff kann dann mit "patch" einfach eingefügt und von berufener 
Seite committed werden ;)

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Rolf Würdemann schrieb:
> Odic X. schrieb:
>> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??
>> (SF-Account habe ich)

Mit dem subversion-Cli (Linux):
In das künftige Arbeitsverzeichnis wechseln,
1
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/ # Firmware
2
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-qtgui/ #GUI
3
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/ #Screenshot


> Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und
> Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan
> hast überlegen und diese eingeben.
>
> Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf
> das Repository brauchst ;)

Hat die nicht jeder?

Ich fand http://svnbook.red-bean.com/nightly/de/index.html hilfreich.

Falk

von Cra Z. (crazor)


Lesenswert?

Checkout ist anonym möglich, aber checkin nur mit SF.net Account und 
Freischaltung der Schreibrechte. Wenn einer der Oberbastler grünes Licht 
gibt (und ich den SF.net handle von Odic X. erfahre), kann ich das 
entsprechend einrichten.

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> 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.

Könntest Du das mal committen?

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> @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.

Ok, wenn Du Änderungen auf Basis der Version 172 machst, kann nicht viel 
passieren...

Falk

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

auch wenn okilidokili das Ticket etwas konfus verfasst hat, ja, ich gebe 
dir recht, nach unserer bisherigen Festlegung- It's a feature not a bug.

Wobei ich es ehrlich gesagt auch jedes mal sehr verwirrend finde, daß 
dieses nicht mehr getriggerte Signal einfach stehen bleibt- vom 
logischen würde ich erwarten das der Bildschirm dann gelöscht wird. 
Manchmal ist es sehr schwer zu erkennen, ob sich das Oszi aufgehängt 
hat, ob das Signal nur so stabil und gut getriggert ist, oder ob es auf 
Trigger normal steht und einfach nicht die Triggerbedingung erfüllt.

Mir persönlich würde es wesentlich besser gefallen den TFT in diesem 
Fall zu löschen und das Signal erst beim erneuten Erreichen der normal- 
Triggerbedingung wieder darzustellen.

Gruß, brunowe

P.S.: verfasst du einen dementsprechenden Kommentar in Sf- Tickets für 
okilidokili?

von Michael H. (stronzo83)


Lesenswert?

@ Hayo

Zum Triggerproblem: das hast du missverstanden.
Der Normaltrigger löst nur aus wenn ein Triggerereignis kommt, das ist 
völlig ok.
Aber: bei der beschriebenen Situation kommen dauern Triggerereignisse 
und es passiert trotzdem nichts, erst wenn man zweimal Run/Stop drückt 
oder nochmal an der Zeitbasis dreht werden die Triggerereignisse wieder 
verarbeitet.
Für den Test wurde ein I2C Bus mit einer Realtime Clock verwendet, auf 
dem dauernd was los ist, so dass also auch dauernd getriggert werden 
müsste.

Gruß
Michael

von Rolf W. (rowue)


Lesenswert?

Michael H. schrieb:
> 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?

trunk: Stamm
branch: Zweig
commit: festlegen ;)
>
> Gruß
> Michael

Grüße,

    rowue

von branadic (Gast)


Lesenswert?

Hallo zusammen,

also die Triggerfunktion im Normal-Mode ist beim Tek ebenfalls exakt so 
umgesetzt. Gibt es kein neues Triggerereignis, dann bleibt das Bild 
solange stehen, bis ein neues Triggerereignis auftaucht. Im Auto-Mode 
wird der Bildschirm jedoch bei Abwesenheit des Triggerereignisses 
gelöscht.

Was jedoch hilfreich wäre, um die Verwirrung etwas zu entwirren:

Am Tek gibt es für den Triggermodus eine LED, anhand derer man erkennen 
kann, ob der Trigger auf Normal oder auf Auto steht. Da es bei uns eine 
solche LED nicht gibt, wäre vielleicht ein Eintrag in der oberen 
Informationsleiste hilfreich? Ein einfaches "A" für Auto oder ein "N" 
für normal würde ja schon reichen.

Meine Anmerkung hat jedoch nichts mit dem von Michael beschriebenem 
Problem zu tun.

Beste Grüße, branadic

von Michael H. (stronzo83)


Lesenswert?

Das Kenntlichmachen des Triggers halte ich für eine gute Idee.

Von anderen Oszis (nicht nur Tek) kenne ich den Normalmodus des Triggers 
übrigens genauso, wie er beim Welec umgesetzt ist, der passt definitiv 
so wie er ist.

Nichtsdestotrotz bleibt aber das beschriebene Problem bestehen, ich 
hoffe auf deutsch habt ihr es besser verstanden.
Achja: beim Start des Oszis steht der Trigger immer auf Auto, wenn er 
sich die alte Einstellung merken würde, wäre das doch hübscher, oder?

@ Rolf: an meinem Englisch scheitert das ganze nicht, das Problem ist, 
dass man sich unter all den Begriffen oft nichts vorstellen kann, wenn 
man die dazugehörigen Tools noch nie verwendet hat. Da jetzt meine 
Prüfungen rum sind, ein Platz für die Masterarbeit und wahrscheinlich 
auch Arbeitsplatz für nachher gefunden ist, habe ich jetzt Zeit, mir 
neben der Fertigstellung zweiter Studienprojekte das ganze mal 
anzusehen.

Gruß
Michael

von Blue F. (blueflash)


Lesenswert?

@Michael

Ok also er sollte eigentlich triggern, da die Triggerschwelle 
überschritten ist, tut es aber nicht? Oder hast Du Grund zur Annahme, 
dass er das Triggerereignis erkennt aber sich danach im Firmwaredickicht 
verhaspelt?

Das kann ich leider erst zu hause überprüfen. Danke jedenfalls für die 
Rückmeldung.


@Branadic

Tja die LED kann ich wirklich nicht nachprogrammieren, aber wird der 
Triggermodus nicht oben rechts in der Statusleiste angezeigt? Ich meine 
mich zu erinnern, dass dort im "Auto" Modus auch Auto eingeblendet wird.


@Falk

Wenn ich aus dem Urlaub zurückkomme wird sicherlich nicht mehr die 172 
der aktuelle Stand sein, aber der dann aktuelle Stand wird dann die 
Basis bilden. Ich werde dann auch bevor ich da was einbaue klären was 
rein soll und was nicht.

Gruß Hayo

von Michael H. (stronzo83)


Lesenswert?

Hayo W. schrieb:
> @Michael
>
> Ok also er sollte eigentlich triggern, da die Triggerschwelle
> überschritten ist, tut es aber nicht? Oder hast Du Grund zur Annahme,
> dass er das Triggerereignis erkennt aber sich danach im Firmwaredickicht
> verhaspelt?
>
> Das kann ich leider erst zu hause überprüfen. Danke jedenfalls für die
> Rückmeldung.

Ja genau er sollte triggern, da der Bus munter vor sich in werkelt (das 
habe ich mit meinem zweiten Oszi zusätzlich kontrolliert), tut es aber 
nicht. Oder besser gesagt: zunächst klappt alles wunderbar, wenn ich an 
der timebase drehe aber auf einmal nicht mehr. Ob das Problem am Trigger 
oder sonstwo liegt, kann ich nicht sicher sagen, das Scope hat aber auf 
alles normal reagiert, so dass ich schon auf den Trigger tippen würde.


Hayo hat Recht, der Triggermodus wird bereits oben eingeblendet (Auto 
bzw. Norm).

Gruß,
Micahel

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
...
> @Falk
>
> Wenn ich aus dem Urlaub zurückkomme wird sicherlich nicht mehr die 172
> der aktuelle Stand sein, aber der dann aktuelle Stand wird dann die
> Basis bilden.

Mit etwas Glück wird Subversion das Einbauen sogar automatisch 
erledigen.

> Ich werde dann auch bevor ich da was einbaue klären was
> rein soll und was nicht.

Einbauen darfst Du natürlich alles, was Du willst. Nur das Ausbauen darf 
sich gerne auf Bugs reduzieren ;-)

Falk

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

@Rolf und Michael,

ja wir haben definitiv nur 4 ADC pro Ch. Wie kommt ihr also auf eine 
Verwürfelungsperiode von 8?
Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber 
dennoch bin ich auf eure Meinung gespannt.
Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut 
über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample 
2000 relativ gut.

Persönlich bin ich noch nicht so ganz von der Verwürfelung überzeugt, 
zumindest nicht als alleinige Ursache.

Gruß, brunowe

von Rolf W. (rowue)


Lesenswert?

Bruno We schrieb:
> @Rolf und Michael,
>
> [Verwürfelung]

Ich rechne gerade was durch, wenn ich mehr habe, sage ich Bescheid ;)

>
> Gruß, brunowe

Grüße,

   rowue

von Guido (Gast)


Lesenswert?

Hallo,

ich habe mal noch mit der Screenshotfunktion gespielt. Tolles
Werkzeug! Die Verwürfelung tritt soweit ich es erkennen kann
nur in den Bereichen mit 500 MS/s und 250 MS/s auf. In den
anderen sehe ich nichts davon.

Wenn der FPGA mit 400 MHz getaktet wird, kann der FIFO ja nicht
ein 1 GS/s aufnehmen. Da müssen also noch andere Tricks verwendet
werden, was die Fehlermöglichkeiten im Design erhöht. Die Zacken
sind da wohl nur die Spitze des Eisbergs.

Ich kann mit den CSV-Daten sogar die beobachte Schwebung ansehen.
Falls jemand die Möglichkeit hat: ein Signal mit ca. 62.5 MHz und
so kleiner Amplitude aufnehmen, dass noch keine extremen
Störungen sichtbar sind (+- 25 Schritte des ADC oder so). Dann in
der Darstellung nur jeden 4. Wert ansehen. Ich vermute, dass da ein
weiterer Takt ins Spiel kommt, der diese Schwebung erzeugt. Das
könnte der FIFO-Takt sein.

Gruß, Guido

von Cra Z. (crazor)


Lesenswert?

Guido schrieb:
> Wenn der FPGA mit 400 MHz getaktet wird

Wird er nicht. Draußen ist ein 25MHz Quarz, drinnen wird vermutlich auf 
125MHz hochmultipliziert, allerhöchstens auf 250MHz. Für den NIOS usw. 
werden niedrigere Frequenzen verwendet werden, so 50-100MHz.

> kann der FIFO ja nicht
> ein 1 GS/s aufnehmen. Da müssen also noch andere Tricks verwendet
> werden

Ja, die Tricks sind z.B., dass wir vier 250MHz-ADC haben. Somit hast du 
pro 250MHz-Takt 32 bit Samplewerte, je 8 von jedem ADC. Es gibt noch 
mehr Tricks, die ich aber erst nachher erläutere, wenn die geschichte 
mit der 4- vs. 8-Werte-Verwürfelung erklärt wurde, möchte nicht die 
Ideen vorwegnehmen.

> was die Fehlermöglichkeiten im Design erhöht.

Ja, ich vermute sie aber woanders, nämlich an den Übergängen der Signale 
von einer in die andere Clock Domain und evtl. an der Stelle, an der die 
ADC-Werte eingelesen werden. Ich traue den Wittigs zu, sowohl die 
Synchronisation falsch zu machen als auch die erste Stufe im FPGA mit 
250MHz laufen zu lassen und dann die dabei entstehenden Timing-Probleme 
zu billigen.

> Die Zacken
> sind da wohl nur die Spitze des Eisbergs.

DAS hast du schön gesagt ;)

Grüße

Daniel

P.S.: Der Daniel, der hier als Daniel (Gast) firmiert, bin nicht ich!

von Rolf W. (rowue)


Lesenswert?

Bruno We schrieb:
> @Rolf und Michael,
>
> ja wir haben definitiv nur 4 ADC pro Ch. Wie kommt ihr also auf eine
> Verwürfelungsperiode von 8?

Ansonsten zu Verwürfelungsperiode von 8: mal 16 Werte (s.o.)
hintereinander:

  25 30 63 63 88 91 118 117 77 81 106 105 132 135 162 161

Wenn Du Dir das ansiehst, wirst Du feststellen, dass die
Werte zwischen Index 5 (88) und 12 (105) innerhalb eines Intervalls
liegen. (Mein Testsignal, monoton steigend)

Wenn Du diese entsprechend (aufsteigend) anordnest und bei
Index 5 den ersten ADC setzt, kommst Du auf die o.g,
Vertauschung für 500MS/s.

Interessant dabei ist, dass jeweils zwei Messwerte sehr
dicht beieinander liegen (nahezu identisch sind).

Dafür gibt es jetzt zwei Erklärungen:

 * zwei Messwerte werden sehr kurz hintereinander aufgenommen.
 * zwei unterschiedliche Messungen alternierend gespeichert
    (3A,3B,1A,1B,4A,4B,2A,2B) - wobei diese Messungen nicht
    direkt aufeinander folgen.

Für Rauscheffekte ist es zu regelmässig.

Für mich stellt sich nun die Frage:
> Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber
> dennoch bin ich auf eure Meinung gespannt.
> Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut
> über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample
> 2000 relativ gut.

Ich jage gleich noch mal die Daten mit dem Offset durch - vielleicht
hat es ja auch was damit zu tun - ansonsten könnte eine Mittelung
innerhalb eines Paares interessant sein ;)
>
> Persönlich bin ich noch nicht so ganz von der Verwürfelung überzeugt,
> zumindest nicht als alleinige Ursache.
>

Also die Verwürfelung existiert. Ob dazu noch eine Mittelung oder
alternierende Speicherung kommt, ist eine andere Sache ;)

> Gruß, brunowe

  Grüße,

   rowue

von Guido (Gast)


Lesenswert?

Hähä,

> Ich traue den Wittigs zu, sowohl ...

ich traue denen auch zu mit 3 Latches zu arbeiten und das
vierte Byte direkt in den 32-Bit-FIFO zu leiten. Uund alles
asynchron?

Gruß, Guido

von Daniel (Gast)


Lesenswert?

hab ich auch nie behauptet!

von Rolf W. (rowue)


Lesenswert?

Rolf Würdemann schrieb:
> Bruno We schrieb:
>> @Rolf und Michael,
>>
>> [...]

> Dafür gibt es jetzt zwei Erklärungen:
>
>  * zwei Messwerte werden sehr kurz hintereinander aufgenommen.
>  * zwei unterschiedliche Messungen alternierend gespeichert
>     (3A,3B,1A,1B,4A,4B,2A,2B) - wobei diese Messungen _nicht_
>     direkt aufeinander folgen.

Dritte Möglichkeit:

   Zwei ADC's laufen bei 250/500MHz parallel und werfen
   ihre Daten rein (Mittelung)

EDIT: MS/s - nicht MHz ;)

>
>

>   Grüße,

Grüße^2,
>
>    rowue

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

So Leute,

ich glaub jetzt werd ich vollends verrückt. Ich wollte mal die Messung 
von Rolf nachstellen.
Also dacht ich mir, der Speicher ist 16k lang, ich sample mit 1GS/s 
(100ns/div), also legst mal schön ein 61kHz Dreiecksignal an, dann 
solltest du ja im besten Fall sauber eine Periode im Speicher haben.

Haha... weit gefehlt, zehn sind es! (siehe Bild)

Bei 500MS (2µs/div) sind es dann entsprechend 20 und bei 250MS (5µs/div) 
sogar 40.

geht gleich weiter...

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Also hab ich bei 500MS die Frequenz halbiert und bei 250MS dann noch mal 
halbiert. So sind es in allen drei Bereichen 10 Perioden. (siehe Bild)
Bin ich blöd, ist mein Oszi defekt?
Kann das bitte mal jemand nachprüfen?

Beste Grüße, branadic

von Rolf W. (rowue)


Lesenswert?

Rolf Würdemann schrieb:
> Bruno We schrieb:
>> @Rolf und Michael,
>>
>> [...]

> Für mich stellt sich nun die Frage:
>> Ok, wir haben uns auf Skype da eben eine Erklärung zurecht gelegt, aber
>> dennoch bin ich auf eure Meinung gespannt.
>> Könnt ihr euch auch erklären warum die Verwürfelung nicht konstant gut
>> über die 16k Samples passt? Also wie oben festgestellt ab ca. Sample
>> 2000 relativ gut.
>
> [...]

Also: Ich habe eben mal gewürfelt und gemittelt, eine Rechnung steht
vor meiner schlussendlichen Antwort noch aus ;)

Zu dem Problem mit der verspäteten Konvergenz, so habe ich hier ein
Bild, bei der ab ca. Sample 1000 mein "eigentliches Signal" anfängt,
davor habe ich "rubbish".

Ein entsprechendes Bild kenne ich auch von der Orginal-FW bei 
Datentransfer per USB. Dazu hatte ich im Source mal was davon gelesen, 
dass eine Position angegeben wird, aber der das Signal "anfängt".

Um nun mit dem "PreTrigger" arbeiten zu können, müssen die Daten
kontinuierlich in den Speicher gesampelt werden.

Evtl. handelt es sich bei den Daten bis Index 2000 noch um den
Rest von den Daten dahinter (und bedenken: ich verwende noch einen
kleinen Offset ;)

Grüße,

   rowue

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

Die letzte Rechnung verlief leider etwas unbefriedigend :(

Aber für alle, die sich gerne mal ein Bild mit Verwürfelung
ansehen möchten habe ich mal ein Bild der steigenden Flanken
mit Verwürfelung beigefügt.

Aus diesen Daten müsste sich generell die Abtastperiode bestimmen
lassen. Wir haben eine definierte Steigung, wir haben Abtastwerte
und den Faktor zwischen Abtastwerten und Spannung.

Leider komme ich bei der Samplefrequenz von 500MSa/s auf eine
Abtastperiode von


und bei 250MSa/s auf eine Abtastperiode von


Der angegebene Fehler stellt den statistischen Fehler
meiner Messpunkte dar.

Ich schau mir da morgen noch mal andere Daten an, ansonsten
müsste ich den Messaufbau nochmal verfeinern ;)

n8 ;)

 rowue

von Thomas (kosmos)


Lesenswert?

@branadic: Wollte dich kurz fragen wie du deine Messdaten so dargestellt 
hast. CVS Daten und Excel?

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> So Leute,
>
> ich glaub jetzt werd ich vollends verrückt. Ich wollte mal die Messung
> von Rolf nachstellen.
> Also dacht ich mir, der Speicher ist 16k lang, ich sample mit 1GS/s
> (100ns/div), also legst mal schön ein 61kHz Dreiecksignal an, dann
> solltest du ja im besten Fall sauber eine Periode im Speicher haben.
>
> [...]

Was aber nicht mein Ansatz ist ;)

 * Der ADC-Wandler hat 255 Intervalle(!)
  Diese werden auf den Spannungsbereich 8  V/DIV aufgeteilt
 * Es existieren eine Anzahl n (hoffentlich) äquidistante
     Abtastpunkte
 * Nun gilt es ein Zusammenspiel von Eingangs-Signal und
     Einstellung des Vorverstärkers zu finden, bei denen
     zwischen Min (0) und Max (255) etwa 16 - 50 Abstastpunkte
     liegen. Desto weniger, desto besser. 16(15) stellt dabei
     einen unteren Grenzwert dar. (50 ist schon bald tödlich)

     Der Hintergrund hierbei ist, den Spannungssprung zwischen
     den Abtastpunkten möglichst gross zu halten um Rauscheffekte
     zu minimieren. (Zeitdiskretes Signal)
  * Ein Signal mit einem linearen Anstieg hat dabei den Vorteil,
     dass die Abtastperiode relativ einfach zurückgerechnet
     werden kann, ohne z.B. den Sinus wieder rausfalten zu
     müssen. (Wobei die Annahme gemacht wird, dass die
     Eingangsverstärker selbst linear sind ;)
  * Bei der Messung sollten Einstellungen für die Eingangsverstärker
     verwendet werden, welche möglichst rauscharm sind ;)

Wie oben beschrieben/gezeigt, scheint die Würfelfolge zu stimmen,
allerdings weicht die ermittelte Abtastperiode doch etwas sehr
stark vom Erwartungswert ab. (2ns, 4ns)

Ich werde mir das morgen mal mit anderen Daten (aus einer Messung
mit dem nächst empfindlicheren Spannungsverstärkung) ansehen. Wenn
die Daten hier auch nicht stimmen, werde ich die Messung mit einem
verfeinerten Messaufbau wiederholen.

Falls jmd. (z.B. mit einem W202XA) die Messung wiederholen möchte,
wäre das sehr cool.

>
> geht gleich weiter...

Grüße,
   rowue

von Stefan E. (stefan_e)


Lesenswert?

@branadic

>So Leute,

>ich glaub jetzt werd ich vollends verrückt.

Das habe ich vor drei Wochen auch schon bemerkt, dass da was faul ist. 
Dachte aber, ich wäre das Problem. Habe damals den Screenshot mit dem 
internen Rect-Generator getestet. Auf dem Bildschirm waren es zwei 
Perioden. In OpenOffice mit den CVS dann ne ganze Nummer mehr...,

Leider kann ich dazu gerade wegen Prüfungen nichts beitragen.

Gruß,

Stefan

von branadic (Gast)


Lesenswert?

@ Thomas O. (kosmos)

Ich speichere, wie du richtig festgestellr hast CSV-Dateien und lade sie 
anschließend in QTOctave und plotte sie dort^bzw. bearbeite sie dort.

@ Rolf Würdemann (rowue)

es ging mir darum, wie du es auch gemacht hast, eine Rampe aufzuzeichen, 
um nach Regelmäßigkeiten Ausschau zu halten. Dazu sollte mir eben das 
61kHz Dreiecksignal dienen. Man hätte erwartet, dass eine Periode im 
Speicher liegt, dem ist aber offensichtlich nicht so.
Auf das, was mir auf dem TFT angezeigt wird verlasse ich mich nicht 
mehr. Solange im Samplespeicher nicht das erwartete liegt ist was faul.
Für mich schaut es so aus: 10Perioden à 100MS sind nicht gleich 1GS. Was 
passiert hier also?

@  Stefan E. (stefan_e)

schade, dass du nicht schon eher geschrieben hast, dass dir da 
irgendwelche Unregelmäßigkeiten aufgefallen sind. Dann wären wir 
vielleicht schon drei Wochen weiter :(

Jetzt noch einmal die Frage an die Kollegen, die die 
Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus? 
Ist das wirklich der Speicher, der aus dem FIFO heraus gefüttert wird? 
Nicht das wir einer Finte hinterher jagen.

Beste Grüße, branadic

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

branadic schrieb:

...

> Jetzt noch einmal die Frage an die Kollegen, die die
> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?

Die Daten aus SIGNAL1[]...SIGNAL4[].

> Ist das wirklich der Speicher, der aus dem FIFO heraus gefüttert wird?

Ich versuche gerade, das herauszufinden... Vielleicht will noch jemand 
einen Blick auf Hardware::ReadOut_Signal werfen? Da sehe ich noch einen 
"readout_sigbuf", in den 4096 longs gelesen werden (oder so...) 
hardware_t.cpp:5219. Danach wird auch Hardware::READADC_ALL aufgerufen. 
Assembler....

> Nicht das wir einer Finte hinterher jagen.

Ich kann leider noch nicht testen :-(

von siegmar (Gast)


Lesenswert?

Hi Leute,

ich verfolge seit geraumer Zeit eure Arbeit und bin sehr beeindruckt !
Tolle Arbeit von allen Beteiligten !!!!!!
Leider habe ich noch nicht das DSO, aber hoffentlich bald...
Eine großes Problem im Augenblick ist den Fehler eindeutig einzugrenzen.
Ist er im Digitalteil( FPGA) oder im Analogteil zu suchen.
Auch die AD-Wandler könnten einen  potentielle Fehlerquelle darstellen 
(Timing Probleme).
Hab leider noch keinen Zeit gefunden, mir den Schaltplan zu Gemüte zu 
führen, aber wäre es nicht denkbar, den digitalen Teil der AD Wandler 
durch z.B ein FPGA zu simulieren ??
Dann wäre man in der Lage, eindeutig den Fehler einzugrenzen.
Leider bin ich kein FPGA Freak, aber ich könnte mir vorstellen, das im 
entsprechenen Forum, ein Experte in der Lage wäre, dies mal "schnell" zu 
coden.
Noch Allen einen schönen Tag
Gruß
Siegmar

von Cra Z. (crazor)


Lesenswert?

siegmar schrieb:

> Dann wäre man in der Lage, eindeutig den Fehler einzugrenzen.
> Leider bin ich kein FPGA Freak, aber ich könnte mir vorstellen, das im
> entsprechenen Forum, ein Experte in der Lage wäre, dies mal "schnell" zu
> coden.

Das wäre möglich, aber der elektrische Aufwand ist hoch. FPGA sind eben 
leider doch keine Mikrocontroller ("Saft drauf und los").

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Falk Willberg schrieb:
> branadic schrieb:
>
> ...
>
>> Jetzt noch einmal die Frage an die Kollegen, die die
>> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?
>
> Die Daten aus SIGNAL1[]...SIGNAL4[].
...
Das scheinen nicht die rohen ADC-Werte zu sein....

Falk

von Daniel G. (Gast)


Lesenswert?

Hallo zusammen,

ich verfolge die Diskussion schon eine Weile und mir ist dabei folgender 
Gedanke gekommen:

Wie sind die vier ADCs denn an den Output des letzten AD8131 angebunden? 
Gibt es hier eine Entkoppelung? Leider sehe ich das im Schaltplan nicht 
oder ich habe das richtige PDF noch nicht gefunden.

Langer Rede kurzer Sinn: Wenn die ADC-Inputs irgendwie entkoppelt sind, 
könnte man alle vier übersteueren (so dass sie möglichst Rauschfrei 0xFF 
liefern) und dann einen künstlich auf eine geringere Spannung 
(idealerweise 0V) ziehen. Das dürfe im Speicher doch ziemlich schnell 
zeigen wo die Daten dieses ADCs landen. Damit könnte man die aktuelle 
Verwürfelungsvermutung absichern.

Oder übersimplifiziere ich das Problem jetzt?

Gruß
Daniel

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Daniel G,

die einzelnen ADC sind leider nicht "entkoppelt". D.h. der Ausgang des 
letzten AD8131 (genauer gesagt die Ausgänge- wg. differentieller 
Ansteuerung) gehen parallel an alle 4 ADC. Ohne große Löterei (und das 
will ich bei dem Pinabstand mal besser lassen) ist dein Vorschlag nicht 
durchzuführen.

Gruß, brunowe

von Daniel G. (Gast)


Lesenswert?

Hallo Bruno We,

hm... gibt es denn ein Schaltbild der Umgebung der ADCs? Ich würde mir 
deren Außenbeschaltung gerne mal ansehen. Evtl. gibt's es einen anderen 
Weg ein "eindeutiges" Signal auf den Weg zu bringen...

Gruß
Daniel

von Günter J. (gjung)


Lesenswert?

Hallo,

Daniel G. schrieb:
> deren Außenbeschaltung gerne mal ansehen. Evtl. gibt's es einen anderen
> Weg ein "eindeutiges" Signal auf den Weg zu bringen...

man könnte die Referenzspannung der einzelnen ADCs modifizieren.
D.h. Nutzsignal ist DC > 0 und dann durch verringern der Ref-V
eines einzelnen ADCs bei diesem einen klar größeren Output erzeugen.

Gruß,
Günter

von Michael H. (Gast)


Lesenswert?

Das ist ja spannender als ein Thriller hier!
Weil im Moment doch recht viele kluge Köpfe an den Problemen knobeln, 
bin ich recht zuversichtlich, dass es bald den einen oder anderen 
Durchbruch geben wird. Wer hätte gedacht dass ein völlig fehlerhaftes 
Produkt solchen Spaß machen kann?
Da ich jetzt eine Woche "Heimaturlaub" mache, wird sich meine 
Beteiligung wohl fürs Erste auf das Mitlesen beschränken, ohne Oszi und 
eigenen PC kann ich sonst wohl nicht viel beitragen.

Gruß,
Michael

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

>Falk Willberg schrieb:
>> branadic schrieb:
>>
>> ...
>>
>>> Jetzt noch einmal die Frage an die Kollegen, die die
>>> Screenshot-Funktionen möglich gemacht haben. Welche Daten lest ihr aus?
>>
>> Die Daten aus SIGNAL1[]...SIGNAL4[].
>...
>Das scheinen nicht die rohen ADC-Werte zu sein....

Hab mal eine Version des letzten SVN stands (173) so umgebaut, das mit 
den Test switch 1 (SHIFT S) die Rohdaten in SIGNAL1[]..SIGNAL4[] landen.

Anbei das entsprechende TomCat.ram

Scheint keine grosse Differenz zu sein.

Martin

von Daniel G. (Gast)


Lesenswert?

Hall Günter,

du hast mich da auf eine Idee gebracht. Lt. Datenblatt wäre Pin 68 des 
MAX1121 eine Möglichkeit. Dieser legt das Ausgabeformat fest. Wenn er 
auf 0 liegt, wird der Wert als Zweier-Komplement ausgegeben, bei 1 als 
normaler Binärwert. Der Pin hat einen internen Pulldown. Wenn er im 
Scope unbeschaltet ist (weil Wittig sich hier auf den Pulldown verlassen 
hat) so könnte man über diesen Pin einen der Wandler von 
Zweier-Komplement auf Binär-Output umschalten. D.h. bei positiven 
Vollausschlag würde der Wert von 0111 1111 auf 1111 1111 springen. Das 
wäre doch eine gut zuordenbare Veränderung, oder?

Gruß
Daniel

von Martin H. (martinh)


Lesenswert?

> Scheint keine grosse Differenz zu sein.

Berichtige:

Jetzt verstehe ich weshalb da zwischen Highspeed und Lowspeed 
unterschieden wird! Mit den Rohdaten wird bei lowspeed sichtbar das da 
immer alle 4 AD's ausgelesen werden (wobei die angezeigte Samplerate 
einem einzelnen AD entspricht, die Daten werden dann so umgeschichtet 
das sie in 4 x 4K bloecken fuer die 4 AD's hintereinander liegen (das 
bedeutet das wir hier in wirklichkeit nur 4K Speicher tiefe haben!)

Martin

von Guido (Gast)


Lesenswert?

Hallo Falk,

die Werte in Signalx sind schon in READADC_ALL vorverarbeitet, d.h.
Offsetkorreektur, ev. Invertierung und Averaging. Ich habe versucht
das in C umzuschreiben, Hayo hat das in ADC_ReadData umbenannt. Ev.
wird da die Funktion leichter zu erkennen sein als im Assemblercode.
Für die lamgsamen Zeitabsen ist das wieder falsch (mein Fehler),
für die schnellen hoffe ich, dass es dasselbe macht wie ADC_READALL.

Ich probiere mal branadics Messung nachzuvollziehen, das kling
interessant.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Hallo Martin,

so habe ich das auch interpretiert und in C umgesetzt. Die
Umschichtung muss wirklich stattfinden, aber ob das was mit
der Zahl benutzter ADCs zu tun hat? Da bin ich mir nicht mehr
sicher, muss noch ausprobiert werden.

Gruß, Guido

von Günter J. (gjung)


Lesenswert?

Hallo Daniel,

Daniel G. schrieb:
> du hast mich da auf eine Idee gebracht. Lt. Datenblatt wäre Pin 68 des
> MAX1121 eine Möglichkeit. Dieser legt das Ausgabeformat fest. Wenn er
> auf 0 liegt, wird der Wert als Zweier-Komplement ausgegeben, bei 1 als
> normaler Binärwert. Der Pin hat einen internen Pulldown. Wenn er im
> Scope unbeschaltet ist (weil Wittig sich hier auf den Pulldown verlassen
> hat) so könnte man über diesen Pin einen der Wandler von
> Zweier-Komplement auf Binär-Output umschalten. D.h. bei positiven
> Vollausschlag würde der Wert von 0111 1111 auf 1111 1111 springen. Das
> wäre doch eine gut zuordenbare Veränderung, oder?

sehr gute Idee, damit würde ein wandernder Pullup (ständiges umlöten 
:-()
oder eventuell eine Verbindung von vier freien Schieberegister-Ausgängen
zu diesem Pin (die Schieberegister die auch z.B. für die 
Bereichsumschaltung
da sind) eine eindeutige Unterscheidung eines spez. ADCs ermöglichen.

Gruß,
Günter

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Guido schrieb:
> Hallo Falk,
>
> die Werte in Signalx sind schon in READADC_ALL vorverarbeitet, d.h.
> Offsetkorreektur, ev. Invertierung und Averaging. Ich habe versucht
> das in C umzuschreiben, Hayo hat das in ADC_ReadData umbenannt.

Ich muß am Datenexport sowieso ein wenig ändern. Ich habe zum probieren 
mal ein pre-pre-pre-088 in http://falk-willberg.de/tmp/pre-088/ 
abgelegt.

Vielleicht lagere ich da künftig meine nicht-kaputten "Kompilate" ;-)

Falk

von Jürgen (Gast)


Angehängte Dateien:

Lesenswert?

Hallo branadic,

sehe gerade deine Versuche von gestern mit 61,5kHz und 1,2 4 Perioden 
usw. Ich habe das mal nachgestellt und nichts da! Passt in der 0.86 beim 
W2024A recht genau! Ist zwar fast kein Dreieck mehr vom 
"Eigenbau-S12-Controller DDS", aber was solls! Im Anhang die 
500MS/s-.csv.(Hab hoffentlich die richtige erwischt). Es sind auf jeden 
Fall nicht 10 Perioden.

Gruß Jürgen

von Bruno W. (brunowe) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Daniel G.

nein einen Schaltplan von der ADC Umgebung und dem FPGA- Part gibt es 
nicht- da hat sich noch keiner ran getraut ;-)

Hier wurden ja wirklich schon tolle Vorschläge zur Identifizierung der 
einzelnen ADC gemacht, Respekt.
Die ADC- Vorspannung wird mit/am letzten AD8131 (U12) erzeugt, die 
Ansteuerung ist hier zu finden:
http://welecw2000a.sourceforge.net/docs/schematics/Analog-Input-Part_assignment_V3_3.pdf
Diese Vorspannung ist für alle 4 ADC und alle Kanäle die Gleiche.

Lötungen direkt an den einzelnen ADC sind schon recht heikel... Evtl. 
finden wir ja doch noch eine Antwort auf SW- Basis.
Ansonsten halte ich die Möglichkeit mit dem Zweier-Kompl. über Pin68 der 
ADC durchaus für gangbar.

Dann hab ich heute auch mal versucht, das von branadic und Stefan E. 
beschriebene Phänomen, der falschen Anzahl von im Speicher hinterlegten 
Perioden nachzustellen. Zum Glück ohne Erfolg!
Als Anlage ein paar Bildchen zum ansehen. Wie gesagt, ich konnte 
keinerlei Unregelmäßigkeiten feststellen. Auffallend ist aber, das 
teilweise fast der gesamte Speicherbereich auch am TFT dargestellt wird. 
D.h. die Speichertiefe nur eine unwesentlich längere (zeitl. gesehen) 
Aufzeichnung zulässt als am TFT dargestellt.
Selbstverständlich werden für die TFT Anzeige eine Menge 
"Zwischensamples" weggelassen (oder gemittelt- denoising) um auf die 
600Px Darstellungsmöglichkeit unseres TFT zu kommen.

Gruß, brunowe

von Guido (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ja, branadics Messung kann ich auch nicht bestätigen. Ist wohl
mal nach "Wer misst, misst Mist".

Sieht mir aus, als ob in den langsamen Bereichen doch alle 4
ADCs benutzt werden. Ich meine eine kleine Offsetverschiebung
zu erkennen, wobei die Korrektur bei meiner Firmware für alle
Datenpunkte dieselbe ist.

Gruß, Guido

von branadic (Gast)


Lesenswert?

Hallo zusammen,

> ja, branadics Messung kann ich auch nicht bestätigen. Ist wohl
mal nach "Wer misst, misst Mist".

danke für die Blumen, aber ein 61kHz-Signal bekomme ich gerade noch 
gebacken zu messen :)

Motiviert durch die heutigen Beiträge habe ich mein Oszi mal komplett 
zurück gesetzt (komplettes Backup inkl. der Protected Bereiche) und die 
FW0.86 erneut aufgespielt.
Jetzt passt es auch bei mir. Scheint, als hätte sich da irgendwas 
verabschiedet, was auch immer da passiert gewesen sein mag. K.A.!

Damit wäre dieser Fehler von der Liste gestrichen und ein solcher Effekt 
mal für die Nachwelt und eine Lösung dafür festgehalten.

Beste Grüße, branadic

von Rolf W. (rowue)


Lesenswert?

Ich finde die Idee mit der Rampe und einer Periode beim zweiten
Nachdenken gar nicht so schlecht - allerdings mit einigen
Modifikationen:

  * Test-Signal mit ~122 kHz (Halbe Periode)
  * Das Signal wird so eingestellt, dass es gut in
      einen Messbereich passt (Vollausschlag ;)
  * Dann wird Der Messbereich um Faktor 1000 verkleinert
    (V -> mV)

Somit sollten wir dann ~16 Samples haben, die innerhalb des
Intervalls [2:253] (grob) liegen. Der Rest überschreitet unseren
Messbereich.

An diesen ~16 Werten dürte sich einiges ablesen lassen ;)

Am besten ohne Bandbreitenbedämpfung, Denoising - ich frage mich
eh gerade schon, ob dass unserer Vorverstärker "so" mitmacht
(oder die 5ns nicht von diesem kommen ;)

Hat wer Lust? ;)

Grüße,

   rowue

EDIT: /me möchte heute Abend mal Messpause machen ;)

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Hallo zusammen,
>
>> [Messung]
>
> Motiviert durch die heutigen Beiträge habe ich mein Oszi mal komplett
> zurück gesetzt (komplettes Backup inkl. der Protected Bereiche) und die
> FW0.86 erneut aufgespielt.
> Jetzt passt es auch bei mir. Scheint, als hätte sich da irgendwas
> verabschiedet, was auch immer da passiert gewesen sein mag. K.A.!
>
> Damit wäre dieser Fehler von der Liste gestrichen und ein solcher Effekt
> mal für die Nachwelt und eine Lösung dafür festgehalten.

Den Fehler sollten wir mal im Auge behalten - gerade Runtime-Errors
und Systeme, die sich dann irgendwann undefiniert verhalten sind
was fieses ....

Hast Du Lust da ein Ticket einzutüten? ;)
>
> Beste Grüße, branadic


Grüße,

   rowue

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Rolf,

da ich mich mit dem Ticketsystem bisher noch nicht auseinander gesetzt 
habe, überlasse ich das lieber mal jemandem, der sich damit auskennt :)

Zu deiner vorherigen Meldung, du meinst wahrscheinlich nicht 122kHz 
sondern 30,5kHz.
Ich hab da mal schnell zwei CSV-Dateien mit eben diesen erstellt. Der 
OPV hat es überlebt :)

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Einmal mit Bandbreitenbegrenzung (mBW) und einmal ohne (oBW). Darfst 
dich an den Daten gerne austoben.
Magst du nicht auch zu uns ins Skype kommen? Dann könnte man in Echtzeit 
kommunizieren. Findest nicht nur den Falk dort, sondern auch BrunoWE, 
Daniel (crazor) sowie mich (mister_pocher) und ganz langsam wächst die 
Gruppe, weil sich doch ab und an jemand überwinden kann. Um schnell mal 
Info's auszutauschen ist diese Plattform eher ungeeignet.

Beste Grüße, branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Also da kaum einer seine Input-Stufen um den Faktor 1000 übersteuern 
möchte, hier mein Vorschlag:
Nehmt doch einfach ein möglichst gutes (steilflankiges) Rechtecksignal- 
Flanke idealerweise 16Px breit, skaliert das Oszi entsprechend damit ihr 
einen möglichst grossen ADC Bereich mit dem Rechteck überstreicht und 
schon sollten die einzelnen ADC- Werte (16Stck) der Flanke ihre 
Verwürfelung zeigen.

Gruß, brunowe

von Karl (Gast)


Lesenswert?

Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder 
schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde, kann 
man dann zuverlässig (über alle Geräte/Toleranzen/Temperaturen) sagen in 
welcher Reihenfolge die Samples anliegen und ob alle Bits richtig sind? 
Meinem Verständnis nach eher nicht, weil es nicht definiert ist, was ein 
FF macht oder wann es das macht, wenn die SU oder Hold Zeiten verletzt 
werden.

Wer seine Hardware ein bischen quälen will: Durch hohe Spannung oder 
tiefe Temperaturen verkürzen sich die Gatterlaufzeiten. Also zückt das 
Kältespray ;-D.

Gibt es eine Möglichkeit, die 25 MHz Referenz durch 20 MHz oder so zu 
ersetzen? Dann hätte man halt ein 800 MSPS Scope. Wenn es damit gut ist, 
wäre zumindest der Fehler gefunden und als Lösung hilft nur noch ein 
neues FPGA Design.

von Daniel G. (Gast)


Lesenswert?

Hallo zusammen,

ich finde es Schade, dass der IRC-Channel zugunsten von Skype aufgegeben 
wurde. Da ich zum Teil mit IT-Security mein Geld verdiene, kommt Skype 
leider nicht in Frage. Ich hoffe Ihr publiziert die Ergebnisse euerer 
Bemühungen hier im Forum. Über die parellele Möglichkeit eines 
regelmäßigen IRC-Chats (z.B. jeden Freitag) würde bestimmt nicht nur ich 
mich freuen...

PS: Ich muss mich wirklich mal im Tracker anmelden ;)

Gruß
Daniel

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Einmal mit Bandbreitenbegrenzung (mBW) und einmal ohne (oBW). Darfst
> dich an den Daten gerne austoben.

Merci - und mit den 30kHz hattest Du deutlich recht (5) ;)

> [Skype]

Naja - zu Skype siehe:

http://de.wikipedia.org/wiki/Skype#Kritik

Aber für Leute, die Jabber/XMPP machen gibt es auf

  conference.jabber.ccc.de

einen Raum "welec" ;)


>
> Beste Grüße, branadic

Grüße,


     rowue ;)

von Rolf W. (rowue)


Lesenswert?

Daniel G. schrieb:
> Hallo zusammen,
>
> [IRC/Skype]

Hi ... treibe mich jetzt auch Abends (wenn ich eh im IRC bin) auch
in #welec rum ...

Sonst - siehe letzten Post ;)

>
> PS: Ich muss mich wirklich mal im Tracker anmelden ;)
>
> Gruß
> Daniel


Grüße,

   rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Daniel G. schrieb:
> Hallo zusammen,
>
> ich finde es Schade, dass der IRC-Channel zugunsten von Skype aufgegeben
> wurde.

Wurde er nicht, es ist nur nichts los... Das würde sich ändern, wenn da 
mehr Teilnehmer wären....

> Da ich zum Teil mit IT-Security mein Geld verdiene, kommt Skype
> leider nicht in Frage.

Das kann ich gut verstehen, geht mir auch so. Da aber ein Kunde auf 
Skype besteht, kann ich sowieso nicht darauf verzichten.....

Falk

von Rolf W. (rowue)


Lesenswert?

Karl schrieb:
> Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder
> schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde, kann
> man dann zuverlässig (über alle Geräte/Toleranzen/Temperaturen) sagen in
> welcher Reihenfolge die Samples anliegen und ob alle Bits richtig sind?
> Meinem Verständnis nach eher nicht, weil es nicht definiert ist, was ein
> FF macht oder wann es das macht, wenn die SU oder Hold Zeiten verletzt
> werden.

Ich hoffe nicht, dass die Entwickler dieses Gerätes solch schwerwiegende
Fehler gemacht haben ....
>
> Wer seine Hardware ein bischen quälen will: Durch hohe Spannung oder
> tiefe Temperaturen verkürzen sich die Gatterlaufzeiten. Also zückt das
> Kältespray ;-D.

Wieso Kältespray? N2, liq.

>
> [...]

von branadic (Gast)


Lesenswert?

Nabend zusammen,

mal noch as anderes:
In der Timebase 2ns/div sehe ich 25 Pixel, erwarten würde man 24, in der 
Timebase 5ns/div zähle ich 67  Pixel, erwarten würde man 60. Noch weiter 
zählen tu ich mir lieber nicht an.

Muss das so sein?

Beste Grüße, branadic

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Karl,

> Gibt es eine Möglichkeit, die 25 MHz Referenz durch 20 MHz oder so zu
> ersetzen? Dann hätte man halt ein 800 MSPS Scope. Wenn es damit gut ist,
> wäre zumindest der Fehler gefunden und als Lösung hilft nur noch ein
> neues FPGA Design.

Je mehr ich über diesen Vorschlag nachdenke, umso besser gefällt er mir.
Was kann schlimmstenfalls beim Austausch des Quarze 25MHz gegen einen 
mit 20MHz passieren?
Die RS232 wird nicht mehr funktionieren, sämtliche auf die Zeitbasis von 
25MHz ausgerichteten Vorgänge laufen langsamer (TB am Oszi stimmt nicht 
mehr etc.). Wenn es dumm läuft, wird der TFT außerhalb seiner 
Spezifikation betrieben und bleibt schwarz. (Halte ich eher für 
unwahrscheinlich)

Verwendet wird als Zeitbasis übrigens ein QO 25,00MHz SMD 3,3V 7x5 
Quarzoszillators (oder gleichwertig)- wer den Austausch wagt, darauf 
achten das er ebenfalls einen mit 3,3V erwischt! (Bei mir ist keiner in 
der Bastelkiste, schade!)
Der Austausch an und für sich sollte problemlos sein.

Gruß, brunowe
(P.S.: gehört ja fast schon in den HW Thread)

von Messtechniker (Gast)


Lesenswert?

Das ist ja interessant: die Idee, den Quarz gegen 20MHz auszutauschen, 
hatte ich in einem Gedankeblitz heute morgen auch,

aber aus anderem Grund:
Kann man an die 4*8 Ausgänge der ADCs Leitungen anbringen? dann könnten 
wir einen LogicPort LA1034 dort anschließen.

Der kann mit max. 200 (10 x 20^^^) MHz extern getaktet werden. Dann 
wüssten wir endlich, was hier wirklich gespielt wird.

Oder über einen gemeinsamen Taktgeber synchronisieren (wer weiß, welcher 
Quarz im LA steckt?)


Ich kann es gar nicht mit ansehen, wie hier Kapital brachliegt:
der eine hat keinen vernünftigen Generator, der andere hat sein Oszi in 
der Reparatur.
Deshalb möchte ich ebenfalls (m)einen Beitrag leisten und Fehlendes zur 
Verfügung stellen, z.B. einen LA1034, ein

weiteres W20xx oder einen Generator (müsste ich erst besorgen).
Wo besteht Bedarf?

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo und guten Abend,

ich wollte heute mal herausfinden, was ich auf dem Bildschirm am Oszi 
sehen kann und was dagegen tatsächlich im Speicher liegt.
Dazu habe ich ein 61kHz Sinussignal mit 500MS/s hergenommen und das mal 
mit zu kleiner Spannungsbasis (50mV/div, Tastkopf 1:1) aufgenommen. Dann 
als Bild exportiert und einmal als CSV-Datei.
Hier seht ihr, was auf dem Bildschirm vom Oszi angezeigt wird.

Gleich geht's weiter...

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

... weiter geht es.
Tatsächlich schauen die exportierten Daten aus dem Speicher??? anders 
aus, nämlich so...

Beste Grüße, branadic

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> ... weiter geht es.
> Tatsächlich schauen die exportierten Daten aus dem Speicher??? anders
> aus, nämlich so...

Und? Die meisten Bildschirme/Grafikkarten haben Ihren 
Koordinatenursprung
Oben-Links und zählen (leider) die Y-Achse positiv runter.
(An der X-Achse gespiegelte kart. Koordinaten) - Dein Plot-Programm
verwendet (wie fast alle mir bekannten Plot-Programme) das
kartesische Koordinaten-System wie wir es kennen ;)

Kann man in der Bildschirmausgabe sicher anpassen - kostet aber
Rechen-Zeit ....
>
> Beste Grüße, branadic


Grüße,


   rowue

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Karl schrieb:
> Mal was anderes. Wenn wirklich beim Übergang der Taktdomänen oder
> schlimmer noch: Beim Timing der 250 MHz Domäne Mist gebaut wurde,

Ich habe eine andere Theorie: Das passt alles ganz prima, aber:
Die Muster, die man zu erkennen glaubt, sind meistens 4 Perioden lang, 
manchmal aber auch länger!
Ich habe mal ein Spektrum des CSV-Dumps der Rohdaten gemacht. Signal war 
ein 5MHz Sinus mit ein paar Oberwellen. Die sieht man auch ganz prima.

Aber da ist auch noch ein Signal bei 89MHz. Und jeweils +/-5, +/-10 und 
+/-15 MHz.
Ich bin sicher, daß 89MHz ein UKW-Rundfunksender ist und die Signale 
daneben die Mischprodukte mit dem 5MHz Signal.

Wenn das Timing der ADCs so unsauber wäre, wie befürchtet, würden wir 
dann so ein prima Spektrum bekommen?

Just my2¢,
Falk

von Karl (Gast)


Lesenswert?

Ich glaube nicht, dass man exakt sagen kann wie sich ein schlechtes 
Timing auswirkt. Ist auch nur eine Vermutung und nachdem ich selbst 
keins von den Dingern hab, der Vorschlag den Quarz zu tauschen.

Das mit dem UKW Sender und den Mischprodukten seh ich ein, aber hat der 
auch die nötige Amplitude und Frequenz (4 oder 8 samples)? Ich glaube 
nicht. Mach mal n Bild wo die Amplitude des 5 MHz Signals dargestellt 
wird.

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Karl schrieb:

> Das mit dem UKW Sender und den Mischprodukten seh ich ein, aber hat der
> auch die nötige Amplitude und Frequenz (4 oder 8 samples)? Ich glaube
> nicht. Mach mal n Bild wo die Amplitude des 5 MHz Signals dargestellt
> wird.

Bittschön.

Falk

von Karl (Gast)


Lesenswert?

Danke :) Ist das Spannung oder Leistung? Egal. Wörst Käjs (TM) schätze 
ich immer noch 30 dB Abstand raus. Das wird von den ADCs doch schon 
garnicht mehr richtig aufgelöst und erklärt leider die Zacken nicht.

Was ich auch noch interessant finde: Clockjitter und nicht idealer 
Abgleich ist super bei 250 MHz zu sehen. Nur so am Rande.

Was mich auf die nächste Idee bringt: Irgendjemand hat doch mal einen 
Pin an den ADCs erwähnt, mit dem man signed/unsigned umschalten kann. Da 
das Problem gern bei hohen Frequenzen UND hohen Pegeln auftritt, 
vielleicht spricht da was über. Könnte man den nicht relativ niederohmig 
auf den richtigen Pegel ziehen?

von Cra Z. (crazor)


Lesenswert?

Karl schrieb:
> Wörst Käjs (TM)

Wurst-Käse? SCNR =)

Wegen der SVN-Plugins nochmal die Rückmeldung: Man kann jetzt zwar die 
trac.ini per Admin-Interface bearbeiten, aber mit Plugins ist leider 
momentan noch nix. Ist aber auch verständlich, dass die Jungs bei SF.net 
nicht wollen, dass auf den Servern, auf denen Hunderte von 
Trac-Installationen laufen, beliebiger Code ausgeführt werden kann.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Da die Ladezeiten in diesen Thread unerträglich geworden sind und dieses 
Forum grundsätzlich keine geeignete Thread-Hierarchie ermöglicht, habe 
ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:

https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=3&t=18

Ich werde auch immer mal wieder im IRC (irc.freenode.net, #welec) sein 
und gelegentlich, wenn ich viel Zeit habe ;-) hier hineinschauen.

Gruß,
Falk

von Michael (Gast)


Lesenswert?

Wie ist denn das Passwort für obigen Link?
Muss man sich bei sourceforge anmelden, um die Beiträge zu lesen?

Thx!

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Michael schrieb:
> Wie ist denn das Passwort für obigen Link?

Ups, das ist der für angemeldete Leser, der hier sollte das Lesen 
erlauben: 
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=3&t=18

> Muss man sich bei sourceforge anmelden, um die Beiträge zu lesen?

Nein nur zum Schreiben. Email-Adresse reicht. Ich habe für solche Zwecke 
Spezialadressen, falls darüber doch mal Spam kommt. Die gibt's an jeder 
Ecke kostenlos.

Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Heute um 21:00 MESZ werden sich Daniel und ich im IRC (irc.freenode.net, 
#welec) über den von ihm vorgeschlagenen Auto-Updater unterhalten.

Mitdiskutanten sind willkommen.

Falk

von Jürgen (Gast)


Lesenswert?

Das wäre dann ungefähr der 5.Updater! Und auch noch "Auto"!
Den brauchen wir ganz dringend.
Viel Spaß!

Jürgen

von Roberto (Gast)


Lesenswert?

Hallo
>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:
Ohje.. :-(
Das wird die Leser und Schreiber reduzieren ... :-(
Beim Antworten im neuen Forum verlangt er ein Passwort :-(
Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben 
und den Thread vielleicht durchnummerieren...
Nach ca. 100 Beiträgen eine neue Thread-Nummer.

l.G. Roberto

von Rolf W. (rowue)


Lesenswert?

Roberto schrieb:
> Hallo
>>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:
> Ohje.. :-(
> Das wird die Leser und Schreiber reduzieren ... :-(
> Beim Antworten im neuen Forum verlangt er ein Passwort :-(
> Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben
> und den Thread vielleicht durchnummerieren...
> Nach ca. 100 Beiträgen eine neue Thread-Nummer.

Mein Vorschlag wäre, dass wir für Fehler/Auffälligkeiten eher
das Ticket-System nutzen (wobei wir dann auch Leute brauchen,
die sich um die Tickets kümmern). Damit werden Informationen
dann themenbezogen gesammelt (auch wenn dabei Infos "verloren"
gehen können (da muss dann die "Informationswiederbeschaffung"
ran ;)

>
> l.G. Roberto


Grüße,

   rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Roberto schrieb:
> Hallo
>>ich einen deutschsprachigen Thread zum Thema PC-Software hier eröffnet:

> Beim Antworten im neuen Forum verlangt er ein Passwort :-(

Meine Güte, dann melde Dich doch da an.

> Ich würde eher vorschlagen, auf den Mikrocontroller-Seiten zu bleiben
> und den Thread vielleicht durchnummerieren...
> Nach ca. 100 Beiträgen eine neue Thread-Nummer.

Warum sollen wir das so furchtbar kompliziert machen, wenn es eine 
saubere Lösung gibt?

Falk
P.S.: http://sourceforge.net/projects/welecw2000a/files/

von Roberto (Gast)


Lesenswert?

Vielleicht kann Roberto nur den Sinn einer Anmeldung nicht erkennen?

l.G.

von Guido (Gast)


Lesenswert?

>Vielleicht kann Roberto nur den Sinn einer Anmeldung nicht erkennen?

Sehe ich auch so: Wir haben hier eine wunderbare Plattform um unsere
Gedanken auszutauschen. Mit mehr Plattformen kommen keine weitere
Ideen dazu. Das einzige Argument gegen diesen Thread ist der Nachteil
für Leute die neu dazukommen. Da müsste mal jemand einen Artikel im
Wiki anfangen.

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

> Wir haben hier eine wunderbare Plattform um unsere Gedanken auszutauschen.

Also bitte, wo ist den das ein gutes Forum?

Ein paar Vorteile von SF?
- Ziemlich uneingeschränkte Verwaltungsmöglichkeiten sämtlicher Foren 
und Threads.
- Fast uneingeschränkte Möglichkeiten des Up- und Downloads. (Also nicht 
nur eine Upload pro Post!)
- Suchfunktion, z.B. nur neue Threads/ nur neue Posts anzeigen usw.
- Keine im NET verstreuten Quellen für VHDL FW PC Software/ Sourcen und 
Foren/ Diskussion.
- Integriertes Wiki und Ticketsystem mit vielfältiger Adminmöglichkeit, 
Möglichkeit der Mailinglist.
- Internationale Bekanntheit von SF, internationale Leserschaft.
- Eigener Projektbereich nur für Welec Belange (Hier im Forum gehen die 
Beiträge in der Masse unter)
- Spamfilter bei SF...

Ich hab ja keine Ahnung was ihr alle für Geheimnisse habt, das ihr euch 
so gegen eine Anmeldung bei SF sträubt, dazu reicht die Angabe einer 
Email-Adr. Auf jeden Fall hab ich von dort noch nie eine Spam- Nachricht 
erhalten. Ich bevorzuge es, wenn ich weiß mit welchen Leuten im Projekt 
ich es zu tun habe und diese ggf. kurzfristig per Email erreichen kann. 
Auch gibt es dann keine Verwirrung mehr mit drei gleichen (nicht 
angemeldeten Michaels, Alexanders, Daniels...) so wie in diesem Forum.

Gruß, brunowe

P.S.
Die eigentlichen Absprachen, Tests etc. sollten sowieso mittels Skype, 
ICQ oder einem ähnlichen Medium durchgeführt werden. Die Response- 
Zeiten in einem Forum sind dazu einfach unbrauchbar!

von Falk W. (dl3daz) Benutzerseite


Lesenswert?


von Rolf W. (rowue)


Lesenswert?

Falk Willberg schrieb:
> Roberto schrieb:
>> Hallo
>>>[...]
>
> Falk
> P.S.: http://sourceforge.net/projects/welecw2000a/files/


Hi Falk,

   hast Du Lust, den Stand einmal in "tags" zu kopieren? ;)


Grüße,

   rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Rolf Würdemann schrieb:
> Falk Willberg schrieb:
>> Roberto schrieb:
>>> Hallo
>>>>[...]
>>
>> Falk
>> P.S.: http://sourceforge.net/projects/welecw2000a/files/
>
>
> Hi Falk,
>
>    hast Du Lust, den Stand einmal in "tags" zu kopieren? ;)

Wie macht man das am Besten mit den Kommandozeilentools?

Falk
P.S.: Da die w2000a-screenshot.exe immer einen Blindflug für mich 
bedeutet, könnte die mal jemand kompilieren und testen, der Windows 
benutzt?

von Rolf W. (rowue)


Lesenswert?

Falk Willberg schrieb:
> Rolf Würdemann schrieb:
>> Falk Willberg schrieb:
>>> Roberto schrieb:
>>>> Hallo
>>>>>[...]
>>>
>>> Falk
>>> P.S.: http://sourceforge.net/projects/welecw2000a/files/
>>
>>
>> Hi Falk,
>>
>>    hast Du Lust, den Stand einmal in "tags" zu kopieren? ;)
>
> Wie macht man das am Besten mit den Kommandozeilentools?

   svn cp QUELLE ZIEL

   also:


   svn cp \
      https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/trunk 
\
      https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/tags/TAGNAME

(Die Pfade sind etwas lang)
>
> Falk

Grüße,

   rowue
> [w200a-screenshot]
Nix Windows here

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Wie sieht es mit einer Integration in Matlab/Octave aus? Anfänge sind 
gemacht.

Wie sollen die CSV-Daten ausgegeben werden? Gefiltert oder roh?

Siehe 
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?uid=86&f=3&t=19&start=0

Gruß,
Falk

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen, hallo Falk,

ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit 
dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit 
einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.

Auffällig ist, dass ein 17 MHz-Signal noch gut ausschaut, bei etwa 18 
MHz beginnen die ersten Ausreißer, um dann bei noch höheren 
Signalfrequenzen in Datenfasching auszuarten.

Der Export der vermeintlichen Roh-Daten ist keiner, zumindest nicht laut 
den bisher von mir ausgewerteten Signalen.
Hab extra jedes Signal einmal mit dem Parameter -d und einmal mit dem 
Parameter -t exportiert.
Warum ist erklär ich mir wie folgt, auch wenn ich nicht so tief in der 
Hardware des Gerätes drinstecke.
Das Programm ließt den Speicherinhalt aus. Da aber nur einmal 16k pro 
Kanal vorhanden sind, müssen die korrigierten Daten folglich wieder in 
denselben Speicher geschrieben werden.
Das heißt, es braucht, um Aussagen treffen zu können was mit den Daten 
geschieht, eine Firmware Version, bei der die Rohdaten von Kanal 1 
meinetwegen im Speicher von Kanal 1 abgelegt werden und die korrigierten 
Daten im Speicher von Kanal 2.

Was sich aber anhand der Bilder abzeichnet ist, dass aus irgendeinem 
Grund noch Fragmente im Speicher liegen, die zu den Lötzinn führt, den 
man auf dem Bildschirm sehen kann.
Ich demonstriere das mal an obigem Bild mit Messungen von heute:
Man sieht der Reihenfolge die ersten 256 Werte aus dem Speicher eines 
10MHz, eines 20MHz, eines 30MHz und eines 40MHz-Signales.

Beim 10MHz-Signal erkennt man leichte Treppenstufen, schon beim 
20MHz-Signal jedoch erkennt man irgendwelche Datenfragmente. Das könnten 
sein:

- Reste von vorherigen Aquisitions?
- Fehler aufgrund falsch überschriebenem Speicherinhalts?
- Fragmente, die aufgrund des Triggers entstehen?

Jedenfalls werden diese bei 30MHz und 40MHz stärker, bis irgendwann, mit 
zunehmender Signalfrequenz, nur noch Lötzinn im Speicher steht.

Wo dieser Datenmüll entsteht, kann ich daher leider mit meinen Messungen 
momentan nicht sagen, weil ich die Rohdaten aus dem ADC eben leider doch 
nicht anschauen kann.
Daher wäre eine modifizierte FW mit den oben aufgeführten Änderungen 
äußerst wünschenswert, damit wir die Ursache ein für allemal festnageln 
können.

Ich hoffe ein wenig zur Aufklärung beigetragen haben zu können.

von Martin H. (martinh)


Lesenswert?

Hallo baranadic,

Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das 
ist ist sehr schwer zu sagen) ist es leider nicht moeglich die 
eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k 
Speicher der schon die fehlerhaften Daten enthaelt.(wenn du die pseudo 
Rohdaten sehen willst empfehle ich dir meine TomCat.ram von 29.07.2009 
16:32 wo du mit dem Test-switch 1 (SHIFT-S) zwischen "Rohdaten" und vor 
verarbeiteten Daten umschalten kannst.

Martin

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Hallo baranadic,
>
> Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das
> ist ist sehr schwer zu sagen) ist es leider nicht moeglich die
> eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k
> Speicher der schon die fehlerhaften Daten enthaelt.

Jein: 
http://sourceforge.net/apps/trac/welecw2000a/wiki/ADC-FIFO-from-Firmware

Falk

von Michael K. (manhunt)


Lesenswert?

Hallo

Ich hätte mal ne Frage/Bitte vielleicht könnte ja mal jemand der hier
noch Überblick hat den Thread in nem Wiki Artikel zusammen fassen? (So 
wie zb beim miniLA

lg Michael

von Martin H. (martinh)


Lesenswert?

Falk Willberg schrieb:
> Martin H. schrieb:
>> Hallo baranadic,
>>
>> Mit dem FPGA Design, das ganz offensichtlich was falsch macht (was das
>> ist ist sehr schwer zu sagen) ist es leider nicht moeglich die
>> eigentlichen ADC daten auszulesen. Die SW hat nur Zugriff auf einen 16k
>> Speicher der schon die fehlerhaften Daten enthaelt.
>
> Jein:
> http://sourceforge.net/apps/trac/welecw2000a/wiki/ADC-FIFO-from-Firmware
>
> Falk
Das ist genau das was ich meine, meine test SW gibt den "roh" 
ausgelesenen Buffer ohne nach Verarbeitung aus (als ausgelesen mit der 
Funktion aus dem wiki). Leider enthalten diese Daten auch schon die 
Fehler, daher bleibt nur das FPGA Design als Fehlerquelle uebrig.

Martin

von branadic (Gast)


Lesenswert?

Hallo Martin,

mit welcher Screenshot-Version lassen sich die Daten aus dem Speicher 
exportieren? Weißt du das zufällig?

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

Vielleicht hier noch einmal der Hinweis an alle... es handelt sich bei 
dem Softcore um einen NIOS I und nicht wie weitläufig angenommen um 
einen NIOS II.
Diese Aussage ist auch nicht aus der Luft gegriffen, sondern stammt von 
Altera selbst aus dem Telefongespräch, das ich wegen der Offenlegung der 
Sourcen hatte.

Beste Grüße, branadic

von Martin H. (martinh)


Lesenswert?

@branadic

Das war Revison 173 aus dem SVN, wenn ich mich richtig erinnere. Wenn du 
unter Windows arbeitest sollte das exe aus meinem post vom  27.07.2009 
16:36 gehen.

Martin

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Martin,

vielen Dank.
Ich habe die Datei jetzt mal eingespielt und spiele gerade damit ein 
wenig. Dabei ist mir aufgefallen, dass der Triggerzeitpunkt auch bei 
10MHz zu stimmen scheint, sobald man auf Rohdaten umschaltet.
Aktiviert man die Korrektur, dann wandert der Triggerpunkt plötzlich weg 
und stimmt nicht mehr. Vielleicht ist das für die FW-Leute ein wichtiger 
Hinweis?

Leider stehen mir hier daheim nur Signale bis 10MHz aus einem 
bescheidenen DDS-10 von ELV zur Verfügung. Aber ich geb dir in sofern 
recht, dass der Datenquark am Anfang des Speichers auch hier zu sehen 
ist, möglicherweise ein erster Hinweis darauf, dass den Daten bei 
höheren Frequenzen das gleiche Schicksal ereilen wird und es wirklich 
ein Problem im FPGA-Design ist.

Anbei mal ein Bild, nicht das ihr noch auf Entzug geratet :)
Zu sehen ist ein 10MHz-Sinussignal aus dem DDS-10. Wiederum direkt mit 
50-Ohm-Kabel und Abschlusswiderstand direkt ans Oszi.
Oben in blau dargestellt die Rohdaten, grün entsprechend ein Shot mit 
den Korrekturwerten. Unten hab ich dann mal die korrigierten Daten 
gespiegelt, damit man einen besseren Vergleich hat.

Was mir noch etwas unverständlich ist, warum dieser Effekt des 
Daten-faschings im Speicher frequenzabhängig ist. Ich würde es 
verstehen, wenn das sampleratenbhängig wäre, aber diese 
Frequenzabhängigkeit hinterblicke ich nicht bzw. kann keinen rechten 
Zusammenhang mit dem FPGA-Design herstellen. Denn bei 1GS/s und einem 
100kHz-Signal würde man auch Ausreißer erwarten. In meinem Messungen von 
100kHz - 200MHz (logarithmisch aufgenommen) kann man das aber nicht 
sehen.

Wer die Daten selbst einmal analysieren möchte, dem stelle ich gerne die 
Daten im CSV-Format zur Verfügung.

Beste Grüße, branadic

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Eben released, siehe SF.net, changelog, README für Details.
Die DOS-Version w2000a-screenshot.exe ist wie immer ungetestet.

Forum: http://sourceforge.net/apps/phpbb/welecw2000a/
Project Homepage: http://sourceforge.net/projects/welecw2000a/
IRC: #welec bei orc.freenode.org

Gruß,
Falk

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo und guten Abend,

für all diejenigen die nicht die Möglichkeit haben beliebige Frequenzen 
zu erzeugen und am Oszi zu messen, hier mal ein logarithmisch 
aufgenommener Frequenzgang mit dem DSO und der FW 0.89.
Man sieht was im Speicher an Daten liegt und das zwischen 10 und 20 MHz 
irgendwas passiert.
Signal war der berühmte Sinus mit 1V Amplitude. Eigentliches Ziel der 
Messung war es, den Frequenzgang des Gerätes in Erfahrung zu bringen, um 
die Eingangsstufe bewerten zu können. Wie ihr selbst sehen könnt ist 
dieser so überhaupt nicht bestimmbar.
Große Hoffnung setze ich nun in das neue FPGA-Design. Ich werd mal 
schauen, dass ich die Version finde, wo zumindest die Signaldarstellung 
funktioniert hat und die ADC-Werte als Bit pro Pixel angezeigt worden. 
Vielleicht lässt sich der Frequenzgang damit zumindest einmal 
abschätzen.

Beste Grüße, branadic

von Rolf W. (rowue)


Angehängte Dateien:

Lesenswert?

branadic schrieb:
> Hallo zusammen, hallo Falk,
>
> ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit
> dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit
> einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.

Hi Branadic,

Obige Messung zeigt:

1Vpp, 10MHz (schwarz), 20MHz(rot), die geringere Amplitude bei
20MHz ist auf den FG (Grundig FG100) zurückzuführen. Die Legende
habe ich aus Versehen (Rufbereitschaft, von sechs Nächten zwei
durchgeschlafen) gelöscht. Gemessen wurde über ein T-Stück an
dem mit 50 Ohm abgeschlossenen Ausgang. Tastkopfeinstellung: 10/1

Der von Dir vorgetragene Effekt ("Datenmüll", 10_20_30_40_MHz)
wird mit dieser Messung widerlegt.

Verwendet wurde ein W2014A, HW: 8C7.E3, FW: Bf.0.87

>
> [...]

Grüße,

   rowue

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Falk Willberg schrieb:
> Eben released, siehe SF.net, changelog, README für Details.
> Die DOS-Version w2000a-screenshot.exe ist wie immer ungetestet.

Da Sourceforge Probleme zu haben scheint, hier meine lokale Kopie:
http://falk-willberg.de/tmp/1.2-OS-0.90/

Forum: http://sourceforge.net/apps/phpbb/welecw2000a/
Project Homepage: http://sourceforge.net/projects/welecw2000a/
IRC: #welec bei orc.freenode.org

Gruß,
Falk

von branadic (Gast)


Lesenswert?

Hallo Rolf,

>Der von Dir vorgetragene Effekt ("Datenmüll", 10_20_30_40_MHz)
>wird mit dieser Messung widerlegt.

herzlichen Glückwunsch, bei deinem Gerät scheint bis 20MHz noch was 
brauchbares im Speicher zu stehen (ersten Quatsch sieht man übrigens 
auch innerhalb der ersten 100 Werte bei dir).

Das der von mir "vorgetragene Effekt" mit dieser Messung "widerlegt" ist 
glaube ich nicht. Man könnte fast meinen du willst mir unterstellen, 
dass ich nicht in der Lage wäre ein Signal in das Welec zu bekommen und 
anschließend darzustellen??? Ich stelle hier schließlich keine wilden 
Theorien auf, sondern warte mit Messungen auf. Wenn das unerwünscht ist, 
dann darfst du das gern kundtun.

Nur weil bei dir und einem 20MHz-Sinussignal (Ein Sinus ist aber schon 
was anderes als das was man da sieht, meinst du nicht auch?) der Effekt 
nicht zu beobachten ist heißt das nicht, dass dies auf alle Geräte 
zutrifft und meine Messungen Quatsch sind. Das lässt eher vermuten, dass 
wir es hier mit einem Timingproblem innerhalb des FPGA-Designs zu tun 
haben und du einen besseren FPGA vom Timing her in deinem Gerät zu haben 
scheinst.

Das Problem mit dem Timing und der Timingunterschiede von Gerät zu Gerät 
ist uns schon zu Beginn der Entwicklung des neuen FPGA-Designs 
aufgefallen. Crazor scheint nämlich auch einen besseren FPGA in seinem 
Gerät zuhaben. Während bei ihm das Design bereits lief hatten Bruno und 
ich noch schwarze Bildschirme aufgrund der Timingprobleme im Design. 
Mittlerweile sind diese Timingprobleme jedoch behoben.

Wie man sieht ist es notwendig noch mehr Messungen gegenüber zu stellen 
und miteinander zu vergleichen. Voreilige Schlüsse bringen keinem was, 
dazu brauchen wir einfach mehr Vergleiche anderer Welec-Besitzer.

Daher die Bitte an alle: Leute, es gibt mittlerweile die 
Screenshotfunktion. Seid doch so nett und exportiert die Daten eines 
höherfrequenten, mit 1GS/s aufgenommenen Sinussignales einfach mal in 
ein CSV-File und schaut euch die Signale mit Excel oder sonst was an und 
lasst uns wissen, ob ähnliche Effekte auch bei euch zu sehen sind oder 
nicht.

W2014A    HW: 8C7.00  FW: OS.0.89beta

Beste Grüße, branadic

von branadic (Gast)


Lesenswert?

Hallo Leute,

der Falk hat von einem meiner Datensätze mal ein Video zusammengestellt, 
wo Signal im Speicher und zugehörige FFT zu sehen sind.
Sieht echt spektakulär aus und verdeutlicht noch einmal, was ich mit dem 
bisher Geschriebenen meinte...

http://www.falk-willberg.de/tmp/FFT.mpeg

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

schön anzusehen, aber ich verstehe trotzdem nicht mehr :-( .
In deinen Daten ist auch der Schwebungseffekt zu sehen. Nimm
mal einen Satz um 60 MHz und schau dir nur jeden 4. Wert an,
dann müsstest du ihn besser sehen.

Gruß, Guido

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Guido,

selbst wenn ich mir jeden 4. Wert anschauen kommt nur unbrauchbarer 
Zickzack heraus.

@ Rolf und alle anderen,

ich habe vorhin noch einmal Messungen gemacht und die ersten Ergebnisse 
möchte ich euch nicht vorenthalten. Hier mal die Kurzmessung.

Die Frage war, ist es möglich auch hohe Frequenzen mit dem Welec zu 
messen. Die Antwort darauf lautet: Ja, vorrausgesetzt der Signalpegel 
des hochfrequenten Signales übersteigt eine bestimmte Schwelle nicht. 
Bruno hatte das seinerzeit ja schon mal anhand eines Oszillators im 
Video gezeigt. Ich möchte diese Aussage mit zwei Bildern belegen.

Signalquelle war wieder der Signalgenerator von Rhode & Schwarz. Als 
Amplitude habe ich 15mV eingestellt und mal ein 50MHz Signal in den 
Spannungsbasen 10mV/div, 20mV/div und 50mV/div aufgezeichnet und die 
Daten exportiert.
Ihr seht die ersten 512 Samples aus dem Speicher.

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Die zweite Aufnahme hier zeigt nun ein 100MHz Sinussignal, wieder mit 
den 3 Spannungsbasen 10mV/div, 20mV/div und 50mV/div.

In weiteren Messungen, die ich aber erst noch komplett auswerten will, 
habe ich mit noch kleinerer Signalamplitude gemessen und bin den 
Frequenzbereich von 100kHz bis 200MHz hochgegangen und habe zudem die 
Messungen sowohl auf Kanal 1 als auch auf Kanal 2 durchgeführt. Sobald 
ich die Ergebnisse habe, werde ich darüber mehr berichten.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

soweit ist das ja nichts neues. Brauchst du noch Messdaten? Bei
kleienr Amplitude kann ich die liefern. Interessant ist die
Produktbildung mit Mischfrequenzen ab ca. 60 MHz. Erklären kann
ich mir das aber immer noch nicht.

Mit kleiner Auflösung zu messen ist imho o.k., da sonst die Probleme
mit den Videoverstärkern hinzukommen. Das könnte man mit meinem 2012
im Vergleich zu einem anderen Geräten untersuchen, da bei mir im
Kanal 1 ja die 22-Ohm-Widerstände drin sind, die schon einen
Unterschied machen.

Also, wenn du Messdaten brauchst, melde dich.

Gruß, Guido

von Thomas (kosmos)


Lesenswert?

könnte es ein Problem des Verstärkerkreises sein, da es anscheinend 
abhängig vom Verstärkungsfaktor ist?

Wie bist du überhaupt auf dieses Problem gestoßen, welcher Sensor 
liefert ein so niedriges Ausgangssignal. Evtl. Piezos?

von branadic (Gast)


Lesenswert?

Hallo Guido,

verschon mich bitte mit Messdaten, ich habe hier noch 6x 38 Dateien, die 
ausgewertet wollen. :)
Kannst du nicht mit einem geeigneten Programm (bspw. QTOctave) selbst 
die Auswertung durchführen?

@ Thomas,

denkbar, Bruno hatte ja schon Messungen durchgeführt, konnte aber nichts 
auffälliges feststellen. Ich werde diese Messungen bei Gelegenheit 
wiederholen.
Es geht auch nicht darum, dass irgendein Sensor ein derartiges Signal 
liefern soll, sondern es geht darum, dass man bspw. nicht in der Lage 
ist, ein 1Vpp Sinussignal von 100MHz mit den Spannungsbasen 1V/div, 
2V/div oder 5V/div in irgendeiner Form bei einem Gerät mit angegebenen 
100MHz Analogbandbreite vernünftig darzustellen. Jetzt stellt sich 
natürlich die Frage wieso nicht und genau dem gehe ich momentan nach.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

O.k. branadic,

natürlich kann ich das. Wenn ich nur eine Idee hätte. wonach ich suchen
soll. Falks FFT ist ist nicht uninteressant, aber ... naja, die
Abtastfrequenz kommt irgendwann ins Spiel. Warum?

Vielleicht sollten wir doch mal einen Tiefpass in die Software
aufnehmen. Der müsste aber bei höchstens 100 MHZ einsetzen und
würde viel Performance fressen.

Gruß, Guido

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Hallo Guido,
>
> selbst wenn ich mir jeden 4. Wert anschauen kommt nur unbrauchbarer
> Zickzack heraus.
>
> @ Rolf und alle anderen,
>
> ich habe vorhin noch einmal Messungen gemacht und die ersten Ergebnisse
> möchte ich euch nicht vorenthalten. Hier mal die Kurzmessung.
>
> [...]

Hi Branadic,

mir war später am Abend auch aufgefallen, dass das 10/20/40
Verhalten ziemlich nach einer Übersteuerung aussieht (und
es insofern in dieser Messung einen (extremen) Hochpass
geben muss).

Was evtl. helfen könnte: Mir war beim Spielen mit dem Kalibrier-
und anderen Rechtecksignalen aufgefallen, dass der Tastkopf (auch
wenn angepasst) in der 10/1 Stellung an den Flanken leicht
zum Überschwingen (z.T. mit "Nulldurchgängen") neigt.

Könnte ein Hinweis sein. Vielleicht sollten wir die Schaltung
mal "durchsimulieren".

Grüße,

       rowue

PS: "Überschwingungen" sieht man z.B. auch in den 50MHz-Samples
von Dir

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> [...]
>
> @ Rolf und alle anderen,
>
> [...]

Hi Branadic,

kurzer Nachtrag: Dein R&S kann doch sicher "vernünftig" pulsen.
Hast Du Lust mal einige, gerne auch niederfrequente, Pulsmessungen
zu machen, und die über 'ne FFT zu ziehen? - Könnte evtl. Aufschluss
über das Fequenzverhalten geben (Rechteck geht auch, aber Puls
ist besser ;)

Grüße,


       rowue

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Hallo zusammen, hallo Falk,
>
> ich habe heute noch mal Messungen am Rhode & Schwarz Signalgenerator mit
> dem DSO gemacht. Signalquelle war ein Sinus von 1V Amplitude direkt mit
> einem 50 Ohm-Kabel plus Abschlusswiderstand an das DSO gehängt.
>
> [...]

Hi Branadic,

magst Du mir evtl. den Gefallen tun, und in Deinem Messaufbau
mal das 50 Ohm Kabel gegen 'nen Tastkopf mit BNC-Adapter tauschen?

Ich habe eben etwas mit den Tastköpfen gespielt (6Vpp rein,
auf 500mV/Div, resp. 50mV/Div gestellt und übersteuert). Hierbei
zeigte sich, dass das System bei der 10/1 Einstellung deutlicher
zum Schwingen neigte, als bei der 1/1 Einstellung (geringere Dämpfung
im HF-Bereich).

(Gedanke aufschreib: kann es sein, dass da unter gewissen Umständen
irgenwas in der Eingangsstufe zum Schwingen angeregt wird und dann das 
Signal versaut?)

Falk: In "set_serial" in der w2000a-screenshot.cpp setzt Du in neueren
Versionen "termios.c_cc[VMIN]" auf 0. Damit bekomme (zumindest ich)
Ärger mit dem "Trace" Modues (wo er in der Schleife klebt, bis ich
den Knopf am Scope drücke). "Ärger" meint: das Programm läuft gerade
mal eine Sekunde.

Grüße,

   rowue

von Rolf W. (rowue)


Lesenswert?

Letzter Gedanke für heute:

Beide Signale zeigen für 50mV/Div annähernd die gleiche Amplitude
(btw: ~60mVpp). Bei dem 50MHz Signal zeigt sich eine nahezu phasenstarre
Verzerrung (Kante). (Bei 20mV/Div zeigt sich bei dem 50MHz-Signal eine
Amplitude von ca. 30mV, dass 100MHz Signal ist nicht mehr zu 
identifizieren.)

Mit der höheren Empfindlichkeit wird das System auch für Störungen
empfindlicher. Sagen wir: es gibt etwas hinter dem Verstärker 
(Trigger?),
was auf z.B. die Stromversorgung durchschlägt und somit in die
Eingangsschaltung "einstrahlt". Bei geringeren Verstärkungsfaktoren
(5V/Div, 2V/Div) wird diese Störung noch nicht so stark in's Gewicht
fallen. Bei höheren Verstärkungsfaktoren (50mV/Div, 10mV/Div) wird
diese Störung mitverstärkt und koppelt somit mit ihrer Erregung.
Unser Oszi fängt an zu schwingen und gerät (unter unschönen Umständen)
in die Resonanzkatastrophe (100MHz, 15mV).

Das, was mir dabei am wenigsten gefällt, ist, dass da per Software
wenig zu machen sein wird.

Was meint ihr dazu? Oder bin ich gerade zu wirr?

Grüße,

   rowue

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

die Gedanken drehen sich im Kreis! Als das hab ich schon vor Monaten 
untersucht und gepostet.
Rolf du bist hier noch nicht so lange dabei, aber sieh doch mal in den 
alten Posts, da findet sich auch eine komplette Simulation der Analog- 
Input-stufen welche ich in LTSpice erstellt habe.
Ich kann die sogar sagen welcher Baustein in der Verstärkerkette dieses 
ausgeprägte Hochpass- Charakter aufweist, der OPA 656. Auch zur Suche 
über evtl. Alternativen findet sich im HW Thread eine Diskussion. Nicht 
zuletzt sind auch schon Bemühungen von Walter und mir am Laufen, diese 
Eingangsstufe (speziell der OPA656, aber auch der OPA1177 tragen 
hauptsächlich zum Rauschen bei) zu ersetzen. DENNOCH- Mein Video mit 
unserem Neuen VHDL Design (s.h. Youtube) wiederlegt eindeutig das die 
analogen Stufen für dieses Phänomen verantwortlich sind.... Also bitte 
diese Diskussion nicht wieder von vorne.


Gruß, brunowe

von Rolf W. (rowue)


Lesenswert?

Bruno We schrieb:
> Hallo,
>
> die Gedanken drehen sich im Kreis! Als das hab ich schon vor Monaten
> untersucht und gepostet.
> [...]

Danke! - Jetzt ist einiges klarer ;) - (Rate mal, was ich heute
gemacht habe ;)

Habe da trotzdem noch die eine oder andere Frage. Sieht mensch
sich nachher im IRC?
>
>
> Gruß, brunowe

Grüße,

   rowue

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

entgegen der Meinung von Bruno (nimm es mir bitte nicht übel), vermute 
ich den Fehler nach Auswertung meiner Messdaten vom Freitag doch eher in 
der Analogstufe und nicht im VHDL.

Dafür sprechen gleich mehrere Gründe. Wer sich die Bilder oben anschaut 
sieht ein Sinussignal von 5.01mV Amplitude, aufgenommen in den 
Spannungsbasen 10mV/div (oberes Diagramm), 20mV/div (mittleres Diagramm) 
und 50mV/div (unteres Diagramm) mit 1GS/s. Dargestellt sind je 128 
Werte.
Bei 90MHz kann man auch bei der Einstellung 10mV/div noch einen Sinus 
erahnen, bei 100MHz treten bei der gewählten Amplitude massive Störungen 
auf.
Gleichzeitig kann man in den anderen beiden Einstellungen sehen, dass 
die Amplitude ansteigt.

Bei 180MHz scheinen diese Störungen wieder zu verschwinden und die 
Amplitude nimmt wieder ab.

Das Signal war hier DC gekoppelt an den Eingang gelegt. Ich werde morgen 
den Versuch noch einmal mit AC-Kopplung durchführen, erwarte hier jedoch 
das gleiche Ergebnis.

Welcher Unterschied besteht also gegenüber dem neuen VHDL und dem 
Welec-Design? Ich hab mich diesbezüglich beim Entwickler (crazor) schlau 
gemacht. Zum einen war bei dem Video von Bruno die AC/DC-Kopplung noch 
nicht geklärt, weiterhin die Verstärkungsfaktoren und als dritte 
momentan bekannte Möglichkeit könnte der DAC als Ursache in Frage 
kommen.

Es könnte also durchaus sein, dass im neuen VHDL irgendein 
Schaltungsteil der Analogstufe vom FPGA her nicht aktiv geschaltet oder 
anderweitig angesteuert wird, der im Welec-Design jedoch arbeitet und zu 
diesen massiven Störungen führt. Ziel ist es für mich daher 
herauszufinden, ob das so ist und wenn ja, welcher Teil dafür 
verantwortlich ist.

Daher werde ich das Design, welches dem Video zugrunde liegt, ebenfalls 
einspielen und den gleichen Versuch noch einmal durchführen, jedoch mit 
verschiedenen Frequenzen und Amplituden.

Die letzte Möglichkeit zur Klärung ist, hier habe ich mich mit Walter 
besprochen, die Messungen von Bruno noch einmal mit einem schnelleren 
Oszilloskop zu verifizieren und die Messungen mit beiden Designs, also 
dem original Welec-Design und dem neuen VHDL, durchzuführen.

@ Rolf

pulsen kann ich mit dem R&S leider nicht, dafür steht mir aber ein 
Funktionsgenerator zur Verfügung.
Du wirst aber verstehen, dass ich nicht alle Messungen gleichzeitig 
durchführen kann und da ich für nächste Woche Urlaub einlegen musste, 
kann dieser Test noch ein paar Tage dauern.

Beste Grüße, branadic

von Guido (Gast)


Lesenswert?

Hallo branadic,

wirklich sehr fleißig. Ich bin aber immer noch der Meinung,
dass beides zusammenkommt. Klar, die Eingangsstufe, genauer
der Übergang vom Videoverstärker auf die ADCs spinnt. Dies
macht sich erst mit stärker dargestellten Signalen bemerkbar
und ist in deinen Messungen klar zu erkennen. Ich empfehle
22-Ohm-Widerstände ;-). Ich muss mal noch einen Abschlußwiderstand
einlöten, habe im Moment aber nur wenig Zeit.

Aber das Spinnen ab 100 MHz (bei meinem 2012A schon früher) ist
damit kaum zu erklären. Da kommt noch was dazu, das ich bisher
überhaupt nicht kapiere. Denke an die Spiegelfrequenzen in Falks
FFTs, oder auch die Schwebung bei ganzzahligen Bruchteilen der
Abtastfrequenz.

Gruß, Guido

von Jürgen (Gast)


Lesenswert?

Hallo Guido,

> und ist in deinen Messungen klar zu erkennen. Ich empfehle
> 22-Ohm-Widerstände ;-). Ich muss mal noch einen Abschlußwiderstand
> einlöten, habe im Moment aber nur wenig Zeit.

welche Baugröße benötige ich für die Widerstände? Muß mal ein paar 
Widerstände bestellen.

Danke und Gruß
Jürgen

von Guido (Gast)


Lesenswert?

Hallo Jürgen,

passende Bauform für die Widerstände ist 0603. Für den Abschluss
habe ich noch nicht rausgefunden, wo man den anbringen könnte.

Gruß, Guido

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Guido schrieb:
> Hallo branadic,
>
> wirklich sehr fleißig. Ich bin aber immer noch der Meinung,
> dass beides zusammenkommt. Klar, die Eingangsstufe, genauer
> der Übergang vom Videoverstärker auf die ADCs spinnt.

Da bin ich nicht mehr sicher. Siehe Bild: 138MHz, 5Vpp 500mv/div.

IRC: #welec (irc.freenode.org)
Forum: http://sourceforge.net/apps/phpbb/welecw2000a/

von egberto (Gast)


Lesenswert?

hmm im Bild ist ein 138 kHz Signal zu sehen...


Hab ich das jetzt richtig verstanden (im englischen Forum) - du hast das 
Schwingungsproblem durch patchen eines ADC-Registers 
gelöst???!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Viele Grüße,

egberto

von Guido (Gast)


Lesenswert?

Hallo Falk,

> Da bin ich nicht mehr sicher. Siehe Bild: 138MHz, 5Vpp 500mv/div.

das sieht gut aus. Wie bist du darauf gekommen, das wirkt doch im
FPGA-Design? Mal ganz langsam: adc_change12_reg wird doch auf
0x0200000 gesetzt. Das änderst du in hardware_t.cpp in 0x0020000?

Gruß, Guido

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

SUPER ARBEIT FALK!
Ich hab mein Oszi eben bis 150Mhz durchgewobbelt.

Auch wenn wir nicht wissen was da geschieht, das sieht verdammt gut aus!

Es zeigt sich bei mir zwar noch eine HF Schwebung (hoffe das Blech kommt 
bald und hilft etwas!) und eine stark schwankende Amplitude über die 
Frequenz....
*******************************
ABER DIE OSZILLATIONEN SIND WEG!
*******************************
Selbstverständlich sind damit die Probleme der relativ stark rauschenden 
Eingangsstufen, sowie die schlechte Linearität nicht beseitigt, aber 
jetzt macht's wieder Spass zum Weiterentwickeln!

Gruß, brunowe

P.S.: Ich sag jetzt nicht, ich habs ja gleich gesagt!

von Odic (Gast)


Lesenswert?

Ich würde mich ja gerne mit euch freuen, kann aber gerade nicht so recht 
folgen.

(Wobei ich nicht ausschliessen möchte, dass es an mir liegt... ;-)  )

Kann mir mal jemand auf die Sprünge helfen?

Beste Grüße,
Odic

von Guido (Gast)


Lesenswert?

Hallo Odic,

geht mir genauso, die Angaben von Falk machen imho keinen
Sinn, die Unterschiede zu den Werten in der Firmware sind zu
groß.

Nach dem Kommentar im Quelltext könnte es sich um ein
zuschaltbares Filter im FPGA handeln, das Falk ausgeschaltet
hat. Wie er auf das Bitmuster gekommen ist? Ist für mich aber
gut nachvollziehbar, dass ein verunglücktes FIR-Filter Murks
macht.

Gruß, Guido

von Rolf W. (rowue)


Lesenswert?

Guido schrieb:
> Hallo Odic,
>
> geht mir genauso, die Angaben von Falk machen imho keinen
> Sinn, die Unterschiede zu den Werten in der Firmware sind zu
> groß.
>
> Nach dem Kommentar im Quelltext könnte es sich um ein
> zuschaltbares Filter im FPGA handeln, das Falk ausgeschaltet
> hat. Wie er auf das Bitmuster gekommen ist? Ist für mich aber
> gut nachvollziehbar, dass ein verunglücktes FIR-Filter Murks
> macht.

Lass die einfach versucht haben, einen Tiefpass einzubauen,
dass zu ggf. optimieren und dabei (vom Algorithmus her) Ein- und
Ausgang vertauscht haben. 'Nen FFT-Filter werden Wittig & Co.
dort nicht eingesetzt haben.

Mehr dazu dürfte im "DSP-Guide" (http://www.dspguide.com/)
zu finden sein ;)

>
> Gruß, Guido

Grüße,

    rowue

PS: Falk - hast Du das auch für die Kanäle 3&4 aktiviert?

von Guido (Gast)


Lesenswert?

So,

in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.
Glückwunsch Falk, das ist wohl ein Volltreffer.

Auf Kanal 1 ändert sich bei mir nichts. Wird doch nicht an den
22-Ohm-Widerständen liegen?

Gruß, Guido

von Rolf W. (rowue)


Lesenswert?

Guido schrieb:
> So,
>
> in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.
> Glückwunsch Falk, das ist wohl ein Volltreffer.

Beim mir (2014) sind Kanal 1&2 o.k. - auf 3&4 habe ich
Zacken und zum Teil Spikes - die muss ich mir aber noch mal
ansehen ...
>
> Auf Kanal 1 ändert sich bei mir nichts. Wird doch nicht an den
> 22-Ohm-Widerständen liegen?
>
> Gruß, Guido

Grüße,

   rowue

von Guido (Gast)


Lesenswert?

Hallo,

jetzt habe ich noch mal mit dem steilflankigen 20-MHz-Signal
probiert und genau die gegenüber früher umgekehrten Verhältnisse
erhalten. Bilder gibts leider keine weil screenshot in der
momentanen Version wohl nicht funktioniert.

Das wäre ja die Härte, wenn die Widerstände die Probleme im Design
verbessert hätten. Naja, zu Vergleichszwecken lasse ich sie mal
noch drin.

Mal grundsätzlich: würde sich nicht jemand der sich auskennt damit
anfreunden können den Saustall in SFN zu beaufsichtigen? Es gibt da
SVN-Versionen, die noch nicht mal durch den Kompiler laufen, das
tgz für Screenshot enthält nur ein Windows-Executable (sehr witzig)
.....

Gruß, Guido

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Guido,

die Screenshot aus der 0.90 läuft bei mir mit der 0.91 wunderbar. Auf 
Kanal 1 und 2 habe ich dieselben Ergebnisse, scheint also mit deinen 
Widerständen zusammen zu hängen.
Meiner Meinung nach ein weiterer Hinweis darauf, dass adc_change12_reg 
irgendwie auf die Analogstufe (Bruno, ich bleib dabei) wirkt und nicht 
im VHDL. Wo genau lässt sich aus dem bisherigen Schaltplan leider nicht 
entnehmen, dafür ist er doch noch zu undetailiert.
Ein falsch angeschlossenes FIR-Filter schließe ich aus, da der Effekt 
direkt auch mit dem Verstärkungsfaktor zusammenhängt und sich 
amplitudenabhängig verhält.

Ich habe heute mit der FW Messungen am Signalgenerator durchgeführt. Für 
die Auswertung der Daten werde ich mir ein wenig mehr Zeit nehmen, damit 
ich mal ein Gefühl für die Bandbreite des Welec bekomme. Mit der neuen 
FW, den ausbleibenden Schwingungen oder was immer das auch ist und den 
heutigen Messungen, könnte man erstmal den Frequenzgang versuchen zu 
quantifizieren.

Gibt es eigentlich irgendwo Info's darüber, inwieweit die 8bit ADC bei 
2V/div ausgesteuert werden, sodass man von der Auflösung auf die 
Amlitude schließen kann?

Oben dazu mal die Bilder, wie sich die Amplitude mit der neuen FW 
verhält. Signal war wieder 1.4V Amplitude (Ueffektiv).

Beste Grüße, branadic

von Rolf W. (rowue)


Lesenswert?

Rolf Würdemann schrieb:
> Guido schrieb:
>> So,
>>
>> in der SVN-Version kann ich es auf Kanal 2 nachvollziehen.
>> Glückwunsch Falk, das ist wohl ein Volltreffer.
>
> Beim mir (2014) sind Kanal 1&2 o.k. - auf 3&4 habe ich
> Zacken und zum Teil Spikes - die muss ich mir aber noch mal
> ansehen ...

Angesehen ...

Auf Kanal 4 bekomme ich "Schwinger" sobald ein Signal
(10 MHz Rechteck) anliegt, auf Kanal 3 kann ich sogar ohne
Signal durch die Einstellung des Null-Punktes Spikes provozieren.
Entweder hat mein Gerät eine Macke, oder es sind auf Kanal
3 und 4 noch weitere Filter aktiv - mag das mal jmd. testen? ;)

>>
>> [...]

@Branadic: Hatte gestern mal mit 200mV/Div 'ne Amplitude bis
jeweils ~+- 3Div gemessen: min:79, max: 181 - das würde
auf etwa 136 Bit als Aussteuerung hinweisen, sollten aber
eher ~200 sein ...

>>
>> Gruß, Guido
>
> Grüße,
>
>    rowue

Grüße,

   rowue

von Guido (Gast)


Lesenswert?

Hallo branadic,

afaik wird bei 2 V/div das Signal erst durch 100 geteilt und
anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal
0...400 mV bei einem Austeuerungsbereich des ADC von
0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und
164.

Jo Mann, das ist kompliziert. Falks Hack wirkt sich zumindest
auch auf die Hardwareeinstellung aus. Z.B. wird der BW-Switch
damit wirkungslos. Über 100 MHz steigt auch die Amplitude an,
das macht mein VCO sicher nicht so stark. Immerhin haben wir
einen weiteren Angriffspunkt, Ich werde morgen mal noch mit den
Schwebungen probieren.

Gruß, Guido

von Guido (Gast)


Lesenswert?

Oops,

wer misst misst Mist (habe ich doch schon mal gepostet ;-)).
Habe beim Ausschalten bemerkt, dass mit Falks Hack beide
Eingangskanäle schwingen. Habe also wohl garnicht das Signal
des VCO gemessen.

Morgen weiter ...

Gute Nacht, Guido

von Rolf W. (rowue)


Lesenswert?

Nachtrag: Kanal 4 bekomme ich jetzt auch ohne Eingangssignal zu "Spiken"
 (Null-Lage durch den Schirm fahren) (MIt Falks Patch)

Grüße,

  rowue

von Rolf W. (rowue)


Lesenswert?

Guido schrieb:
> Hallo branadic,
>
> afaik wird bei 2 V/div das Signal erst durch 100 geteilt und
> anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal
> 0...400 mV bei einem Austeuerungsbereich des ADC von
> 0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und
> 164.

Oder die Änderung/Erkenntniss wurde noch nicht umgesetzt,
dass sind wir bei: 2V/div, durch 100 geteilt und mit 2
multipliziert. -> 0-320mV -> [0:131]

Hätte aber auch den Nachteil, dass dann die Bandbreitenbegrenzung
beim OPA nicht aktiv ist.

>
> [...]
>
> Gruß, Guido

Grüße,

    rowue

von Rolf W. (rowue)


Lesenswert?

Moin/Nabend oder was auch immer ...

Ich habe in's Trac mal zwei Patches gestellt:

a) nen Bugfix für den "trace-mode" beim Screenshot (#27)
b) flashloader.sh (#28)

wäre nett, wenn die jmd. mal einpatchen und committen könnte
(kurze Anleitung findet sich in #27)

Bei Macports gibt es die Empfehlung/Ansage: Einen Commit/Punkt.
Fehler lassen sich so einfacher finden (Punkt kann hierbei sein:
Feature, Bugfix, Release, etc) - wäre auch meine Empfehlung an
dieser Stelle ;)

Grüße,

      rowue

PS: Eine Übersicht über offene Tickets:

http://sourceforge.net/apps/trac/welecw2000a/report/1

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Hallo Guido,
>
> [...]
> Ein falsch angeschlossenes FIR-Filter schließe ich aus, da der Effekt
> direkt auch mit dem Verstärkungsfaktor zusammenhängt und sich
> amplitudenabhängig verhält.
>

Naja, ich hatte da z.B. den Effekt, dass ich durch Umschalten
des Tastkopfes (und entsprechender Verstellung der Eingangsteilung)
von 10/1 auf 1/1 das damalige Verhalten "dämpfen" konnte, das
System also unempfindlicher gegen das Schwingen wurde.

Neben dem Umstand, dass ich den Eingangswiderstand durch
das Umschalten verringere, verringere ich auch die Bandbreite
und erhöhe die Anstiegszeit. Sprich: ich ziehe ihm die oberen
Fourier-Koeffizienten weg.

Diese können nun im Zusammenspiel mit dem OPA die Schaltung
zum Schwingen angeregt haben, oder jmd. hat versucht, dass
Verhalten des OPA per Software in den Griff zu bekommen und
hat sich dabei "in den Fuss" geschossen.


> Ich habe heute mit der FW Messungen am Signalgenerator durchgeführt. Für
> die Auswertung der Daten werde ich mir ein wenig mehr Zeit nehmen, damit
> ich mal ein Gefühl für die Bandbreite des Welec bekomme. Mit der neuen
> FW, den ausbleibenden Schwingungen oder was immer das auch ist und den
> heutigen Messungen, könnte man erstmal den Frequenzgang versuchen zu
> quantifizieren.

Wäre sehr gut ;)

>
> [...]

> Oben dazu mal die Bilder, wie sich die Amplitude mit der neuen FW
> verhält. Signal war wieder 1.4V Amplitude (Ueffektiv).
>

Hupps ....

> Beste Grüße, branadic


Grüße,

   rowue

von branadic (Gast)


Lesenswert?

Hallo Guido,

>afaik wird bei 2 V/div das Signal erst durch 100 geteilt und
>anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal
>0...400 mV bei einem Austeuerungsbereich des ADC von
>0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und
>164.

danke für deine Antwort. Aber wie mir scheint, gibt es in der FW eine 
Skalierungsstufe, die den reduzierten Aussteuerbereich der ADC wieder 
ausgleich soll?
Wie bin ich darauf gekommen: Ich habe ja die Messungen mit Falk's FW 
0.91 durchgeführt und die Daten abgespeichert. Nun wollte ich die 
Bit-Werte wieder zurück in eine Spannung rechnen.
Da 128 eigentlich NULL entspricht schiebt man die Daten erst einmal 
wieder um 128 runter:

Samplewert-128

Als Ergebnis hat man nun ein Signal, das zwischen -128 und 128. Wenn 
0.625V gerade 8bit entspricht (resp. -128 bis +128) würde man also über 
die einfache Verhätnisgleichung und anschließende Rückwärtsverstärkung 
auf die richtige Spannung bekommen müssen:

(Samplewert-128) *0.625V/256 *100/2.5

oder anders geschrieben:

(Samplewert-128) *0.3125V/128 *100/2.5

Tatsächlich ist das aber nicht so und die Spannungswerte sind zu klein. 
Rechne ich jedoch mit 0.4V anstelle der 0.3125V komme ich auf die 
Spannungswerte, wie sie auch auf dem Oszi angezeigt werden und wie ich 
sie erwarten würde:

(Samplewert-128) *0.4/128 *100/2.5

Jetzt stellt sich mir ganz unabhängig von dieser Rechnerei die Frage, 
was passiert wenn nun aus irgendeinem Grund Signale am ADC auftreten, 
die größer als der reduzierte Aussteuerbereich sind?

Beste Grüße, branadic

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
> Hallo Guido,
>
>>afaik wird bei 2 V/div das Signal erst durch 100 geteilt und
>>anschließend mit 2,5 multipliziert. Ergibt bei 8 div maximal
>>0...400 mV bei einem Austeuerungsbereich des ADC von
>>0...625 mV. Damit liegen die Werte im FIFO zwischen 0 und
>>164.
>
> [...]
>
> (Samplewert-128) *0.625V/256 *100/2.5
>
> oder anders geschrieben:
>
> (Samplewert-128) *0.3125V/128 *100/2.5

Rechne mal

Laut bruno's Erklärung sehr weit oben im Thread sind die
Verstärkunksfaktoren 1;2;5 und nicht 1.25;2.5;5. Es war
mal angedacht, diese in 1.25;2.5;5 zu ändern. Es scheint
aber noch nicht umgesetzt worden zu sein (viele Änderungen
am Code (Anzeige, QM)

Evtl. wirst Du das auch in Deinen Analysen daran sehen,
dass bei den 5'er Stufen die Bandbreite (stärker) begrenzt
wird als bei den 1'er und 2'er Stufen.

>
> Tatsächlich ist das aber nicht so und die Spannungswerte sind zu klein.
> Rechne ich jedoch mit 0.4V anstelle der 0.3125V komme ich auf die
> Spannungswerte, wie sie auch auf dem Oszi angezeigt werden und wie ich
> sie erwarten würde:
>
> (Samplewert-128) *0.4/128 *100/2.5
>
> Jetzt stellt sich mir ganz unabhängig von dieser Rechnerei die Frage,
> was passiert wenn nun aus irgendeinem Grund Signale am ADC auftreten,
> die größer als der reduzierte Aussteuerbereich sind?

Den ADC dürfte das nicht interessieren, solange dies im erlaubten
Aussteuerbereich liegt. In der Anzeige laufen die dann (wenn ich
mir Ticket #7 ansehe) gegen die oberen und unteren Grenzen. In den
csv-Dumps müsstest Du sie ohne diese Einschränkung sehen.

> Beste Grüße, branadic


Grüße,

    rowue

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe mit den Daten aus meinen Messungen, ohne das Rauschen 
herauszufiltern, mal den Frequenzgang berechnet. Die Amplitude [Vpp] bei 
1MHz hab ich dazu mal als 0dB angenommen und die restlichen Werte darauf 
normiert.
Damit ergibt sich für die Einstellung 2V/div bei mir oben gezeigter 
Frequenzgang.

Beste Grüße, branadic

von branadic (Gast)


Angehängte Dateien:

Lesenswert?

Ach ja, bevor Fragen aufkommen, was tatsächliche Stützstellen sind und 
die Grafik in Frage gestellt wird, hier mal noch ein bildlicher 
Nachtrag.

Beste Grüße, branadic

von Michael H. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo.
Ich habe gerade mal die Beta 0.91 draufgehaut und ein wenig 
herumgespielt. Leider fehlt mir bisher noch eine Quelle für 
hochfrequente Signale, allerdings habe ich die Flanke eines 2,7kHz 
Rechtecksignals bei relativ kleinen Zeitbasen (z.B. 200ns) betrachtet 
und dabei sind mir riesige Ausreißer aufgefallen, die im Schnitt alle 
paar Sekunden zu sehen sind und die ich bei vorherigen Firmwareversionen 
nicht bemerkt habe.
Die Spitzen zeigen sich mal öfter, mal selten - komisch.
Kann das jemand nachstellen? Ich weiß nicht, ob ich das bei den alten 
Versionen nur nicht bemerkt habe oder ob das ein neues Problem ist,
es ist bei mir aber auf allen Kanälen zu sehen.
Komischerweise ließ sich schlecht auf diese Spitzen triggern, ich habe 
aber einen Screenshot hinbekommen, den ihr hier sehen könnt.

Leider kann ich nicht ausschließen, dass es an der NE555 Schaltung 
liegt, ich halte das aber für nicht sehr wahrscheinlich.

Außerdem hatte ich vorhin noch ein Problem, das ich aber nicht mehr 
reproduzieren kann: ich konnte keine 500ns einstellen sondern nur 1 us 
oder 200 ns. Damit verbunden war eine ziemlich versaute Darstellung der 
Flanke. Nach ein wenig herumdrehen an der Zeitbasis war alles plötzlich 
wieder normal.

Gruß,
Michael

von branadic (Gast)


Lesenswert?

Hallo Michael,

diesen Ausreißer kann ich bestätigen. Ich habe diesen Ausreißer in 
meinen Aufzeichnungen auch jeweils am Anfang oder am Ende einer 
Messreihe, wobei es sich nur um einen einzelnen Wert handelt. Vermutet 
wird, dass hier vielleicht ein Bit gekippt ist.

Noch mal ein kleiner Nachtrag:

Was man anhand der obigen Bilder im Wesentlichen sehen kann, ist das 
Frequenzverhalten des OPA656 aus der Analogstufe, der für den 
Frequenzbereich von 0-100MHz im Prinzip ausreichend wäre, nicht aber für 
die W202xA Geräte. Hier hätte man einen Unterschied in der Hardware 
erwarten müssen, aber offensichtlich gibt es den nicht. Zumindest an der 
Stelle hat Wittig/Welec geflunkert.

Beste Grüße, branadic

von Falk (Gast)


Lesenswert?


von branadic (Gast)


Lesenswert?

Weitere Hardware-Diskussionen verlagere ich jetzt auch mal auf:

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

von Michael H. (Gast)


Lesenswert?

Falls noch jemand die alte Firmware (0.90 oder älter) draufhat, könnte 
derjenige bitte mal überprüfen, ob bei ihm auch die seltsamen Spikes 
auftreten, die ich ein paar posts weiter oben beschrieben habe?

Gruß,
Michael

von Jan H. (cyno)


Lesenswert?

Hallo Michael,

Michael H. schrieb:
> Falls noch jemand die alte Firmware (0.90 oder älter) draufhat, könnte
> derjenige bitte mal überprüfen, ob bei ihm auch die seltsamen Spikes
> auftreten, die ich ein paar posts weiter oben beschrieben habe?

Ich hab mein W2022A Skope seit letzter Woche in Benutzung und genau 
diese Spikes hatte ich auch bei der Messung eines ca. 58 kHz 
Rechtecksignals. Dachte aber auch, dass es eventuell an der Schaltung 
liegen könnte (ATMEGA16 im STK500), aber sehr wahrscheinlich kam mir das 
auch nicht vor.
Komisch war, dass die Spikes nach "Auto-Setup" weg waren?! Leider habe 
ich nichtmehr in Erinnerung in welcher Zeitbasis die Spikes aufgetreten 
sind... ;-/

Gruß,
Jan

von Hardy G. (hardy-g)


Lesenswert?

Mein W2022A hat inzwischen auch fw beta 0.91 aufgespielt bekommen und 
ich kann die Spikes ebenfalls bestätigen. Ich habe Frequenzen von 2kHz - 
100 kHz getestet. Bei meinem Welec ist bis 10us/div alles ok. Ab 5us/div 
(200Ms/s) bis zum Ende der Timebase treten sporadisch Spikes auf.

Hardy

von mike0815 (Gast)


Lesenswert?

Hallo erstmal,
ich habe mit Spannung eure Entwicklungen bezüglich des Welec2022 
bzw.2024 verfolgt und möchte mal ein Lob aussprechen! Es ist ja 
unglaublich, was man mit diesem DSO Firmwaremässig anstellen kann.
Da ich jetzt selbst im Besitz eines W2022 bin, möchte ich diese Projekt 
auch weiterhin verfolgen, was aber sehr schwierig ist, da hier zig 
Threads am laufen sind...im Sourceforge ist alles auf englisch, gibt es 
da denn keine auf Deutsch??? Würde da gerne den einen oder anderen 
Beitrag dazu leisten!
So, möchte hier nicht weiter zu müllen und wünsche allen noch einen 
erfolgreichen Tag.

LG mike0815

von Michael K. (manhunt)


Lesenswert?

Hallo

Ich hab ebenfalls die Firmware 0.91 eingespielt und Getestet mit 
Frquenzen 1khz, 1mhz und 10mhz und ich habe die Singale in verschiedenen 
v/div angesehen jedoch haben sich keine Spikes bei mir eingeschlichen.

/* welech 2024A */

von branadic (Gast)


Lesenswert?

Tag zusammen,

orientiert euch bitte nicht an dem, was auf dem Bildschirm dargestellt 
wird, sondern was tatsächlich an Daten im Speicher liegt und schaut euch 
diese Daten genauer an.

Dazu wurde die w2000a-screenshot.exe entwickelt.
Unter Win einfach die Komandozeile öffnen, in das Verzeichnis mit der 
w2000a-screenshot.exe wechseln und die Datei mit:

w2000a-screenshot.exe -c 1 (für COM-Port 1) -d (für korrigierte Daten) 
oder -r (für Rohdaten) -o (für einmaliges Auslesen) -t csv oder ascii 
(Dateityp wählen)

öffnen. Dann am Oszi in das QuickPrint Menu wechseln und auf den Button 
CSV drücken. Schon wird der Speicherinhalt in eine Datei geschrieben. 
Wenn ihr CSV gewählt habt könnt ihr euch die Daten im einfachsten Fall 
mit Excel anschauen.
Anhand dieser Daten lassen sich mehr Aussagen treffen, als die 
Eindrücke, die ihr am Bildschirm gewinnen könnt.

zur Frage nach den Foren...

Im Sourceforge wird zum Teil auch Deutsch gesprochen wenn auch eher 
notgedrungenermaßen Da Englisch jedoch eine Weltsprache ist und somit 
weltweit Welec-Besitzer in den Genuss der Entwicklung kommen und daran 
Einfluss haben können ist der Großteil in Englisch.
Ist diese befremdlich wirkende Sprache denn wirklich ein so ernsthaftes 
Problem? Es wird niemandem der Kopf abgerissen, nur weil die Beiträge 
nicht 100% grammatikalisch richtig sind. Also traut euch ruhig!

Gruß, branadic

von mike0815 (Gast)


Lesenswert?

...da hast du wohl recht, nur bei speziellen Ausdrücken, wird man dann 
wohl den Langenscheid auspacken müssen...
Ich war mal auf der FW-Seite von Sourceforg und wollte mir mal das 
aktuelle Image von Hayo ( der ja unglaubliches leistet) ziehen, da ich 
schon erfolgreich hin u. her geflasht habe, jedoch ist es nicht möglich 
diese herunter zu laden, ausser die neue Screenshotversion, ist die 
Seite noch nicht richtig aktiv, oder was bremst da?

Gruß Michael

von Cra Z. (crazor)


Lesenswert?

Michael,
ich habe das schnell getestet und konnte auch eine der Firmwares 
herunterladen. Wo hängt's denn bei dir? Schon mal versucht, einen 
anderen Mirror zu wählen, wenn der Download nicht klappt?

von mike0815 (Gast)


Lesenswert?

Hä? Mirror??? Wo kann ich denn den auswählen? Hatte doch die Seite vor 
mir, da waren wohl alle Dateien, nur konnte ich sie nicht anklicken, auf 
welcher Seite warst du denn da??? Habe noch eine Adresse gefunden :

(http://sourceforge.net/apps/phpbb/welecw2000a/viewforum.php?f=5),

da stand aber nur die 0.90 zur verfügung, wollte aber gerne die 0.91er 
testen, bevor ich das Ding zurück gebe!!!

von Guido (Gast)


Lesenswert?

Hallo Michael,

dich trifft der Fortschritt.

Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.
SFN ist halt eine heilige Kuh, jetzt tanze darum...

Guido

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Guido schrieb:
> Hallo Michael,
>
> dich trifft der Fortschritt.
>
> Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.

Blödsinn.

> SFN ist halt eine heilige Kuh, jetzt tanze darum...

Blödsinn.

http://sourceforge.net/projects/welecw2000a/

Falk

von Guido (Gast)


Lesenswert?

>Guido schrieb:
>> Hallo Michael,
>>
>> dich trifft der Fortschritt.
>>
>> Installiere erstmal einen SVN-Client, ohne den geht leider nichts mehr.

>Blödsinn.

Danke.

>> SFN ist halt eine heilige Kuh, jetzt tanze darum...

>Blödsinn.

Nochmal, danke.

Du mich auch, Guido

von Robert (Razer) (Gast)


Lesenswert?

Nicht unfreundlich werden, auch nicht zu später Stunde.

Die 0.91er gibt es auf http://sourceforge.net/projects/welecw2000a/ 
(ganz unten)

Einzelne Files aus dem Repostory: 
http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/tags

lg Robert

von mike0815 (Gast)


Lesenswert?

...was'n mit euch los??? SVN-Client??? Heilige Kuh??? Jetzt geht's aber 
los hier...
Werde mal den Link von Falk ausprobieren !

Jetzt habe ich mal die 0.90er aufgespielt, bei 50mV, 500mV und 5V ist 
das Eigenrauschen minimalistisch im Vergleich zu vorher, ich bin 
begeistert!

Nur bei den anderen Spannungen ist das Eigenrauschen enorm. Welec 
beschrieb ja auch, das bei den oben angebenen Werten, das Eigenrauschen 
am wenigsten ist.

Nun ja, muß ich bei den anderen Spannungseinstellungen jedesmal die 
Null-Linie neu Kalibrieren??? Die haben da einen erheblichen Versatz!

...na dann, bis gleich

Gruß Michael

von mike0815 (Gast)


Lesenswert?

ich noch mal...Jetz muß ich mal blöd fragen, wo ist denn in dem Pack die 
das Flash?? Wie soll ich eine "w2000a-screenshot.exe" flashen ??? Habe 
hier schon zig Stunden mit lesen verbracht, hab ich da jetzt was 
verpeilt???

Gruß Michael

von Robert (Razer) (Gast)


Lesenswert?

? In welchem Paket nun?

Im folgenden Paket ist alles enthalten. Auch die Flash-Datei 
(TomCat.flash): 
http://downloads.sourceforge.net/project/welecw2000a/Open%20Source%20Firmware/1.2-OS-0.91/1.2-OS-0.91.tgz

lg Robert

von Robert (Razer) (Gast)


Lesenswert?

PS.: Man muss den Link in das Adressfenster kopieren. Ansonsten 
funktioniert der Download nicht, da das Prozent Zeichen nicht übernommen 
wird.

von mike0815 (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Robert, wenn ich die "w2000a-screenshot-0.91.gz" runter lade und 
entpacke, habe ich nur 3 Files drinnen und genau die 'TomCat.flash' ist 
nicht dabei, ist mir ein Rätsel...ich habe mal einen Sreenshot gemacht, 
damit du siehst, was ich m meine!

Gruß Michael

von Robert (Razer) (Gast)


Lesenswert?

Du hast das falsche Archiv. Du benötigst das Archiv "1.2-OS-0.91.tgz"
Diese Datei ist im Post oben von mir verlinkt.

von mike0815 (Gast)


Lesenswert?

eben, da kann ich nix auswählen, warum auch immer, ich sehe die Datei, 
kann sie weder anklicken, noch kann ich sie kopieren oder im neuen 
Fenster öffnen...vielleicht könntest du sie mal hier anhängen dann wären 
wir auf der sicheren Seite bevor ich hier alles zu mülle...
Ich komme da nicht dran, bin jetzt mit meinem Latein am Ende, da steckt 
der Teufel drin oder was auch immer, wäre ich vom anderen Geschlecht, 
könnte ich es ja evtl. noch verstehen.....uhhh, das war 
diskriminierend...'lach'

Gruß Michael

von Robert (Razer) (Gast)


Angehängte Dateien:

Lesenswert?

lg und gute Nacht =)

von mike0815 (Gast)


Lesenswert?

man, was für eine Prozedur...vielen Dank, Robert, genau die wollte ich, 
alles drinnen!!!
Ich wünsche auch eine gute Nacht, jetzt langt's, werde morgen das Image 
aufspielen und dann mal testen!
Ich hoffe das das Problem mit den Zero-lines bei der 0.91er behoben ist, 
da bei mir das die Messungen total verfälscht, muß nach jedem 
Eingangswechsel neu Kalibrieren...

LG Michael

von Jürgen (Gast)


Lesenswert?

> mike0815 schrieb:

> man, was für eine Prozedur...vielen Dank, Robert, genau die wollte ich,
> alles drinnen!!!

Wie von Guido schon richtig bemerkt: Das ist eben der Fortschritt! (:O

Jedenfalls funktioniert Falk's Experiment gegen Signalverzerrungen 
(adc_change12_reg) in der Version 0.91 leider definitiv nicht bei den 
4-Kanalgeräten.

Gruß Jürgen

von Jürgen (Gast)


Lesenswert?

Funktioniert doch. Hatte mich blöd angestellt!!!!

Gruß Jürgen

von Jürgen (Gast)


Lesenswert?

Na so ein Zufall auch! Gleich ein Namensvetter da?
Oder doch jemand, der seinen Namen besser nicht nennen will?
Kein Kommentar dazu!

von Jürgen (Gast)


Lesenswert?

Ich meinte doch die Sache mit dem Referenzsignal.

Gruß Jürgen

von Michael H. (Gast)


Lesenswert?

Es scheint Probleme mit den QuickMeasure Funktionen zu geben, sobald ich 
Zeitbasen <50ns erreiche - kann das jemand bestätigen?
Risetime, Frequenz, Duty Cycle, +Width, -Width, Periode: alles passt 
wunderbar bis 50ns, ab 20ns kommt nur noch Mist raus.

Getestes habe ich mit einem 12,4MHz Rechtecksignal, das ich mit nem R32C 
erzeugt habe, Kanal 1, 1V/div, DC-gekoppelt.

Wenn es anderen genauso geht erstelle ich dazu nachher ein Ticket.

Gruß
Michael

von Blue F. (blueflash)


Lesenswert?

Michael H. schrieb:
> Es scheint Probleme mit den QuickMeasure Funktionen zu geben, sobald ich
> Zeitbasen <50ns erreiche - kann das jemand bestätigen?

Hallo Michael,

getestet hab ich das noch nicht, aber es ist durchaus möglich, dass Du 
recht hast. Da unterhalb von 50 nS die interpolierten Zeitbasen 
anfangen, liegen die Signaldaten nicht mehr im Ursprünglichen 
Datenbereich, sondern in einem Eigenen für die interpolierten Daten. Das 
muß natürlich auch bei QM berücksichtigt werden. Wenn das nicht 
geschieht kommt natürlich Mist dabei raus.

Eigentlich ist das Stefans Baustelle, aber wenn er da nicht zu kommt 
kann ich da auch mal ein Auge drauf werfen. Ein Ticket ist aber keine 
schlechte Idee, dann geht das nicht unter.

Gruß Hayo

von mike0815 (Gast)


Lesenswert?

Wie von Guido schon richtig bemerkt: Das ist eben der Fortschritt! (:O



...ja was jetzt? Muß ich mich erst registrieren um an die Dateien zu 
kommen, oder werde ich hier ein bißchen hoch genommen???

Gruß Michael

von Thomas (kosmos)


Lesenswert?

mir ist auch noch ein kleiner Schönheitsfehler aufgefallen, wenn ich die 
Display-Taste drücke dann Funktionieren alle Menütasten bis auf die 
Taste für Grid 33%, 66% und 99%, dies läßt sich nur mit dem Drehrad 
ändern. Könnte man das nicht auch auf die Menütaste legen damit man 
damit auch wechseln kann ohne einen 2ten Handgriff auf die Drehtaste zu 
brauchen? Bei Switch Grid und Switch Drawing geht es doch auch mit einem 
Handgriff.

von Michael H. (Gast)


Lesenswert?

Ich wundere mich, dass kaum noch jemand etwas postet, hier nicht und in 
sourceforge auch nicht - gibt es Leute, die sich von der englischen 
Sprache abschrecken lassen? Es wäre doch schade, wenn man die vergraulen 
würde...und wenn man ehrlich ist, diskutieren ja doch nur 
deutschsprachige Menschen bisher.

Oder was könnte noch dahinterstecken, dass die einst rege Diskussion so 
eingeschlafen ist?

von egberto (Gast)


Lesenswert?

Urlaubs - und Ferienzeit!!!

Nicht aufgeben, die kommen schon alle wieder zurück!

von branadic (Gast)


Lesenswert?

Hallo,

nur weil nichts gepostet wird heißt das nicht, dass nicht im Hintergrund 
die Köpfe rauchen.
Sind alle fleißig bei der Sache und machen Fortschritte, sei es im HDL, 
an der Hardware Front oder am PC Frontend.
Was sich in Sachen Firmware tut wage ich derzeit nicht zu beurteilen, 
aber sicherlich wird auch da fleißig gearbeitet.
Nicht vergessen Michael, alle machen das aus Spaß an der Freude und 
nicht, weil sie dafür bezahlt werden.

Beste Grüße, branadic

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

In der Tat - die Köpfe rauchen und ich bin nicht untätig (niemals!).

Ich glaube Einige hatten es schon bemerkt, die Sache mit dem neu 
gesetzten adc_change-Register hat einen Haken. Wenn das Bit 25 
(0x02000000), welches unter Anderem für die Schwingungen verantwortlich 
ist, nicht gesetzt ist, dann sind zwar die Schwingungen bei hohen 
Frequenzen weg, dafür tritt aber ein anderes Problem auf (deswegen wohl 
auch der ganze Zampadu mit den Filterbits). Und zwar gibt es bei 
Zeitbasen < 10µS Spikes (und zwar jeweils einen) mit Vollausschlag auf 
allen Kanälen am Ende der ADC-Aufzeichnung (so zwischen Wert 14000 und 
16000). Die exakte Position ist abhängig von der Zeitbasis immer exakt 
die gleiche auf Kanal 1 + 4 und um 5 Werte verschoben auf Kanal 2 + 3 
(siehe Bild). Die Ursache ist mir nicht so ganz klar (ob digital oder 
analog verursacht).

In der Holiday Edition gibt es bereits eine Lösung für das Problem.

Gruß Hayo

von Michael H. (Gast)


Lesenswert?

Ich habe mich doch nur gewundert, dass so wenig gepostet wird und mich 
gefragt ob das an der englischen Sprache liegen könnte - dass nach wie 
vor viele Leute (gerade weil sie es ja aus Spaß machen) an dem Projekt 
arbeiten, daran habe ich gar keinen Zweifel.

Du hast eine Lösung für die Spikes gefunden, Hayo? Das wäre ja klasse, 
wenn man sich nicht mehr zwischen Spikes und Murks bei hohen Frequenzen 
entscheiden müsste! Ich fange langsam an zu sabbern, wenn ich "Holiday 
Edition" lese...
Aber wenn dir die Ursache der Spikes auch nicht so recht klar ist, wie 
konntest du das ganze beheben?

Gruß,
Michael

von egberto (Gast)


Lesenswert?

er wird die Werte einfach rauswerfen und durch den Mittelwert der beiden 
Nachbarn ersetze..denke ich mal so

von Blue F. (blueflash)


Lesenswert?

Das ist die aktuelle Lösung - korrekt. Ich experimentiere allerdings mit 
dem adc_change-Register an einer etwas geschmeidigeren Lösung, weiß aber 
nicht ob das hinhaut.

Hayo

von Blue F. (blueflash)


Lesenswert?

Um nochmal meine Ausführungen zur HE aus dem Hardware Thread zu 
präzisieren hier ein kleiner Überblick über die Themen an denen ich 
arbeite bzw. die schon eingebaut sind.

Im Wesentlichen betrifft das das die Tickets und das Verhalten bei hohen 
Frequenzen.

Zur Zeit probiere ich mit verschiedenen Registerwerten herum um die 
Spikes wegzukriegen ohne die Schwingneigung bei hohen Frequenzen wieder 
einzubauen.

Ansonsten:

- Ticket 3: Autoscale + Rollmode -> erledigt
- Ticket 5: Ich habe die Save / Recall Funktion komplett 
überarbeitet/repariert und dabei auch das Ticket erledigt. Es gibt jetzt 
auch volle Unterstützung für den USTB-Mode. Weiterhin werden nach 
Beendigung des Recalls alle vorherigen Einstellungen wieder hergestellt.
-> erledigt
Ticket 7: Im accurate drawing mode werden Signale die außerhalb des 
Darstellungsbereichs liegen nicht mehr "plattgedrückt", sondern nicht 
mehr dargestellt. Im schnellen Darstellungsmodus ist alles beim Alten. 
Man kann sich also aussuchen welche Darstellung einem besser gefällt. -> 
erledigt

Des Weiteren werden noch einige Erweiterungen an der FFT dazukommen.

Alles klar?

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@rowue

Dein Patch (Ticket 26) ist natürlich auch dabei.

Hayo

von Michael H. (Gast)


Lesenswert?

Ticket 32 ist doch ein ziemlich alter Hut, also schon lange bekannt - 
weiß inzwischen jemand was dahintersteckt?

Michael

von Rolf W. (rowue)


Lesenswert?

Michael H. schrieb:
> Ticket 32 ist doch ein ziemlich alter Hut, also schon lange bekannt -
> weiß inzwischen jemand was dahintersteckt?

Also wenn Du mit Denoising misst, ist das Ticket eine Doublette von
#14 ;) - Dort findest Du auch einen Kommentar, was dahinter steckt
und, dass mensch den Fehler ggf. nicht fixen sollte:

Sonst in Kürze:

   Durch die Verwendung des "Moving Average Filter" (wandernder
Mittelwert Filter) sind einige Messwerte (Filterlänge - 1 ) nicht
definiert. Da stellt sich eher die Frage, was mensch mit diesen Werten 
macht:

a) Mensch verkürzt den Filter zum Ende des Bereiches entsprechend und
 ist so in der Lage die Werte darzustellen - schlecht: die 
Charakteristik
 des Filters wird geändert

b) Mensch nimmt den letzten Wert n'mal und füllt damit die nicht 
definierten
 Werte auf - auch schlecht - das Signal am Ende ist dann ein Strich

c) Mensch zeigt diese Werte an und verweist in einer FAQ drauf.
 Meines erachtens die beste Möglichkeit - das Filterverhalten bleibt
 definiert und jeder sieht, dass da Gülle steht ;)

>
> Michael

Grüße,

   rowue

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> @rowue
>
> Dein Patch (Ticket 26) ist natürlich auch dabei.

Danke! ;)

Noch eine kurze Anfrage meinerseits: wie sähe es denn
von eurer Seite aus aus, mir write-access (Commit-Rechte)
auf das svn zu geben?

Damit könnte ich kleinere Bugfixes und Enhancements
direkt einspielen (grössere Sachen würde ich als
"Schein-Ticket" filen ;) - ohne über das Ticket-System
gehen zu müssen ...

Die Entscheidung braucht nicht "über's Knie" gebrochen zu
werden (mein DSO ist gerade in Böblingen und da ich nicht
testen kann, werde ich da gerade nichts machen) - könnte
aber perspektivisch die Arbeit erleichtern ;)

>
> Hayo

Grüße,

   rowue

von Michael H. (Gast)


Lesenswert?

Danke für die Erklärung Rolf, hatte ich bisher nicht mitbekommen.

Mich stört dieses Verhalten schon muss ich sagen, insofern würde ich für 
die Lösung plädieren, die entsprechenden Werte durch den letzen gültigen 
davor zu ersetzen - es kann sich ja nicht um viele Werte handeln, die so 
bearbeitet werden müssen, so dass das Resultat doch recht ansehnlich 
sein sollte, oder?

Michael

von Blue F. (blueflash)


Lesenswert?

So die Spikeproblematik ist gelöst. Es gibt tatsächlich einen 
Registerwert, mit dem die Spikes unterdrückt werden aber trotzdem keine 
Schwingungen auftreten.

Gruß Hayo

von Thomas (kosmos)


Lesenswert?

Fettes Dank für die Mühe. Wann kann man die neue Firmware erhaschen?

von Michael H. (Gast)


Lesenswert?

Na das klingt doch wieder mal super!
Was wie warum da passiert weißt du aber auch nicht, oder Hayo?

Gruß
Michael

von Sven (Gast)


Lesenswert?

Hi,

hab mir ein W2022A bei ebay ersteigert. Warte noch bis es ankommt.

@Hayo W.
Gibt es irgendwo eine übersicht was deine Firmware im Vergleich der 
Originalen schon alles kann? Habe auch schon bei Sourceforge.net 
gesucht, aber mein Englisch ist nicht so gut.

Oder was gibt es denn noch so für Opensource firmwares dafür? habe Schon 
ziemlich lange gesucht, aber konnte das ganze noch nicht so richtig 
überschauen.

von Michael H. (Gast)


Lesenswert?

Gerade habe ich gemerkt, dass, je nach gewählter Zeitbasis, es nach 
einem Single Shot mal möglich ist, nach dem Triggerereignis horizontal 
reinzuzoomen und mal nicht. Das ist ganz schön lästig!
Dazu erstelle ich nachher gleich noch ein Ticket.

Außerdem habe ich eben an einer Rechteckfunktion "Averaging" als 
Acquire-Mode ausprobiert und festgestellt, dass das Ergebnis sehr 
bescheiden ist. Mein anderes Oszi zeigt ein Rechteck wie aus dem 
Lehrbuch wenn ich Average wähle, beim Welec verbessert sich die 
Darstellung dagegen nur ein wenig. Über wie viele Perioden wird denn da 
gemittelt?
Ist das auch ein Ticket wert?

Gruß
Michael

von Guido (Gast)


Lesenswert?

Hallo Michael,

das Ticket kannst du dir sparen. Wirf mal einen Blick in Hayos
Programming-Maps, dann siehst du, dass bei mancher Timebase nur
wenige Punkte mehr gesampelt als angezeigt werden. Da ist
narürlich ein Zoomen nicht mehr möglich.

Gruß, Guido

von Michael H. (Gast)


Lesenswert?

Danke Guido, das hatte ich nicht realisiert. Dann ist das natürlich 
klar, lästig ist es aber nach wie vor.

Jemand mit den entsprechenden Rechten kann übrigens Ticket #18 löschen, 
da von #31 abgedeckt.

Michael

von Odic (Gast)


Lesenswert?

N'Abend Guido,

ich vermute mal, das ist auch der Grund für die unterschiedlichen 
Abhängigkeit zwischen main- und delayed-timebase, oder?

Sind an der Stelle in naher Zukunft Änderungen geplant?

Beste Grüße,
Odic

von Guido (Gast)


Lesenswert?

Hallo Odic und Michael,

da kann ich nur spekulieren. Hayo wollte sich schon lange mal
mit den Timebase-Einstellungen auseinandersetzen, muss aber
ständig andere Baustellen flicken. Ich könnte mir aber
vorstellen, dass da auch noch was zu machen ist, d.h. die
momentane Lösung mit heißer Nadel gestrickt wurde, wie vieles
anderes auch.

Gruß, Guido

von Rolf W. (rowue)


Lesenswert?

Michael H. schrieb:
> Danke Guido, das hatte ich nicht realisiert. Dann ist das natürlich
> klar, lästig ist es aber nach wie vor.
>
> Jemand mit den entsprechenden Rechten kann übrigens Ticket #18 löschen,
> da von #31 abgedeckt.

Habe ich gerade gemacht - btw: Ihr solltet auch entsprechende
Informationen an die Tickets anhängen können - somit sollten
nicht immer neue Tickets aufgemacht werden müssen ;)
>
> Michael


Grüße,

   rowue

von Bert (Gast)


Lesenswert?

Ticket #2 kann vermutlich auch geschlossen werden.
Die FPGA-T51 Entwicklung scheint eingestellt worden zu sein, oder?
Bitte auch Ticket #1 prüfen, bei mir funktioniert der Math-Button 
(1.2-OS0.91).
Gruß Bert

von Rolf W. (rowue)


Lesenswert?

Bert schrieb:
> Ticket #2 kann vermutlich auch geschlossen werden.
> Die FPGA-T51 Entwicklung scheint eingestellt worden zu sein, oder?
> Bitte auch Ticket #1 prüfen, bei mir funktioniert der Math-Button
> (1.2-OS0.91).

Hi Bert, dass sind vermutlich beides Tickets aus dem FPGA-Bereich ;)

Wäre evtl. interessant, wenn einige Leute mit "neueren" W2022A's
mal Ihren Math-Button mit der 0.88/0.89 im Gegensatz zu 0.91 prüfen
- ich musste da einen Patch für einen Kollegen mit solch einem
Gerät einbauen (gekauft ca. Juli/August 2009) und es könnte sein,
dass Wittig da einen Stapel Geräte mit Kurzschluss hat - dann
sollten wir den Patch evtl. drin lassen ;)

> Gruß Bert

Grüße,

   rowue

von Blue F. (blueflash)


Lesenswert?

Thomas O. schrieb:
> Fettes Dank für die Mühe. Wann kann man die neue Firmware erhaschen?

Heute bzw. nachher.


Michael H. schrieb:
> Na das klingt doch wieder mal super!
> Was wie warum da passiert weißt du aber auch nicht, oder Hayo?

Die Ursache ist in der Tat nicht ganz klar, aber man kann durch 
Ausprobieren die Zusammenhänge zwischen einzelnen Registerbits und 
Anzeigefehlern herstellen.


Sven schrieb:
> Hi,

> Gibt es irgendwo eine übersicht was deine Firmware im Vergleich der
> Originalen schon alles kann?

Es ist ein Changelog dabei, da stehen alle Änderungen drin. Aber viel 
einfacher ist es direkt zu vergleichen. Dazu mußt Du Dein Flash nicht 
überschreiben, sondern kannst die Firmware direkt ins RAM laden 
(Beschreibung ist dabei). Eigentlich kann man sagen, das die OS-Firmware 
alles was die originale Firmware kann (oder auch nicht) besser kann und 
auch noch mehr Funktionen hat.

> Oder was gibt es denn noch so für Opensource firmwares dafür? habe Schon
> ziemlich lange gesucht, aber konnte das ganze noch nicht so richtig
> überschauen.

Keine, es gibt nur dieses Projekt.


Guido schrieb:
> Hallo Odic und Michael,
>
> da kann ich nur spekulieren. Hayo wollte sich schon lange mal
> mit den Timebase-Einstellungen auseinandersetzen, muss aber
> ständig andere Baustellen flicken.

In den nächsten Tagen wollte ich dazu mal ein paar Vorabtests machen. Da 
wird sich auf jeden Fall noch was tun.

> Ich könnte mir aber
> vorstellen, dass da auch noch was zu machen ist, d.h. die
> momentane Lösung mit heißer Nadel gestrickt wurde, wie vieles
> anderes auch.

Jupp, das sehe ich auch so.


Bis nachher

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Ok, hier ist sie!

Out now, 0.92 Holiday Edition. Bitte beachtet das Changelog und testet 
die neu hinzugekommenen Fixes und Funktionen. Zur Dokumentation benutzt 
bitte die beigelegte Screenshotversion, da die anderen Vesionen nicht 
kompatibel sind.

Gebt bitte Euer Statement ab, welche der Funktionen in die "OS"-Version 
einfließen soll.

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Ok, hier ist sie!
>
> [Version 0.92HE released]
>
>

Habe die Version schon mal in das Ticket-System des Trac aufgenommen.
(1.2.BF.0.92HE)

>
> Gruß Hayo

Grüße,

    rowue

von Michael H. (Gast)


Lesenswert?

Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als 
früher ist, kann das sein?

Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme: Das 
Oszi verstellt beim Laden nicht mehr den Trigger, steht aber immer auf 
"Stop" und als ich versuchsweise eine Einstellung mit drei Signalen 
gespeichert und geladen habe und anschließend das ganze mit nur einem 
Signal, wurden die Nulllinienmarkierungen aller vier Kanäle mit 
eingeblendet, Ergebnis war: 2x Kanal 1, die anderen drei jeweils einmal. 
Das ist aber wohl nur ein Refresh-Problem, da alles verschwand nachdem 
ich einmal auf Kanal 2 gedrückt hatte.
Ich konnte es auch reproduzieren: ein Signal speichern, laden und 
anschließend auf "Run/Stop" drücken liefert bei mir den beschriebenen 
Fehler.

Sonst habe ich noch nichts getestet, aber ich bin sicher, dass das Welec 
damit wieder einen großen Schritt nach vorn gemacht hat.

Danke schonmal für die Verbesserungen!

Michael

von Sven (Gast)


Lesenswert?

Hallo,

Danke hab jetzt den Changelog gefunden, sourceforge.net finde ich ein 
bisschen unübersichtlich.

Ist echt Wahnsinn was ihr schon erreicht habt. Morgen müsste mein Oszi 
los geschickt werden. Wenn es ankommt kann ich beim Testen helfen. Für 
mehr werden meine Programmierkenntnisse nicht reichen.

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

@Hayo

Danke fuer die HE, bei mir treten die spikes in AUTO mode nun nicht mehr 
auf, dafuer habe ich nun manchmal spikes im Normal mode! Die sind leider 
viel schwieriger zu erkennen weil sie nicht immer an der selben stelle 
im Speicher sind!

N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu 
funkzionieren:

Bis zu 50ns/div ist sie OK (die Darstellung hat einen kleinen Versatz),
aber wen ich weiter zoome (was meiner Meinung nach nicht moeglich sein 
sollte) wird nur eine Linie dargestellt (vermutlich ein falscher Bereich 
der Daten). und ich kann nicht mehr nach 50ns/div zurueck gehen.

Martin

von Blue F. (blueflash)


Lesenswert?

Danke schon mal für die ersten Testberichte.

@Michael H.

> Ich habe den Eindruck, dass die Refresh-Rate mit Noise Filter höher als
> früher ist, kann das sein?

Jein, das kommt auf die eingestellte Zeitbasis an, da je nach 
ungenutzten Samplewerten mit unterschiedlicher Filtertiefe gearbeitet 
wird. Den Bereich <= 100nS habe ich auf schnelle Shift-Operation 
umgestellt statt wie vorher normale Division, weiß aber nicht ob das 
schon in der letzten Version drin war oder ob das jetzt neu ist.

> Beim Speichern und Laden von Signalen gibt es nach wie vor Probleme:
> Das Oszi verstellt beim Laden nicht mehr den Trigger, steht aber
> immer auf "Stop"

Ja natürlich! Da ist wohl die Funktionsweise des Recall  unklar. Also 
das gespeicherte Signal wird mit allen zugehörigen Einstellungen aus dem 
Flash geladen. Damit dann im nächsten Durchlauf das geladene Signal 
nicht gleich wieder vom aktuellen Signal überschrieben wird, geht das 
Gerät in den Stop-Modus. Durch das Drücken der Stoptaste wird dann der 
Stop-Modus und damit auch der Recall beendet -> die alten Einstellungen 
werden aus dem Flash wieder hergestellt und der normale Betrieb wieder 
gestartet.

> und als ich versuchsweise eine Einstellung mit drei Signalen
> gespeichert und geladen habe und anschließend das ganze mit
> nur einem Signal, wurden die Nulllinienmarkierungen aller
> vier Kanäle mit eingeblendet, Ergebnis war: 2x Kanal 1,
> die anderen drei jeweils einmal.

Diese Testkonstellation hate ich noch nicht. Danke für den Tip, werde 
ich mal checken.


@Sven

Programmierkenntnisse sind nicht nötig. Mit den Tests helft Ihr mir 
erheblich weiter. Da ich nicht die Zeit habe alle Konstellationen zu 
testen bin ich auf diese Hilfe angewiesen.


@Martin H.

> Danke fuer die HE, bei mir treten die spikes in AUTO mode nun
> nicht mehr auf, dafuer habe ich nun manchmal spikes im Normal mode!
> Die sind leider viel schwieriger zu erkennen weil sie nicht immer
> an der selben stelle im Speicher sind!

Ok werde ich mal checken. Ich habe alle Tests bislang im AUTO-Modus 
gemacht.

> N.b. die Delayed Funktion scheint bei 1Gs/sec nicht richtig zu
> funkzionieren:

Da habe ich in dieser Version nichts dran geändert. Das müßte also ein 
Fall für die offizielle "OS"-Version (Ticket) sein.

Gruß und danke

Hayo

von Robert S. (razer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hallo Hayo,

Ich habe gerade deine Firmware aufgespielt. Im FFT Menü gibt es einen 
Fehler beim Anzeigen des Menüs "Mode". Siehe Screenshot.

Ein weiterer kleiner Bug (war schon in vorigen Versionen). Wenn man 
"Autoscale" drückt und danach "Undo Autoscale), werden im oberen Menü 
die Spannungsberecihe aller Kanäle angezeigt obwohl nur einer aktiviert 
ist. (siehe Screenshot im zweiten Posting).

Der DAC Abgleich funktioniert bei mir nicht korrekt oder ich mach etwas 
falsch. Ich stelle alle Kanäle auf 5V/div und starte "Search Zero Lines" 
und danach "Calibrate DAC".

Danach stelle ich alle Kanäle auf 2V/div und mach das gleiche.

Stelle ich nun wieder zurück auf 5V/div habe ich auf Kanal 3 und 4 einen 
Offset von -0.5div ud auf Kanal einen Offset von +0.25div. Auf Kanal 2 
ca einen Offset von +2 Pixel.

Mache ich etwas falsch?

lg Robert

von Robert S. (razer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Screenshot 2

von Guido (Gast)


Lesenswert?

Hallo Robert,

du machst was falsch. ;-)

"Search Zero Lines" nur einmal im 5er Bereich drücken, in den
anderen Bereichen dann nur noch "Calibrate DAC".

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

@Robert S.

Zum Kalibrieren hat Guido schon alles gesagt. Ansonsten danke für den 
Fehlerreport, da hab ich ja wieder was zu tun, bevor das in die 
"OS"-Version einfließen kann.

Gruß Hayo

von Robert S. (razer) Benutzerseite


Lesenswert?

Danke für die Hilfe!!

Ich hab noch zwei Fehler beim Delayed Mode gefunden.

#1: Ist der Delayed Mode aktive und man schaltet das Gerät aus und 
wieder an, muss man am Timebase Rad einmal drehen, damit ein Signal 
angezeigt wird.

#2: Im Delays Mode wird das Softmenü der Gritintensität nicht 
aktualisiert wenn man im Display Menü am zugehörigen Drehencoder dreht 
(die Gridintensität ändert sich schon). Wenn man den Delayed Mode 
beendet wird wieder die Gridintensität vor aktivieren des Delayed Modes 
angezeigt. Sollte man im Delayed Mode einen Screenshot machen, wird die 
Grid-Plane mit der Intensität aus dem Main Mode angezeigt, nicht mit der 
geänderten.

lg Robert

von Blue F. (blueflash)


Lesenswert?

Auch ein Fall für ein Ticket, da dieses Problem auch die "OS"-Version 
betrifft. Die 0.92HE-Änderungen findet Ihr im Changelog.

Hayo

von Mike K. (1tester)


Lesenswert?

Hallo


Ich hab mein Oszi erst sehr kurz und benutze aufgrund der Spikes noch 
immer die firmware 90.

Nun hab ich eine Frage wieso ist das "Rauschen" bei 1V größer als bei 
500mV sollte es da nicht größer werden je kleiner die V Basis ist... 
also der Ausschlag? Weil bei mir ist es genau umgekehrt. Im Anhang sind 
2 Bilder das bei 1V hat deutliche hügel das bei 500mV nicht mehr so 
sehr. (Ich weiß handy Kamera aber gibts ne MAC oder Linux software zum 
Screenshot auslesen?)


http://img255.imageshack.us/i/67664861.jpg/


http://img171.imageshack.us/i/500mv.jpg/

lg Mike

von Blue F. (blueflash)


Lesenswert?

Hallo Mike,

es gibt auch eine Linuxversion, die ist auch bei der HE dabei.

Die Messbereiche sind grundsätzlich in drei Hauptbereiche eingeteilt, 
die sich durch den Skalierungsfaktor unterscheiden. Alle 5er Bereiche 
haben einen günstigenren Faktor als die 2er oder 1er. Daher haben aller 
5er Bereiche ein geringeres Rauschen als die 2er und 1er Bereiche.

Gruß Hayo

von Mike K. (1tester)


Lesenswert?

Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon 
"fertig" oder schraubt ihr dort noch herum?

Danke für die schnelle Antwort.

lg Mike

von Rolf W. (rowue)


Lesenswert?

Mike K. schrieb:
> Wie darf ich mir das mit dem Faktor vorstellen? Und ist das ganze schon
> "fertig" oder schraubt ihr dort noch herum?

"fertig"? - Was für ein Wort ;)

Wie Du aus dem Text von brunowe weiter oben entnehmen kannst,
hat das DSO vier Verstärker, aus denen sich die Verstärkungsstufen
(1; 1,25)*(1;2;4) -> (1;1,25;2;2.5;4;5) einstellen lassen.

Das Rauschen der ersten beiden Verstärker bleibt etwa gleich
(7nV/sqrt(Hz)+ 20nV/sqrt(Hz) -> 27nV/sqrt(Hz) (ohne Rauschstrom))
und wird mit den nächsten Stufen entsprechend verstärkt.
Jeder der beiden nächsten Verstärker steuert nochmal 20nV/sqrt(Hz)
zu.

Entsprechend verhält sich das Signal/Rauschverhältniss reziprok
zur Amplitude des Eingangssignals.

An der hardwareseitigen Behebung dieses Problems arbeiten derzeit
Leute. Eine Umstellung der Verstärkungsfaktoren (1,25; 2; 4 -> 1;2,5;5)
erfodert weitere Messungen (es gibt hier verschiedene Ergebnisse zur 
Durchlasskurve des Gerätes zwischen beiden Serien (W201X, W202X))
und hätte derzeit nur evtl. Vorteile für die Firmware (Geschwindigkeit, 
Speicherbedarf ;)

Die dekadischen Stufen (1V, 100mV, ...) werden über ein 
Widerstandsnetzwerk abgebildet.
>
> Danke für die schnelle Antwort.
>
> lg Mike

Grüße,

   rowue

von Michael H. (Gast)


Lesenswert?

Gerade habe ich versucht, die oben beschriebenen Spikes im "Normal" Mode 
zu beobachten.
Testsignal 5V, 325kHz Rechteck. Es gibt Ausreißer, die ich aber wohl von 
dem vom Controller erzeugten Signal kommen - die diversen 
Rechtecksignale die ich damit generiere koppeln ganz gut gegenseitig 
über.
Vielleicht kann das noch jemand mit professionelleren Mitteln testen?

Obwohl: wenn ich mit Single Shot eine Aufnahme nach der anderen mache, 
erwische ich - selten, aber immerhin - einen Spike mit ca. derselben 
Amplitude wie das Rechteck, der eigentlich nicht vom Signal herrühren 
kann. Leider ist bei der HE das alte Problem mit dem zerstückelten 
Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass 
ich keinen ansehnlichen Shot erstellen konnte. Der Spike erschien bei 
mir stets recht nah am rechten Bildschirmrand und hatte immer gleiches 
Aussehen.

Obwohl ich nur mit Kanal 4 gemessen habe, war übrigens die ganze Zeit 
das Triggersymbol von Kanal 2 eingeblendet - wahrscheinlich hilft ein 
Refresh an passender Stelle?

Die anderen Spikes scheinen wirklich verschwunden zu sein, sehr schön.

Gruß
Michael

von Michael H. (Gast)


Angehängte Dateien:

Lesenswert?

Nachtrag zum Triggersymbol:
Siehe Screenshot.

Ich habe mit Kanal 4 gemessen, Trigger stand auf Source 4. Trotzdem war 
auch das Triggersymbol von Kanal 2 eingeblendet. Also habe ich mal auf 
Source 2 geschaltet und am Trigger gedreht - dabei entstand dann das 
Bild, das ihr hier sehen könnt.
Wenn ich Source 1 wähle, kann ich entsprechend nochmal beliebig viele 
1er Triggersymbole dazuzaubern usw.

Gruß
Michael

von Sven (Gast)


Lesenswert?

Sorry wenn ich nochmal ne blöde Frage stelle.

Mein oszi ist heute gekommen. Hab erstmal ein backup von allem gemacht, 
das ging 3 1/2 Stunden. Jetzt will ich zum test mal euere Firmware drauf 
machen, dies dauer jetzt aber ca. 6h. Ist das normal? Ich habe ein USB 
to RS232 converter vom Reichelt.
Kann ich das update jetzt einfach abbrechen und dann über das perl 
Script machen? Da solls ja schneller gehen.

von Mike K. (1tester)


Lesenswert?

Danke für die Erklärung  Rolf Würdemann.

Jetzt wart ich nur mehr auf 0.92, aber zurzeit glüht der svn nur so vor 
updates.

lg Mike

von Cra Z. (crazor)


Lesenswert?

Ich habe vor ewigkeiten ja schonmal davon geredet, dass "bald" eine 
Version des FPGA-Redesigns zur verfügung stünde, mit dem man schonmal 
"spielen" kann. Neben Studiums-Endspurt-Stress kamen diverse Probleme 
mit dem Design hinzu, und große Teile wurden seitdem überarbeitet oder 
neu implementiert. Außerdem habe ich nun tatkräftige Unterstützung bei 
der Entwicklung!

Nach langer Zeit gibt's also mal wieder was zu zeigen: 
http://www.youtube.com/watch?v=vwSE2alpnYQ

Viel Spaß damit

Daniel

von Blue F. (blueflash)


Lesenswert?

Michael H. schrieb:

> Leider ist bei der HE das alte Problem mit dem zerstückelten
> Screenshot wieder da (ja, ich habe screenshot_0.4BF verwendet), so dass
> ich keinen ansehnlichen Shot erstellen konnte.

Den Effekt hatte ich mal unter Linux. Bei mir funktioniert allerdings 
jetzt alles. Sonst unter Windows das BMP-Format verwenden.

Hayo

von Michael W. (slackman)


Lesenswert?

Hallo Sven,
für das schnelle Update benötigst Du Pearl! Unter Windows sollte es so 
gehen (Zitat von viel weiter oben):
-----
Ich verwende ActivePerl 5.8.8 (habe ich von
http://www.oldapps.com/Perl.php geladen).

Zusaetzlich benoetigst du das Modul Win32:SerialPort

Am einfachsten ist die Installierung via Perl Package Manager (PPM):

1. Neues Repository eintragen via Edit -> Preferences
   und den Reiter Repositories
   Name: Bribes
   Location: http://www.bribes.org/perl/ppm
   (ein ausfuerliches help findest du unter
    http://www.bribes.org/perl/ppmdir.html)

2. Jezt kannst du das Modul Win32-SerialPort installieren:
   Zeile mit Win32-SerialPort suchen und an klicken
   Action -> Install Win32-Serialport 0.19

Das sollte alles sein.
-----
Ich hatte Anfangs auch Probleme mit Pearl und habe später gemerkt, dass 
ein Nullmodemkabel das Problem dann behoben hat! Man ist versucht, den 
Reichelt-Adapter direkt mit dem Scope zu verbinden (passt ja!), 
allerdings sind dann RX und TX vertauscht. Also: Nullmodem-Kabel!

Den Rest findest Du im Updatepaket beschrieben.

Michel

von Sven (Gast)


Lesenswert?

Hi Michael,
habs gestern dann einfach weiter laufen lassen, weil ich nicht wusste 
was passiert wenn ichs abbreche.
Heute morgen warens angeblich nur noch 18s bis es fertig ist, aber es 
kamen nur timeout Fehler. Also musst ichs abbrechen, aber die Firmware 
von hayo ist nun drauf und funktioniert auch so weit.
Hatte den adapter direkt (ohne nullmodem- Kabel) drauf gesteckt. Wenn 
TxD und RxD vertauscht wären dürfte ich doch gar keine Verbindung 
bekommen, oder?
Ist das beiligende RS232 Kabel ein Nullmodem- Kabel? mit diesem hab ich 
grad mal einen Software Download gestartet, das geht auch nicht 
scneller.

von Mike K. (1tester)


Lesenswert?

@Sven

Beim downloaden mit Perl der Original Firmware brauchst du zirka 1Std 
fürs spätere uploaden der hier erhältlichen firmware per perlskript 
brauchst du 5min

lg Mike

von Sven (Gast)


Lesenswert?

Nachtrag:
Stimmt, mit dem perlscript gehts nur mit dem beiligenden Kabel, mit dem 
welecupdater gehts auch ohne. Danke

von mike0815 (Gast)


Lesenswert?

hast du denn auch die Baudrate von 115200 am Port eingestellt?

Also ich hatte heute das erste mal das Perlskript benutzt, nach 3min war 
alles drinnen, ich dachte schon, es wäre nur die Hälfte angekommen, war 
aber alles i.O.
Wie kann so ein extremer Zeitunterschied zwischen den beiden 
Flash-Methoden sein???

Gruß, Michael

von Michael H. (Gast)


Lesenswert?

Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine 
Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der 
Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?

Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts 
angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger 
Rumdreherei erscheint das Signal dann auf einmal wieder.
Ich werde auch nochmal versuchen, das nachzustellen.

Gruß
Michael

von Rolf W. (rowue)


Lesenswert?

Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine
> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der
> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?
>

Es existieren Samplerates von 50 und 100 MSa/s, diese sind aber auch
in der Zeitbasis schwer auszuselektieren.

> Zu #38: Auch bei mir kommt es mit der HE immer wieder vor, dass nichts
> angezeigt wird, obwohl alle Einstellungen korrekt sind. Nach einiger
> Rumdreherei erscheint das Signal dann auf einmal wieder.
> Ich werde auch nochmal versuchen, das nachzustellen.

Ich konnte mittlerweile das Signal durch Drehung der 
Verstärkereinstellung
wieder "sichtbar" machen.
>
> Gruß
> Michael


Grüße,

    rowue

PS: Sachdienliche Hinweise zu den Tickets können gerne an die
entsprechenden Tickets angehängt werden ;)
PPS: Die neue FW sieht gut aus, hat aber leider einige neue Bugs.
QM mit Zeitbasen <50ns funktioniert leider immer noch nicht
(Skalierungsproblem?)

von Blue F. (blueflash)


Lesenswert?

Hallo Leute,

ich war zwischenzeitlich etwas beruflich eingespannt, so dass ich leider 
nicht zu meiner Lieblingsbeschäftigung gekommen bin. Eure Beiträge und 
Fehlermeldungen habe ich dennoch verfolgt und werde eine korrigierte 
Fassung der HE in Kürze hier posten damit wir das dann mal endlich in 
die OS Version reinpatchen können.

Ich war aber trotz alledem nicht untätig. In der Zwischenzeit habe ich 
mich mit anständigem Mess-Equipment eingedeckt, um mal zuverlässige 
Aussagen zum Einsatzbereich (Bandbreite und Signalintegrität) der W201x 
und W202x Geräte machen zu können (HP3325A Präzisionssignalgenerator, 
Tektronix 2465A 350MHz Oszilloskop). Wollen doch mal sehen was die W20xx 
so hergeben mit den neuesten Firmwareänderungen.

@Rolf

Kein Skalierungsproblem. Wie schon weiter oben gesagt liegt es mit 
ziemlicher Sicherheit daran, dass die interpolierten Daten in anderen 
Speicherbereichen liegen. Ob ich dazu auch noch komme weiß ich 
allerdings nicht.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Michael H. schrieb:
> Zu Ticket #40: wenn ich das richtig in Erinnerung habe, existieren keine
> Samplerates von 50 oder 100MSa/s, weil zwischen 250 und 25MSa/s der
> Übergang von 16k auf 4k Speichertiefe stattfindet. Stimmt das so?


Nein, der Grund ist entweder ein Fehler im FPGA-Design oder nur die 
vergurkte Firmwareprogrammierung. Ob Ersteres zutrifft ergründe ich 
noch. Wenn es nur die Firmware ist werde ich das auf jeden Fall 
nachrüsten, beim FPGA-Design kann ich nicht viel machen, außer die 
Sampletiefe und die Samplerate etwas geschickter zu verteilen als 
momentan. Da bleibt dann nur der Umstieg auf eins der neuen FPGA-Designs 
(siehe Hardware-Thread).

Gruß Hayo

von rowue (Gast)


Lesenswert?

Hi Hajo,

bei mir steht auch noch ein HP8116A und ein Grundig FG100,
ersterer könnte interessant sein, wenn wir mal in höhere
Bereiche gehen wollen ;)

Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
umzuschalten - dann hätten wir in allen Bereichen die
gleiche Aussteuertiefe (habe schon etwas dran gespielt,
muss da aber noch mal ran;)

Grüße,

    rowue

von Blue F. (blueflash)


Lesenswert?

rowue schrieb:
> Hi Hajo,
>
> bei mir steht auch noch ein HP8116A und ein Grundig FG100,
> ersterer könnte interessant sein, wenn wir mal in höhere
> Bereiche gehen wollen ;)

Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel 
Ausgang) ?

> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
> umzuschalten - dann hätten wir in allen Bereichen die
> gleiche Aussteuertiefe (habe schon etwas dran gespielt,
> muss da aber noch mal ran;)

Wie hast Du die Umschaltung gemacht (Softwareseitig oder 
Hardwareseitig)?


Werde gleich mal die ersten Ergebnisse meiner Vergleichstests 
veröffentlichen, allerdings wie es sich gehört im Hardwarethread.

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> rowue schrieb:
>> Hi Hajo,
>>
>> bei mir steht auch noch ein HP8116A und ein Grundig FG100,
>> ersterer könnte interessant sein, wenn wir mal in höhere
>> Bereiche gehen wollen ;)
>
> Nette Ausrüstung, kann der HP auch noch mehr als 50MHz (via Rear Panel
> Ausgang) ?

Müsste ich mal prüfen - tendentiell eher nicht, wobei
ich allerdings in der FFT auch bei 50MHz die Oberwellen bis
200MHz klar erkennen kann (inkl. des von Andre beschriebenen
"überziehens")

>
>> Btw:was hältst Du davon, die Verstärker malauf 1,2.5,5
>> umzuschalten - dann hätten wir in allen Bereichen die
>> gleiche Aussteuertiefe (habe schon etwas dran gespielt,
>> muss da aber noch mal ran;)
>
> Wie hast Du die Umschaltung gemacht (Softwareseitig oder
> Hardwareseitig)?

Über die Bit-Register - also Hardwareseitig - ich habe
als Skalierungsfaktoren (auf die 400 px) mittels Messung
2,55;2,56;2,55 herausbekommen (wobei der theor. Wert bei
2,4606 liegt) und will als nächstes Nachschauen, wie ich
den "ZeroScaleFactor" bestimme, auch, wenn mir die Werte
bekannt vorkommen ;)

Neben dem evtl. Vorteil, nur zwei Werte (delayed, normal)
für die Darstellung auf dem Bildschirm zu haben, hätte
das noch in der Auswertung den Vorteil nicht ständig die
veränderten Verstärkungen der einzelnen Stufen einbeziehen
zu müssen. Dafür hätten wir halt nur um die 156 Bit zur
Verfügung :(
>
>
> Werde gleich mal die ersten Ergebnisse meiner Vergleichstests
> veröffentlichen, allerdings wie es sich gehört im Hardwarethread.
>

o.k. ;) - Oder im SF-Forum ;)

> Gruß Hayo

Grüße,

   rowue

(Sorry für "Hajo" ;)

von Blue F. (blueflash)


Lesenswert?

Hmm,

ist doch etwas später geworden beim Griechen, daher gibt es die 
Fotoserie zu meinen Messungen erst morgen (also nachher).

Sorry Hayo

von Guido (Gast)


Lesenswert?

Hallo Hayo und Rolf,

die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet.
Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:
1
case 0 : dat_buf = 0x0005; break;
2
case 1 : dat_buf = 0x0005; break;
3
case 2 : dat_buf = 0x0005; break;
4
case 3 : dat_buf = 0x0005; break;// 10 mV
5
case 4 : dat_buf = 0x0045; break;// 20 mV
6
case 5 : dat_buf = 0x00D5; break;// 50 mV
7
case 6 : dat_buf = 0x0009; break;// 100 mV
8
case 7 : dat_buf = 0x0049; break;// 200 mV
9
case 8 : dat_buf = 0x00D9; break;// 500 mV
10
case 9 : dat_buf = 0x000A; break;// 1 V
11
case 10 : dat_buf = 0x004A; break;// 2 V
12
case 11 : dat_buf = 0x00DA; break;// 5 V

@ Rolf: Hast du das auch so?

Gruß, Guido

von Rolf W. (rowue)


Lesenswert?

Guido schrieb:
> Hallo Hayo und Rolf,
>
> die Verstärkungen 1, 2.5, 5 habe ich in BF0.56 schon mal getestet.
> Ich habe dafür folgende Einstellung in Hardware::Setswitches verwendet:
>
>
1
> 
2
> case 0 : dat_buf = 0x0005; break;
3
> [...]
4
> 
5
>
>
> @ Rolf: Hast du das auch so?

Genau so ;)

Ich habe dann mit dem HP in den 50, 20, 10 mV/DIV Stufen jeweils die 
Gleich-Spannungen in 1DIV Schritten von -4 DIV bis 4 DIV(*) eingestellt, 
mit dem Multimeter kontrolliert (0,3% Messgenauigkeit, in der weiteren 
Fehlerfortpflanzung vernachlässigt) und die (Roh-)Daten 
(bandbreitenbegrenzt) ausgelesen.

Von diesen Rohdaten habe ich jeweils die ersten 2048 Sätze genommen und 
die Mittelwerte gebildet. Mit diesen Mittelwerten (inkl. Fehler) habe 
ich dann eine lineare Regression (Fit mit Polynom ersten Grades) im 
Bezug auf Bits/DIV durchgeführt. Es ergaben sich folgende Zusammenhänge:
1
10 mV/DIV: 19,4926 pm 0,1738  Bits/DIV  (rel. Fehler: 0,8916%)
2
20 mV/DIV: 19,5195 pm 0,1507  Bits/DIV  (rel. Fehler: 0,7720%) 
3
50 mV/DIV: 19,6316 pm 0,1337  Bits/DIV  (rel. Fehler: 0,681%)

Als Skalierungsfaktoren für die Software hätte ich somit (**)
1
10mV/DIV: 2,5651 pm 0,0229
2
20mV/DIV: 2,5615 pm 0,0198
3
50mV/DIV: 2,5469 pm 0,0173

Mit folgenden Auflösungen [mV/Bit]:
1
10 mV/DIV: 0,513  pm 0,0046
2
20 mV/DIV: 1,0246 pm 0,0079
3
50 mV/DIV: 2,5469 pm 0,0173

Wenn gewünscht, kann ich die Änderungen an tc_hardware.cpp mal in's svn 
spühlen, dann können hier weitere Messungen zur Auflösung, etc 
vorgenommen werden - ich gehe da schon von - leichten - Unterschieden 
auf Grund der Bauteilstreuung aus.

Die angegebenen Fehler beziehen sich auf die Fehler der Anpassung (wie 
gut passt eine Kurve mit dieser Steigung auf die Messpunkte). Für die 
Fehler der berechneten Mittelwerte habe ich mal den mittleren relativen 
Fehler berechnet:
1
10 mV/DIV: 1,3653%
2
20 mV/DIV: 1,0736%
3
50 mV/DIV: 0,8531%

(ja, ich habe gepfuscht und die Standardabweichung des Fehlers nicht 
angegeben ;)

>
> Gruß, Guido

Grüße,

    rowue

(*)  Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
(**) Ich habe die Daten gerade noch mal ausgewertet, deshalb der
     Unterschied zum vorherigen Posting.

von Blue F. (blueflash)


Lesenswert?

Hi,

muß Euch leider noch mal auf morgen vertrösten mit meiner Bilderserie.


Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Rolf Würdemann schrieb:
> Guido schrieb:
>> [...]
>
> (*)  Also für 200mV/DIV z.B. von -200mV bis 200mV in 50mV Schritten.
Soll natürlich 50mV/DIV heissen ;)

> [...]

von Blue F. (blueflash)


Lesenswert?

@Rolf

Ich habe mal die Messungen in den Hardwarethread gestellt. Leider stehen 
mir nur bis 10 MHz die präzisen Rechtecksignale zur Verfügung. Darüber 
habe ich nur ein nicht ganz so sauberes Hilfssignal, dass ich auf der 
Rückseite des Funktionsgenerators abgreifen kann. Zudem habe ich da auch 
nur einen nicht einstellbaren recht kleinen Signalpegel. Da wäre eine 
Meßreihe mit Deinem 50 MHz Pulsgenerator sicher ganz interessant, zumal 
man da dann auch die verschiedenen Spannungsbereiche miteinander 
vergleichen könnte.

Gruß Hayo

von mike0815 (Gast)


Lesenswert?

moin erstmal,
ich habe folgendes bei der  Nullinienkalibrierung in fast allen 
Bereichen (Feintuning nur mit der DAC-Taste) festgestellt: bei 
mehrmaligen betätigen, war der erste Kanal nicht auf null zu bekommen, 
erst nach mehrmaligen verschieben des 1. Kanals (W2022A)nach oben(dann 
jedes mal die DAC-Taste betätigt), hat sich die Kalibrierung auf null 
eingestellt !

Im Quickmeasure habe ich zwischen beiden Kanälen einen Messunterschied 
(egal ob 1V, 2V oder 5V-Bereich) von 0,5V -0,7V! Erst wenn ich beide 
Kanäle in den unteren Bereich des Bildschirms verschiebe, sind die 
gemessenen Spannungen gleich!
Ich hoffe, die Info war nützlich...

Gruß, Michael

von Blue F. (blueflash)


Lesenswert?

@mike0815

Ok, danke das ist ein praktischer Hinweis zum Kalibrieren.

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> @Rolf
>
> [Pulsgenerator]

Hi Hayo,

sorry erstmal für die späte Antwort - ich hatte die letzten
Tage etwas sehr mit den 1;2.5;5 Faktoren und ihrer Abbildung
im Source gespielt ;)

Ich sehe mal zu, dass ich mir am WE noch das 2022A von
'nem Kollegen ausleihen kann, um dann mit beiden Geräten
entsprechende Aufnahmen zu machen. Allerdings könnte
es noch interessant sein, dies mit Deinem Tek zu vergleichen
(da ja die Bandbreite, etc. des HP nicht bekannt ist).

Alternativ könnte ich mit einigen Annahmen die "theoretischen"
Ausgangssignale des HP simulieren und dagegen stellen.

>
> Gruß Hayo

Grüße,

   rowue

von Rolf W. (rowue)


Lesenswert?

mike0815 schrieb:
> moin erstmal,

Mohltiet ;)

> [Problem mit der DAC-Kalibrierung]

@mike0815:

Welche Version nutzt Du? Die 0.92HE oder die 0.91OS?

@Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
Deiner letzten?

Ich weiss, dass Falk was an der ADC-Kalibrierung geändert
hat (r176, r178, die vor Deinem Urlaub war r172). Ich habe
bei meinen Spielereien (Faktoren) das Problem symmetrisch
zur Null-Linie (leicht, proportional zum Abstand).
>
> Gruß, Michael

Grüße,


   rowue

von Blue F. (blueflash)


Lesenswert?

Rolf Würdemann schrieb:

> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
> Deiner letzten?

Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er 
denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das 
Handling verändert?

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Rolf Würdemann schrieb:
>
>> @Hayo: Auf welche Version setzt Du auf? Die aus dem svn oder
>> Deiner letzten?
>
> Meiner letzten! Die Änderungen von Falk sind also nicht drin. Was hat er
> denn geändert? Hat er die Kalibrierung verbessert, oder "nur" das
> Handling verändert?

Generell? Oder bezogen auf die ADC-Kalibrierung?

Letzteres:
http://sourceforge.net/apps/trac/welecw2000a/changeset/176/fpga/nios/oss/trunk/src/hardware_t.cpp


Wenn Du eine Übersicht haben möchtest:

http://sourceforge.net/apps/trac/welecw2000a/log/fpga/nios/oss/trunk
>
> Gruß Hayo


Grüße,

    rowue

von mike0815 (Gast)


Lesenswert?

Hallo Rolf,

> [Problem mit der DAC-Kalibrierung]

...ich nutze die letze Ver.92HE auf W2022 (Hardwarever. 8C7.0L)

...du meine Fres.., eben mach ich das Teil an, da sind beide Nullinien 
(Kanal 1+2 1V-Div)1,5 Teilstriche nach unten gerutscht, nach 1x 
Dac-Abgleich, geht der 2.Kanal exakt auf null, der 1.Kanal zickt noch 
herum.
Wenn ich die Nulllinie (nur 1.Kanal)mehrmals nach unten u. oben 
verschiebe und nach jedem schieben die DAC drücke, bequemt auch er sich 
endlich aufzusetzen!
Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config 
geschrieben und dann abgespeichert, nein, doch???
Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die 
Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann 
wieder Ok.

...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe 
Problem???

Gruß, Michael

von Blue F. (blueflash)


Lesenswert?

mike0815 schrieb:

> Ich dachte, die Kalibrierung wird nach dem Abgleich in die Config
> geschrieben und dann abgespeichert, nein, doch???

Jupp, wird sie.

> Jetzt hatte ich nochmal abgeschaltet und neu hochgefahren, die
> Nulllinien waren wieder etwas verschoben, nach 1x DAC drücken war's dann
> wieder Ok.
> ...liegt das jetzt explizit nur an meinem Gerät, oder habt ihr dasselbe
> Problem???

Hmm, das muß ich mal überprüfen. Die 0.93HE steht in den Startlöchern. 
Da hat sich einiges getan. Unter anderem habe ich die Startupsequenz 
komplett geändert um den Reload aus dem Flash für jede Ausgangssituation 
zu gewährleisten und nebenbei das gemeldete Problem mit dem Restart nach 
Delayed-Betrieb zu beseitigen.

Vielleicht läßt sich das dann gleich mit erledigen.

Gruß Hayo

von Mike K. (1tester)


Lesenswert?

Nur mal so ne dumme frage aber woher bekommt man eigentlich das Bin für 
die Holiday edition?

lg Mike

von Blue F. (blueflash)


Lesenswert?

Da es sich nicht um offizielle Releases handelt, sondern um 
Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter 
oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im 
Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten 
Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so 
dass es über eine einfache Korrektur doch schon hinausgeht.

Hayo

von mike0815 (Gast)


Lesenswert?

Hallo Hayo,

> Die 0.93HE steht in den Startlöchern. <

ach, das wird wieder eine HE?? Ist ja wurscht, ich bin schon ganz 
gespannt, wann ist denn mit der 093HE zu rechnen?
Jedenfalls, macht es hier einen riesen Spass!
Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen 
betrifft, da es mein Erstes ist...nach 35 Jahren...'lach'
Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und 
der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne 
Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche 
Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da 
noch was versaue!!!
Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese 
für übersichtlicher halte als die SVN.
Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen 
und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch 
übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine 
oder andere Anfänger, so wie ich es bin, einen besseren Durchblick 
erhalten!!!
Hoffentlich gibt's jetzt kein Augenrollen bei den Profis...

Mein Gedanke dabei ist, das sich dann auch weniger Versierte hier 
beteiligen und ihren Beitrag zum Projekt leisten können, denn viele 
Augen, sehen auch mehr...und wenn es auch nur Kleinigkeiten sind 
(vielleicht mit großer Wirkung), die Andere nicht sehen oder gesehen 
haben.
Wie auch immer, wäre nur ein Vorschlag von mir...

Grüsse an alle aus dem Hessenland

von Guido (Gast)


Lesenswert?

@ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im
Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach
ausschalten.

Gruß, Guido

von Blue F. (blueflash)


Lesenswert?

mike0815 schrieb:

> ach, das wird wieder eine HE??

Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist 
werde ich das HE mal mit anhängen um den Bezug herzustellen und um 
klarzustellen, dass es keine offizielle Version aus dem SFN ist.

> Jedenfalls, macht es hier einen riesen Spass!

Das geht uns allen auch so, daher verbraten wir hier ja auch soviel Zeit 
anstatt soziale Kontakte zu pflegen ;-)

> Ich selber bin noch in der Aufbauphase was den Umgang mit Oszilloskopen
> betrifft, da es mein Erstes ist...nach 35 Jahren...'lach'

Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses 
Projekt!

> Immerhin habe ich keine Probleme beim Backup und Flashen, Quartus und
> der USB-Treiber von Slog ist ebenfalls installiert und funzt ohne
> Probleme, würde ja gerne mehr experimentieren, nur habe ich so manche
> Bedenken, beim Aufspielen z.B. EPCS16N aufzuspielen, nicht das ich da
> noch was versaue!!!

Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die 
reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei 
Gelegenheit auch mal ausprobieren.

> Schade, das die Google-Groups nicht mehr so gepflegt wird, da ich diese
> für übersichtlicher halte als die SVN.

Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein 
paar Dokus oder Softwarebundles ablegen.

> Vielleicht könnte man von dem Projekt einige Kopien dort hinein setzen
> und somit auch die eine oder andere Anleitung zusätzlich auf Deutsch
> übersetzen, (so wie es z.B. in den Flashversionen) damit auch der eine
> oder andere Anfänger, so wie ich es bin, einen besseren Durchblick
> erhalten!!!

Leider wurde die Seite für den Upload gesperrt und wird vermutlich auch 
nicht wieder geöffnet um den Fokus auf die SFN-Seite zu setzen.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Guido schrieb:
> @ mike0815: kleine Korrektur noch: Die Kalibrierwerte werden im
> Flash gespeichert wenn du die Zeitbasis verstellst. Erst danach
> ausschalten.

Hi Guido, kleine Korrektur meinerseits, seit einigen Versionen (frag 
mich jetzt nicht nach der genauen) werden die Einstellungen direkt 
gespeichert. Das erkennst Du an folgendem Coding:

  //Save new values to flash
  config_changed = true;

Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal 
ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen 
Konfigurationsdaten ins Flash geschrieben.

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,


> > Die 0.93HE steht in den Startlöchern. <
>ach, das wird wieder eine HE?? Ist ja wurscht...

Also mir ist das ganz und gar nicht wurscht!
Ab dem 05.10 werde ich wieder an der GUI weiter entwickeln (Mein 
Co-Programmierer ist derzeit anderweitig beschäftigt).
Leider ist in den HE Versionen der Datentransfer nicht im vollen Umfang 
verwirklicht (Befehlssatz gem. SF), demzufolge kann ich diese nicht zur 
Entwicklung heranziehen! Die in den Grundzügen bereits vorhandene GUI 
baut ergo auf die OS 0.91 auf.... schade, da mit dieser Version bei mir 
massive Probl. bei höheren Freq. auf Ch1 auftreten.


Gruß, brunowe

von mike0815 (Gast)


Lesenswert?

hallo Hayo,

> Ja ich dachte mir da es im Prinzip eine fehlerkorrigierte 0.92HE ist...<

...stimmt, bin ich ganz deiner Meinung!!!

> ...anstatt soziale Kontakte zu pflegen ;-) <

nun ja, man(Mann) sollte das tun, was ihm Spass macht, das Leben ist 
kurz...

> Ist doch zum Kennenlernen von Theorie und Praxis geradezu ideal dieses
Projekt! <

ABSOLUT!!!

> Da kann ich wenig zu sagen, da ich mich bislang größtenteils auf die
reine FW-Entwicklung konzentriert habe. Allerdings wollte ich das bei
Gelegenheit auch mal ausprobieren. <

Das ist auch gut so, denn so hat jeder seinen Part, der Tag hat ja nur 
24 Std.(leider)

> Das fand ich auch, da ließen sich recht unkompliziert einfach mal ein
paar Dokus oder Softwarebundles ablegen. <

ist das denn im SVN nicht auch möglich??? Ja ich weiß, Innternational 
(Die Russen sehr aktiv...)
Nur könnte das eine oder andere in Englisch falsch verstanden werden, 
also mir geht's manchmal so, dann komme ich in's schleudern, wie wäre es 
mit Kopien in deutscher Sprache??? Ich denke, das das der eine oder 
andere Hobbyist begrüssen würde, da ja nicht alle der englischen Sprache 
(z.B. Spezialausdrücke...) mächtig sind.

> Leider wurde die Seite für den Upload gesperrt... <

hmm, wieso das denn? Könnte man das nicht parallel bestücken, oder wäre 
da der Aufwand zu groß???

Gruß Michael

von Cra Z. (crazor)


Lesenswert?

Hayo W. schrieb:
> Diese Variable wird beim Durchlauf der Hauptschleife jeweils einmal
> ausgewertet und wenn sie gesetzt ist werden alle gerade aktuellen
> Konfigurationsdaten ins Flash geschrieben.

Erfolgt das Setzen in Interrupt-Handlern? Dann erfolgt das 
Rücksetzen&Flashen hoffentlich unter Ausschluss von weiteren Interrupt? 
;)

von mike0815 (Gast)


Lesenswert?

hallo brunowe,

>Also mir ist das ganz und gar nicht wurscht!<

...das konnte ich ja nicht wissen, wie werdet ihr euch denn da jetzt 
einig? Jetzt wird's kompliziert, wenn sich die Versionen dermaßen 
unterscheiden?!?
...un nu?

Gruß Michael

von Blue F. (blueflash)


Lesenswert?

@Bruno

Wenn die 0.93HE hier getestet wurde und keine größeren Fehler mehr 
auftreten, können die Änderungen in die OS-Version einfließen. Bislang 
war das Ganze noch nicht ausgereift genug um es einfach da rein zu 
mergen. Es handelt sich doch zum Teil um recht umfangreiche Änderungen, 
daher möchte ich vorher sichergehen das da dann nicht neue Fehler mit in 
die OS-Version eingebaut werden (so wie sie ja in der 0.92HE vorhanden 
waren). Die wären ja ansonsten jetzt schon mit drin.

Andererseits muß ich erst prüfen ob ich alle Änderungen der OS-Version 
auch in meiner eigenen Version haben möchte. Mir fehlt da momentan der 
Überblick ob das alles stabil läuft und ungeprüft will ich das nicht 
einfach so übernehmen.

Gruß Hayo

von Michael D. (mike0815)


Lesenswert?

Ich nochmal zum "DAC-Abgleich"

...habe festgestellt(W2022A-092HE), das wenn ich die DAC-Kalibrierung 
durchgeführt habe und dann den NOIS Filter einschalte, ich nochmals 
einen Abgleich durchführen muß (DAC-Taste drücken), diesmal nur 1x in 
den 5er-Bereichen, in allen anderen Bereichen, muß ich mindestenst 1-4x 
die DAC-Taste drücken, dann erst ist alles hübsch!

Dann hätte ich noch eine Frage zum Coupling-Mode, was für eine Bewandnis 
hat es mit dem PROBE-Softkey? Welche Funktion hat er? Kann ich intern 
1:1 - 1000:1 schalten oder was hat er für eine Funktion?

Gruß Michael

von Michael H. (Gast)


Lesenswert?

Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch 
wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden. 
Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist 
angezeigt.

Gruß
Michael

von Michael D. (mike0815)


Lesenswert?

Michael H. schrieb:
> Wenn du einen Tastkopf mit Vorteiler anschließt, muss das Oszi das doch
> wissen, damit trotzdem die richtigen Spannungswerte angezeigt werden.
> Wenn du den Tastkopf von 1:1 auf 10:1 umschaltest, wird doch sonst Mist
> angezeigt.
>
> Gruß
> Michael

...logisch! Ist denn der 'MIST', der da angezeigt wird, so erheblich 
bzw. die Werte falsch? Wenn ich am Tastkopf 10:1 eingestellt habe, dann 
habe ich z.B. 680mV als 6,8V umgerechnet...
...nun ja, das ist dann natürlich eine angenhme Sache, d.h. wenn ich den 
Tastkopp auf 10:1 stelle muß ichh den PROBE-Knopp auch auf 10:1 
schalten?

Habe das eben mal gestestest: Tastknopp 10:1 und Probeknopp ebenfalls 
auf 10:1 und wieder zurück auf 1:1...
Es gibt vom Messverhalten keinen Unterschied beim verstellen des 
PROBE-Knopp's!
...und stimmt, bei Tastkoppschalter 1:10 kommt Müll raus, ist da jetzt 
der Eingang hinüber, oder was?


Gruß Michael

von branadic (Gast)


Lesenswert?

Hallo Michael,

bevor du noch lange weiterfragst, würde ich dir folgenden Link einmal 
empfehlen:

http://www.google.de/#hl=de&source=hp&q=messen+mit+dem+oszilloskop&btnG=Google-Suche&meta=&aq=0&oq=messen+mit+dem+oszilloskop&fp=8fee3db28befc153

Danach solltest du dir einen Großteil deiner Fragen selbst beantworten 
können.

Gruß, branadic

von Cra Z. (crazor)


Lesenswert?

Ansonsten bleibt noch zu erinnern: Man kann an 2 Orten den Vorteiler 
einstellen: Im Kanal- und im Trigger-Menü...

von lötfix (Gast)


Lesenswert?

@Michael

Kauf dir ein Tek - das erkennt, wenn du am Tastkopf 10:1 eingestellt 
hast... ;-)

von Michael D. (mike0815)


Lesenswert?

...jetzt hab' ich mein Fett weg...

...ein Tek, ja genau, vielleicht mach ich noch ne' Sammlung auf.

von Jürgen (Gast)


Lesenswert?

So, jetzt muss ich doch mal meinen Senf dazu geben!

Hayo W. schrieb:

>Da es sich nicht um offizielle Releases handelt, sondern um
>Testversionen poste ich sie hier. Die 0.92HE findest Du etwas weiter
>oben, die 0.93HE kommt in Kürze auch hier. Dabei handelt es sich im
>Wesentlichen um eine Fehlerkorrektur der in der 0.92HE gemeldeten
>Fehler. Allerdings habe ich dafür einige Sachen komplett umgestrickt, so
>dass es über eine einfache Korrektur doch schon hinausgeht.

>Hayo

Was heisst hier"nicht offizielle Releases"? Du hast doch mindestens 90% 
der bisherigen (NIOS1-) Firmware Entwicklungsarbeit geleistet und hast 
mittlerweile den besten Überblick über Struktur und Konzept! Für mich 
und sicher auch andere ist es immer noch das offizielle Release, da 
nicht nur punktuell an einigen Ecken geändert wurde! Und, so umfangreich 
waren die bisherigen Änderungen in der 0.91 ja wohl nun doch nicht, daß 
sie nicht mit einer 0.93HE zusammen geführt werden könnten.
Deshalb bitte: Die 0.93HE wieder mit Sourcen veröffentlichen, damit man 
sich ein Bild machen kann, wo denn nun die Ergänzungen der 
sogenannten"offiziellen Version"liegen!

Musste ich mal loswerden.

Gruß Jürgen

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Jürgen,

mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben 
gebracht hat...
melde dich bei SF an, und merge die Versionen!!!
Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas 
scheut...


Gruß, brunowe

von Blue F. (blueflash)


Lesenswert?

Hi,

der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich 
eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die 
Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne 
bei.

Ich selbst entwickle zur Zeit immer noch auf der Basis meiner eigenen FW 
da mir die Änderungen an der OS-Version nicht verifiziert bzw. validiert 
genug sind. Mir fehlt da momentan der Überblick wer da alles an welchen 
Baustellen herumflickt und ob das alles richtig gestestet wird. Daher 
ist es mir (zumindest momentan) lieber, die Änderungen die ich in meiner 
FW ausgiebig getestet habe nachträglich in die OS-Version einfließen zu 
lassen, bzw. sinnige Änderungen aus der OS-Version zu übernehmen.

By the way: gibt es einen konkreten Status zur Remoteschnittstelle und 
zur Screenshotfunktion? Läuft das stabil?

Gruß Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Hayo,

der Status der implementierten Befehle ist hier dokumentiert:
http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI

Das USB Protokoll ist hier beschrieben:
http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol

Der Datentransfer via RS232 läuft absolut stabil. Leider lassen die 
derzeit möglichen 115kBd keine tolle refresh- rate bei meiner GUI zu.
Die RS232 ist da eindeutig der limitierende Faktor was z.B. die live 
Darstellung einer FFT betrifft (ca. 2-3 Bilder/s). Im neuen VHDL Design 
kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden, 
aber da sollen sich die VHDL Profis ruhig noch etwas spielen.

Gruß, brunowe

von Cra Z. (crazor)


Lesenswert?

Bruno We schrieb:
> Im neuen VHDL Design
> kann die Transfer- Rate wohl zumindest auf 230kBd gesteigert werden,

Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die 
mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige 
was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Hi,
>
> der Grund warum ich erstmal keine Sourcen beigelegt habe ist, dass ich
> eine Abspaltung der Entwicklungslinie verhindern wollte. Wenn jemand die
> Sourcen in die OS-Version mergen möchte lege ich die Sourcen aber gerne
> bei.

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo,

> Nee, auch im originalen Design von den Wittigs ist doch die 2. UART, die
> mit dem FX1 verbunden ist, in ihrer Baudrate konfigurierbar. Das einzige
> was zu 230KBd fehlt, ist eine USB-UART-Firmware für den FX1....

Ok... soweit logisch. Dachte allerdings das der FPGA die Daten dann auch 
in der dementsprechenden Geschwindigkeit "weiter schieben" muss?! Oder 
ist die Geschwindigkeit via FW anpassbar, also nicht via HW fix 
vorgegeben?

Gruß, brunowe

von Jürgen (Gast)


Lesenswert?

Hallo brunowe,

>mein Vorschlag als einer der Ersten der das Projekt überhaupt zum Leben
>gebracht hat...

Danke sehr dafür !

>melde dich bei SF an, und merge die Versionen!!!
>Trotz SVN ist genau das die Arbeit, vor der sich derzeit jeder etwas
>scheut...

Das ist wohl nicht der wirkliche Grund. Ich bin erstmal zufrieden, daß 
ich mir die aktuellen Sourcen z.Zt.in einem Stück herunter laden kann u 
hab jedenfalls keine Lust mich erst wieder durch seitenlange Help-Files 
zu kämpfen und am Ende vom System unverständliche Fehlermeldungen zu 
bekommen.

Gruß Jürgen

von Jürgen (Gast)


Lesenswert?

@ brunowe
Brunowe schrieb:

>Das USB Protokoll ist hier beschrieben:
>http://sourceforge.net/apps/trac/welecw2000a/wiki/...

Diese Beschreibung ist doch wohl sehr unvollständig!
Was ist denn mit der original Protokollbeschreibung von Welec, 
zusammengestellt von Jochen Schäuble?
http://schaeuble.info/de/category/jochen/w2000a

Das USB Protokoll funktioniert so noch in der OS 0.91. Allerdings ist 
dieses Protokoll überhaupt nicht auf Geschwindigkeit optimiert.
Oder soll Deine GUI nur über RS232 laufen und das USB-Protokoll hat 
darauf keinen Einfluß?

Beste Grüße,
Jürgen

von Rolf W. (rowue)


Lesenswert?

Hi ...

Nach dem ich einige Tage Don Quichotte gespielt habe, nun einige
Kommentare zum Thema svn/sfn von mir:

Begriffsunterscheidung:

  svn: Abkürzung für Subversion - System zur Versionsverwaltung
       (Source-Code, Messdaten, Texte) - ich verwende dieses z.B.
       für Messdaten ebenso wie für Texte (u.a. meine damalige DA)
       als auch für Sourcen.

       svn bietet hier die nette Möglichkeit, Änderungen zu
       dokumentieren und ggf. wieder Rückgängig zu machen.

  trac: System zur Verwaltung von Projekt-Daten - spielt wunderbar
        mit svn, enthält u.a. ein Wiki ein Ticketsystem und bietet
        die Möglichkeit, Änderungen im Source und Tickets zu
        verlinken (damit mensch nachher sehen kann, wofür die
        Änderung gemacht wurde (Bugfixes))

  sfn: Plattform für Open-Source Projekte, u.a. mit verteilter
       Distribution und Angebot, svn, und trac zu verwenden.

Wenn jemand nun auf die Seite:

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

geht, landet man im Trac-Wiki des SFN-Projektes und kann sich
z.B. die Sourcen (mit Änderungen) im svn oder offene/geschlossene
Tickets ansehen.


Oben auf der Seite steht:

"Visit project welecw2000a", ebenso wie "Welec W2000A". Beide
Links führen auf die Seite:

   http://sourceforge.net/projects/welecw2000a/

Dort befindet sich eine Sektion "Files". In dieser Sektion
findet man die Releases - also die herausgegebenen Versionen.

Während im svn (derzeit) nur die Sourcen drin sind, sind hier
auch die compilierten Versionen (soweit verfügbar) drin, welche
sich dann einfach in das DSO hochladen lassen.

Die Sourcen einiger Releases (es sollten eigentlich alle sein ;)
findet man im svn unter:

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/tags

Das Verzeichnis

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/trunk

enthält den derzeitigen Entwicklungstand (der OS Version).

Über das Verzeichnis

  http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/oss/branches

können z.B. Abzweigungen im Source-Tree (tiefgreifende Änderungen,
Version 2.0, etc) verwaltet werden (um diese dann später wieder
in den trunk einzupflegen)

Wird auf Basis des svn(-Tree) gearbeitet, so lassen sich 
Versionskonflikte zumeist sehr einfach lösen. Hier könnten wir aber das 
Problem haben,
dass der Dateiaufbau der BF und der der OS sich unterscheiden. Falk 
hatte damals die Änderungen von Hayo eingepflegt, das war aber eben mal 
drei Stunden Arbeit (und händisches einpflegen ist eher fehleranfällig).

Die Arbeit mit svn scheint erstmal sehr viel Overhead zu haben,
hat sie aber nicht - ist der Client der Wahl (gerne auch cli) gefunden, 
so ist die Lernkurve sehr steil (Nach dem Motto: einen Tag für den 
Client der Wahl, 'nen viertel Tag für das svn) und die Vorzüge einer 
Versionsverwaltung sind in einem Projekt (egal ob Text, Source oder
Messdaten) nicht zu unterschätzen (wer einmal Rohdaten weggeworfen hat 
und sie nachher wieder brauchte wird dies bestätigen können).

Wenn ich mir die Tickets im Trac ansehe
(http://sourceforge.net/apps/trac/welecw2000a/report/1)

sieht man, dass sowohl in der BF als auch in der OS Fehler offen sind.
Wir können nun daraus zwei Baustellen machen. Oder gemeinsam an 
einer
arbeiten.


Grüße,

    rowue

PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer 
Abweichung von 1,8% ...

von branadic (Gast)


Lesenswert?

> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer
> Abweichung von 1,8% ...

Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite 
aufmerksam machen:

http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement

Gruß, branadic

von Rolf W. (rowue)


Lesenswert?

branadic schrieb:
>> PS: Zur Qualität der Änderungen: Ich arbeite hier gerade an einer
>> Abweichung von 1,8% ...
>
> Dann möchte ich dich vielleicht auf den unteren Teil dieser Seite
> aufmerksam machen:
>
> http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement

merci ;)
>
> Gruß, branadic


Beste Grüße,

   rowue

von Kurt B. (kurt)


Lesenswert?

Hallo Leute!

Hat jemand von Euch mit dem Vinculum Board weitergearbeitet?

Der USB Stick hat leider sehr unterschiedliche Zugriffszeiten sodass 
wahrscheinlich ein FIFO und ein Handshake in die Kommunikation mit dem 
Oszi eingebaut werden muss.

Es wäre schön, wenn jemand der das bisherige Protokoll versteht es mal 
im Klartext notieren könnte. Damit meine ich die den Teil der den 
Screenshot einleitet, die Lauflängendekodierung und die Bilderstellung.

Dann könnte man das Protokoll in Richtung Handshake optimieren und auf 
den Mikocntroller portieren.

Mfg,
Kurt

von branadic (Gast)


Lesenswert?

Hallo zusammen,

da viele scheinbar ja ein unglaubliches Problem mit der englischen 
Sprache haben, gibt es jetzt im SourceForge phpBoard einen 
deutschsprachigen Bereich.
Zu finden ist das Ganze hier:

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

Eine Anmeldung bei SourceForge ist natürlich notwendig, dafür sind die 
wichtigen Diskussionen dann unmittelbar mit der Haupt-Projektseite 
verbunden und nur wirklich Projektinvolvierte nehmen an der Diskussion 
teil.

Das Forum bitte nicht mit sinnlosen Kommentaren füllen, die allgemeinen 
Regeln einhalten und bei Fragen, einfach eine Mail an die Administration 
senden, bspw. wenn ein neues Unterforum angelegt werden müsste/könnte. 
Topics dürft ihr selbst starten. Bitte haltet die Struktur ein. Für 
Anregungen ist euere Meinung aber gern gefragt.

Topics bitte hinreichend genau benennen, damit alles auch übersichtlich 
bleibt. So ist im Firmware-Bereich die Struktur:

NIOS - Problemstellung
ZPU - Problemstellung
LEON3 - Problemstellung

denkbar, allerdings könnten hier auch extra Unterforen für die 3 
Prozessoren angelegt werden.
Ich denke wir kommen damit den nicht englischsprachigen Leuten sehr weit 
entgegen, nutzt die Plattform bitte auch.

Beste Grüße, branadic

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi,
hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers 
müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst 
gibts Ärger von der Chefin.

Auch wenn sich oberflächlich außer der Fehlerkorrektur scheinbar nicht 
so viel getan hat, sind die Änderungen unter der Haube recht 
umfangreich.

Das DSO startet jetzt nach dem Ausschalten immer mit der letzten 
(gespeicherten) Einstellung vor dem Ausschalten. Neu ist hierbei unter 
Anderem die Unterstützung für den Math-Betrieb (auch FFT) und den 
USTB-Betrieb.

Um etwas kompatibler zur OS-Version zu sein habe ich Falks aktuelle 
Version der Remoteschnittstelle mit eingebaut. Ich habe es allerdings 
nicht mehr geschafft die Screenshot-Version umzurüsten, daher bitte 
wieder die beigelegte Version verwenden.

Da es letztens hier angefragt wurde lege ich die Sourcen diesmal bei.

Achtung - dies ist keine Entwicklerversion für das SFN! Nach 
erfolgreichen Tests können die Änderungen je nach Zustimmung in die 
SFN-Version übernommen werden. Ob ich das mache oder jemand anderes 
können wir ja noch klären.

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

Hallo zusammen,

ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster 
Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder 
andere Sache beisteuern können.

@Hayo

Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine 
Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk 
mitbekommst.

von Blue F. (blueflash)


Lesenswert?

Stefan E. schrieb:
> Hallo zusammen,
>
> ich habe ja lange nichts mehr von mir hören lassen. Aber ab nächster
> Woche ist wieder mehr Zeit. Da werde ich sicher wieder die eine oder
> andere Sache beisteuern können.

Super!

> Leg dir doch im SFN einen branch an. Dann kannst du ungestört deine
> Sourcen einpflegen, während du gleichzeitig alle Änderungen im trunk
> mitbekommst.

Da muß ich zu meiner Schande gestehen, dass ich noch keine Zeit gefunden 
habe mich mit SVN und drumherum auseinanderzusetzen. Wenn ich 
zwischendurch Zeit hatte hab ich nur an der FW rumgeschraubt. Muß ich 
also noch ran. Dann werde ich Deinen Vorschlag mal aufgreifen.

Ansonsten noch an alle viel Spaß beim Testen,

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Hi,
> hat etwas gedauert mit der nächsten Version, aber zum Ende des Sommers
> müssen halt erst die restlichen Arbeiten im Garten fertig werden, sonst
> gibts Ärger von der Chefin.

Das wollen wir ja nicht! ;)

>
> [1.2.BF.094.HE]

Ich habe die Version in's Ticket-System eingetragen,
dann können evtl. Fehler dort gleich eingetragen werden ;)

URL: http://sourceforge.net/apps/trac/welecw2000a/report


>
> Achtung - dies ist keine Entwicklerversion für das SFN! Nach
> erfolgreichen Tests können die Änderungen je nach Zustimmung in die
> SFN-Version übernommen werden. Ob ich das mache oder jemand anderes
> können wir ja noch klären.

Vorschlag: lass uns beide das doch gemeinsam machen ;)
>
> Gruß Hayo


Grüße,

    rowue

von Blue F. (blueflash)


Lesenswert?

Ok,

wie hattest Du Dir das vorgestellt?

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Ok,
>
> wie hattest Du Dir das vorgestellt?

Wir treffen uns Samstag (früher Nachmittag), erstellen
erstmal einen unified diff Deiner aktuellen Sourcen zum
Stand 0.88 (war glaube ich der, den Hayo zum einpatchen
vervendet hat) und patchen mit Hilfe dieses Diffs die
Sachen in das svn.

Treffen könne wir uns (von meiner Seite aus) bei Dir,
bei mir oder bei mir in der Firma. Zu Dir müsste ich
mit Bus/Bahn und (ggf.) Fahrrad.

Bei mir stände uns ein grosser Schreibtisch und eine seperate
Werkbank zur Verfügung. Da ich gerade zwei Geräte (W2014A,
W2022A) zur Verfügung habe, könnten wir die Patches auch
gleich auf beiden Geräte testen. Wenn Du das Tek mitbringst,
könnten wir uns ebenso die Ausgaben des HP auf den drei Geräten
ansehen.

Bei mir in der Firma hätten wir in der Werkstat viel Platz
und Internet bis zum Abwinken, müssten aber evtl. unsere
Geräte (falls wir was testen möchten) rantragen (ISP).

>
> Gruß Hayo

Grüße,

    rowue

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

Hi allerseits,

hier die aktualisierte 0.95HE - Bruno war aufgefallen dass die 
Remoteschnittstelle nicht funktioniert, daher habe ich nochmal gesucht 
und festgestellt, dass ich vergessen hatte die UART-ISR mit 
nachzuziehen. Das sollte jetzt also funktionieren. Falls es noch 
Probleme gibt immer raus damit.

@Rolf

Hört sich echt gut an, leider bin ich jetzt am WE komplett ausgebucht, 
da ich Besuch aus dem Ruhrpott bekomme. Grundsätzlich können wir das 
aber gerne machen. Welche der Örtlichkeiten wir dann wählen können wir 
dann ja kurzfristig abstimmen.

Gruß Hayo

von Jürgen (Gast)


Lesenswert?

Hi Hayo,

konnte zwar gestern nur kurz testen, aber bei 1Gs/s-50ns/div und Noise 
Filter on und im Single Shot wandert die die Anzeige im Stop 
unweigerlich nach links aus dem Bildschirm hinaus. Passiert aber nur mit 
eingeschaltetem Noise Filter. Bei Normal und Averaging nicht!

Gruß Jürgen

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Hi allerseits,
>
> [0.95HE]

Habe das Ticket-System angepasst (und die 0.94HE dort gelöscht)
Es wäre nett, wenn Fehlermeldungen (überwiegend) dort landen ;)
>
> @Rolf
>
> [Besuch aus dem Pütt]

O.K. - wollen wir dann das nächste Wochenende (10./11.10.,
preferiert: Samstag, den 10.10) in's Auge fassen? ;)

>
> Gruß Hayo


Grüße,

   rowue

von Blue F. (blueflash)


Lesenswert?

@Jürgen

Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu 
sein, denn das Problem müßte eigentlich auch bei den älteren Versionen 
auftreten. Ich weiß auch schon so ungefähr woran es liegt.

Danke für den Hinweis

Hayo

von Blue F. (blueflash)


Lesenswert?

Ok,

Bug erkannt - Gefahr gebannt. Ist erledigt. Nebenbei habe ich noch die 
Start/Stop-Logik beim Singleshot optimiert.

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> @Jürgen
>
> Ok, habs mir mal angesehen. Scheint vorher noch niemendem aufgefallen zu
> sein, denn das Problem müßte eigentlich auch bei den älteren Versionen
> auftreten.

Schau mal in's Ticket-System ;)

http://sourceforge.net/apps/trac/welecw2000a/report/1

> Ich weiß auch schon so ungefähr woran es liegt.
>
> Danke für den Hinweis
>
> Hayo
Grüße,


   rowue

von Blue F. (blueflash)


Lesenswert?

Du meinst Ticket 39??

Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung 
eher in eine andere Richtung wies. Werde ich dann resolven wenn die 
Korrektur raus ist.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

So,

da nach über 50 Downloads jetzt keine weiteren Rückmeldungen vorliegen 
scheint es zumindest keine gravierenden Schnitzer zu geben. Die 
Remoteschnittstelle scheint daher wohl auch zu funktionieren.

Daher hier nochmals eine fehlerkorrigierte HE. Das wegdriftende Signal 
im Stopmodus bei eingeschaltetem Noise-Filter ist gefixed. Bei der 
Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so 
dass diese jetzt vernünftig funktioniert. Nebenbei habe ich noch weiter 
das Coding aufgeräumt und tote Variablen und Coding gelöscht. Beim 
ersten Start könnte es leichte Nebeneffekte geben, da sich das 
Flashlayout mal wieder etwas geändert hat.

Ein einfaches Default-Setup sollte das aber beheben.

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Du meinst Ticket 39??
>

Jupp ;)

> Das hatte ich nicht damit in Verbindung gebracht, da die Beschreibung
> eher in eine andere Richtung wies. Werde ich dann resolven wenn die
> Korrektur raus ist.

Die Beschreibung war nicht allzu gut - sorry ...
ich hatte das Phänomen, dass am linken Rand (des Signals)
dieses bei Betätigen der Stop-Taste an den oberen Bildschirm-Rand
zog.
>
> Hayo


Grüße,

   rowue

PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt

von Michael H. (stronzo83)


Lesenswert?

Die Single/Run Logik kapiere ich noch nicht so recht - hilfst du mir auf 
die Sprünge?

Michael

von Michael H. (stronzo83)


Lesenswert?

Ah da stimmte noch was nicht mit meiner Masse, jetzt macht das ganze 
Sinn und scheint auch gut zu funktionieren.

Michael

von Blue F. (blueflash)


Lesenswert?

Zum Singlemodus ist noch anzumerken, dass der Triggermode zwangsweise in 
den Normalmodus geschaltet wird, damit auch wirklich nur dann ein neues 
Ereignis ausgelöst wird wenn die Triggerschwelle überschritten wird.

Sollte da aber nichts kommen (zu hoher Triggerlevel oder so) wartet das 
DSO natürlich bis zum Sankt Nimmerleinstag.

Der Singlemodus steht jetzt nur noch dann zur Verfügung wenn der 
Single-Druckknopf grün hinterleuchtet ist - dazu muß man die 
Run/Stop-Taste drücken. Im aktivierten Zustand ist der Druckknopf orange 
hinterleuchtet. Nach erfolgtem Triggerereignis ist er wieder grün und 
signalisiert damit Bereitschaft. Das Ganze wird durch erneutes Drücken 
der Run/Stop-Taste beendet.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Rolf Würdemann schrieb:
> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt

Sind aber noch genug für alle da...      ;-)

Gruß Hayo

von Rolf W. (rowue)


Lesenswert?

Hayo W. schrieb:
> Rolf Würdemann schrieb:
>> PS: Du hast ja heute morgen gut im Ticket-System aufgeräumt
>
> Sind aber noch genug für alle da...      ;-)

Wink verstanden ;)
Ich hoffe mal, dass ich Fr/Sa mit der Geschichte an der
ich gerade bin durch bin, dann kann ich mir das eine oder
andere "greifen" ;)
>
> Gruß Hayo

Grüße,

   rowue

von Stefan E. (stefan_e)


Lesenswert?

Hallo,

ist es Absicht, dass wenn ich Quickmeasure aus und dann wieder 
einschalte die Kanalwahl der einzelnen Messfunktionen überschrieben 
wird? Denke ja hoffentlich mal nicht. Hab das mal rausgenommen. Jetzt 
bleibt die Kanalwahl der einzelnen Messfunktionen beim Aus- und 
Einschalten von Quickmeasurement erhalten.

Ich werde die Änderungen in den aktuellen trunk der OSS ablegen. Ich 
hoffe odch, dass irgendwann hier auch mal deine Änderungen erscheinen. 
Es ist schon ein Aufwand in zwei Verisonen immer nachzuschauen, ob 
jemand anderes das Problem vielleicht schon gefixt hat.

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

@Hayo

Ich habe mich mal daran veruscht, die HE0.96 und die OSS.91 
zusammenzuführen, damit wir wieder an einem Strang ziehen. Hat auch fast 
alles geklappt. Kannst du mal schauen, ob noch alles drinnen ist, was du 
die letzte Zeit gemacht hast. Außerdem habe ich bei der RS232-Verbindung 
irgendwas vermischt. Jedenfalls geht die Screenshot-Funktion derzeit 
nicht. In tc_vars.cpp Zeile 2570 & 2450 habe ich den Überblick verloren, 
was den nun eigentlich ins Menü für den Screenshot rein muss. Bin da 
gerade nicht so auf dem laufenden. Vielleicht kannst du die 
Screenshot-Funktion wieder richten. Blicke da gerade nicht durch ;-)

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Stefan, hallo Hayo,

schön das du am mergen bist Stefan! Ich hoffe du nimmst die Remote 
Control Funktionen aus der OS.91 da die in der HE 0.96 definitiv noch 
einige Probleme haben! Wollte ein Ticket aufmachen, da aber die 0.96 
nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler 
auch in der 0.95 auftaucht, hab ich nicht getestet).
Ich Hatte auch keine Lust das Ganze ausführlich zu testen, da mich das 
bei meiner GUI Programmierung nur behindert.

Der "Dump data  STX  ASCII 03" liefert definitiv falsche Daten,
Die continious dump Befehle zeigen gar keine Wirkung...

Hier hab ich mal einen Screenshot der neuen GUI veröffentlicht, damit 
man auch sieht wo das Ganze hinführen wird...

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

Gruß, brunowe

von Stefan E. (stefan_e)


Angehängte Dateien:

Lesenswert?

Hallo brunowe,

ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit 
deiner GUI testen?

Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die 
Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und 
grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es 
heute Abend in SF.

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:
> Hallo brunowe,
>
> ich hab nochmal ein paar Änderungen gemacht. Kannst du die nochmal mit
> deiner GUI testen?
>
> Die Screenshoot-Funktionen sind jetzt wieder aus der OSS und die
> Remote-Steuerung habe ich veruscht komplett zu übernehmen. Wenn du und
> grünes Licht gibst, dass dein Zeug noch funktioniert übernehme ich es
> heute Abend in SF.

Committe meinetwegen einfach, wenn es Probleme mit der PC-Kommunikation 
gibt, kümmere ich mich darum.

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

von Blue F. (blueflash)


Lesenswert?

Hi,

besten Dank schonmal an Stefan für das Mergen der Versionen, ich weiß 
nicht wann Rolf und ich sonst dazu gekommen wären.

Zur Remote-Schnittstelle: Da mir die Testmöglichkeiten fehlen habe ich 
die OS-Sourcen nach offensichtlichen Änderungen durchsucht und diese 
dann bei mir eingebaut. Kann gut sein, dass noch eine Kleinigkeit fehlt, 
die mir nicht aufgefallen ist, hier sollte aber die OS-Version die 
Vorgabe liefern.

Zum Screenshot: Ich hatte das Druckmenü bei mir so geändert, dass die 
einzelnen Funktionen vom DSO aus anwählbar sind und daher die 
Screenshotfunktionen mit einem Parameter versehen.

Um mit der aktuellen PC-Software kompatibel zu sein, müssen die 
Screenshotfunktionen der OS-Version verwendet werden - auch die RLE 
Encoderfunction!

Um das Ganze zu mergen gibt es zwei Varianten:
Entweder  muß die Menüstruktur der OS-Version verwendet werden, dann 
werden keine Parameter gebraucht, oder die Screenshotfunktionen und die 
PC-Software werden um diese Parameter erweitert, dann kann meine 
Menüstruktur verwendet werden (Definition in tc_vars 2450/2570/2607).

Die flash_t kann vermutlich komplett von mir übernommen werden, da dort 
wahrscheinlich keiner etwas geändert hat.

In hardware_t gibt es die neuen Funktionen Reset_To_Default() und 
Restore_From_Flash() die bei der neuen Startupsequenz genauso zum 
Einsatz kommen wie bei der Recall-Funktion und der 
Autoscale-Undo-Funktion.

-> handle_ADC() hat sich unter Anderem geändert!

In userif_t hat sich ebenfalls einiges getan, unter anderem die neue 
Run/Stop/Single-Logik im Button handler.

commif_t kann größtenteils von der OS-Version übernommen werden, hier 
habe ich nur im USB-Transfer einige tote Variablen entfernt (CH1_DAC_1 
usw.)

In display_t haben sich die Draw-Routinen etwas geändert.

In signal_t hat sich die Noise Suppression etwas geändert (if-Bedingung 
- siehe Ticket 39)

Ich werde aber noch mal über Deine gemergten Files drüberschauen und mal 
sehen ob mir da was auffällt.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den 
ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da 
einfach was schiefgelaufen?

Gruß Hayo

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hayo W. schrieb:
> Wollte eben mal Deine gemergten Sachen besichtigen, kann aber in den
> ZIPs nichts finden. Hast Du eine exotische ZIP-Version, oder ist da
> einfach was schiefgelaufen?

Da sind nur ziemlich lange relative Pfade drin.

Ich habs mal für Winzip vorverdaut ;-)

Falk

von Blue F. (blueflash)


Lesenswert?

@Falk

Danke.

@Stefan

Ich habe mal userif_t.cpp geprüft - es gibt noch 5 Stellen die geändert 
werden müssen und je nach wunsch evtl. die Quick Print Menüfunktionen. 
Ich prüfe noch die anderen und stelle die überarbeiteten Files dann hier 
ein.

Gruß

Hayo

von Martin H. (martinh)


Lesenswert?

Hayo W. schrieb:
>
> Bei der
> Gelegenheit habe ich die Run/Stop/Single-Logik komplett überarbeitet, so
> dass diese jetzt vernünftig funktioniert.

Mir gefiel das vorher besser!
Mit der 0.96HE ist es nicht mehr möglich das Signal im stop mode zu 
analisieren (strecken, verschieben usw.) überdies wenn ich in den delay 
modus wechsle sind die Signale weg!


grüss Martin

von Blue F. (blueflash)


Lesenswert?

@Martin

Ich habe im Stop-Modus das Drehgeberinterface blockiert, da sich die 
Nullpunktlage verschieben ließ, ohne dass das Signal folgte. Wenn das 
vom Handling gefälliger ist mit der Möglichkeit was zu verstellen, kann 
ich das auch wieder rausnehmen oder etwas feiner einschränken.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

Martin H. schrieb:

> wenn ich in den delaymodus wechsle sind die Signale weg!

Das war mir noch nicht aufgefallen, ist in Arbeit...

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Martin H. schrieb:
>
>> wenn ich in den delaymodus wechsle sind die Signale weg!
>
> Das war mir noch nicht aufgefallen, ist in Arbeit...

Können wir vielleicht endlich mal versuchen, eine Version zu 
pflegen?

Wer einen Bug findet, meldet den hier: 
http://sourceforge.net/apps/trac/welecw2000a/report
Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen 
werden committed und ggfs. wird eine Release daraus gemacht, das man 
dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen 
kann.

Sonst wird das Durcheinander noch größer.

Falk

von Blue F. (blueflash)


Lesenswert?

@Falk

Wenn ich noch was ändere, baue ich das in die gemergte Version mit ein, 
evtl. ändere ich aber auch erst nach dem Mergen direkt in der OS 
Version.

Keine Sorge, ich mach jetzt deswegen keine neue Version auf.

Gruß Hayo

von Blue F. (blueflash)


Lesenswert?

@Stefan

Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an 
der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer 
dabei.

@all

Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen 
Status?

Gruß Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> @Stefan
>
> Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an
> der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer
> dabei.
>
> @all
>
> Sind diese Änderungen konsolidiert, oder ist das noch im experimentellen
> Status?

Ich habe eben Stefans Files commited (revision 245).

Falk

von Rolf W. (rowue)


Lesenswert?

Bruno We schrieb:
> Hallo Stefan, hallo Hayo,
>
> [....] Wollte ein Ticket aufmachen, da aber die 0.96
> nicht im Ticketsystem ist, hab ich's erst mal gelassen (ob der Fehler
> auch in der 0.95 auftaucht, hab ich nicht getestet).[...]

Habe die 0.96HE im Ticket-System nachgetragen
>
> Gruß, brunowe


Grüße,

   rowue

von Stefan E. (stefan_e)


Lesenswert?

>@Stefan

>Beim Prüfen der gemergten userif_t.cpp ist mir aufgefallen, dass da an
>der QM-Funktion was geändert wurde. Da steht allerdings kein Änderer
>dabei.

Das war ich. Hab mich wohl nicht eingetragen. Vorher wurden beim Ein-und 
Ausschalten von QM die ausgewählten Kanäle der Messfunktionen geändert. 
Das hab ich abgestellt.

>Können wir vielleicht endlich mal versuchen, eine Version zu
>pflegen?

>Wer einen Bug findet, meldet den hier:
>http://sourceforge.net/apps/trac/welecw2000a/report
>Der wird dann gefixt, der Bugreport wird bearbeitet, die Änderungen
>werden committed und ggfs. wird eine Release daraus gemacht, das man
>dann unter http://sourceforge.net/projects/welecw2000a/ herunterladen
>kann.

>Sonst wird das Durcheinander noch größer

Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann 
ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in 
welcher Version behoben war.

@Hayo
Wenn du noch die letzten Änderungen schickst, aktualisiere ich das in 
SF, bis du dich damit mal selber befasst. Lieber viele kleine Schritte, 
als so ein großer. Danach würde ich die 0.92_OSS rausbringen, auf der 
wir alle weiterentwickeln.

von Stefan E. (stefan_e)


Lesenswert?

>Da sind nur ziemlich lange relative Pfade drin.

>Ich habs mal für Winzip vorverdaut ;-)

Hab das unter OpenSuse gezippt. Das da dann überhaupt die Pfade mit 
drinnen sind ist mir neu.
Das WinZip ein Mist ist dachte ich mir ja schon immer ... ;-)

von Michael H. (stronzo83)


Lesenswert?

@ Hayo

Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte 
bis dahin nicht verstanden, dass das überhaupt möglich ist...
Wenn ich mal auf Energiereserven in mir stoße, fange ich vielleicht mit 
einem kleinen Handbuch zur Firmware an, sicher haben andere auch 
Probleme, alle Möglichkeiten zu entdecken.
Achja: bei mir funktioniert der delayed modus mit der 0.96 tadellos.

Ich fände es auch gut, wenn man im Stop Mode die Möglichkeit zum 
Scrollen oder Zoomen (wo möglich) wieder bekommen könnte.

Gruß
Michael

von Blue F. (blueflash)


Lesenswert?

Falk Willberg schrieb:

> Ich habe eben Stefans Files commited (revision 245).

Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen 
sind noch nicht geprüft.

Ist das so gewollt?

Gruß Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Stefan E. schrieb:

> Ganz meiner Meinung. Deshalb ja jetzt der "Gewaltschritt". Darauf kann
> ich jetzt aufbauen. Habe am Schluss nicht mehr gewusst, was schon in
> welcher Version behoben war.

Damit testen kann, wer testen will, hier noch eine TomCat.ram aus den 
SVN-Sourcen: http://falk-willberg.de/tmp/TomCat.ram.gz

Falk

von Roberto (Gast)


Lesenswert?

Hallo werte W20xxA Besitzer und Interessierte!

Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal 
einen zweiten Teil davon aufgemacht!
Bitte hier weiterschreiben:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Danke !
l.G. Roberto

von Stefan E. (stefan_e)


Lesenswert?

>Danke für die Erklärung zum QuickMeasure mit mehreren Kanälen. Ich hatte
>bis dahin nicht verstanden, dass das überhaupt möglich ist..

Wir haben uns doch nicht irgendeinen billigen Oskar gekauft, bei dem QM 
nur auf einem Kanal gleichzeitig möglich ist. ;-)

Ich denke, dass du dich auf #33 beziehst. Da hab ich versucht das zu 
erklären. ;-)

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Roberto schrieb:
> Hallo werte W20xxA Besitzer und Interessierte!
>
> Da der Thread hier schon sehr sehr sehr lange geworden ist, habe ich mal
> einen zweiten Teil davon aufgemacht!
> Bitte hier weiterschreiben:
> Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

Ohne mich!

Falk

von Michael H. (stronzo83)


Lesenswert?

Oh, da habe ich doch glatt dem falschen die Lorbeeren zugeschustert, so 
war das nicht gedacht.
Stimmt, du warst ja der QM-Fachmann! Dann also danke nochmal an dich für 
die Erklärung und die gute Arbeit an den Messfunktionen.
Ein gutes Beispiel für die Nützlichkeit habe ich hier gerade laufen: ein 
I2C Farbsensor, dessen Werte ich mit nem Controller als dreikanalige PWM 
ausgebe (RGB). Da kann man sehr schön sehen und messen, was für 
Farbanteile man da gerade hat. Jaja, die Welec-Kiste hat zwar noch ihre 
Macken, aber irgendwie ist sie mir doch schon ans Herz gewachsen :)
Wie aufwändig ist es denn, die Messerei für die schnellen timebases zu 
fixen?

Deinen Vorstoß zur Zusammenführung der Versionen finde ich auch klasse, 
es bahnte sich ja schon der eine oder andere Streit an deswegen.

Gruß
Michael

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Hayo W. schrieb:
> Falk Willberg schrieb:
>
>> Ich habe eben Stefans Files commited (revision 245).
>
> Allein in der userif_t.cpp waren noch 5 fehlerhafte Stellen, die anderen
> sind noch nicht geprüft.

Dann pflege die Fixes doch ein.

> Ist das so gewollt?

Ich wollte endlich wieder eine Basis haben, auf der ich sinnvoll 
weitermachen kann. Es gibt da ein paar Erweiterungen, auf die jemand 
wartet.

Falk

von Stefan E. (stefan_e)


Lesenswert?

@Hayo

Es wäre schön wenn das Strecken und Verschieben des Signals im 
Stop-Modus wieder ginge ...

von Manuel (Gast)


Lesenswert?

hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur 
ganz kurz auf geht und dann gleich wieder weg ist?

ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen 
laptop und da gehts nur kurz auf und ist nach ner  halben sekunde wieder 
weg...
danke schonmal

von Manuel (Gast)


Lesenswert?

ok, hat sich schon erledigt!
hab den falschen com-port gehabt.
(konnte nur die fehlermeldung nicht lesen, weils so schnell wieder weg 
war...sogar zu schnell für nen screenshot. bin dann einfach mal auf der 
entertaste geblieben, dass es so oft auf und zu ging dass ichs lesen 
konnte)

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Manuel schrieb:
> hi, wollte mal fragen, was schief läuft, wenn das screenshotprogramm nur
> ganz kurz auf geht und dann gleich wieder weg ist?
>
> ich hatte es schonmal, da liefs tip top... jetzt hab ich nen anderen
> laptop und da gehts nur kurz auf und ist nach ner  halben sekunde wieder
> weg...

Das screenshot-Programm ist ein Kommandozeilen-Tool. Im Terminal (oder 
wie heißt das unter Win?) siehst Du auch die Fehlermeldung.

Wahrscheinlich ist das Problem, daß am Laptop keine COM1 vorhanden ist, 
auf die das Tool ohne Parameter zugreift.

Alternativ installiere Linux, damit gehen auch andere Sachen besser.

Vielleicht könnte sich mal ein Windows-User des Screenshot-Tools 
annehmen? Da sollte sich doch bei >95% Marktanteil jemand finden...

Falk
P.S.: Solche Fragen sind bei 
http://sourceforge.net/apps/phpbb/welecw2000a/ besser aufgehoben.

von Michael D. (mike0815)


Lesenswert?

...das ist die Dos-Eingabeaufforderung "CMD.exe" meistens unter 
C:\Windows\system32 zu finden oder unter dem Reiter "Zubehör"

Gruß Michael

von Jürgen (Gast)


Lesenswert?

@alle

Roberto hat doch nun schon den neuen Thread aufgemacht.

Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

Schreibt doch bitte alle dort weiter, damit dieser Thread nicht noch 
länger wird!

Gruß Jürgen

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Jürgen schrieb:
> @alle
>
> Roberto hat doch nun schon den neuen Thread aufgemacht.
>
> Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
>
> Schreibt doch bitte alle dort weiter, damit dieser Thread nicht noch
> länger wird!

Nein, http://sourceforge.net/apps/phpbb/welecw2000a/ ist besser 
geeignet.

Falk

von Daniel (Gast)


Lesenswert?

egal, hauptsache nicht mehr hier rein.

finde es inzwischen auch sehr ätzend und unübersichtlich

von Michael D. (mike0815)


Lesenswert?

...also was dann jetz? Mir geht das jetzt auf'n S..., wann sind wir uns 
denn hier einich???
Ich versuche so gut wie möglich hier den Überblick zu behalten was aber 
bald unmöglich sein wird, da der Thread hier wirklich schon 100km lang 
ist!

Ich fände es jetzt nicht schlecht, wenn es, wie FALK es schon 
vorgeschlagen hat, im SF weiter ginge, da ja schon 3 Thread's 
(ENTWICKLER, HARDWARE, SOFTWARE) aufgemacht worden sind!!!

Ich selbst bin dort als KASTOR7 registriert(mike0815 war schon 
vergeben)!
Bei Fragen oder Beiträgen von hier, kann ja verlinkt werden...
...das wäre jetzt mein Vorschlag, was hält denn der Rest davon???

Gruß Michael

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

Hallo Michael,

allein schon weil wir auf SF (innerhalb unseres Projekts) Admin Rechte 
haben, bin ich stark dafür!

P.S.:
Ich hab mal hier:
http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=18&t=34
ein aktuelles Foto von der GUI eingestellt. Derzeit bin ich dabei einige 
Programme der Profis zu analysieren, um mal zu sehen wie die das ein 
oder andere Problem in der Programmierung und Darstellung gelöst haben.
Da ich derzeit schon ca. 3000 Zeilen Programmcode geschrieben habe 
wird's langsam Zeit für eine ordentliche Programmstruktur...

Gruß, brunowe

von Ingo M. (ingom)


Lesenswert?

Meine Meinung dazu könnt Ihr hier

Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"

lesen und kommentieren. Danke!

von Alessandro C. (musashi)


Lesenswert?

Hallo zu allen!
entschuldigt sich für meinen bösesten Deutschen, aber ich habe ein 
Problem mit dem W2012A und ich brauche eure Hilfe..

Ich versuchte die Fortbildung der Firmware mit der Software von Welec zu 
machen (W2000-Update)und während es für Fehler entlud, schloß ich das 
Fenster. es scheint jetzt, daß ich keine firware mehr installiert  habe 
und wenn ich wieder das Programm den upload losgehen lasse, fängt es 
nicht an..
wie ich kann wiedergutmachen?

von fat.wombat (Gast)


Lesenswert?

Sorry, konnte mich nicht zurückhalten - die Online-Übersetzter sind 
manchmal so lustig ;-))))

"entschuldigt sich für meinen bösesten Deutschen"


Oooooohhohhohho, ROFL-ROFL :-D

von xx x. (gipro)


Lesenswert?

Hallo an alle! Ich kaufte den Umfang von welec und ausgeliefert haben, 
den Artikel regelmäßig bezahlt denn es ist eine Schande, nicht um E-Mail 
zu reagieren.
Ich dachte, dass die Deutschen richtigen Leute waren. Enttäuschung 
total!
Ich möchte eine Antwort von Ingenieur.

Hello everyone! I purchased the scope from welec and have shipped the 
item regularly paid for it is a shame not respond to email.
I thought that the Germans were right people. Disappointment total!

Ciao a tutti !  Ho acquistato l'oscilloscopio dalla welec e non hanno 
spedito l'oggetto regolarmente pagato è una vergogna non risponde ad 
email .
Credevo che i tedeschi erano persone corrette .Delusione totale!

von Dietmar (Gast)


Lesenswert?

Hallo,

ich hatte bereits 2010 ein W2014A von Michael Wittig über ebay 
ersteigert. Hardwareversion 1c9.0d, Softwareversion 1.4. wegen der 
bekannten probleme satnd es bei mir jahrelang nahezu ungenutzt herum. 
Nun bin ich endlich dazu gekommendie neueste BlueFlash firmware 
1.2.BF.7.13C2 zu flashen und auch den External Trigger Mod und den 
LB-Mod vorzunehmen. Das Gerät ist jetzt wirklich brauchbar! Vielen Dank 
an alle Beteiligten für die große Mühe!
Leider zeigen sich zuweilen immer noch die lästigen Spikes. Im Forum 
habe ich gelesen, dass unter Umständen ein Umflashen des FPGA auf 
Version 8C7.0L Besserung versprechen könnte. Leider finde ich nirgendwo 
das benötigte sof File für diese Version. Könnte mir jemand einen Link 
benennen?

Vielen Dank!
Dietmar

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.