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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 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 O. (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 O. (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 O. (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 O. (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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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