Hier ist die Fortsetzung von: Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)" Und noch die Hardware Diskussion: Beitrag "Wittig(welec) DSO W20xxA Hardware"
:
Gesperrt durch Admin
> Das heißt du könntest nur die Kompressionsroutine übernehmen? Eigentlich ja, aber das Coding von Falk ist doch ziemlich "kompakt" geschrieben und daher nicht ganz einfach nachzuvollziehen. Es gibt auch noch einige weitere Änderungen die ich dann anpassen müßte. Ich hatte mir das schon mal angesehen, aber dann doch keine Zeit/Lust gehabt. Vielleicht baue ich das demnächst trotzdem mal um. >>Hayo W. schrieb: >> Was ich mir vorstellen könnte wäre, dass abhängig von der Auswahl BF/OS >> die Buttons eine jeweils eigene Beschriftung und Funktion haben >Gute Idee! Bekomme ich dann den 5. Soft-Button als "Save to USB"? Klar kein Problem. Ich vermute mal nur für die OS-Version solange ich die Kompressionsroutine noch nicht upgedatet habe? Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung stellen? Gruß Hayo
Hayo W. schrieb: > Die Funktion die hinter dem Button steckt würdest Du dann zur Verfügung > stellen? Na klar!
Ich versuche mal das zum nächsten Release vorzubereiten, für die Funktion mach ich Dir dann einen leeren Methoden-Body. Hayo
Habe nur ich ein Problem beim Norm-Trigger vom W2024 Ch3/4? Mit der FW 2.9.C2 W2024 beobachte ich folgendes Problem: Ein normaler Edge-Trigger auf Kanal 3 bzw. 4 funktioniert bei Umschaltung der TB nur in jeder zweiten Stellung, also z.B. bei ... 20, 5 und 1 us/div kommt der Trigger durch und bei ... 10, 2 und 1 us/div kommt er nicht durch. Dagegen hilft: Run/Stop auf 'Stop' und wieder auf 'Run'. Dann geht's auf den anderen Stufen, als ob dabei irgendetwas wesentliches wieder richtig gesetzt wird. Trigger auf Ch1/2 tut's immer. Hat jemand eine Idee oder ist das ein (bekanntes?) FPGA-Problem? Gruß Rainer
Du hast recht, bei mir ist das auch zu beobachten. Ich kümmere mich darum. Danke für den Tip Hayo
Bei mir tritt das nur bei Zeitbasen von 5ms bis 500ms auf. Hat hier jemand andere Erkenntnisse? Das Problem müßte eigentlich auch bei älteren FW-Versionen auftreten. Muß ich nochmal prüfen. Hayo
Hayo W. schrieb: > Ok, Problem ist behoben. Klasse, hatte gerade alles von 2 ns/div bis 200 ms/div durchprobiert - trat überall auf. Aber du warst schneller. Danke Rainer
Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war alles ok. Es ist auch schon die zusätzliche manuelle Triggerung via Single-Button und die Hardwareunterstützung des LTC 2602 drin. Gruß Hayo
Hallo Hayo, nächstes Problem: Ich muss auf ein (beliebiges) Zeichen vom UART warten. Dazu habe ich eine globale Variable angelegt die in der Hardware::ISR_UART() auf 1 gesetzt wird. Die Abfrage sieht dann einfach so aus:
1 | rx=0; //Globale Variable zurücksetzen |
2 | while(!(rx)); //Warte bis sie von der ISR gesetzt wird |
3 | rx=0; //Wieder zurücksetzen (eigentlich hier unnötig) |
Gibt es da eine elegantere Möglichkeit oder kann das so bleiben? Ginge auch eine Abfrage von puart->np_uartstatus und puart->np_uartrxdata? Das beliebige Zeichen ist zur Zeit ein Leerzeichen (0x20). Besteht die Gefahr dass ich damit etwas durcheinanderbringe? Mfg, Kurt
Hayo W. schrieb: > Die 2.10 ist zwar noch nicht fertig, aber Du kannst ja mal bei diesem > Vorabrelease prüfen ob das Problem bei Dir noch auftritt. Bei mir war > alles ok. Der Trigger über Ch3/4 scheint zu funktionieren. Aber ganz weit bin ich mit Testen nicht gekommen, weil die Kiste jetzt sehr gerne total einfriert. Bis auf Softkey-Reset geht dann gar nichts mehr. Gruß Rainer
Sorry, hatte vorhin quick & dirty die Sache ausprobiert und dabei eine Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles sollte gut sein. @Kurt Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und wenn nix kommt, hast Du das Gleiche wie ich vorhin! Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen, denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird jedesmal gemacht. Hayo
Hayo W. schrieb: > hatte vorhin quick & dirty die Sache ausprobiert und dabei eine > Endlosfalle mit eingebaut. Jetzt ist da ein Timeout drin und alles > sollte gut sein. Hajo, da kommt noch kein weißer Rauch. Irgendwie scheint die Falle immer noch drin zu sein. Nur manchmal (etliche Sekunden) kommt die Bedienung durch, so dass man eine Chance hat die TB zu verstellen. Nix mit locker durchdrehen ... Gruß Rainer
Hi Rainer, gib mir mal ein paar Details zu den verwendeten Einstellungen (Hardwaremenü, TB, aktive Kanäle, Spannungsbereich), denn bei mir lief das irgendwie problemlos. Gruß Hayo
So - hab nochmal eine kleinigkeit geändert, damit die Bedienung bei Zeitbasen mit langer Abtastzeit etwas flüssiger wird. Bitte berücksichtigen, dass aber grundsätzlich das Ganze ab 20ms an aufwärts etwas langsamer wird, und damit auch die Reaktionsgeschwindigkeit auf das Human Interface. Gruß Hayo
Hi Hayo, mmh, keine besonderen Einstellungen: - Default Setup - Trigger Norm, Ch.4 rising Edge, Level 2.5 V - TB um die 1us/div, sofern machbar ;-) - Signal: 5V Einzelpulse 1us auf Ch.4 Problem scheinen die Einzel-Events zu sein. Dabei verfängt das DSO sich gerne. Wenn ich aber statt dessen nach einem Soft-Reset das Probe Comp Signal dran habe, läuft alles. Gruß Rainer
Noch einer! Ich habe jetzt einen völlig anderen Lösungsansatz gewählt. Die Bedienung wird dadurch flüssiger und ich hatte auch keine Aussetzer bei meinen Tests. Diese Variante gefällt mir bislang am besten. Probierts doch bitte mal aus. Hayo
Hayo W. schrieb: > Probierts doch bitte mal aus. Signal: Probe Comp an Ch1, Einzelpulse an Ch4 Die Hänger sind in der 2.10.Pre4 weg, aber wenn Trigger auf Ch4 steht und ich die TB langsamer mache, kommen ab 10us/s bei Einzelpulssignal kein Trigger mehr durch, d.h. 2ns/div ..5us/div geht, 10us/div ... geht dann nicht mehr. Allerding: Wenn ich dann bei z.B. 20us/div auf Ch1-Trigger schalte (Erfassung läuft wg. Ch1.Signal) und wieder zurück auf Ch4, funktioniert auch Trigger auf Einzelpulse wieder, solange ich nicht von 5us/div auf 10us/div umschalte. Wird an dieser Grenze irgendetwas Grundlegendes geändert? Gruß Rainer
Ja zwischen 10µs und 5µs wird anscheinend die Betriebsart der ADC umgeschaltet, denn bei 5µs werden 16k Werte gesampelt und ab 10µs sind es dann nur noch 4k. Genauer kann man das in der Programmers Reference sehen auf dem Reiter "Timebase Table". Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das Signal zu klein kleiner als ein Div hoch. Dann setzt der trigger schon mal aus. Aber sobald das Signal größer ist läuft alles ohne Aussetzer. Können die Anderen hier das auch mal testen bitte? Nicht das ich der Einzige bin bei dem es keine Aussetzter gibt. Gruß Hayo
Hayo W. schrieb: > @Kurt > > Wenn Du das so machst, steht die ganze Kiste bis was vom UART kommt. Und > wenn nix kommt, hast Du das Gleiche wie ich vorhin! > > Also entweder einen Timeout einbauen, oder besser nur mit if() abfragen, > denn dann kann die Hauptschleife weiterlaufen und die Abfrage wird > jedesmal gemacht. > > Hayo Den Timeout mit if() habe ich schon drin, oben war nur ein (zu) stark verkürztes Beispiel. Sorry. Es ging mir nur darum ob die Sache mit der globalen Variablen so in Ordnung ist oder man es besser machen kann.
Hayo W. schrieb: > Allerdings tritt das Problem bei mir nicht auf, außer ich wähle das > Signal zu klein kleiner als ein Div hoch. An der Signalhöhe liegt es definitiv nicht (2,5 div und TL ca. 50%). Ich kann auch reproduzierbar zwischen 5 und 10us/div umschalten, Trigger Ch4 mit Einzelpuls kommt nur bei 5us/div durch, dto. die rote/Ch4-Trigger-LED. Bei 10us/div rauscht nach gefühlten 30 s ein Puls durch (Spike auf Ch4) und dann triggert das DSO auch wieder aufs Einzelsignal. Hilft das?
Im Prinzip mache ich das auch so mit globalen Flags. Allerdings solltest Du bei globalen Variablen den Namen möglichst sprechend wählen - z.B. USB_rx_flag oder USB_rx_request oder so, Dann wird das etwas übersichtlicher und besser lesbar. Gruß Hayo
@Rainer Ich hatte etwas schwierigkeiten Deinen Fall nachzustellen, hab es aber jetzt hingekriegt. Die Pulse müssen schon sehr langsam kommen damit das Problem auftritt (1 Puls pro Sekunde). Aber dann passiert es bei mir auch wie beschrieben. Mal sehen ob ich die Ursache lokalisieren kann. Gruß Hayo
Hayo W. schrieb: > Die Pulse müssen schon sehr langsam kommen damit das > Problem auftritt (1 Puls pro Sekunde). Tun sie, ich löse die von Hand aus. Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der eigentlich hätte auf 0 gestellt werden müssen? Gruß Rainer
> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf > 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es > sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft, der > eigentlich hätte auf 0 gestellt werden müssen? Keiner den ich benutze, aber es ist schon mal ein Ansatz für die Suche. Gruß Hayo
Zück schon mal den Lötkolben, Hayo. Die Leiterplatten gehen heute noch in den Postkasten. branadic
Na Du bist aber fix. Da passt das ja das heute meine Lötstation gekommen ist. Gruß Hayo
Angehängte Dateien:
-
kompost.jpg
200 KB
moin moin Hayo, hier was fuers Wochenende, hat mich ein paar stunden suche gekostet obwohl meine Soft 'unschuldig' war was du auf dem Bild siehst ist ein SYMETRISCHES Signal, nur das Oszi zeigt was anderes, irgendwie als waehre dein Puffer zu kurz oder wird ueberschrieben, oder ? FW = BF2.8 vlG Charly
@Charly, Hayo Der am rechten Rand dargestellte Datenmüll stammt zeitlich aus einem anderen Bereich des Signals und taucht am rechten Rand immer auf, wenn das Fenster mit der Horizontalverschiebung ganz nach Rechts geschoben ist, d.h. am Ende der gesampleten Daten liegt. Horizontalregler a bissl nach links drehen und schon ist es nicht mehr zu sehen ;-) Schönen Sonntag Rainer
Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal ausprobieren. Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht weitergekommen. Ich denke aber dass es sich eher um ein minder priorisiertes Problem handelt oder? Ich habe erst mal am Quick Print Menü weitergemacht, was schwieriger war als ich dachte, da ich (eigentlich wie immer) auf Altlasten in der Menüsteuerung gestoßen bin. Jetzt hab ich da aber aufgeräumt und alles ist gut. Ich werde nachher mal die fertige 2.10 hier hochladen. Gruß Hayo
Hayo W. schrieb: > Ich habe erst mal am Quick Print Menü weitergemacht Super, ich werde die später meine neuen Funktionen schicken: UC_rle_enc(...) UC_SCREENSHOT_BW() UC_SCREENSHOT() UC_DUMPCSV() Mfg, Kurt
Hayo W. schrieb: > Is ja'n Ding. Das war mir noch nicht aufgefallen. Muß ich mal > ausprobieren. Mit einem Sägezahnsignal läßt sich vielleicht am einfachsten klären, wo die Mülldaten herkommen. > Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht > weitergekommen. Ich denke aber dass es sich eher um ein minder > priorisiertes Problem handelt oder? Das denke ich auch. Die W2022 Nutzer haben sowieso nur 2 Kanäle zum Triggern und die Frontend-Front lauert ja auch noch auf Einbindung der Chip-Ansteuerung. Gruß Rainer
> Wegen der Triggeraussetzer auf Kanal 3 + 4 bin ich leider auch nicht > weitergekommen. Ich denke aber dass es sich eher um ein minder > priorisiertes Problem handelt oder? >>Das denke ich auch. Sehe ich anders. Für mich hat das zuverlässige Funktionieren der Elementarfunktionen (z.B. Triggerung) oberste Priorität. Der Oszi ist ja immerhin ein Messmittel und ich möchte ihn auch so einsetzten (und mich drauf verlassen!). Ich will hier aber keinem den Spaß verderben, Hayo soll das machen, was er am spannendsten findet (aber solche lästigen Bugs bitte nicht vergessen). Da wir schon mal dabei sind - vielen Dank an alle, die hier ihre Zeit investieren!! Viele Grüße, Mirko
Hallo Hayo, na dann bin ich gespannt auf die 10er. Mal eine kurze Frage am Rand, woran erkenne ich dann in der neuen Firmware, dass der DAC auch richtig unterstützt wird? Ich hab den heutigen Tag genutzt meine DACs auszutauschen und zugleich meinen Kanal 4 etwas frei zu machen, damit die Huckepackplatine Platz findet. branadic
So, der Reihe nach: - @Charly -> das Datenmüllproblem habe ich eben noch beseitigt. - @Mirko -> ja ist irgendwie ärgerlich, aber wenn man einen zuverlässigen Trigger braucht muß man eben Kanal 1 oder 2 nehmen. Vielleich stoße ich noch auf eine Lösung. - @Kurt -> alles klar, ich habe Dir eine leere Methode gebaut, die angesprungen wird wenn der USB-Button gedrückt wird. Zur Zeit gibt sie nur einen Text auf dem Terminal aus. Du Findest sie in der commif_t.cpp ganz am Ende -> void CommIF::Save2USB(void) - @Branadic -> tja entweder funktioniert es mit dem 16 Bit DAC - oder nicht. Kann sein das ich den Registerwert noch um zwei Bit verschieben muß, das muß ich aber noch ausprobieren. Zur Zeit kann ich das ja leider noch nicht testen. Wenn Du umschaltest auf 16 Bit werden die drei anderen Kanäle sich nicht mehr verstellen lassen. Wenn es gut Läuft geht dann aber der Kanal 4. Ansonsten einfach bescheid sagen, dann ändere ich das. Zur 2.10: - Es gibt jetzt zwei unterschiedliche Quick Print Menüs für OS und BF. Die Umschaltung erfolgt wie gehabt. Gruß Hayo
Hallo Hayo, hier sind die geänderten Dateien. Ausgangsbasis war die 2.9_C2 Mfg, Kurt Jetzt warst du schneller. Mal sehen was du angestellt hast. ;-)
Sieht doch schon gut aus! Aber wäre nicht ein eigener Eintrag im Screenshot-Versions Softbutton besser? Und dann die 3 linken Softkeys wie in der OS-Version (Color, BW, CSV).
Hi Kurt, ich hatte Dich in Deinem Post neulich so verstanden, dass Du da an der freien Stelle einen Button für den USB-Transfer hinhaben wolltest. Hab ich Dich da falsch verstanden? Wir können das natürlich noch ändern bei Bedarf. Gruß Hayo
Hallo Hayo, nach dem Umstellen des DAC auf LT2602 verschwinden bei Kanal 1 und 3 die Signale irgendwo außerhalb es Bildschirmes, Kanal 2 bleibt an gleicher Stelle. Auch ein Calibrate DAC bringt die Signale für Kanal 1 und 3 nicht zurück. Veränder ich nun die Position von Kanal 2 durch Drehen am Knopf, was ja in einer Änderung des DAC-Wertes resultieren sollte, bleibt das Signal an selber Stelle, aber das Kanal-Zeichen inkl. des Pfeiles (linker und rechter Bildschirmrand) wandert. Tut also noch nicht wie gewünscht. branadic
Kann sein dass ich mich da etwas undeutlich ausgedrückt hatte. Das Dateiformat in dem gespeichert wird kann ich auf meinem µC einstellen. Aber für die Art der Datenübertragung (Farbe, S/W, CSV) bauche ich je einen eigenen Softbutton. Ich könnte zwar meine UC_ Funktionen mit den OS_ Funktionen zusammenlegen (die sind im Prinzip kompatibel, nur die RLE unterscheidet sich) aber das halte ich in der Entwicklungsphase nicht für sinnvol.
Ok, dann baue ich das nochmal um und spendiere Deiner Funktion ein eigenes Menü. Gruß Hayo
@Hayo, Hayo W. schrieb: > Rainer W. schrieb: >> Die "gefühlten 30 s", die das DSO nach der Umschaltung von 5 auf >> 10us/div keinen Trigger annimmt, sind reproduzierbare 35 s. Kann es >> sein, dass in der Zeit ein 32-Bit Zähler einmal die Runde läuft...? > > Vielleich stoße ich noch auf eine Lösung. Der Trigger läuft ja schon zuverlässig. Man hat "nur" die Totzeit nach der TB Umschaltung 5->10us. Falls an meiner etwas kühnen 32-Bit Vermutung etwas dran ist, wären das z.B. 34,4 s bei 125 MHz. Nur mal so ins Blaue gedacht... Hayo W. schrieb: > - @Charly -> das Datenmüllproblem habe ich eben noch beseitigt. Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am Ende mit ins Display rutscht? Sieht bei mir so aus... Gruß Rainer
Angehängte Dateien:
-
plane1_5.png
573 Bytes
Jetzt noch 2 (optische) Kleinigkeiten: In OS_SCREENSHOT_BW(void) und UC_SCREENSHOT_BW(void) muss die UI_Plane1 noch mit in das Array. Also:
1 | unsigned long *planes[] = { |
2 | UI_Plane1, UI_Plane2, UI_Plane5, // UI_Plane3, UI_Plane4 |
3 | Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4, |
4 | Channel_Math_Plane, |
5 | Memory_Plane1, Memory_Plane2, Memory_Plane3, |
6 | Marker_Plane1, Marker_Plane2, |
7 | Grid_Plane, |
8 | NULL
|
9 | };
|
In der UI_Plane1 scheint auch noch ein Fehler beim Zeichnen der Umrandung des rechten Softbutton zu sein. Auf dem Bild im Anhang sieht man dass die Umrandung nicht geschlossen ist.
Danke Hayo, hab grad die neue Ver. eingespiel, werd heut mal testen... aber 2 neue Fehler / 'Unschoenheiten' 1. ab einer TB >1ms muss man f. manuelles triggern im Single mode die Single Taste mehrmals druecken ;( 2. der Pretrigger Wert wird beim langsamen durchdrehen der TB nicht aktualisiert vlG Charly
@Hayo Rainer schrieb: > Kann es sein, dass da immer noch ein einzelnes falsches Datenwort am > Ende mit ins Display rutscht? Sieht bei mir so aus... Das was da auf dem letzten Pixel noch zu sehen ist, stammt wohl vom Noise-Filter bei Einstellungen "smooth" oder "strong". Gruß Rainer
@Kurt baue ich mit ein. @Charly Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein. Danke für die Rückmeldung Hayo
Hayo, hast du meine Meldung bezüglich der DACs gesehen? Scheint in den letzten Postings der anderen User irgendwie untergegangen zu sein. brandic
Hi branadic, sorry, der Post war tatsächlich etwas an mir vorbeigerauscht. Bin momentan immer noch etwas in Stress hier beim Rollout meines Projektes. Welchen Kanal (bzw. Kanäle) hattest Du denn nun auf 16 Bit umgerüstet? War das nicht Kanal 4? Übrigens ist heute Deine Sendung bei mir angekommen - danke! Muß mal sehen wann ich das einbauen kann, da muß man sich ja schon etwas Zeit für nehmen. Gruß Hayo
Hallo Hayo, da es sich bei dem DAC um einen DUAL DAC handelt werden pro gewechseltem DAC also auch zwei Kanäle in Mitleidenschaft gezogen (Kanal 1 + 2 und Kanal 3 + 4). Ich habe bei mir beide DAC gewechselt, demzufolge sind alle 4 Kanäle davon betroffen. Da ich aber an meinem Kanal 4 etwas aufgeräumt habe, um Platz für die Huckepackplatine zu machen, kann ich dir nicht sagen was jetzt dort genau passiert. Schön das die Sendung schon eingetroffen ist, dann kann es ja bald mit der Implementierung losgehen. Das freut mich. Ein wenig Zeit wird man sicherlich brauchen, aber die größte Last, der Aufbau einer Leiterplatte, wurde dir ja schon abgenommen ;) branadic
Wenn es bei Dir momentan noch nicht funktioniert werde ich Dir bei Gelegenheit mal eine modifizierte Version bauen. Bin aber momentan echt im Streß, da ich ab morgen für den Rest der Woche eine Schulung gebe und mich auch noch vorbereiten muß. Gruß Hayo
Hayo W. schrieb: > @Charly > > Stimmt, ist in Arbeit. Sollte in der nächsten Version behoben sein. Danke Meister ! <tiefes verbeugen> & viel erfolg bei der schulung, und hoffentlich haste keine mit 'Teflonpfannenkopf' dabei :)
So, bin gerade nach Hause gekommen - und was finde ich im Briefkasten? Post von Linear Technology! Die Jungs haben mir doch tatsächlich zwei LTC2602 als kostenloses Sample geschickt und das ziemlich zügig. Danke noch mal für den Tip! Schade, dass ich momentan überhaupt keine Zeit habe etwas zu basteln. Naja, muß halt noch etwas warten. Gruß Hayo
hi mir ist gestern ein fehler in den math-funktionen aufgefallen. messen wollte ich die restwelligkeit einer gleichspannung (8V). da sich an dem messpunkt noch ein welliger spannungsabfall (1Vpp) von einem shunt hinzu addiert, wollte ich diesen mit der CH1-CH2 funktion herrausrechnen. beide kanäle waren dabei im 5V messbereich und die referenzlinien in der bildschirmmitte. die überlagerte spannung vom shunt wurde zwar korrekt herraus gerechnet, allerdings stimte die skalierung des ergebnisses nicht. die ergebnisslinie lag nicht wie erwartet bei 8V sondern irgendwo bei 11V. gruß sunny
Ich möchte nochmal an die Sammelbestellung für die Bauteile der Huckepackplatine erinnern. Die Frist endet Freitag Abend. Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Mfg, Kurt
Hi, bin wieder mal gerade erst zu hause angekommen und wollte mal kurz die Gelegenheit nutzen zu fragen wo ich denn den LTC2612 auf der Platine finde. Ist ja doch recht klein das Teilchen. @Branadic Du hast da doch bestimmt aktuell den Überblick oder? Sonst such ich mir da bestimmt nen Wolf. Gruß Hayo
Ach, das ist ja gleich um die Ecke bei den Vorwiderständen die ich schon getauscht hatte. Danke.
Kurt Bohnen schrieb: > Ich möchte nochmal an die Sammelbestellung für die Bauteile der > > Huckepackplatine erinnern. Die Frist endet Freitag Abend. > > > > Beitrag "Re: Wittig(welec) DSO W20xxA Hardware" Oh, danke, wäre mir sonst durchgegangen. Ich komme gerade aus dem Urlaub wieder und konnte das aktuell nicht verfolgen. Mehr dort. Jörg
Und wieder ward es ruhig. Es gibt ja anscheinend doch eine ganze Reihe Leute, die sich ein Welec zugelegt haben. Jetzt hat man mehrfach die Ausrede gehört, dass für Mikrocontrolleraufgaben das Welec ausreichend sei. Nur wenige Leute wollen wirklich anspruchsvollere Messungen damit durchführen. Also Frage an all die Mikrocontroller-Programmierer, die ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren nicht unterstützen? Wenn Hayo nichts implementieren kann, weil er gerade keine Zeit hat, passiert scheinbar überhaupt nichts mehr. Auf die Art und Weise kommt das Projekt nicht voran. Ich verstehe, dass Walter das Projekt verlassen hat und so langsam verliere auch ich die Lust immer nur zu warten.. branadic
Wenn Hayo grade nichts dran tut würde ich mich anbieten mal meine Grafikfunktionen in seine Quellen zu mergen, die ich vor 1,5 Jahren in Subversion eingecheckt hatte. Wie sieht der Entwicklungsflow derzeit aus? Hayo, kann ich mit die Quellen von dir "ausleihen" und dir das Resultat zurückschicken? Oder gibt es mittlerweile eine Versionsverwaltung? Jörg
branadic schrieb: > Also Frage an all die Mikrocontroller-Programmierer, die > ihr im Besitz eines Welec seid, warum könnt ihr Hayo beim Programmieren > nicht unterstützen? Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich nachvollziehen kannst, wo was erledigt wird. Nur wenige werden je verstehen wie was erledigt wird. Gruß, Guido
Guido schrieb: > Rechne mit 2 Wochen Vollzeit bis du leidlich > nachvollziehen kannst, wo was erledigt wird. Außerdem müsste Hayo entscheiden, wer wo was ändern darf. Und dafür braucht er auch wieder Zeit. Vor allem braucht man auch SELBER Zeit. Ich hatte seinerzeit vorgehabt, Alex008 beim FPGA-Design zu unterstützen, aber aufgrund zuwenig Zeit davon Abstand genommen. Es macht keinen Sinn, wenn man nur halbe Arbeit abliefern kann. Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal eine kleine Pause einlegt. Dass es überhaupt schon soweit vorangekommen ist - alle Achtung! Dickes Kompliment an die Entwickler! > Nur wenige werden je verstehen wie was erledigt wird. Hat Hayo inzwischen eine Liste erstellt, wo was zu erledigen wäre? Wenn es viele kleine Teile wären, könnte man sich eher mal dran setzen. Gruß Ingo
Da kommt auch die Frage auf, was ist mit den ganzen anderen Programmierern der OS-Firmware? Vor längerer Zeit gab es Zoff weil Hayo "sich quergestellt" hat. Danach haben anscheinend 5-10 Programmierer ihr Welec auf den Schrott geworfen und haben kapituliert. Nur Hayo hat tapfer weitergearbeitet und treibt auch jetzt noch das Projekt vorwärts. Das ist schon eine merkwürdige Geschichte!? Wenigsten Jörg möchte "zurückkommen", vielen Dank! Den Einwand von Guido muss ich leider bestätigen. Der Quelltext umfasst ca. 48000 Zeilen. Das ist etwas mehr als die normalen µC Projekte. Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder VHDL? Eine kleine Statusmeldung seinerseits wie weit er mit der Dokumentation gekommen ist, wäre auch schön. Ist euch eigentlich aufgefallen dass die Auktionspreise für die Welecs deutlich gefallen sind? Früher waren es immer so 350€. Jetzt nur noch 250-280€. Verlieren die Leute das Vertrauen in unser Projekt? Sobald die Sammelbestellung für die Teile der Huckepackplatinen abgeschlossen ist werde ich noch eine Sammelbestellung für den USB-Host organisieren. Die Hardware ist fast endgültig fertig, die Firmware hat schon einen brauchbaren Funktionsumfang und läuft stabil genug.
Kurt Bohnen schrieb: > Vieleicht findet sich noch jemand der Alex helfen kann bei Software oder > VHDL? Gibt es irgendwo eine Übersicht, was noch zu erledigen wäre? Gruß Ingo
Guido schrieb: > Hast du selbst mal einen Blick in die Sourcen geworfen? Das ist kein > LED blinken lassen. Rechne mit 2 Wochen Vollzeit bis du leidlich > nachvollziehen kannst, wo was erledigt wird. Nur wenige werden > je verstehen wie was erledigt wird. Hallo Guido, das Projekt gibt es doch auch nicht erst seit gestern und ganz ehrlich, eine LED blinken lassen hat mit Programmieren nicht das geringste zu tun. Es ist halt blöd, wenn die Software ein reines 1-Mann-Projekt ist. Ich denke auch Hayo ist für Unterstützung dankbar. Du hast dich ja scheinbar auch zurück gezogen. Ingo M. schrieb: > Insofern finde ich es nicht schlimm, wenn dieses Projekt ab und zu mal > eine kleine Pause einlegt. Genau das passiert, wenn nur noch einer am Projekt arbeitet und der Rest sich raus hält. Dann kann aber keine Rede mehr von "unserem Welec-Projekt" sein. Zumindest hat meine Anfrage hier doch den Erfolg gebracht, dass sich einige Leute melden und ihre Unterstützung anbieten, das ist doch ein Anfang. branadic
Hallo Jungs, nur keinen Stress. Bin zwar momentan noch etwas knapp an Zeit, aber nur keine Panik, es geht bald weiter. Ich sag morgen noch mal was dazu bis dann Hayo
branadic schrieb: > Du hast dich ja scheinbar auch zurück gezogen. Schon, aber nicht weil ich mir irgendwann gesagt habe, da mache ich nicht weiter. Die Unterbrechung, als Hayo abwesend war, hat mich halt völlig rausgebracht, ich habe andere Projekte begonnen. Jetzt müsste ich wieder bei Null anfangen und sehe dafür aber keine Notwendigkeit. Der Aufwand wäre sehr groß, da C++ nicht meine Welt ist, und besser als Hayo würde ich es doch nicht hinbekommen. Du musst einfach akzeptieren, dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau programmieren können. Andererseits gibt es nur sehr wenige Informatiker, die genügend von Messtechnik verstehen um ein solches Projekt zu stemmen. Herr Wittig könnte dir sicherlich ein Lied davrüber singen. Und nocheinmal: Niemand hier hat etwas gegen SFN! Nur diskutieren tun wir halt lieber hier. Grüße, Guido
Guido schrieb: > Du musst einfach akzeptieren, > dass es nur sehr wenige Elektrotechniker gibt, die auf diesem Niveau > programmieren können. Andererseits gibt es nur sehr wenige Informatiker, > die genügend von Messtechnik verstehen um ein solches Projekt zu > stemmen. Niveau hin oder her, Programmieren ist so anspruchsvoll nun auch wieder nicht, lassen wir doch mal die Kirche im Dorf. Es ist einfach nur so, dass die meisten einfach keinen Bock darauf haben, weil es eine stupide Arbeit ist. So umfangreich ist das Einarbeiten in die Thematik auch nicht, man ist nur zu bequem, weil es da ja jemanden gibt der die Arbeit für einen erledigt, so sieht es doch wohl aus! Hayo hat nur das größere Durchhaltevermöge gezeigt. Gesetz dem Fall Hayo hört auch auf, dann war es das mit eurem Projekt. Es hat schon immer geschadet seine Karten auf ein Pferd zu setzen, man sollte immer noch einen Trumpf in der Hinterhand haben. Mit einer solchen Organisationsstruktur in einem Projekt ist man zum Scheitern verurteilt. Da kann man nur sagen, Welec-Projekt adé. MFG, T. Dübel
Hallo allerseirs, ich sehe ich muß mir mal die Zeit nehmen einen längeren Beitrag zu schreiben. Da meine Beweggründe für die eine oder andere Entscheidung anscheinend immer noch nicht ganz transparent für alle sind werde ich das noch mal erläutern: Ich bin schon recht lange in der Softwareentwicklung tätig und weiß daher das ein Projekt welches von mehreren Entwicklern bearbeitet wird eine steuernde Instanz braucht die: - Vorgaben macht - koordiniert - Ergebnisse prüft - entscheidet welche Änderungen übernommen werden - neue Releases herausgibt nachdem die Änderungen getestet wurden Das gilt nicht nur für kommerzielle Projekte sondern auch für Open Source. Bei unserem Projekt gab es (auch wegen relativ dünner Personaldecke) sowas nicht. Das führt zum Teil zu etwas unkoordinierter Entwicklung und Wildwuchs. Um hier unabhängig zu sein habe ich meine Version getrennt von der OS-Version weiterentwickelt und dann gegenseitig sinnvolle Verbesserungen ausgetauscht. Das ist auch immer noch der aktuelle Stand, obwohl zur Zeit an der OS-Version relativ wenig gearbeitet wird. Zum Beitrag hier drüber: Lieber T.Dübel, Programmieren gehört zu den komplexesten Ingenieursleistungen überhaupt. Dass es nicht ganz so einfach ist wie Du behauptest sieht man an dem Ergebnis das die Firma WELEC nach mehreren Jahren Entwicklung abgeliefert hat und auf dem unsere Entwicklungen hier basieren. Und gesetzt den Fall ich höre auf, so stehen alle bisherigen Arbeiten als Source mit Dokumentation zur Verfügung, so dass es keinen Grund gibt die Entwicklung nicht fortzuführen. Ich habe 2008 mit sehr viel weniger angefangen! Zu SFN: Ich finde es unbedingt wichtig, das wir alle Ergebnisse und Informationen an einer zentralen Stelle wie SFN zusammentragen um diese allen geordnet verfügbar zu machen. Das hat nichts damit zu tun, das ein großer Teil der Kommunikation hier im Forum stattfindet. Meine aktuellen Releases sind immer auch auf SFN zu finden. Hier im Forum habe ich einfach direkteren Kontakt zu allen Betroffenen. @Jörg, Ingo, Guido, Kurt und alle die mithelfen wollen: Meine aktuelle To Do Liste die mir so gerade einfällt sieht ungefähr so aus: - Pretriggerwerte aktualisieren wenn TB geändert wird (ist in Arbeit) - Unterstützung für 16 Bit DAC. Die erste Anpassung scheint noch nicht zu funktionieren. Ich hätte eine Idee wo noch etwas geändert werden müßte. Wenn sich jemand des Themas annehmen möchte kann ich gerne Hinweise zu den entscheidenden Stellen geben. - Unterstützung für die Addon-Platine von branadic. Auch hier ist kurzfristige Hilfe willkommen damit die hardwareseitige Entwicklung weitergehen kann. Ich helfe auch gerne bei der Orientierung in der Source. - Druckmenü für Kurt erweitern -> ist in Arbeit - Manuellen Trigger prüfen und evtl. anpassen (geringe Prio) - Math-Funktionen (+ - *) prüfen überarbeiten (falsche Ergebnisse?) - Neues USB-Interface weiterentwickeln und PC-Software erstellen. - FFT-Bereich weiter entwickeln. - Screenshot BF-Version auf die aktuelle Komprimierungsroutine der OS-Version updaten um etwas schneller zu werden und kompatibel zu sein. Fehlt was entscheidendes? Wenn Ihr Ergebnisse habt, baue ich die gerne mit in die Source ein. Zu Subversion: Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber die Synchronisation hat nur zwei mal geklappt, dann habe ich aus Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr hinbekommen. Ich müßte das also versuchen wieder neu einzurichten. So erstmal genug Gruß Hayo
Hi Hayo, ich habe mich gestern Abend mal mit Walter über die Ansteuerung der Huckepackplatine unterhalten und er hat versucht mir die nötigen Änderungen zu erklären. Leider habe ich es nur zu 90% verstanden und muss nochmal nachfragen. Danach werde ich ein Bildchen malen wie die Platinen angesteuert werden müssen. Mfg, Kurt
Hi Kurt, das klingt gut. Wenn ich mich da nicht komplett neu reindenken muß kann ich da auch schneller eine Implementierung anbieten - bzw. jemand anderes hier. @All Ach ja, falls der Eine oder Andere Bedenken hat, dass ich mit der Entwicklung hier aufhöre, so möchte ich darauf hinweisen, dass ich mir extra für die Entwicklung und zum Testen der WELECS umfangreiches Equipment im Wert von über 1000 Euro zugelegt habe. Das haut man nicht mal eben so in die Tonne. Also locker bleiben und Ruhe ausstrahlen ;-) Gruß Hayo
Hallo, zu deinem Problem: Hayo W. schrieb: > Zu Subversion: > > Ich hatte mit Rolfs Hilfe ein SVN-Verzeichnis bei SFN eingerichtet, aber > die Synchronisation hat nur zwei mal geklappt, dann habe ich aus > Versehen bei mir die Steuerdateien gelöscht und habe es dann nicht mehr > hinbekommen. Ich müßte das also versuchen wieder neu einzurichten. Mögliche Abhilfe: 1.) Projekt von Sourceforge neu auschecken(in neuen lokalen Ordner). 2.) Sourcen, usw. vom Ordner ohne Steuerdaten direkt in den ausgecheckten Stand kopieren. 3.) dann ist ein Commit wieder möglich und sollte gleich vorgenommen werden. zuküntig: Oft Committen und ggf. branches bei Teständerungen o.ä. verwenden. weitere Fragen zu Subversion: bitte gerne hier stellen... MfG Werner S.
Liebe Oszilloskop-Gemeinde! Wie Branadic, Hayo und Co schon behauptet haben, stimme ich zu, dass die Programmierung keine stupide Arbeit ist. Das gilt besonders hier für den Embedded-Bereich, welcher sich mit Messtechnik, Signalverarbeitung wie hier zu tun hat. Für das Programmieren hier muss man die Messtechnik gut verstehen und mittelmäßig selbst bauen können und digitale Schaltungen verstehen. Die Programmiersprache C, C++ ist nunmal Standard in dem Bereich und keinesfalls Deppensicher. Zudem ergeben sich erschwerte Bedingungen auf Grund der spärlich vorhandenen Debug-Möglichkeit und der begrenzten CPU-Performance. Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen Digitalchip-Entwickler nötig. Das war der Teil in unserem Studium, bei welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und der Unüberschaubarkeit teils große Schwierigkeiten haben. Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun haben. Eines ist klar, sich in einen unvollständigen fremden Source-Code einzulesen, ist sehr mühsam und kann manchmal so sehr frustrieren, dass jeder seine eigene Suppe kocht. Die geringe Verbreitung der Hardware kommt noch dazu - Kein Wunder also, dass wir so wenig Entwickler sind. MfG Alexander
@Hayo Eine Frage zur Screenshot-Funktion: Früher konnte man durch "Doppel-Click" auf die Quick-Print-Taste einen ScreenShot auslösen, den man dann auf dem PC via RS232 mit dem entsprechenden w2000a-screenshot.exe empfangen konnte. Ist die Funktion gerade im Bau bzw. unter die Räder gekommen oder was macht das DSA jetzt bei Doppel-Click. Muß man da jetzt besondere Einstellungen vornehmen, damit der PC das mitbekommt? Mit der 2.10 bekomme ich z.Z. nur einen ScreenShot hin, wenn ich direkt die Tasten im Quick-Print Menü benutze, kann dann aber z.B. Cursoreinstellungen nicht dokumentieren. Kannst du da, wenn du Zeit hast, mal ein paar erhellende Worte fallen lassen? Gruß Rainer
Hallo Rainer, hast du darauf geachtet das die Screenshot Version (BF oder OS) von PC und Oszi übereinstimmen? Mfg, Kurt
Hallo Rainer, die Funkion sollte wie gehabt arbeiten. Wie Kurt schon sagt muß aber die richtige Version eingestellt sein (passend zur PC-Software). Ich bin ja ohnehin gerade dabei die Druckfunktion für Kurt anzupassen, da kann ich das sonst noch mal testen. Gruß Hayo
Was heißt "übereinstimmen"? Die beiden w2000a-screenshot.exe sind schon etwas betagter (BF 2.Nov.2010 bzw. OS 21.Sep.2010) und habe ich aus dem letzten FW-Update von Hayo (1.2.BF.2.10.zip). Gibt es da was aktuelleres? Auf PC-Seite funktioniert eigentlich alles, wenn ich den ScreenShot.exe auf Daten vom DSO lauern lasse. Nur der "Quick Print" Doppel-Click tut anscheinend etwas anderes als früher. Gruß Rainer
Ich prüf das mal und sag dann Bescheid. Hayo
Hayo W. schrieb: > Ich prüf das mal und sag dann Bescheid. Das wäre prima, das DSO ist nach dem Doppel-Click beschäftigt, aber der PC merkt nichts von Daten. Gruß Rainer
Ja Du hast recht. Das hatte ich bislang noch nicht bemerkt. Ich vermute, dass ich durch den Umbau für Kurt da einen Fehler eingebaut habe. Das korrigiere ich natürlich zur nächsten Version. Danke für den Hinweis Hayo
So, hab mich heute mal drangesetzt und einige Punkte abgearbeitet: - neues Quick Print Menü mit Unterstützung für Kurts Projekt - Pretrigger wird jetzt immer korrekt upgedatet - 16 Bit DAC wird jetzt (hoffentlich) korrekt unterstützt. Ich habe mir mal die Spezifikation runtergeladen und das Registersetting angepasst - Quick Print double push funktioniert wieder Und jetzt geht es wieder ab zum Griechen. Bis nachher Gruß Hayo
Hallo Hayo, das gefällt mir sehr gut und es funtkioniert! Leider hast du vergessen die handleInChar anzupassen. Hier nochmal die benötigten Zeilen:
1 | case 5: |
2 | CommIF::UC_SCREENSHOT(); // -> UC version |
3 | break; |
4 | case 6: |
5 | CommIF::UC_SCREENSHOT_BW(); // -> UC version black and white |
6 | break; |
7 | case 7: |
8 | CommIF::UC_DUMPCSV(); // -> UC version |
9 | break; |
Dann habe ich noch eine neue uc_dumpcsv die bei 2 Kanal Geräten auch nur Daten der 2 Kanäle überträgt. Mfg, Kurt
Ok, bin gerade vom Griechen zurück. Hatte ich übersehen. Ich bau das morgen mal ein und gebe dann eine neue Compilation raus. @branadic Es würde mich mal interessieren ob die 16 bit DAC-Ansteuerung jetzt funktioniert. Gruß Hayo
Der frühe Vogel fängt den Wurm! Alles schläft - einer fährt, oder so ähnlich. Also, hab noch ne Nachtschicht eingelegt und die Korrekturen eingebaut. Gruß Hayo
Hallo Hayo, was heißt hier alles schläft? Bin gerade erst nach Hause gekommen. Die DAC teste ich nachher mal, jetzt ist erst einmal Augen ausruhen angesagt. branadic
Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem 16bit DAC zusammen, die Signallinien landen nicht auf 0. Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u. rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt doppelt so schnell auf dem Bildschirm hoch und runter. Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event LED solange dauerhaft leuchten zu lassen, solange hintereinander Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen ist auf Trigger Wait umgeschaltet wird? Das Flackern ist echt hart, man könnte meinen man schaut einen dieser asiatischen SciFi-Trickfilme. branadic
branadic schrieb: > Also Hayo, DAC-Kalibrierroutine funktioniert noch nicht korrekt mit dem > 16bit DAC zusammen, die Signallinien landen nicht auf 0. Das hab ich mir gedacht. Die Kalibrierroutine ist auf den 14 Bit DAC optimiert. Das müßte ich dann anpassen wenn ich das Teil bei mir einglötet habe. Wie groß ist denn die Abweichung? -> Screebshot > Beim Verstellen des DAC-Level wandern Signal und Kanalanzeige (links u. > rechts) nicht gleichmäßig sondern die Kanalanzeige wandert gefühlt > doppelt so schnell auf dem Bildschirm hoch und runter. Das ist klar, denn die Schrittweite hat sich ziemlich stark geändert. Das muß ich auch noch anpassen. Aber die Verstellung an sich funktioniert korrekt? Wie sieht es mit der Verstellgeschwindigkeit Ansprechverhalten Einstellgenauigkeit aus? Macht der Umbau Sinn? > Dann hätte ich noch eine Anregung zu den flimmernden LEDs für Trigger > Wait und Trigger Event. Wäre es vielleicht sinnvoller die Trigger Event > LED solange dauerhaft leuchten zu lassen, solange hintereinander > Triggersignale kommen und erst wenn 1s lang kein Triggersignal gekommen > ist auf Trigger Wait umgeschaltet wird? Das fände ich persönlich nicht so gut. Die Anzeige macht für mich so schon Sinn, auch wenn es zugegebenermaßen manchmal etwas hektisch blitzelt. > Das Flackern ist echt hart, man könnte meinen man schaut einen dieser > asiatischen SciFi-Trickfilme. Deshalb habe ich die Möglichkeit vorgesehen die LEDs separat abzuschalten. Gruß Hayo
Verstellung ist soweit in Ordnung, Geschwindigkeit etc ebenfalls. Der Umbau macht auf jeden Fall Sinn. Ich möchte daran erinnern, dass wir mit der Huckepackplatine zusätzliche Spannungsbasen von 5mV/div, 2mV/div und 1mV/div dazu gewinnen und spätestens da wird eine feinere Verstellung notwendig sein. Was die LEDs angeht, ich kann dir nur sagen wie das bei Tektronix gelöst ist, Disco-Licht gibt es dort nicht. Übrigens ist es überhaupt nicht notwendig an der Frontplatte herumzuschnippeln oder mit Heißkleber rum zu sauen, wenn man Osram Topleds verwendet. Die sind hell genug auch durch die Frontfolie durch zu leuchten. Für rot verwende ich LS T67B (super-rot) und für grün LT T67C (true green). Das eher matschige grün im Welec scheint die LTG T676 zu sein. branadic
So Branadic, damit Du nicht so gefrustet bist über die Diskobeleuchtung habe ich Dir eine neue Kompilation gemacht mit überarbeiteter 16 Bit DAC-Unterstützung. Eigentlich müßte es jetzt alles korrekt funktionieren. Ich habe die Ansteuerung jetzt so gemacht, dass man auf den Umschalter im Hardwaremenü eigentlich verzichten könnte. Die Ansteuerung ist nämlich eigentlich Sofwarekompatibel für alle drei DAC-Typen ausgelegt, so dass man sie beliebig tauschen kann ohne etwas anpassen zu müssen - vorausgesetzt man hat das von vornherein in der Ansteuerung berücksichtigt. Ich muß wohl nicht erwähnen, dass WELEC das natürlich nicht so implementiert hat. Sollte also jetzt alles korrekt sein werde ich in der nächsten Version den Schalter wieder rausnehmen. Gruß Hayo
By the way - ich habe mir das Hirn zermartert was der 16 Bit DAC eigentlich bringen soll. Mir ist nix eingefallen. Vielleicht kannst Du mir da auf die Sprünge helfen. Die Schrittweite ist nämlich nicht von der DAC-Auflösung abhängig, sondern wird in "Pixelschritten" vorgenommen. Und die sind bei den korrespondierenden Spannungsbereichen (5er/2er/1er) immer gleich. Beim 16 Bit DAC sind dann die Werteschritte einfach nur Faktor 4 größer. Oder hab ich da einen Denkfehler??? Gruß Hayo
Angehängte Dateien:
-
Kanal3_25MS.png
4,9 KB -
Kanal3_250MS.png
3,2 KB
Hallo Hayo, die DAC-Implementierung schaut soweit gut aus, zumindest für Kanal 1 und 2. Kanal3 macht einige Probleme: 1. Kanal3 bekomme ich durch den DAC-Abgleich nicht komplett auf Null, es bleibt ein geringer positiver Offset. 2. Bei Zeitbasen >10µs (<=25MS) entstehen auf Kanal3 und komischerweise nur dort unschöne Störungen, die bei Zeitbasen <=5µs/div (>=250MS) nicht zu sehen sind. Diese sind je nach DAC-Level unterschiedlich stark. Um Null herum füllen sie sogar bei einigen Leveln den halben Bildschirm, wie du den beiden Bildern entnehmen kannst. Was den DAC angeht, so wird eine Verstellung um ein MSB bei Zeitbasen von 1mV/div einem großen Sprung auf dem Bildschirm entsprechen, daher hatte Walter den Tausch vorgeschlagen. Zudem sollte sich der Signal-Störabstand des DAC-Ausgangssignals durch die höhere Auflösung in den anderen Spannungsbasen reduzieren. Immerhin wird jedwedes DAC-Rauschen mit verstärkt, weil das DAC-Signal relativ früh in den Signalzweig eingespeist wird und somit alle Verstärkerstufen durchläuft. branadic
Moin moin,
ich hab mich noch mal drangesetzt und einige Testreihen zum DAC gemacht
bzw. die Werte nachgerechnet und die techn. Specs verglichen.
Grundsätzlich bringt der 16 Bit DAC in den 5er Ranges keinen Vorteil und
in den 2er Ranges nur wenig.
Die elektrischen Eigenschaften der drei Typen sind identisch.
Die Schrittweite beträgt beim 14 Bit DAC in den 5er Ranges 3/Pix und in
den 2er Ranges 1 bzw. 2/Pix.
Beim 16 Bit Dac liegt die Schrittweite in den 5er Bereichen bei 12 bzw.
13/Pix und in den 2er Bereichen bei 5/Pix.
Einen Auflösungsvorteil bringt es in den 1er Bereichen, da hier die
Schrittweite des 14 Bit DAC bei 1/2Pix liegt. Heißt übersetzt, nur alle
2 Pixel wird der DAC um 1 weitergestellt.
Das ist natürlich beim 16 Bit DAC besser. Hier liegt die Schrittweite
dann bei 2 bzw. 3/Pix.
Die Werte kann jeder leicht selbst ermitteln, wenn er sich über ein
Terminalprogramm die Variablenwerte ausgeben läßt (","). Die DAC-Werte
findet man im fünften Abschnitt.
So Branadic,
nun zu Deinem Problem auf Kanal 3. Das scheint mir ein Hardwareproblem
zu sein - kalte Lötstelle, Brücke etc.. Bei mir funktioniert sowohl der
Zero-Abgleich als auch alles Andere. Keine Spikes oder sowas Ähnliches.
Die firmwareseitige Implementierung ist also ok.
Ich werde mir den DAC also auch einbauen um in den 1er Bereichen eine
feinere Auflösung zu erzielen.
In der nächsten Version wird die Ansteuerung so sein dass keine
Umschaltung mehr erforderlich ist und auch ein gemischter Betrieb (bei
den 4 Kanalern) möglich ist.
Gruß Hayo
Hayo W. schrieb: > Das scheint mir ein Hardwareproblem > zu sein - kalte Lötstelle, Brücke etc Das glaube ich nicht Hayo, weil die Spikes sofort weg sind, sobald die Samplerate >25MS beträgt, wie erklärst du das elektrisch? branadic
Geschickter Einwand - aber wie erklärst Du Dir dass es nur bei bestimmten Zeitbasen auftritt obwohl die Zeitbasen keinen Einfluß auf die DAC-Ansteuerung haben? Ich bin gerade bei der neuen Version, damit kannst Du das nochmal prüfen - und alle Anderen auch, da jetzt die DACS immer gleich angesteuert werden. Gruß Hayo
Hallo Hayo, ich behaupte ja nicht, dass es zwangsläufig an der DAC-Ansteuerung liegt, könnte auch was anderes im FPGA o.ä. sein. Ich kann dir nur nicht sagen was es ist, genauso wenig wie jemand beantworten kann, woher die Spikes auf den Kanälen genau kommen, denn im Leon-Design sind sie nicht zu finden. Witzigerweise sind sie auf Kanal 1 in voller Signalhöhe zu sehen, auf Kanal 2 kippen sie um die Hälfte hoch und runter und auf Kanal3 sehe ich sie gar nicht, wenn nicht gerade der DAC-Level auf einer ungünstigen Position steht und die oben gezeigten Störungen produziert. branadic
alex008 schrieb: > Für eine VHDL-Entwicklung ist unbedingt ein Niveau für einen > Digitalchip-Entwickler nötig. Welches Standardwerk empfiehlst du als Lektüre, um auf das Niveau eines Digitalchip-Entwicklers zu kommen? Ich habe bisher noch keinen Chip entwickelt, weiß aber grundsätzlich, wie Chips entwickelt werden und kenne mich zumindest in Assembler und C sehr gut aus. Ich habe auch mal einen Compiler für einen Scheme-Prozessor geschrieben, das war sehr hardwarenah. > Das war der Teil in unserem Studium, bei > welchen die meisten Studienkollegen aufgrund der Fehleranfälligkeit und > der Unüberschaubarkeit teils große Schwierigkeiten haben. > Weiters wollen die meisten im Berufsleben nichts mehr damit zu tun > haben. Das bedeutet also, dass es nur wenig VHDL-Entwickler gibt? Wie sind zur Zeit die beruflichen Aussichten? Muss man sich international orientieren? Und wie sieht es mit Verilog aus? Das würde mich wirklich mal interessieren. Gruß Ingo
Ich arbeite in einer kleineren Chipentwicklungsfirma, bin selbst aber embedded Softwerker. Nachdem was ich so manchmal mitkriege: VHDL ist kaum noch üblich, wird eher als Lehrsprache betrachtet. Die produktive Arbeit wird in Verilog erledigt. Das ist vielleicht so wie Pascal (oder Modula-2) vs. C. War mal anders, als ich anfing war VHDL höher angesehen. Jörg
Ok werte Gemeinde, ich war fleißig und habe die letzten Tage durchprogrammiert. Leider hat die Zeit nicht gereicht alle Punkte auf der Liste abzuarbeiten, aber die neue Version kann sich trotzdem sehen lassen. Hier die Highlights: - automatischer Support für 12/14/16 Bit DAC ohne Umschaltung! Auch gemischte Bestückung. - neue Kalibrierroutine die für die neue DAC-Ansteuerung optimiert wurde und eine neue Kalibrierlogik hat, die jetzt den Offset dynamisch gegen Null approximiert. Weiterhin habe ich den ADC-Abgleich und den DAC-Abgleich zusammengelegt. Es gibt also nur noch einen Button für den Abgleich. Damit Ihr die neue Routine besser testen könnt habe ich die Debug-Ausgaben auf RS232 dringelassen. Ihr könnt Euch also den Abgleichvorgang in einem Terminalfenster ansehen und prüfen ob er wirklich auf Null geht. D.h. der Offset liegt dann unterhalb der Anzeigegenauigkeit in allen Spannungsbereichen! Besser geht es nicht... - Der freie Platz neben dem Kalbrierbutton hat auch schon eine neue Funktion bekommen. Hier kann man zwischen 4 verschiedenen Kalibriersätzen wählen (für branadic und alle die aktive Tastköpfe benutzen) - Main Wheel Support für die Channel Delay Popups und für Average und Noise Filter. - Weiterhin noch einige kleine Änderungen. (siehe changelog und special_functions.txt) Gruß Hayo
Hallo Hayo, ich hab die neue Version mal eingespielt, allerdings ist nach der Kalibrierung mein Kanal3 (über Kanal4 kann ich nichts sagen da teilentstückt) verschwunden. Hab mal zwei Kalibriervörgänge mitgeschnitten, vielleicht kannst du darin was entdecken? branadic
Hallo Branadic, Dein Kanal 4 liefert wie erwartet keine Werte. Aber Kanal 3 wird korrekt kalibrtert. Gruß Hayo
Hallo Hayo, wie ich schrieb habe ich den teilweise entstückt, um Platz für die Huckepackplatine zu machen. Wirkt sich das jetzt etwa negativ auf die Kalibrierung von Kanal 3 aus? branadic
Ah, du hast in der Zwischenzeit dein Posting editiert, auch gut... Ich habe mich einmal durch die Calibration Sets gedrückt und wenn ich dann wieder bei Standard ankomme, dann ist Kanal 3 wieder da. Noch was, Kanal 1 ist zu tief, also unterhalb der gedachten Nulllinie, woran kann das liegen? branadic
Da haben sich unsere Posts wohl überschnitten. Ich hatte beim zweiten Überlesen schon gesehen dass Du den Kanal 4 rausgelötet hast. Hast Du die Kalibrierung mal für alle 4 Kalibrier-Sets gemacht? Deinem Protokol entnehme ich aber, dass mit Deinem Kanal 3 alles genau richtig klappt. Also hakt es wohl woanders. Gruß Hayo
Es könnte sein, dass die DAC-Skalierungsfaktoren für die 16 Bit DACs angepasst werden müssen. Dafür muß ich aber bei mir den 16 Bit DAC einbauen um das zu überprüfen. Gruß Hayo
Okay, jetzt haben wir den zeitlichen Versatz wieder ausgeglichen :) Also, nach der Kalibrierung muss ich mich einmal durch die Sets drücken, damit Kanal 3 wieder dargestellt wird. Vielleicht hängt das irgendwie mit meinem Kanal 4 zusammen, kann gut sein. Kanal 2 und 3 liegen dann sauber auf Null, nur Kanal 1 liegt 6 Pixel unter Null. Hab das mit der Triggerlinie mal ausgezählt. Lässt sich das eigentlich irgendwie über das Terminal manuell erade biegen? Die Testschalter scheinen nicht mehr ganz aktuell zu sein oder irre ich mich da? branadic
Warte mal, ich seh mal kurz nach. Ich hatte die manuelle DAC-Kalibrierung extra drin gelassen. Moment...
Es ergibt sich ein Bild Hayo, die Abweichung hat was mit der Position auf dem Bildschirm zu tun, bei Kanal 1 fällt das nur gleich so extrem auf, weil der Kanal am oberen Bildschirmrand klebt. Kurbel ich Kanal 3 auch nach oben auf die Position von Kanal 1, dann weißt er den gleichen scheinbar negativen Offset auf. Spannungspegel und Bildschirmposition passen nicht 100% zusammen, dass ist alles. In der Bildschirmmitte ist auch bei Kanal 1 alles in Ordnung. branadic
...ok hab's, also mit shift + Z kannst Du den Testkanal verstellen der den wirksamen Kanal vorgibt. Den Spannungsbereich für den kalibriert wird mußt Du von Hand einstellen (5er oder 2er oder 1er) mit der normalen Bereichseinstellung auf dem Frontpanel. Du mußt natürlich auch ein Kalibrierset ausgewählt haben mit dem Du testest. Die kalibrierung kannst Du dann mit Shift + E hochzählen und mit Shift + W runterzählen. Das Ergebnis kannst Du Dir dann mit "," ansehen. Bei mir liegen die Offsetkorrekturen bei: * CH1 DAC correction 1: 406 * CH3 DAC correction 1: 448 * * CH1 DAC correction 2: 478 * CH3 DAC correction 2: 506 * * CH1 DAC correction 3: 400 * CH3 DAC correction 3: 427 * * CH2 DAC correction 1: 358 * CH4 DAC correction 1: 418 * * CH2 DAC correction 2: 422 * CH4 DAC correction 2: 478 * * CH2 DAC correction 3: 373 * CH4 DAC correction 3: 427 * Gruß Hayo
Ok, hast Du mal Dein Hardwaresetting geprüft? Welchen Pre Gain hast Du eingestellt? Das was Du da beschreibst deutet auf die Skalierungsfaktoren hin! Gruß Hayo
Hallo Hayo, ja habe ich geprüft, das passt soweit auch alles, steht auf PreGain 1.25. Messungen mit Multimeter und Oszi an einer Batterie oder an einem Labornetzteil zeigen auch näherungsweise das gleiche Ergebnis. branadic
Hallo Hayo, anbei mal drei Bilder, die verdeutlichen sollen, was Sache ist. Vielleicht hilft das bei der Fehlersuche? branadic
Ok, das sind ganz klar die Skalierungsfaktoren, die nicht passen. Wenn auf Gridmitte die Offsets Null sind aber oben und unten im Grid Aweichungen auftreten dann ist es das. Die sind ja auch nur für den 14 Bit DAC ermittelt worden. Leider kann ich da erst tätig werden sobald ich den 16 Bitter bei mir drin habe. Ich könnte sonst noch versuchen so nach Gefühl die Werte für Dich anzupassen, damit Du was zum Probieren hast. Wie sehen denn die 5er und 2er Bereiche aus? Gruß Hayo
Hast Du die Möglichkeit zu kompilieren? Die Faktoren findest Du in der
tc_vars.cpp ab Zeile 1165.
float DAC_ScaleFactor[3][5] =
gain 1/gain 1.25/24 Ohm/33 Ohm/addon
{{ 2.480, 2.480, 2.6456, 2.520, 2.476 }, // 1er ranges
{ 4.940, 4.940, 5.2912, 4.980, 4.952 }, // 2er ranges
{12.360,12.360,13.2280,12.432,12.432 }}; // 5er ranges
Du könntest sie Dir einfach selbst anpassen.
Hayo W. schrieb: > Wie sehen denn die 5er und 2er Bereiche aus? Kann ich dir heute Abend sagen, muss ich prüfen. Hayo W. schrieb: > Hast Du die Möglichkeit zu kompilieren? Nein, ich habe die Tool Chain nicht installiert, da ich mit Programmierung, die über Matlab/Octave hinaus geht, nicht wirklich was am Hut habe. branadic
Hayo W. schrieb: > Hast Du die Möglichkeit zu kompilieren? Kann ich übernehmen. Welche Werte müssen denn geändert werden? Jeweils der letze in der Zeile? Mfg, Kurt PS: Die Digikey Lieferung ist schon in Köln und müsste morgen ankommen.
Nein etwas anders, am Besten Du suchst Dir eine Spalte aus - z.B. die Letzte. Die läßt sich dann anwählen über das Hardwaremenü Pre Gain -> "Addon". Die drei Werte sind dann für jeweils einen Spannungsbereich. Der Oberste für die 1er Spannungsbereiche, der mittlere für die 2er und der unterste ist für die 5er. Ich vermute, dass die Werte für den 16 Bit DAC einfach noch nicht genau genug sind und nur feinjustiert werden müssen. Zum Justieren muß die Nullposition des Kanals möglichst weit oben oder unten sein um die maximale Abweichung zu haben. Gruß Hayo
Was mich aber etwas wundert, ist der Unterschied zwischen Kanal 2 und den beiden andern Kanälen. Kanal 2 sieht ja eigentlich ganz ok aus. Es sollte bei gleicher Eingangshardware eigentlich keinen Unterschied geben. Ist da was an den Widerständen geändert worden? Gruß Hayo
Hallo Hayo, verdammt, es ist schon so lange her... ich habe auf Kanal 1 und Kanal 3 die 24.9Ohm drin, Kanal 2 hat noch die 0 Ohm drin. Den 150k hab ich allerdings nicht ausgetauscht. Wenn ich jetzt die beiden Kanäle nach oben kurbel wird die Abweichung zur Nulllinie aber noch größer. Hier stoßen wir also auf die erste Problematik, wie die ganzen Hardwareunterschiede gescheit in den Griff bekommen? Ich könnte natürlich hergehen und alle Widerstände wie im Datenblatt vorgesehen bestücken, sprich 2x 24.9 Ohm und 150 Ohm. Das sollte dann aber auch die festgelegte Konfiguration für die Huckepackplatine sein, sonst bekommt man das nicht unter einen gemeinsamen Hut. branadic
Na dann ist ja alles klar. Es liegt also nicht am DAC. Mit der 24/150 Ohm Bestückung passen die Faktoren der 24 Ohm Pre Gain Einstellung. Die habe ich auch drin. Rüste die doch einfach um, das ist vom Aufwand her am einfachsten denke ich. Gruß Hayo
Hallo Hayo, passen tut es ja trotzdem nicht 100%ig, siehe Kanal 2 mit PreGain 1.25 Einstellung. Von den 24 Ohm halte ich ebenso wenig wie von den 33 Ohm, wenn man es richtig machen will, dann müssten es entweder 24.9 Ohm mit kleinster Toleranz und den 150 Ohm am ADC sein oder aber handverlesene 24 Ohm, die nominal 25 Ohm aufweisen mit den 150 Ohm am ADC. Alles andere macht schlichtweg keinen Sinn. Schließlich soll es sich um ein Messgerät und nicht um ein Schätzeisen handeln. branadic
Noch ein Nachtrag, Kanal 2 hatte ich seinerzeit nicht umgerüstet, weil da diese tollen nachträglich eingezogenen Leitungen im Weg waren. branadic
Kanal 2 sieht doch gut aus. Must Dir das mal im 5er Bereich ansehen, da ist weniger Rauschen drauf. Sonst rüste das doch erstmal zurück auf Originalbestückung, dann können wir besser vergleichen. Hayo
Kanal 2 ist doch auf Originalbestückung, sprich auf 0 Ohm Widerstände oder meinst du ich solle die DAC zurücklöten? Das muss dann wirklich nicht sein, zumal die das Auslöten eh nicht überlebt haben, ein Nachteil von bleifrei gelöteten SMD-Bauteilen, wenn man die Leiterplatte beim Auslöten schonen möchte. branadic
Nein, nein, nicht den DAC zurückbauen, nur die Widerstände von Kanal 1 + 3. Oder damit leben, dass nur Kanal 2 richtig anzeigt. Jedenfalls zeigt mir Dein Ergebnis, dass die DAC-Ansteuerung korrekt funktioniert. Ich werde das bei meinen Geräten auch mal umrüsten. Gruß Hayo
Branadic, ein Messgerät mit 8-Bit-Auflösung! Also schön ruhig bleiben. ;-) Auch mit 10 Bit wird es kein Messgerät. Die Werte sind doch nur Empfehlungen und solange die Software auf ein Pixel genau darauf eingestellt werden kann ist doch alles o.k. Gruß, Guido
Guido schrieb: > Also schön ruhig > bleiben. ;-) Vielleicht bleibst du noch ne Nummer ruhiger und schaust mal, wie groß die Abweichung tatsächlich ist? Im Rahmen dessen was möglich ist sollte man auch genau sein! branadic
Schon klar, dass das zuviel ist. Aber mit den Widerständen muss es nicht so exakt sein. Das meinte ich.
Ich nutze das FFT oft für Audio Projekte. Gibt es eine Möglichkeit, das das Spektrum feiner eingestellt werden kann? Das währe bei kleinen Frequenzen sehr sinnvoll.
Die FFT-Sektion ist noch "under construction", d.h hier wird sich noch einiges tun. Was meinst Du denn mit feiner einstellen? Die Auflösung der Spektrallinien ist durch die kleinste Abtastrate (500Sa/s) und die Bildschirmauflösung begrenzt. D.h. ich kann maximal eine FFT mit 1024 Werten machen und habe dann 512 Spektrallinien. War es das was Du meintest? Gruß Hayo
So, für das Wochenende gibt es wieder was zum spielen. Diesmal habe ich mich der Screenshot-Funktion angenommen und einen Rundumschlag gemacht (aufgeräumt und erweitert). Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC und USB-Host zu wählen. Für alle Screenshots wird jetzt die schnellere Kompressionsroutine der 0.92.OS Version verwendet. Auf PC Seite gibt es zwei neue Screenshot-Versionen. Beide können wahlweise eingesetzt werden und verwenden beide den gleichen Kompressionsalgorithmus. - die neue OS-Version 0.93 hat sich bei der Parametererkennung über RS232 etwas geändert. Das heißt sie ist weiter abwärtskompatibel zu älteren Firmwareversionen (BF und OS), aber sie läßt sich genauso mit der neuen FW ansteuern und kann wie gehabt auch remote triggern. - die neue BF-Version 2.0 hat jetzt den schnellen Kompressionsalgorithmus der OS-Version. Der Aufruf ist noch schlanker geworden, es kann optional der Port (bzw. das device) übergeben werden, muß aber nicht. Defaultmäßig wird wie bei der OS-Version COM1 bzw. /dev/ttyS0 verwendet. Bei ASCII und CSV Format werden zusätzlich die aktuellen Einstell-Parameter übertragen und ans Ende der Datei gehängt. Die alten Screenshotversionen können nicht mehr verwendet werden!!! Gruß Hayo
Hallo alle zusammen, habe mich gerade mit dem seriellen Update beschäftigt: Für das .ram reicht es aus, das File mit mode com1,115200,n,8,2 leider ist der mode-Befehl sehr buggy, meist geht 115200 nicht copy /b tomcat.ram com1 zu übertragen. Wichtig sind die 2 Stopbits, sonst ist die Übertragung zu schnell. Der Transfer dauert dann 1313562*(1+8+2)/115200=125,426 Sekunden. Alternativ die Übertragungsfunktion (Upload) eines Terminalprogramms verwenden, auch hier 2 Stopbits. Dazu muss man allerdings das Kabel oder die DSUB-Buchse modifizieren, weil sonst ein Error kommt. An der Dsub9-Buchse sind tatsächlich nur die Pins 2, 3 und 5 angeschlossen, nicht einmal Shield liegt auf Gnd. Um den copy-Befehl auf die Serielle zufriedenzustellen, müssen die Pins 1,6,7,8,9 miteinander verbunden werden. Zu der fackernden LED im Stop-Mode: hier wäre ein retriggerbares Monoflop das richtige, d.h. sobald ein Triggerereignis eintritt, wird ein Zähler wieder auf seinen Anfangswert (z.B. 50) gesetzt, um dann jede Millisekunde heruntergezählt zu werden. Solange er ungleich 0 ist. leuchtet die LED. D.h. bei Signalen über 20 Herz soll die LED durchgehend leuchten. Die kurze Leuchtdauer soll auch für das Leuchten bei Triggerauslösung gelten, hier leuchtet die LED etwas zu lange. Lieber Hayo, ich habe großen Respekt vor Deinem Durchhaltevermögen und Deiner Konsequenz. Vielen Dank von meiner Seite, dass Du alle meine Vorschläge umgehend realisiert hast. Ist es möglich, das Menü für die LED-Steuerung zu erweitern? Es wäre toll, wenn man bei der rechten LED zusätzlich auswählen könnte, ob sie bei einem potentiellen Trigger (trigger) aufblitzt oder nur bei einem tatsächlich ausgelöstem Trigger (trig'd = triggered). Der Punkt "use Ch4-LED" sollte eigentlich eine separat aktivierbare Checkbox sein, um die LED umzuleiten, unabhängig von ihrem Modus. Genauso könnte es man auswählbar machen, ob ein Druck auf Single im NORM-Mode - auf single schaltet (wie es momentan ist) oder - einen manuellen Trigger auslöst (was ich bevorzuge, man muss dann über Stop gehen, wenn man auf Single will.) Noch was zur Spannungsanzeige des Triggerlevels: die stimmt nicht exakt mit der Voltage/Division überein. bei 50mV/div und Triggerlinie exakt ein Kasterl daneben wird 52mV angezeigt. Zur Anzeige und Schrittgröße beim Drehen an der PreTrig-Time: die Anzeige sollte immer 3 gültige Stellen haben (ist von 9,0 bis 9,9 ms nicht der Fall) und eine Rastung soll sich immer auf die letzte Ziffer beziehen. Jetzt muss man z.B. 13 Rasten drehen, um von 99,0 auf 100,0 ms zu kommen (oder 2 Rasten von 10,1 auf 10,2). Oder man macht die Einstellung exponentiell, indem die Schrittweite immer z.B. 1% des angezeigten Wertes beträgt. Und diese Schrittweite wünsche ich mir per Druck auf den Drehknopf z.B. zyklisch aus drei-acht Werten auswählen zu können (z. B. 1, 2, 5 digits, 1%, 2%, 5% des momentanen Wertes). Das sind viele Wünsche, ich weiß. Bis demnächst
Angehängte Dateien:
-
bug-2.13-kanal3u4_1.png
4,9 KB -
bug-2.13-kanal3_2.png
5,8 KB
Hallo Hayo, bzgl. Firmware v2.13: Ich habe da einen merkwuerdigen Bug gefunden, den ich wie folgt 100%tig reproduzieren kann: (1) Zeitbasis <= 50ns/Div (2) Kanal 3 oder 4 aktivieren (3) "Center Channel" Softbutton druecken Bildschirmausgabe dann wie im ersten Screenshot. Tritt jedoch nicht bei Kanal 1 u. 2 auf. Verschiebe ich Kanal 3 per Hand ein paar Pixel nach oben, kann ich gar die Ausgabe wie im zweiten Screenshot provozieren. Dies funktioniert jedoch nicht bei Kanal 1, 2 und 4. Verschiebe ich die Kanaele wieder woanders hin sind die Fehler weg. Ob ich im Display Menue bei "Switch Drawing" Line() oder vertical pixel eingestellt habe macht keinen Unterschied. Der Bug tritt auch bei anderen, etwas langsameren Zeitbasen auf, allerdings nicht genau in der Mitte. Default-Setup und Abgleich habe ich vorgenommen. Ich habe das W2024A. Vorherige Firmware-Version war die 2.10, dort habe ich den Fehler nicht beobachtet. Niklas Zusatz: Lasse ich mir den Trace im Bug-Zustand auf RS232 als CSV ausgeben finden sich viele Werte fuer den betroffenen Kanal mit 0 und 254, d.h., vermutlich ist es kein reiner Fehler bei der Zeichnung.
Hallo Ihr Beiden, danke für die Rückmeldung. Ich bin leider dieses Wochennde etwas knapp an Zeit, aber Eure Beiträge sind zur Kenntnis genommen. Ich muß mal sehen ob ich morgen oder übermorgen Abend dazu komme mich damit etwas näher zu beschäftigen. Gruß Hayo
Noch was, vielleicht hilft es Dir, Hayo, bei der Fehlersuche: Die Anzahl, wie oft auf Single gedrückt werden muss, bis ein Trigger ausgelöst wird, hängt von der Zeitbasis ab: 1ms 1x 2ms 2x 5ms 4x 10ms 8x 20ms 16x 50ms 32x 100ms 64x @branadic: auch ich denke, dass man keine Widerstände selektieren braucht, sondern dass die Korrekturfaktoren eingebbar sein sollen. So kann man x-beliebige krumme Verstärkungsfaktoren wählen, um z.B. den ADC-Eingangsbereich optimal zu nutzen. Allerdings weiß ich nicht, ob ohne HW-Mul das von der Performance her sinnvoll ist. Auf jeden Fall freut es mich, dass wieder alle an einem Strang ziehen und es zügig vorangeht. Ich komme ja kaum mit dem Flashen hinterher ;-)
Hallo Niklas, es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen, aber ich kriege es nicht hin. Welche Hardwareeinstellung hast Du gewählt? Kann das noch jemand hier nachstellen, oder ist das ein spezielles Problem von Niklas? Gruß Hayo
Hallo Hayo, > es hat mir keine Ruhe gelassen. Ich habe mal versucht das nachzustellen, > aber ich kriege es nicht hin. Mhm, gerade, nachdem das Geraet fuer eine Stunde aus war, habe ich es auch nicht sofort wieder reproduziert bekommen, erst nach "Utility->Calibrate Offsets" klappt es wieder 100%tig. (Nach "Warmlaufen" des Oszis kann ich btw. eine Verschiebung der Nullinien gegenueber Kaltzustand feststellen, vllt. ist zum Reproduzieren daher ein frisches "Calibrate Offsets" noetig.) > Welche Hardwareeinstellung hast Du gewählt? Du meinst "Utility->More->Hardware"? ADC -> Factory PreGain -> Factory zudem in "Utility->More": Delays: Ch1: 8ns / Ch2: 0ns / Ch3: 5ns / Ch4: 5ns Das Geraet ist bis auf Schirmblech und zwei SMD LEDs beim Trigger unveraendert. Ich sehe auch gerade das branadic oben in seinem Beitrag vom 19.2.: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" einen aehnlichen Effekt beobachtet hat. Niklas
Angehängte Dateien:
-
bug-2.10-kanal3u4.png
4,5 KB
Hallo nochmal,
ich habe die alte v2.10 mal ins RAM geladen, um zu schauen,
ob das Problem wirklich dort nicht auftaucht.
Ergebnis: Auch bei v2.10 habe ich den Effekt bei Kanal 3 und 4,
allerdings nicht genau auf der Bildschirmmitte sondern etwas
versetzt (3-10 Pixel) nach oben. Da ich meist "Center Channel" bzw.
"Dispatch Channels" benutze ist es mir wohl bislang nicht
aufgefallen.
Ebenso wie Hayo frage ich mich ob es ein isoliertes Problem bei
mir ist oder auch bei anderen 4-Kanal-Geraeten auftritt.
Wer testen moechte:
(1) Zeitbasis auf 50ns/Div einstellen, Trigger auf "Auto"
(2) Kanal 3 oder 4 auf Bildschirmmitte ("Center Channel")
(3) Pixelweise nach oben (oder unten) verschieben
Weiter frage ich mich, ob es sich um ein thermisches Problem
handeln koennte, da die Anzahl Ausreisser mit Aufwaermen des Oszis
zuzunehmen scheinen. Allerdings erklaert das nicht, warum der Fehler
beim Verschieben des Traces verschwindet bzw. ueberhaupt anscheinend
nur in der Bildschirmmitte auftritt.
Das sieht fuer mich daher eher nach einem Bug in der
Softcore-Firmware aus.
Anbei nochmal ein charakteristischer Screenshot, FW v2.10.
Niklas
Bevor ich verschwinde und bei meinen Schwiegereltern die Bude entrümple noch ein Gedanke: Stell doch mal alle Delays auf 0ns und probier es nochmal. Gruß Hayo
Hallo Hayo,
> Stell doch mal alle Delays auf 0ns und probier es nochmal.
Macht leider keinen Unterschied. Auch die anderen Einstellungen
zu ADC und PreGain scheinen keinen Einfluss zu haben.
Niklas
Niklas O. schrieb: > Wer testen moechte: Hab' ich getan mit 'Default Setup' und dann wie oben. Bei mir am W2024A mit FW BF2.13 ohne Befund. Kommt mir wie ein klemmendes oberstes Bit vor? Hast du mal von außen ein Analogsignal (Sägezahn/Sinus) draufgegeben und beim Nulldurchgang geguckt? Gruß Rainer
Den gleichen Verdacht mit dem verklemmten Bit hatte ich auch schon. Vorschlag zur Fehlersuche: Auf der Platine des geöffneten DSO auf die Chips drücken. Teilweise sind die Lötverbindungen an den SMD-Bauteilen nicht optimal und verursachen dann so komische Effekte. Ich glaube Kurt hatte das mal an den RAM-Bausteinen. Gruß Hayo
Ich kann mir keine Ursache in der Platinenhardware vorstellen, die einen solchen Effekt verursachen sollte. Wenn die Daten digitalisiert und erst einmal im FPGA gelandet sind, wie sollen da die Bit kippen, wenn nicht gerade ein Fehler im FPGA oder in der Firmware vorliegt, das irgendwo irgendwelche Überläufe o.ä. stattfinden. Ich habe bspw. auf Kanal 2 den Effekt, dass die "zufälligen" Spikes nur zur Signalhälfte kippen. Das kann kein Fehler der Platinen-Hardware sein, zumal mit Alex Design derartige Effekte bisher überhaupt nicht beobachtbar sind. branadic
Angehängte Dateien:
-
sinusdurchgang.png
3,4 KB
Hallo Hayo und Rainer, scheint in der Tat ein klemmendes Bit zu sein. Gerade wie vorgeschlagen nen Sinus angelegt. Die Fehlwerte treten genau wie erwartet beim Nulldurchgang auf. Anbei Screenshot. Nicht wundern, ich habe leider hier nichts besseres als 750 kHz aus nem XR2206-basierten Generator und bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf als das ich das mit einem Screenshot haette aufzeichnen koennen. Die Ursache ist damit wohl geklaert, danke an euch fuer den Tipp. Kalte Loetstellen wuerden dann auch die beobachtete Verschlimmerung bei Erwaermung erklaeren. Aufschrauben und evtl. Nachloeten verschiebe ich aber erstmal bis auf unbestimmt. Niklas Update: Urgs, zweimal den selben Screenshot. Kann man anscheinend auch nicht wieder entfernen.
Niklas O. schrieb: > Anbei Screenshot. Nicht wundern, ich habe leider hier nichts > besseres als 750 kHz aus nem XR2206-basierten Generator und > bei Zeitbasen >100ns/Div treten die Ausreisser zu selten auf > als das ich das mit einem Screenshot haette aufzeichnen koennen. Sieht doch super aus. Meine Interpretation ist, dass das oberste Bit etwas verspätet schaltet und dadurch am Nulldurchgang steigend (0xFF -> 0x00) gerne 0x80 auftritt bzw. fallend (0x00 -> 0xFF) der Wert 0x7F. Das wären dann Peaks nach Minus-FS bzw. nach Plus-FS. Der erste Fall ist genau in deinem Bild zu sehen. Am fallenden Nulldurchgang würde ich entsprechend einen Peak nach "+" erwarten. Das Problem wäre dann an einer Stelle, wo die Werte als 2er-Komplement vorliegen. Die Verzögerung muß natürlich nicht zwingend durch eine schlechte (hochohmigere) Lötstelle entstehen, sondern kann auch an einem Timingfehler und temperaturabhängigen Toleranzen im FPGA liegen, was sich dann mit branadics Interpretation decken würde. Hast du einen anständigen Lüfter drin? Gruß Rainer
Angehängte Dateien:
Hallo nochmal, Rainer schrieb: > Der erste Fall ist genau in deinem Bild zu sehen. > Am fallenden Nulldurchgang würde ich entsprechend > einen Peak nach "+" erwarten. Ich habe das ganze mal >5 Minuten mit "Display->Persist" aktiviert bei 1us/Div aufzeichnen lassen. Deine Erwartung trat dort nicht ein, wobei wie gesagt bei diesen langsamen Zeitbasen die Ausreisser selten auftreten. (Screenshot 1) Ich habe auch mal die Amplitude (und damit die Steilheit auf dem Screen) stark erhoeht und mir den fallenden Nulldurchgang bei 50ns/Div angeschaut. Dort sehe ich dann die von Dir erwarteten "+" Peaks. (Screenshot 2) (Im aufsteigenden Durchgang entsprechend "-".) Was ich nicht verstehe ist aber, warum ich, wenn ich den Trace nach unten verschiebe, die Spikes weiterhin in der Bildschirmmitte, und nicht wie ich erwarten wuerde beim wahren Nulldurchgang, sehe? (Screenshot 3) Jetzt bin ich schon sehr irritiert. Was passiert denn mit den Werten der 4 interleaveten ADCs pro Kanal bis sie irgendwann im Softcore ankommen und gezeichnet werden? (Ich vermute mal dass die Softcore zeichnet, bitte korrigiert mich wenn ich falsch liege, den Teil der Firmware habe ich mir nie angeschaut.) > Hast du einen anständigen Lüfter drin? Originalluefter mit der Klebestreifen-Modifikation, jedoch ohne vergroesserte Schlitze aussen. Also "nein" :) Niklas
Niklas O. schrieb: > Ich habe das ganze mal >5 Minuten mit "Display->Persist" > aktiviert bei 1us/Div aufzeichnen lassen. Deine > Erwartung trat dort nicht ein, ... Mmmh. Da müßte man jetzt wissen, welche der Abtastwerte bei 1us/div für die Darstellung benutzt werden. Die Chancen die entscheidende Wandlung zu verpassen, ist da vielleicht schon zu groß und die Peaks, die da in die "falsche" Richtung gehen, könnten durch Rauschen entstehen, das da gerade in Gegenrichtung läuft (???). > Was ich nicht verstehe ist aber, warum ich, wenn ich den > Trace nach unten verschiebe, die Spikes weiterhin in > der Bildschirmmitte ... sehe? (Screenshot 3) Ohne jetzt in den Schaltplan geguckt zu haben, vermute ich, dass die Signalverschiebung durch Addition eines Offsets aus dem DAC gemacht wird. Die ADCs messen immer bezogen auf die Bildschirmmitte (Man möge mich bitte korrigieren, wenn ich da falsch liege) > Jetzt bin ich schon sehr irritiert. Was passiert denn > mit den Werten der 4 interleaveten ADCs pro Kanal bis sie > irgendwann im Softcore ankommen und gezeichnet werden? Gute Frage. Eine Möglichkeit wäre, dass der Peak immer vom selben ADC kommt. Aber dann wäre mir nicht klar, wieso Kanal 3 und 4 betroffen sind. Werden die Peaks eigentlich plattgebügelt, wenn du ein Noise Filter aktivierst? Als Lüfter bin ich mit dem "NOISEBLOCK 8X1R" von ex. Angelika sehr zufrieden (80 mm und nicht zu hören) Gruß Rainer
Also mein Vorschlag ist immer noch (kostet auch nix) - schraub die Rückwand ab, starte das Gerät und provoziere den Fehler. Dann drückst Du auf den ADCs des dritten oder vierten Kanals etwas herum - die sind da frei zugänglich. Wenn sich da nix ändert würde ich bei Gelegenheit die Chips auf der Rückseite der Platine in Angriff nehmen, aber dazu muß man etwas mehr auseinanderschrauben. Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass das durchaus kein Einzelfall ist. Gruß Hayo
Hayo W. schrieb: > Wie gesagt hatte Kurt (wenn ich mich nicht irre) darauf hingewiesen dass > das durchaus kein Einzelfall ist. Nein, das war wahrscheinlich Bruno. Ich hatte nur mal Lötzinnbrücke zwischen 2 Eingängen eines Schieberegisters.
Hallo, mal was anderes: Man kann ja, wenn man bereits im Mode/Coupling-Menue ist, durch abermaliges Druecken der Taste Mode zwischen Auto, Normal und Combi umschalten. Ich faende es sinnvoll, wenn eine Umschaltung analog dazu auch bei Edge (Rising->Falling->Rising->...) und Pulse Width (Time Qualifier-Variationen), als sowohl fuer Main/Delayed (Main->Delayed->Main->... (nicht X-Y)) moeglich waere. Das ganze habe ich gerade mal in 20 Zeilen eingebaut (alles Ergaenzungen, keine Zeilenaenderungen). Diff ist im Anhang. Vllt. kann Hayo das ja bei der naechsten Version einbauen. Ansonsten, bzgl. Screenshot/Datendump: Mittlerweile benutzen wohl sowohl das Original als auch die abgewandelte BF-Version die selbe Kompression (und wohl auch selbes Protokoll). Unterschied scheint mir nach kurzem Blick eigentlich nur Verhalten gegenueber dem Nutzer und moegliche Optionen zu sein. (Plus Neuerungen wie Ausgabe Einstellungsparameter bei CSV/ASCII.) Ich finde es unschoen, da immer noch zwei Versionen zu haben -- bei fast identischer Codebasis. Wenn nichts dagegen spricht wuerde ich mich daran machen, diese wieder zusammen zu fuehren. Das gewohnte unterschiedliche Verhalten "OS" vs. "BF" gegenueber dem Nutzer kann man sicher durch Mitliefern von zwei Batchdateien mit entsprechend gesetzten Kommandooptionen beibehalten. Niklas
Hi, bin gerade erst zurück. @Niklas Die Funktionen die Du da als Diff mitgeschickt hast baue ich natürlich mit ein, macht ja auch Sinn. Auch das mit der Screenshotversion hab ich mir schon überlegt, da hast Du natürlich recht. Wir könnten die BF-Version auslaufen lassen und die OS-Version auf den Releasestand 1.00 bringen. Mittlerweile ist es ja ein "stable release". Was dann noch übernommen werden müßte ist die Erweiterung bei ASCII und CSV, ansonsten funktioniert die OS genauso wie die BF-Version und kann aber noch zusätzlich remote triggern und Schwarzweiß-Shots machen. Machst Du das? Gruß Hayo
Ach ja, Du könntest den Namen verkürzen wie bei der BF-Version, dann muß man nicht immer so viel eintippen, sondern kann das Teil einfach ohne Parameter im Defaultmodus starten. Gruß Hayo
Hallo Hayo, > [Screenshot/Dump] > [Uebernahme Erweiterungen] > Machst Du das? Ja. Niklas
Hallo Hayo, zur Vereinfachung der Bedienung habe ich folgenden wahrscheinlich einfach umsetzbaren Vorschlag: Wenn man eine Kanal-Tasten (1..4) zur Aktivierung bzw. Deaktivierung eines Kanals drückt, werden in der aktuellen FW die Softkeys für die zugehörigen Kanaleinstellungen angezeigt. Wenn man jetzt einen Kanal deaktiviert, werden automatisch alle Softkeys disabled, was eigentlich niemand wirklich etwas bringt. Sehr viel praktischer wäre, wenn entweder die Taste "Dispatch Channels" aktiv bliebe oder das ganze Menü auf einen der noch aktiven Kanäle geschaltet würde. Das ist immer richtiger/besser als ein komplett deaktiviertes Menü. Gruß Rainer
Hallo Rainer, da hast Du eigentlich recht. Ich versuche das mal zum nächsten Release einzubauen. Gruß Hayo
Hallo, Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor allem aber die notwendigen Infos für die Programmierer-Fraktion. http://sourceforge.net/apps/trac/welecw2000a/wiki/leon3design Ich habe gestern mal das Design eingespielt und mich ein wenig darin umgeschaut. Macht schon einen guten Eindruck, auch wenn sich das natürlich nicht mit der aktuellen BF-Firmware vergleich lässt. Die Geschwindigkeit ist jedoch beeindruckend. Man sollte dann keine Angst davor haben, dass Design ruhig mal einzuspielen. branadic
Hallo branadic, erstmal verstehe ich nur Bahnhof, muss ich wohl mehrmals durchlesen. Warst du damals mit dem urjtag weitergekommen? Bei mir hatte es ganz vielversprechend ausgesehen.
Guido schrieb: > Warst du damals mit dem urjtag weitergekommen? Was meinst du damit? Kann mich nicht erinnern an der Baustelle tätig gewesen zu sein. branadic
Dann habe ich das wohl verwechselt. Hatte nur in Erinnerung, dass jemand das passende BSDL-File gesucht hat und dachte du warst das.
@brandic > Man sollte dann keine Angst davor haben, dass Design ruhig mal > einzuspielen. Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte W2000a.SOF und -BIN ? Oder hattest du die vom letzten jahr eingespielt? Gruß Michael
Michael D. schrieb: > Die letzte Previev ist 7 Monate her, gibt es da eine aktualisierte > W2000a.SOF und -BIN ? > Oder hattest du die vom letzten jahr eingespielt? branadic schrieb: > Alex hat das Wiki zum Leon3 etwas aktualisiert. Ich hoffe, dass in den > nächsten Tagen weitere Infos und das aktuelle Preview hinzu kommen, vor > allem aber die notwendigen Infos für die Programmierer-Fraktion. Ich denke die Frage hatte ich bereits beantwortet und im Wiki ist es auch erwähnt. Es handelt sich um eine neue Preview. branadic
Hayo W. schrieb: > Auf der DSO Seite gibt es jetzt keine Unterscheidung mehr zwischen OS > und BF-Version. Es gibt nur noch die Möglichkeit zwischen den Zielen PC > und USB-Host zu wählen. Hallo Hayo, wo schaltet man das denn um? Wenn ich Quick Print drücke passiert garnichts. Mfg, Kurt
Hallo, anbei das vereinigte "OS+BF" W2000A Screenshot Programm in der Version 0.94. In Kuerze das Wichtigste: Es gab einiges aufzuraeumen. Im Wesentlichen sollte sich das Programm wie gewohnt verhalten. Die Dokumentation ist updatet und die Kommandooption -h sollte jetzt wieder der Realitaet entsprechen (wenn nicht ist das ein Bug, bitte melden). Traces werden jetzt als trace-nnnn.suf und nicht als screenshot-nnnn.suf gespeichert. Die Option -r fuer Raw funktionierte in der OS nicht mehr mit der Firmware und fiel weg. Es gibt eine neue Option -a, die, wie bei der BF Version, so sie fuer Windows kompiliert wurde (und dann auch nur bei Screenshots), zweimal \a, also Bell/Piepser, ausgibt nach jeder Uebertragung. Zudem werden wie bei BF Parameter wie Zeitbasis, Ranges, Kopplungen usw. ausgeschrieben. Die .bat/.sh sind updatet, so dass diese auch funktionieren sollten wenn man sie von einem anderen Verzeichnis aus ausruft. Achja, und die Parameter werden jetzt auch weiter uebergeben. Damit zukuenftig klar ist, ob die Programmversion zur Firmware passt, wird dies nun beim Start automatisch abgefragt. Die Windows-EXE konnte ich nicht mit Scope testen. Ansonsten: Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne hier melden. Wenn alles passt und nichts grossartiges mehr fehlt koennen wir die Version dann demnaechst 1.0 nennen. Niklas
Angehängte Dateien:
@Kurt Es passiert nix? Bei mir sieht es so aus wie auf dem Screenshot, den ich übrigens mit der coolen neuen 0.94 gemacht habe - läuft gut! Wie ist das bei den Anderen? Habt Ihr da Probleme? Hayo
@Niklas bei mir kommt während der Versionsprüfung die Meldung - unknown token: handleInChar(FF), UartRxGuiCmd: 69 Hat das was zu bedeuten? Ansonsten funktioniert aber alles bestens. Gruß Hayo
Hallo Niklas, fleißig, fleißig. Danke Niklas O. schrieb: > > Die Windows-EXE konnte ich nicht mit Scope testen. Da geht der Daumen auch hoch - läuft > Wer Ideen hat, was noch eingebaut werden sollte, kann sich gerne > hier melden. Mit der Formatierung des Headers bei ASCII und CSV kann ich noch nicht ganz warm werden. Wie wäre es mit etwas Kompakterem/Strukturierterem (ggf. <Tabs> vor den Argumenten), z.B. [Header] number_of_channels=4 channel_status=on;on;off;on channel_ranges=5V/div;5V/div;0;5V/div ... timebase=500KSa/s values=Ch1;Ch2;Ch3;Ch4 [Data] 83;130;255;171 83;129;255;172 ... Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges' und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl. praktisch. Gruß Rainer
Rainer W. schrieb: > Um die Daten in einer Tabellenkalkulation einfach richtig skalieren zu > können und eine Zeitachse zu generieren, wären die Angaben zu 'Ranges' > und 'timebase' in zusätzlichen Parametern als reine Zahlen evtl. > praktisch. Ja das hatte ich mir auch schon überlegt, da ja die jetzigen Parameterangaben nur informativen Charakter haben, aber nicht gut automatisch auswertbar sind. Hayo
Hallo, @Hayo: > bei mir kommt während der Versionsprüfung die Meldung > - unknown token: handleInChar(FF), UartRxGuiCmd: 69 > Hat das was zu bedeuten? So wie ich das sehe sind in der aktuellen Firmware Debugging-Ausgaben eingeschaltet, zumindest teilweise. (Siehe commif_t.cpp, Zeile 4'181.) Wenn man auf der seriellen Konsole etwas eingibt, z.B. 'h', kommt auch entsprechend 'handleInChar(68)' zurueck, gefolgt von der Hilfe-Tabelle. Dem Screenshot-Program sind die zusaetzlichen Ausgaben an sich egal. @Rainer: > [Formatierung Header] > Wie wäre es mit etwas Kompakterem/Strukturierterem > (ggf. <Tabs> vor den Argumenten), z.B. [..] Ja, das waere sinvoll. Fuer ASCII sieht Dein Beispiel schon gut aus, aber ich frage mich wie man das bei CSV am Besten machen koennte, so dass man nicht manuell nachbearbeiten und formatieren muss. Gibt es vllt. ein nicht zu schwer zu erzeugendes Tabellenformat das Excel, OpenOffice Calc und so weiter einlesen koennen welches einfache Formatierungen erlaubt? @Rainer, @Hayo: > Um die Daten in einer Tabellenkalkulation einfach > richtig skalieren zu können und eine Zeitachse zu > generieren, wären die Angaben zu 'Ranges' und 'timebase' > in zusätzlichen Parametern als reine Zahlen evtl. praktisch. Ja das sehe ich auch so. Sollte man das noch weiter treiben und gleich im Screenshot-Programm (optional) anbieten die 8-Bit-Zahlen in Spannungswerte umzuschreiben? Zudem muessen sicher nicht 16k Samples rausgeschrieben werden wenn die Zeitbasis in Wirklichkeit mit weniger arbeitet. Abgesehen davon: Generell kann ich das Ganze auch so bauen, dass man mit Templates arbeiten kann. Man hat also z.B. eine Datei rainer.tpl, mit Inhalt wie folgt:
1 | [Header] |
2 | number_of_channels=%numchannels% |
3 | channel_ranges=%ch1range_str%;%ch2range_str%;5%ch3range_str%;%ch4range_str% |
4 | [..] |
5 | [Data] |
6 | _FOREACH_%ch1%;%ch2%;%ch3;%ch4% |
...die dann zu Rainers Beispielausgabe expandiert. Allerdings sollten meiner Meinung nach erst die vorherigen Punkte klaeren und dies als zukuenftige Erweiterung ansehen. Niklas
Hallo Niklas, als importfreundlichen Header könnte ich mir soetwas vorstellen: [Header] number_of_channels=<tab>4 channel_status=<tab>on<tab>off<tab>off<tab>off channel_bandwith_limits=<tab>off<tab>off<tab>off<tab>off values=<tab>Ch1<tab>Ch2<tab>Ch3<tab>Ch4 [Data] 160<tab>159<tab>152<tab>188 Excel liest das bei Einstellung Trennzeichen="Tab" gut ein. Für die richtige Skalierung würde ich einfach Sampleabstand in Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere Headerzeilen aufnehmen. Der ASCII-Export mit Templates wäre natürlich der wahre Luxus. Gruß Rainer
Angehängte Dateien:
-
Inverted_Running.png
3,4 KB -
Inverted_Stopped.png
3,4 KB
@Hayo ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft nicht invertiert dargestellt. Gruß Rainer
Rainer W. schrieb: > Für die richtige Skalierung würde ich einfach Sampleabstand in > Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere > Headerzeilen aufnehmen. Der Sampleabstand ergibt sind ja aus der Timebase die bereits übertragen wird. Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel, hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß. Grundsätzlich aber eine gute Idee, kann ich auch noch nachreichen (auf DSO-Seite). > ich bin da gerade noch auf folgenden Bug bei invertierter Erfassung > eines Kanals gestoßen: Nach Drücken der STOP-Taste wird der Kanal oft > nicht invertiert dargestellt. Sehe ich mir an und versuche es zu fixen. Gruß Hayo
Hallo, @Rainer: > Excel liest das bei Einstellung Trennzeichen="Tab" gut ein. Ah, jetzt verstehe ich auch wie Du das mit den Tabs vor den Argumenten heute Morgen meintest. Eigentlich koennten wir das Trennzeichen auch gleich frei konfigurierbar machen. @Rainer und @Hayo: > Für die richtige Skalierung würde ich einfach Sampleabstand in > Nanosekunden und Skalierungsfaktoren sowie Offsets als weitere > Headerzeilen aufnehmen. Ich habe gerade mal geschaut wie ich an die Zero-Offsets (ZeroLevelCh1-4) kommen kann. Irgendwie scheint man da direkt nur ueber USB dranzukommen, ansonsten muesste man bei RS232 den Output von ',' parsen. Uebersehe ich da etwas? Sonst muessten wir das wohl noch einbauen. Ansonsten: Gehe ich richtig der Annahme das ich den Spannungswert ueber Z/(400/(24*8))+32-X/24*R, wobei Z=Zerolevel [0;400] fuer den jeweiligen Kanal, X der ausgelesene Wert und R Range, also z.B. 5V/div, errechnen kann? Niklas
Hayo W. schrieb: > Das mit den Skalierungsfaktoren hatte ich auch auf dem Zettel, > hab's aber erstmal verschoben, da man die float Faktoren auf DSO-Seite > in Bytes zerlegen muß und auf PC-Seite wieder zusammenbauen muß. Kann man da nicht einfach einen passend normierten Int32 übertragen. Das sollte doch reichen, um soetwas wie 1 mV/div bis 500 V/div abzudecken. Gruß Rainer
@Niklas Da zackern wir nicht lange rum. Alle Werte die Du brauchst schieben wir mit über die Schnittstelle als Shot. Sag mir was Du brauchst, ich bau das ein. Gruß Hayo
Das Problem mit dem fehlenden Quick Print Menü ist erledigt. Nachdem ich nochmal die 2.12 und dann nochmal die 2.13 installiert hatte war es wieder da.
Nanu, ein scwarzes Loch für Menüs? Is ja strange. Aber wenn's jetzt geht ist ja alles ok. Gruß Hayo
Hallo, ich habe die Umrechnung zu Spannungswerten am Laufen. Die noetigen Skalierungsfaktoren und die Zero-Offsets uebertrage ich im Rahmen der anderen Parameter nach dem Tracedump. Es stellen sich jetzt fuer mich, bevor ich weiter mache, folgende grundsaetzliche Fragen: (1) Die unkonvertierten Werte sind ja invertiert, d.h., fuer eine positivere Spannung sinken die Werte und vice versa -- was beim direkten Zeichnen dann natuerlich auch invertiert ist gegenueber dem Scope-Bild. Soll dies so bleiben (es kann ja sein, dass es dafuer einen guten Grund gibt) und nur optional umkehrbar sein, oder sollten wir, wo wir gerade dabei sind, das auch "beheben"? (2) Schon immer uebertragen wir stets stur 4x16kSa, auch wenn wir weniger Kanaele haben und auch wenn wir eine Zeitbasis eingestellt haben die nur mit 4kSa pro Kanal arbeit (<=25MSa/s). Das sollten wir meines Erachtens auch gleich beheben und dem Programm vom DSO sagen lassen, wie viele (aktive) Kaenele und wie viele Samples es empfangen wird. Ansonsten: Ich wuerde vorschlagen eine neue Kommandooption einzubinden die festlegt, wie die Daten bei einem Tracedump (vor)verarbeitet werden. Ich stelle mir hier folgendes vor: -o [i][mv] wobei: i -> invertieren (siehe oben) m -> Werte in mV als ganze Zahlen, v -> Werte in V mit 3 Nachkommastellen Niklas
Hallo Niklas, * Bei den unkonvertierten Werten wäre ich generell für Invertierung, d.h. hohe Werte oben. * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und die Kanalanzahl steht ja sowieso schon als Parameter "number of channels" im Header. Unter "Values" würde ich immer die originale Gerätekanalnummer nennen, damit man ggf. immer die Hardwarezuordnung hat. * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit dem neuen Frontend knapp sind. * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien dann zumindest unter Windows nicht mehr austauschbar sind, wenn auf den Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde das vermeiden. * Beim unkonvertierten Tracedump würde ich im Header die Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B (jeweils Integer) angeben, so dass gilt Y = ( X + B ) * A / N mit z.B. N = 1 / uV Evtl. ist auch Y = ( X * A + B) / N günstiger. Dann hätte man keine Floats und die Umrechnung wäre elementar. Gruß Rainer
Hi Niklas, ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch gleich die DSO-Seite mit abfackelst? Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von Dir einzupflegen? Den Invert-Bug habe ich übrigens schon behoben. Morgen habe ich tagsüber etwas Zeit, da werde ich mal die bisher aufgelaufenen Punkte abarbeiten. Ich sag ja, nach der Winterpause geht es wieder richtig los! Gruß Hayo
Wie steht es denn um die Ansteurung der Huckepack Platine?
Hallo Rainer, > * Die Ausgabe würde ich auf die genutzte Speichertiefe beschränken und > die Kanalanzahl steht ja sowieso schon als Parameter "number of > channels" im Header. Allerdings wird dieser erst am Ende uebertragen (Hayo hat das so gemacht damit die OS und aeltere Versionen weiter funktionieren), aber das koennen wir ja gleich auch aendern. > Unter "Values" würde ich immer die originale Gerätekanalnummer > nennen, damit man ggf. immer die Hardwarezuordnung hat. Da stimme ich zu. > * Bei der Skalierung kann ich mir vorstellen, dass ganzzahlige mV mit > dem neuen Frontend knapp sind. Sollten wir bei -o dazu noch u fuer uV anbieten? > * Bei der Ausgabe von Float gebe ich zu bedenken, dass die Dateien > zumindest unter Windows nicht mehr austauschbar sind, wenn auf den > Rechnern verschiedene Dezimaltrennzeichen eingestellt sind. Ich würde > das vermeiden. Mhm, das ist wirklich unschoen. Gerade geschaut: ist bei OpenOffice unabhaengig von Plattform auch so. (Beim Oeffnen der CSV ist im Konfigurationsdialog auch gleich die Sprache auswaehlbar, mit entsprechend spezifisch gesetztem Default.) > * Beim unkonvertierten Tracedump würde ich im Header die > Skalierungsparameter für jeden Kanal in Form von zwei Werte A und B > (jeweils Integer) angeben, so dass gilt > Y = ( X + B ) * A / N mit z.B. N = 1 / uV > Evtl. ist auch Y = ( X * A + B) / N günstiger. > Dann hätte man keine Floats und die Umrechnung wäre elementar. Mhm. Ich waere fuer die erste Variante, da man mit -B dann den unskalierten Nullpunkt haette. Fuer einfache Analysen und Zeichnung reicht dieser Wert zusammen mit den unkonv. Werten aus. Niklas
Noch ein Nachschlag zu den übertragenen Kanälen, grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt übertragenen Parameter Timebase und channel_x_active eingeschränkt werden. Ab Zeitbasis 10µs bis 500ms werden ja nur noch 4K pro Kanal abgetastet und wenn man noch die aktiven Kanäle abfragt sollte das die Geschwindigkeit im Schnitt doch deutlich erhöhen. Ich bin gespannt auf die Neuerungen... Hayo
Hallo Hayo, > ich sehe schon da geht was. Verstehe ich das richtig, dass Du auch > gleich die DSO-Seite mit abfackelst? > Dann brauche ich da nichts zu machen und nur die fertigen Sourcen von > Dir einzupflegen? Ja. Ich gebe Dir dann fuer die Firmware ein Diff. > grundsätzlich kann und sollte die Datenmenge anhand der schon jetzt > übertragenen Parameter Timebase und channel_x_active eingeschränkt > werden. Ja. Kann man sich natuerlich auch drueber streiten ob das Programm die Grenze fuer 4kSa vs. 16kSa kennen muss oder nur die Timebases an sich... Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher der erste Schnellschuss. Niklas
Niklas O. schrieb: > Wie gesagt, bislang wird der Header erst am Ende uebertragen, daher > der erste Schnellschuss. Ja das hatte ich wegen der Abwärtskompatibilität so gemacht. Dadurch verträgt sich das auch mit alten Versionen die nur die Werte übertragen. Den Zopf können wir aber auch abschneiden... Hayo
Hayo W. schrieb: > Den Zopf können wir aber auch abschneiden... Wer etwas dagegen hat, möge jetzt sprechen oder für immer schweigen Gruß Rainer
Schon mal vorab - ich habe heute eine ganze Menge geschafft (viele kleine Baustellen). Wenn dann noch die Erweiterungen von Niklas dazu kommen kann ich nur sagen es gibt wieder viel auszuprobieren :-) Wenn Niklas das zeitlich hinbekommt könnte das neue Release evtl. Sonntag fertig werden. Gruß Hayo
Hallo, anbei die neue v0.95 vom W2000A Screenshot Program mit dem voellig ueberarbeitetem Tracedump. Dazu das Diff gegen die Original Firmware v2.13. Dieses enthaelt auch die Aenderungen aus Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" Zum Ausprobieren dann noch ein Kompilat zum Einladen ins RAM. Notizen: - Leider konnte ich die Windows-EXE auch bei diesem Release nicht mit dem Scope testen. - Zum Einbau der Ausgabe der A und B Skalierungswerte, wie Rainer sie im letzten Punkt von Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)" vorgeschlagen hat, bin ich nicht mehr gekommen. - Mit dem Parameter -p und den darin gueltigen Flags v (Volt), m (mV), u (uV) sowie q ("quiet", keine Ausgabe des Headers) koennen die Daten bei der Ausgabe entsprechend vorverarbeitet werden. Bsp.: ./w2000a-screenshot -d -t ascii -p mq schreibt eine trace-0000.asc mit mV-Skalierung ohne Header. - Da -p v mit ganzzahligen Werten wenig Sinn ergibt werden bei diesem Modus Stellen nach Komma (Punkt) ausgegeben. (Siehe auch Rainers Hinweise bzgl. Float und CSV.) Niklas
Hallo Niklas,
unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung
irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und
Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen:
* Found Data Start Marker after 10s
- Receiving trace data...
4100 bytes..._
Der Cursor bleibt hinter "bytes..." stehen und es wird eine leere
Ausgangsdatei angelegt. Bei vier aktiven Kanälen läuft der Zähler
entsprechend bis 16400 bytes und dann passiert nichts weiter.
Der Screenshot in eine PPM-Datei ist ok.
Gruß
Rainer
P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch
vermißt
Hallo Rainer, > unter Win klappt mit der 0.94 / 2.14 Ram anscheinend bei der Übertragung > irgendetwas noch nicht. Wenn ich bei 1ms/div einen Kanal aktiv habe, und > Save to CSV oder ASCII im QP-Menü drücke, bekomme ich zu sehen: > * Found Data Start Marker after 10s > - Receiving trace data... > 4100 bytes..._ Kann es sein, dass Du tatsaechlich, wie Du schreibst, versehentlich die v0.94 benutzt statt der neuen v0.95? Die Ausgabe waere bei der neuen Version auch anders. > P.S. In der Hilfe (-h) habe ich die Optionen für die Skalierung noch > vermißt. Die sollte unter Misc erklaert sein. Starte mal bitte die .exe mit -v. Niklas P.S.: Ich frage mich gerade ob wir nicht auf DSO-Seite fuer Screenshot und Tracedump eine Header-Version ausgeben sollten. Wenn die Version neuer ist als das Programm kennt, verweigert es den Dienst. Im Moment prueft das Programm nur ob die Firmwareversion den Mindesanforderungen genuegt und nicht neuer als 10 Versionen ist.
Hallo Niklas, Gutes Argument. Kaum macht man alles richtig - schon geht es. Ich hatte irgendwie die alte Version ausgepackt. Nun ist auch die Hilfe vollständig. Anscheinend ist es schon ein bisschen spät. Sorry. Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Eine Ausgabe der Versionsnummer ist vielleicht eine gute Idee. Gruß Rainer
Hallo Rainer, > Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle > am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d > 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Mhm, wo mache ich das denn? Meinst Du vllt. die printf() in Schleifen mit \r (0x0d) vorne? Das dient dazu, dass ich dieselbe Zeile in der Ausgabe mehrfach schreiben kann, z.B. um eine Statusanzeige hochzuzaehlen. Niklas Update: Ich glaube Du meintest Hayo.
Kurt Bohnen schrieb: > Wie steht es denn um die Ansteurung der Huckepack Platine? Ist wohl untergegangen.
Niklas O. schrieb: >> Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle >> am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d >> 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? > > Mhm, wo mache ich das denn? Die unüblichen <lf><cr>s war mir direkt in den Daten auf der Schnittstelle bei den Versionstexten aufgefallen. Da hast du wohl Recht, ist wohl Hayo's Baustelle. (siehe Anhang) Zum Datenformat habe ich noch folgende Anmerkungen: 1) Díe Kanalnamen (CHx) würde ich als Parameter (z.B. channel_name) in den Header nehmen, damit unter /[Data]/ reine Zahlen stehen 2) Bei channel_delays würde ich channel_delays_ns angeben, auch damit hinten reine Zahlen stehen (Wer weiß wozu?) 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben verschoben" assoziiert. Wenn man die Daten in einer Tabellenkalkulation skaliert, spielt das sowieso keine Rolle ob "+" oder "-". Dann bin ich gespannt, wie das mit den fertigen Skalierungsfaktoren wird. Insgesamt - superschnell und großer Fortschritt auf der Baustelle. Gruß Rainer
Rainer schrieb: > Hat es eigentlich einen besonderen Grund, dass du auf der Schnittstelle > am Zeilenende immer 0x0a 0x0d überträgst, während sonst eigentlich 0x0d > 0x0a üblich ist (z,B, auch die Bootmeldung vom DSO)? Nein, hat keinen Grund, ich mache das frei von der Leber weg, da dort auch keine Kompatibilitätsprobleme zu befürchten sind. Ob ich erst den Wagenrücklauf mache und dann die neue Zeile oder umgekehrt bleibt unterm Strich gleich. Gruß Hayo
Kurt Bohnen schrieb: > Kurt Bohnen schrieb: >> Wie steht es denn um die Ansteurung der Huckepack Platine? > > Ist wohl untergegangen. Ja sorry die Frage hatte ich übersehen. Da ich noch keine Zeit hatte die Platine bei mir einzubauen ist das noch in Warteposition. Als Erstes wollte ich auch mal den 16 Bit DAC einbauen um zu prüfen ob das richtig funktioniert. Bei branadic ist ja nicht so richtig klar geworden ob das ok ist. Gruß Hayo
@Niklas Super wie schnell Du vorankommst und was die Screenshot-Schnittstelle inzwischen alles kann. Ich freue mich schon auf das nächste FW-Release. Noch eine Bitte, kannst Du mir zusätzlich zum Diff auch noch die Sourcen zukommen lassen? Dann kann ich mir das im Kontext vorher ansehen. Gruß Hayo
@Niklas Diff ist eingebaut und getestet - läuft gut! Gruß Hayo
Angehängte Dateien:
-
Datatrans.gif
57 KB
Hallo Ich verfolge dieses Projekt seit längerer Zeit als stiller Leser. Daher ein Dankeschön an alle die Ihre Freizeit für dieses Projekt opfern. Ich hätte eine Frage an die Experten. Ich bin gerade dabei meine Lautsprecherboxen zu verbessern und müsste daher Impedanz Messungen durchführen(über den gesamten Frequenzgang). Ich möchte die Auswertung und Darstellung mit LabView machen. Dafür brauche ich vom Oszilloskop kontinuierliche Messdaten. Gibt es eine Möglichkeit diesen Datentransfer durchzuführen? Kann man vielleicht im w2000a_schreenshot Programm (v. Niklas) eine Funktion hinzufügen die, die selektierten Messdaten von der Funktion „Qick Meas“ übernimmt. Und über die Datenschnittstelle an den PC weitergibt. Welec W2012A Gruß August
Thread beobachten
Seitenaufteilung abschalten