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
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
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?
@ 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
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
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
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
@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
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
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
@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
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
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
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!
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
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
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
Angehängte Dateien:
-
Messung_1.PNG
58 KB
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...
Angehängte Dateien:
-
Messung_2.PNG
46 KB
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
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
Angehängte Dateien:
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
@branadic: Wollte dich kurz fragen wie du deine Messdaten so dargestellt hast. CVS Daten und Excel?
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
@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
@ 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
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 :-(
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
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").
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
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
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
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
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
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
>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
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
> 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
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
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
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
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
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
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
Angehängte Dateien:
-
6khz.png
5,3 KB
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
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
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 ;)
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
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 :)
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
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
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.
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
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 ;)
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
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
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. > > [...]
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
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)
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?
Angehängte Dateien:
-
dc_uebersteuert_500MS.PNG
3,7 KB
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...
Angehängte Dateien:
... weiter geht es. Tatsächlich schauen die exportierten Daten aus dem Speicher??? anders aus, nämlich so... Beste Grüße, branadic
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
Angehängte Dateien:
-
Spektrum2.png
1,9 KB
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
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.
Angehängte Dateien:
-
Spektrum4.jpg
26 KB
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
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?
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.
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
Wie ist denn das Passwort für obigen Link? Muss man sich bei sourceforge anmelden, um die Beiträge zu lesen? Thx!
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
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
Das wäre dann ungefähr der 5.Updater! Und auch noch "Auto"! Den brauchen wir ganz dringend. Viel Spaß! Jürgen
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
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
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/
Vielleicht kann Roberto nur den Sinn einer Anmeldung nicht erkennen? l.G.
>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
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!
Wer testen will: http://sourceforge.net/projects/welecw2000a/files/Open%20Source%20Firmware/1.2-OS-0.89/1.2-OS-0.89.tgz/download http://sourceforge.net/projects/welecw2000a/files/PC-Software/w2000a-screenshot/w2000a-screenshot-0.89.tgz/download Falk
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
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?
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
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
Angehängte Dateien:
-
10_20_30_40MHz.png
9,1 KB
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.
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
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
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
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
Hallo Martin, mit welcher Screenshot-Version lassen sich die Daten aus dem Speicher exportieren? Weißt du das zufällig? Beste Grüße, branadic
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
@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
Angehängte Dateien:
-
10MHz_RAW_Correction.PNG
50 KB
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
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
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
Angehängte Dateien:
-
10MHz_20MHz_1GaS_s.png
74 KB
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
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
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
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
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
Angehängte Dateien:
-
50MHz-Sinus.png
70 KB
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.
Angehängte Dateien:
-
100MHz-Sinus.png
95 KB
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
Angehängte Dateien:
-
Sig-240MHz-int-gen.jpeg
150 KB
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/
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
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
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!
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
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
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?
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
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
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
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
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
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
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
Nachtrag: Kanal 4 bekomme ich jetzt auch ohne Eingangssignal zu "Spiken" (Null-Lage durch den Schirm fahren) (MIt Falks Patch) Grüße, rowue
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
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
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
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
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
Angehängte Dateien:
-
Frequenzgang.png
1,9 KB
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
Angehängte Dateien:
-
Frequenzgang.png
2,2 KB
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
Angehängte Dateien:
-
screenshot-0000.png
3,4 KB
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
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
Weitere Hardware-Diskussionen verlagere ich jetzt auch mal auf: http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=12&t=22
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
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
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
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
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 */
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
...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
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?
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!!!
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
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
>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
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
...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
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
? 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
PS.: Man muss den Link in das Adressfenster kopieren. Ansonsten funktioniert der Download nicht, da das Prozent Zeichen nicht übernommen wird.
Angehängte Dateien:
-
Welec_Sreenshot02.jpg
240 KB
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
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.
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
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
> 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
Funktioniert doch. Hatte mich blöd angestellt!!!! Gruß Jürgen
Na so ein Zufall auch! Gleich ein Namensvetter da? Oder doch jemand, der seinen Namen besser nicht nennen will? Kein Kommentar dazu!
Ich meinte doch die Sache mit dem Referenzsignal. Gruß Jürgen
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
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
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
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.
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?
Urlaubs - und Ferienzeit!!! Nicht aufgeben, die kommen schon alle wieder zurück!
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
Angehängte Dateien:
-
screenshot-0001.png
5 KB
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
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
er wird die Werte einfach rauswerfen und durch den Mittelwert der beiden Nachbarn ersetze..denke ich mal so
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
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
@rowue Dein Patch (Ticket 26) ist natürlich auch dabei. Hayo
Ticket 32 ist doch ein ziemlich alter Hut, also schon lange bekannt - weiß inzwischen jemand was dahintersteckt? Michael
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
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
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
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
Fettes Dank für die Mühe. Wann kann man die neue Firmware erhaschen?
Na das klingt doch wieder mal super! Was wie warum da passiert weißt du aber auch nicht, oder Hayo? Gruß Michael
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.
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
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
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
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
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
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
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
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
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.