> 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
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
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
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
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.
@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
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
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
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
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,
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
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
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
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 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
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
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
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
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
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
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
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
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,
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,
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
@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
@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:
...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
@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.
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
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
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.
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
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
Hallo Rainer,
> 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
Beim naechsten Release, bei diesem hatte ich das vergessen.
> 2) Bei channel_delays würde ich channel_delays_ns angeben, auch> damit hinten reine Zahlen stehen (Wer weiß wozu?)
Ja.
> 3) Bei channel_vzero_levels ist es vielleicht intuitiver, wenn man das> Vorzeichen ändert, weil man "+" irgendwie doch mit "nach oben> verschoben" assoziiert. [..] Dann bin ich gespannt, wie das mit> fertigen Skalierungsfaktoren
Der channel_vzero_levels und channel_scale_factors Kram faellt eh
komplett weg sobald ich die Skalierungswerte A und B eingebaut habe,
von daher keine Anpassung mehr daran.
Niklas
@Niklas
ich hatte vermutet, dass die channel_vzero_levels und
channel_scale_factors schon die Anfangsstrukturen für die neuen
Skalierungsfaktoren sind. Aber dann ist ja alles auf gutem Wege.
@August
Die Idee mit der Meßdatenübertragung an den PC finde ich sehr gut.
Eine Sache die ich mir vorstellen kann, wäre ein Kommando, dass man vom
PC an das DSO schickt und dann kommen die aktiven Quick Measure Werte
zurück. Wäre das LabView-tauglich?
Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer
Fernsteuerung des gesamten W2000A vom PC aus aus?
Hallo August,
> [..] 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.
(1) Zur "Quick Measure"-Datenuebertragung:
Ja, das ist eine gute Idee, schaue ich mir an. Welches Format
waere da interessant? Aehnlich wie es bei den Tracedaten
ablaeuft? Also z.B.:
<code>
[Measurements]
frequency_str=<tab>2.5MHz
frequency_num=<tab>2500000
[..]
</code>
Das Ganze dann zusaetzlich zu einem Trace? Optional?
(2) Zu LabView und kontinuierliche Messdaten:
Ich selbst habe leider keine Ahnung von LabView. Ich weiss nicht,
ob sich hier jemand aus dem Forum vllt. schon einmal daran gemacht
hat, einen LabView-Treiber zu implementieren, um das DSO darueber
zu steuern.
Bzgl. der kontinuierlichen Uebertragung der Daten ist zu sagen das
dies zwar bei "Quick Measure" noch gut funktionieren wuerde,
es aber unmoeglich wird bei den Traces, aufgrund (a) der begrenzten
Speichertiefe des Oszis (16kSa/Kanal) (b) der Schnitstelle und nicht
zuletzt (c) wegen des langsamen Softcores. Ich glaube auch nicht
dass das bei USB grossartig besser wird.
Ob es bei 4 Traces alle 6s noch sinnvoll ist diese "kontinuierlich"
zu uebertragen weiss ich nicht.
Niklas
> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer> Fernsteuerung des gesamten W2000A vom PC aus aus?
Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es
eine einfache Implementierung, die auf Tastatureingaben eines Terminals
reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von
Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung
hat auch schon jemand für sein Projekt benutzt (Kurt Du?).
> 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?
Ist auch machbar und war auch mal für USB von WELEC implementiert -
leider so schlecht dass man es rausnehmen mußte. Nur wie Niklas schon
sagte wird die Wiederholrate extrem langsam wenn zu viele Daten
übertragen werden.
Eine Lösung wäre vielleicht wenn nur die 600 Werte des aktuellen Screens
übertragen würden.
Gruß Hayo
Hallo Hayo,
>> Hayo, was sagst du dazu? Und wie sieht das eigentlich mit einer>> Fernsteuerung des gesamten W2000A vom PC aus aus?
Das funzte mal mit der originalen Soft von Wittig, allerdings nur mit
der FW 1.4, hatte aber nur funktioniert, wenn sie dazu Lust hatte, dann
trampelte die Software manchmal auf der Stelle und es regte sich nichts
mehr!
> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es> eine einfache Implementierung, die auf Tastatureingaben eines Terminals> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von> Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung> hat auch schon jemand für sein Projekt benutzt (Kurt Du?).
...wo liegt die denn rum???
Gruß Michael
@Niklas
Es gibt noch zwei Werte, die evtl. für die Parameterübergabe interessant
wären:
- die Pretriggerposition im Speicher (Memory Index 0....16383 /
0....4095)
Format ist Integer.
- der Pretriggerwert als float. Während dieser vorher nur lokal
berechnet wurde habe ich Ihn jetzt global deklariert, so dass er
jederzeit zur Verfügung steht.
Ich habe die Variablen mal auskommentiert in die CSV-Routine eingetragen
falls das von Interesse sein sollte.
Hayo
Hallo Niklas
Ich habe eher an eine einfache Übertragung wie bei Digital-Multimeter
mit RS232 Schnittstelle gedacht.
Die im „Quick Measure“ angezeigten Messwerte ( max 3) könnten zum
Beispiel mit dem Voltcraft Protokoll übertragen werden. Ist zwar nur für
einen Messwert, könnte man aber erweitern.
[[http://blog.dest-unreach.be/2009/05/01/voltcraft-vc-940-protocol-reverse-engineered]]
Ich werde mich in den nächsten Tagen umschauen welche Protokolle wir
verwenden könnten.
Der LabView Dateneingang kann an das jeweilige Protokoll angepasst
werden.
Gruß
August
Es ist soweit,
wie versprochen die neue Version bei der sich einiges getan hat.
Die Highlights sind:
- Natürlich die neue Screenshot-Version von Niklas mit neuer
CSV-Übertragung
- neue double push Funktionalität bei Edge-Button, Pulswidth-Button und
Main-Button ebenfalls von Niklas
- invert Bug ist gefixt
- neuer stabil arbeitender manueller Trigger
- neues Trigger-Submenü mit diversen Einstellmöglichkeiten, zu finden im
Mode/Coupling Menü. Da sollte für jeden Geschmack was zu finden sein.
Weitere Details entnehmt bitte dem changelog und der Datei
Special Functions.txt
@eProfi
Die Schrittweite der Pre Trigger Einstellung habe ich nicht auf die
letzte Stelle des Zeitwertes bezogen, sondern auf die Zeitauflösung pro
Pixel, da mir das sinniger erschien.
Gruß Hayo
Hayo W. schrieb:> Eine Fernsteuerung gibt es bereits. Zum einen gibt es> eine einfache Implementierung, die auf Tastatureingaben eines Terminals> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von> Falk, die recht umfangreiche Möglichkeiten bietet. Diese Remotesteuerung> hat auch schon jemand für sein Projekt benutzt (Kurt Du?).
Die Remotesteuerung wurde seinerzeit von Bruno im FFT-Screener (Matlab)
verwendet. Leider wurde an dieser Baustelle nicht weitergearbeitet und
ich komme derzeit nicht dazu mich damit zu beschäftigen, zumal ich eh
nur auf Arbeit daran werkeln könnte, da der FFT-Screener nicht
kompatibel zu Octave ist.
branadic
Hallo Hayo,
Hayo W. schrieb:>> ... Und wie sieht das eigentlich mit einer>> Fernsteuerung des gesamten W2000A vom PC aus aus?>> Ist alles machbar. Eine Fernsteuerung gibt es bereits. Zum einen gibt es> eine einfache Implementierung, die auf Tastatureingaben eines Terminals> reagiert, zum Anderen gibt es eine aufwändigere Remotesteuerung von> Falk, die recht umfangreiche Möglichkeiten bietet.
Mit "Tastatureingaben..." meinst du das Remote Control Protokoll, was im
Moment als "suggestion" unter
http://sourceforge.net/apps/trac/welecw2000a/wiki/RemoteControlAPI
beschrieben ist? Dast ist ja noch arg rudimentär und Zukunftsmusik.
Das von Falk außeinandergedröselte USB Protokoll bietet da ja schon
einiges mehr. Gibt's da Quellcodebeispiele, wie man das unter Win vom PC
aus nutzen kann?
http://sourceforge.net/apps/trac/welecw2000a/wiki/USB-Protocol
"Set timebase" über Terminal habe ich gerade probiert (mit BT.2.13 FW).
Da tut sich auch etwas, aber außer Debugausgaben kommt nichts weiter
zurück. Dabei bin ich auf folgende offene Baustelle gestoßen: Die
Umschaltung ist etwas "eigenwillig", d.h. die Kommandowirkung hängt von
der vorher eingestellten Zeitbasis ab.
Wenn man z.B. <stx>ET<0x18>... schickt, schaltet das DSO auf
unterschiedliche Bereiche um, je nachdem wo es vorher stand. (z.B.
5us/div -> 5s/div, 20s/div -> 1s/div, 100ns/div -> 500ms/div). Außerdem
kommt man nicht in die ganz langsamen Bereiche, weil Parameter über
<0x1F> nicht angenommen werden.
Aber ich vermute mal, dass die Baustelle z.Z eher brach liegt, oder?
Schönen Sonntag
Rainer
Edit: Danke für die neue Wochenend-Edition
Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com),
un utente mi ha chiesto se Hayo e voi altri accettate donazioni per
supportare il progetto, magari tramite paypal o simili, non sono sicuro
così chiedo qui.
Hello, on the site (recently changed the address: www.cheap-hack.com), a
user asked me if you Hayo and other, accepted donations to support the
project, perhaps through paypal or similar, I'm not sure so I ask here.
By, Gyppe.
gyppe schrieb:> Ciao, sul sito (a proposito ho cambiato indirizzo: www.cheap-hack.com),> un utente mi ha chiesto se Hayo e voi altri accettate donazioni per> supportare il progetto, magari tramite paypal o simili, non sono sicuro> così chiedo qui.>>> Hello, on the site (recently changed the address: www.cheap-hack.com), a> user asked me if you Hayo and other, accepted donations to support the> project, perhaps through paypal or similar, I'm not sure so I ask here.>> Bie, Gyppe.
Hi,
ich vergaß noch anzumerken, dass ich aufgrund der umfangreichen
Änderungen gezwungen war die Flasheinstellungen zurückzusetzen. Also
nicht vergessen das Gerät neu zu kalibrieren und die
Hardwareeinstellungen neu zu machen.
Please notice that I had to reset the flash. So calibration and hardware
adjustment is recommended.
@gyppe
- no donation, it is just for fun!
Hayo
Leider habe ich noch einige Bugs entdeckt.
Z.B. arbeitete der manuelle Trigger immer noch nicht so richtig unter
allen Umständen. Jetzt sollte er es aber tun.
Daher noch mal ein Update in dem nur einige Fixes sind aber sonst nix
Neues.
Hayo
Hallo zusammen!
Ich hab seit ein paar Monaten eure Firmware(s) auf meinem Welec-Oszi und
möchte mich bei allen Entwicklern hier, vor allem Hayo, mal herzlich
dafür bedanken, dass ihr in eurer Freizeit unentgeltlich die Arbeit
macht, die die Fa. Wittig leider nicht macht! Die originale Software mit
der Wittig die Geräte immer noch ausliefert ist eigentlich eine
Frechheit!
Inzwischen nehme ich aber doch immer öfters mal das Welec anstatt meines
20 Jahre alten Hameg's, das ich eigentlich mit dem Wittig ablösen
wollte...
Vielen Dank!
Gruß, Michael
New 2.15 version tested. On the welcome screen appear to be a "beta"
version...
Anyway all the functions that i've can tested are ok. Very good job with
the filters!!
Thanks again, Hayo and all!!
What's the next step?
Excuse me for the question, but i don't understand German language and
google translate make a bad job:
What are the benefits on ADC/DAC substitutions that is described on some
previous messages?
Ciao, Paolo
Paolo schrieb:> New 2.15 version tested. On the welcome screen appear to be a "beta"> version...
don't worry, I just forgot to delete the "beta"
> What's the next step?
Several little improvements at math-functions and FFT. Hardwaresupport
for the new input stage of branadic.
> Excuse me for the question, but i don't understand German language and> google translate make a bad job:> What are the benefits on ADC/DAC substitutions that is described on some> previous messages?
the 16 Bit DAC has a finer division at zerolevel adjustment. This is
only relevant to the 2/0.2/0.02 and 1/0.1/0.01 ranges. It is not really
necessary but nice to have.
I got the LT2602 as free sample from Linear Technology. They are very
small and You need to have some experience in soldering SMD parts if You
want to replace them.
Kind regards
Hayo
Hallo Hayo,
die neue Auto-Pre-Trigger Funktion finde ich ausgesprochen praktisch.
Beim Messen in der Einstellung "Left Edge" hat sich aber gezeigt, dass
es vielleicht günstiger wäre, das "Left" nicht ganz wörtlich zu nehmen,
sondern den Trigger auf den ersten Grid Raster zu legen
(Left_Edge_1_12.png).
Meistens interessiert doch ein bisschen, was vorne los ist ;-)
Gruß
Rainer
Hi Rainer,
gleich vorweg - ich sehe mal zu dass ich das noch als extra Menüpunkt
mit einbaue.
Zum "Left Edge":
Das ist ja den alten Analog-Oszis nachempfunden. Man stellt ja
normalerweise die Zeitbasis so ein, dass nach dem Triggerdurchgang etwas
mehr als eine Periode auf dem Schirm zu sehen ist. Dann hat man nämlich
auch den am Anfang fehlenden Teil der nächsten steigenden Flanke locker
mit auf dem Screen.
Dazu kommt, dass viele Signale auch nicht so steil ansteigende Flanken
haben, so dass auch vom Triggerlevel an die ganze Flanke zu sehen ist.
Gruß Hayo
Etwas Anderes,
ich mache mir gerade Gedanken über die Ansteuerung der Addon Platine.
Hat schon jemand das Teil eingebaut und kann mir gegebenenfalls
Testergebnisse liefern?
Hayo
So ich hab mal wieder was zum ausprobieren für Euch. Ich habe etwas
rumgespielt nachdem ich für Rainer den neuen Menüeintrag eingebaut
hatte.
Dabei sind wieder die Spikes aufgetaucht und ich konnte feststellen dass
die Spikes durch das Verstellen der Timebase verursacht werden.
Einstellung:
- Triggersource Kanal 4
- Combi oder Norm Trigger
- Timebase 50ns
- Signal auf Kanal 4
Alles ist gut. Dann Zeitbasis auf 50µs verstellt und wieder zurück auf
50ns siehe Bild Test01.
Dann Zeitbasis auf 5µs verstellt und dann zurück auf 50ns - siehe
Test02.
Dann wieder verstellt und so weiter Test03...Test05.
Wenn man das Gerät ausschaltet und wieder einschaltet ist alles wieder
gut.
Ist das bei Euch auch so?
Gruß Hayo
Jo, hatte ich letzte Woche und gerade dann, wo ich es nicht brauchen
konnte!
Allerdings sporadisch, manchmal auf Kanal 1 dann mal auf Kanal 2
(W2022), wie es gerade Lust hat!
Gemessenes Signal war 57 kHz Rechteck an einem LM2576 Adj. Dachte schon,
jetzt ist er hinuber!!
Die Grundlinie über das Display scheuchen, brachte auch keine
Besserung.
An der Warmlaufphase scheint es aber nicht zu liegen, da das DSO schon
über eine Std. lief. Nach neuem hochfahren, war wieder alles hübsch...
Gruß Michael
Sehe gerade, du hast 16V Sägezahn!?! Ich hatte bei der Restripplemessung
dieselbe Einstellung wie du 2V/DIV, 50nS und Combitrigger "AC", ob das
bei "DC" auch der Fall ist?
Wenn du das provozieren kannst, dann prüf' das doch mal...
Gruß Michael
Hallo,
ich melde mich mal kurz.
Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen
uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.
Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h
gebraucht (Wegspeichern der in RenderText() berechneten Werte
fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der
Dimensionierung).
Die Ausgabe sieht dann so aus (echte Werte):
1
meas-000.txt
2
[measurements]
3
str=;dX = 5.4 us;1/dX = 185 kHz;dY 1 = 29 mV
4
desc=;dX = ;1/dX = ;dY 1 =
5
dimension=;u;k;m
6
unit=;s;Hz;V
7
value_bd=;5;185;29
8
value_ad=;4;0;0
9
value_float=;5.4;185.0;29.0
Konkrete Vorschlaege/Anregungen gerne willkommen.
Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",
"Save to PPM", "Save to CSV" usw. einfach "Screenshot",
"Trace" und "Measurements" machen, wobei dann das Format
ueber ein Untermenue konfigurierbar wird.
@August:
Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram
geben damit Du das Ganze schon nutzen kannst.
Bezueglich meiner Spikes auf Kanal 3+4 beim Nulldurchgang
auf dem DSO:
Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,
wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was
aendert. Negativ. Da das ganze Board ziemlich warm war
hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt
und bei offenen Geraet direkt gegen die Platine blasen
lassen. Das verminderte die Anzahl Spikes jedoch nur gering.
Nochmal komplett Front abnehmen, um auf die andere Seite
der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.
Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn
reproduzieren kann, kann ich mangels schnellem Signalgenerator
nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt
auch erst bei 50ns sehr haeufig auf.
Niklas
Niklas O. schrieb:> Hallo,>> ich melde mich mal kurz.>> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h> gebraucht (Wegspeichern der in RenderText() berechneten Werte> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der> Dimensionierung).
Währe es nicht einfacher den Float-Wert global zu deklarieren und dann
per Multiplakation als Integer zu übertragen?
> Wir sollten dann vllt. noch aus den Softbuttons "Save to BMP",> "Save to PPM", "Save to CSV" usw. einfach "Screenshot",> "Trace" und "Measurements" machen, wobei dann das Format> ueber ein Untermenue konfigurierbar wird.
Das wäre eine Möglichkeit, ich mach mir mal ein paar Gedanken dazu
> @August:> Wenn Du moechtest kann ich Dir kompilierte TomCat.flash/.ram> geben damit Du das Ganze schon nutzen kannst.>>> Ich hab' Sonntag auch noch das Geraet aufgeschraubt und mal,> wie Hayo vorschlug, auf die ADCs gedrueckt ob sich da was> aendert. Negativ. Da das ganze Board ziemlich warm war> hab' ich einen starken 80mm Luefter (~6 Watt) rausgekramt> und bei offenen Geraet direkt gegen die Platine blasen> lassen. Das verminderte die Anzahl Spikes jedoch nur gering.> Nochmal komplett Front abnehmen, um auf die andere Seite> der Platine zu schauen, will ich erstmal nicht, zu wenig Zeit.
Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so
gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert
hatte waren etwas nervig). Das ist wirklich angenehm und es wird
wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.
Der Wackler könnte natürlich durchaus auch auf der anderen Platinenseite
liegen. Ausprobieren lohnt sich allemal.
Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:
von oben in den Spalt zwischen Knopf und Frontplatte linsen während man
den Knopf dreht. Irgendwann kommt die abgeflachte Seite der Achse
vorbei...
Dann mit einem dünnen Schraubendreher dazwischengehen und mit der
flachen Seite des Schraubendrehers den Rand an der Achse als
Abstützpunkt beim Hebeln benutzen. Dadurch entlastet man den Rest des
Drehgebers.
> Was Hayo zuletzt bei sich auf Kanal 3+4 mittels Saegezahn> reproduzieren kann, kann ich mangels schnellem Signalgenerator> nicht pruefen. Bei mir treten die Stoerungen aber wie gesagt> auch erst bei 50ns sehr haeufig auf.
Es tritt nicht nur bei 50ns auf, aber bei 50ns und kleiner werden alle
vier ADC dargestellt und dadurch auch alle Störungen, während bei
den TB > 50ns immer nur 1 oder 2 ADC zur Anzeige kommen.
Da "verschwinden" die Spikes teilweise scheinbar.
Gruß Hayo
Hallo Hayo,
>> Ich hab' am Sonntag die Sache mit Quick-/Cursor-Messungen>> uebertragen eingebaut, ist zu 80% fertig, fehlt noch Feinschliff.>> Ich hab' dazu nur zwei kleine Ergaenzungen in floatstr_t.cpp/h>> gebraucht (Wegspeichern der in RenderText() berechneten Werte>> fuer Vor-Komma- und Nach-Komma-Zahlen sowie Ausgabe der>> Dimensionierung).>> Währe es nicht einfacher den Float-Wert global zu deklarieren und dann> per Multiplakation als Integer zu übertragen?
Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.
Es sieht im Moment so aus:
1
voidFloatStr::RenderText(void)
2
AmEnde:
3
// copy values to protected variables for readout via Read_Int(B/A)Dot()
4
Value_BDot=intbd;
5
Value_ADot=intad;
> [..]> Ich habe bei meinem W2022A einen 80iger Lüfter eingebaut der bei 9V so> gut wie keine Geräusche macht (drei andere Lüfter die ich ausprobiert> hatte waren etwas nervig). Das ist wirklich angenehm und es wird> wirklich ordentlich warme Luft aus dem Gehäuse gedrückt.
Ja. Rainer hat mir oben auch schon einen leisen Luefter bei Reichelt
vorgeschlagen den er bei sich verbaut hat. Das Problem mit dem 80er,
den ich Sonntag benutzt habe: Der zieht 0,47A. (Abgesehen davon
dass er hoellisch laut ist.)
Der Original war iirc. weit unter 0,1A. Bei der naechsten Pollin-
oder Reichelt Bestellung bestelle ich einen entsprechenden Luefter
mit.
> Beim Abhebeln der teilweise festsitzenden Knöpfe gehe ich immer so vor:
Beim letzten Mal, Anloeten der zwei Trigger-LEDs, Osrams in SMD,
hab' ich da schon viel Freude mit gehabt... (sind btw. hell
genug dass die ohne Modifikationen durch den Silkscreen
durchscheinen.)
Wo wir bei den Drehgebern sind:
Bei Yokogawa hab' ich eine nette Vereinfachung bzgl. des
Verschiebens der Traces gesehen:
Wenn man die Drehencoder schnell dreht springen die Traces
von Gridline zu Gridline, bei langsamen Drehen wie gewohnt
Pixelweise. Vmtl. haben das die anderen hochwertigen
Scopes aber auch.
Ich hab' das ganze auch schon mal kurz angetestet,
sieht dann im Code so aus:
1
voidUserIF::ON_Zero_Channel_1(void)
2
[..]
3
if(Rotary_Direction==0)//clockwise rotary direction
4
[..]
5
else//Main mode TY
6
{
7
if(rotbuf>8){// rotbuf -> Anzahl Schritte
8
inta,b,c;
9
// a positiv machen
10
a=Virtual_ZeroLevelCH1+4096;
11
// naechstgelegene Gridlinie,
12
// vllt. hier noch anders runden
13
b=a/50;
14
// zur naechsten Gridlinie springen
15
c=(b+1)*50;
16
// Zurueckskalieren und Wert setzen
17
Virtual_ZeroLevelCH1=c-4096;
18
}else{
Analog dasselbe fuer die andere Drehrichtung. Der ganze
bestehende Code hierzu liesze sich btw. deutlich verkuerzen.
...Und funktioniert soweit. Ist etwas "wackelig", was aber
an dem miserablen Response des Scopes liegt, woran wir
aber wohl ohne das neue FPGA Design nichts aendern koennen.
Ansonsten muss ich wohl eh nochmal an die Front dran, da
beim W2024A fuers JTAG eine Loetbruecke fehlt und ich sonst
nicht das neue Design ausprobieren kann.
Niklas
Hallo Hayo
zu den Spikes: (hatte ich schonmal geschrieben)
Kannst Du die Frequenz von deinem Generator auch ändern?
Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher
Zeiteinstelleung am DSO
l.G. Roberto
@Niklas
> Ginge auch, dann wuerden jedoch die Dimensionierung wegfallen.> Es sieht im Moment so aus:void FloatStr::RenderText(void)> Am Ende:> // copy values to protected variables for readout via Read_Int(B/A)Dot()> Value_BDot = intbd;
Verstehe, Du benutzt die Instanzmethode readout() um Dir den Wert zu
besorgen, das scheint mir ganz elegant zu sein. Wenn Du mit Deinen
Änderungen soweit bist kann ich das ja mit einbauen.
> Wenn man die Drehencoder schnell dreht springen die Traces> von Gridline zu Gridline, bei langsamen Drehen wie gewohnt> Pixelweise.
Hört sich interessant an, werde ich mal übernehmen und testen.
@Roberto
> Bei mir änderten sich die Spikes auch mit der Frequenz bei gleicher> Zeiteinstelleung am DSO
Das muß ich mal testen, hört sich ja merkwürdig an.
Gruß Hayo
es gibt einen 80er Lüfter von Papst glaube der macht nur 9 dB, habe 2
davon in meiner PC Front die sind nur hörbar wenn man den Kopf an die
Front des PCs steckt. Man muss allerdings auch sagen das der nicht ganz
so viel Durchsatz hat wie andere 80er Lüfter.
By the way...
> was aber> an dem miserablen Response des Scopes liegt, woran wir> aber wohl ohne das neue FPGA Design nichts aendern koennen.
Ich habe mal die USTB-Timerwerte nachgerechnet und habe die akute
Vermutung, dass unsere Büchse nicht wie bisher angenommen mit 33MHz
läuft, sondern nur mit 25MHz.
Das würde natürlich auch Einiges erklären...
Hayo
@Niklas
Ich habe Deine Idee mal aufgegriffen und etwas umgestrickt. Das sieht
dann so aus und funktioniert ganz gut:
else // main mode
{
if (rotbuf > 10)
{
int div, cmp;
div = Virtual_ZeroLevelCH1/50; // in which div we are?
if(Virtual_ZeroLevelCH1 > 0) // positive
{
cmp = div * 50;
if (cmp == Virtual_ZeroLevelCH1){div--;} // zero level was on grid
division before
}
else // negative
{ div--; } // next grid division
Virtual_ZeroLevelCH1 = (div)*50; // set zerolevel to next grid
division
}
Hayo
> also auf ans Übertakten ;-) ist da ein externer Taktgeber drauf oder> taktet der FPGA intern?
...den Vorschlag hatte ich letztes Jahr schon mal gemacht! Im Datenblatt
müsste ja stehen, was der Prozessor maximal so abhaben kann.
Gruß Michael
Normal ist der für 33MHz ausgelegt (im NIOS I Design). Deshalb bin ich
ja auch erstmal davon ausgegangen dass es so ist. Nur haben mich die
Timerwerte bei den USTB etwas irritiert, da die iterativ ermittelten
Werte nicht zu den vorher berechneten Werten passten. Die jetzt
verwendeten Werte passen zu einer Taktfrequenz von 25MHz und einem Timer
der mit halber Taktfrequenz läuft.
Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen
und dann mal gucken ob es funktioniert (alle Timerwerte müßte man
natürlich anpassen).
Evtl. könnte es Problem mit den ADCs geben. Irgend einen Grund muß es ja
geben, dass die auf einen Teil der Performance verzichtet haben (man
läßt sich ja auch nicht freiwillig ein Bein in Beton eingießen oder?).
Gruß Hayo
nun ja, vielleicht wollten die "Welec-Designer", zur Sicherheit unter
dem Limit bleiben, damit das Teil nicht abschmiert?!?
Ein höherer Takt zieht mehr Leistung und somit auch mehr
Wärmeentwicklung, also muß auch mehr Kühlung her, dürfte ja kein Problem
sein
Den Mega8-16PU, habe ich mal mit 33MHz takten lassen, der wurde nicht
mal warm.
Ich lege mal 2 Auszüge des Altera EPCS16 bei, schau mal rein.
Da steht nur was von der Write Clock Frequency...
Gruß Michael
Hayo W. schrieb:> Man könnte ja mal den 25MHz Quarz-Oszillator gegen einen 33iger tauschen
Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird
garnichts mehr funktionieren!
Eine weitere Frage ist, was die DCM(PLL) macht, wenn sie plötzlich
übertaktet wird.
Mfg,
Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.
> Bei dem jetzt schon extrem kritischen FPGA-Timing? Nach dem Tausch wird> garnichts mehr funktionieren!
Das vermute ich auch, aber es wäre vielleicht einen Versuch wert. Ich
denke kaputt gehen wird wohl nichts, aber es wird wohl nicht sauber
laufen.
> Kurt, der noch lebt, aber krank war und sich nur langsam erhohlt.
Gute Besserung!
Hayo
Eure Meinung ist gefragt.
Ich habe die Idee von Niklas mit den Rasterschritten beim Verstellen des
Zerolevels mal für Kanal 1 und 3 eingebaut.
Bei Kanal 2 + 4 ist noch alles beim Alten. Ich bin etwas unschlüssig ob
das besser ist als das Alte oder nicht. Wie seht Ihr das?
-> Die Triggermenüerweiterung für Rainer ist auch schon drin zum
Probieren.
Gruß Hayo
Hallo!
Um das mit dem Takt noch mal abzuklären: Der CycloneII FPGA hat 4 PLLs.
Jede PLL besitzt eigene Takteingänge und einen Taktausgang!. Damit muss
man den Quarz zwangsweise an allen vier PLL-Takteingängen anhängen.
Es sind neben den vier Takteingängen für die PLLs noch andere Takte
vorhanden. Sollte das NOIS I Taktnetzwerk sauber mit der
Signalerfassungsnetzwerk kommunizieren können und einen eigenen
Takteingang haben (beim LEON3 mache ich das beabsichtigt nicht), dann
könnte man die Taktgeschwindigkeit erhöhen.
Für die vier zeitversetzten Taktsignale der ADCs ist das nicht
empfehlenswert, da dadurch die gleichmäßige Abstastung noch mehr
zerstört wird!
MfG
Alexander
habe gerade das Prellverhalten eines Jalousinenschalters getestet und da
sind mir wieder einige Bugs aufgefallen. Und zwar erhalte ich im Single
Trigger Modus auf Kanal 1 (Kanal 2 nicht getestet) bei einer
eingestellten Horizontalauflösung von 1V/Div und einer Abtastrate von 1
mSek/Div keine Auslösung bei einer fallenden Flanke, das Signal ist 5V
DC das wie gesagt über einen Taster geleitet wird. Bei 2mSek/Div löst
der Trigger auch häufig nicht aus. Bei den andere Abtastraten geht es
einwandfrei, bis auf den Umstand das am Ende der Aufzeichnung die ca.
letze 5 Stellen im Display immer ein Spike 5V vorhanden ist. Ich
vermute das die Zeichenroutine hier etwas verhaut und sich oder
irgendwie ein Überlauf der Adressen stattfindet und wieder Daten aus dem
vorderem Speicherbereich gezeichnet werden. Beim laden des gespeicherten
Traces ist dieser Spike plötzlich weg. Gespeichert wird also der
richtige Bereich, beim Betrachten direkt nach dem Auslösen hingegen
passt der Speicherbereich nicht 100%tig
Oszi: W2022
Firmwareversion: 1.2.BF.2.7
Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound
erst damit zu aktivieren oder eine Screenshot.cfg um dort die
Einstellung dauerhaft vorzunehmen?
Beispiel 1:
scrennshot.exe /s = startet die screenshot.exe Datei mit Soundausgabe
Beispiel 2:
scrennshot.cfg Datei wo Screenshot.exe erst nachschaut was gewünscht
wird bevor etwas piepst oder nicht
Sound=0 oder 1
Die Familie schläft gerade und nach jeder Dateiübertragung piepst der PC
Lautsprecher und da hat man ja leider keinen Einfluss auf die
Lautstärke, wenn ich nicht umbedingt einen Poti einbauen will.
Hallo Thomas,
> Kann man in die Screenshot BF1.6 einen Schalter einbauen um den Sound> erst damit zu aktivieren oder eine Screenshot.cfg um dort die> Einstellung dauerhaft vorzunehmen?
Die BF-Version wurde wieder mit der OS vereint. Die neuen
Versionen haben einen entsprechenden Schalter, dieser lautet
"-a" (Alarm). Nur wenn "-a" gesetzt ist bimmelt es.
Eine Konfigurationsdatei wird ohnehin in Zukunft kommen. Bis
dahin kannst Du die Optionen weiter in die .bat eintragen.
Die ist jetzt auch so gebaut dass man sie von anderen
Verzeichnissen aufrufen kann und ihr zusaetzliche Parameter
uebergeben kann.
Aktuelle Screenshot-Programme sind wie gewohnt auch in den
Firmware-Releases.
Niklas
Hallo nochmal Thomas,
> [Triggerverhalten]> Oszi: W2022> Firmwareversion: 1.2.BF.2.7
Probier' mal die .15 oder .16 aus, am Trigger hat Hayo
in der letzten Zeit geschraubt.
Niklas
Hallo zusammen,
ich habe gerade die neue Variante der Zerolevel Einstellung getestet und
muss sagen: finde ich klasse. In der Regel setze zumindest ich die
Kanäle ohnehin auf einen geraden Spannungswert, sprich ich verschiebe
die Kanäle manuell kästchenweise, weil man sich dann mit dem Ablesen
leichter tut. Das geht mit der neuen Variante wesentlich einfacher ohne
dass man die Möglichkeit verliert, beliebige Spannungen zu setzen - ich
bin also sehr für die Einführung auf allen Kanälen!
Das einzige was dabei stört sind mal wieder die unsäglichen
Bedienelemente, irgendwann werde ich mir da mal neue suchen müssen.
Gruß
Michael
Hayo W. schrieb:> Gute Besserung!
Danke!
http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum
Unter Hardware/aktuellste Daten habe ich mal den aktuellen Schaltplan
und ein Bild vom Layout hochgeladen. Layout und Schaltplan sind fast
fertig und brauchen nur noch kleine Schönheitskorrekturen.
Mfg,
Kurt
Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken. Ich
habe das aber jetzt trotzdem mal für alle Kanäle eingebaut mit dem
Zusatz, dass ab einer bestimmten Menge Drehimpulse nicht nur ein Raster
weiter gesprungen wird, sondern zwei. Dann kann man auch etwas schneller
über den Screen hoppeln.
Ansonsten mache ich gerade eine Komplettrenovierung bei der
Autoscalefunktion und im Timebasecontroller.
Gruß Hayo
Thomas O. schrieb:> Oszi: W2022> Firmwareversion: 1.2.BF.2.7
Hi Thomas,
danke für die Rückmeldung. Aber wie Niklas schon sagte bitte immer die
aktuellste freigegebene Version bei Firmware und Screenshot verwenden.
Gruß Hayo
Hayo W. schrieb:> Allzu viele Rückmeldungen sind ja nicht zu Niklas Idee gekommken.
Hallo Hayo,
die großen Sprünge beim Offset sind bestimmt nicht verkehrt. Ich war da
zunächst etwas unschlüssig, da man sowieso bei großen Wegen immer
umgreifen mußte. Aber in der alten Version passierte es auch oft, dass
sich beim schnellen Drehen mit der Position fast gar nichts tat
(Unterabtastung der Geber?) und das ist jetzt in der 1.6 wesentlich
besser.
Gruß
Rainer
Hayo,
noch ein anderes Thema: Triggerlevel
Läßt es sich ohne großen Aufwand hinbekommen, dass bei Umschaltung der
Y-Verstärkung der Triggerlevel (in mV) konstant bleibt?
Im Moment muß man bei Änderung vom Y-Gain immer den Triggerlevel
ebenfalls nachstellen, wenn der Bezug von Signalhöhe zu Triggerlevel
gleich bleiben soll. Ich finde das eher unpraktisch.
Und hast du das vollständig disablete Kanal-Soft-Menü nach Abschaltung
eines Kanals noch auf deiner ToDo Liste, wo du gerade beim Renovieren
bist?
Die neue Auto-Pre-Triggereinstellung "First Grid" ist sehr praktisch.
Schönen Sonntag
Rainer
ok habe die aktuelle 2.16 beta drauf und da gibt es die von mir
beschriebenen Probleme nicht mehr. Mir ist aber etwas aufgefallen das
schon mal gefixt wurde. Wenn man die Zeitbasis streckt sollte das Signal
nach rechts gestreckt werden so das die erste Flanke an der gleichen
Stelle bleibt. Ist das jetzt evtl. im Menü irgendwo einzuschalten, wurde
das wieder absichtlich entfernt oder wurde es vergessen?
Das mit Triggerpunkt finde ich genial so kann jeder das ganze so
einstellen wie er es braucht. Triggerpunkt auf erstem DIV oder in der
Mitte.... Genauso die Einstellung wie man die Singleshot Taste nutzen
will, einfach spitze wenn man die Einstellungen so individualisieren
kann.
Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass
der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein
zoomen möchte.
Wäre es möglich die Dateiübertragung auf den Rechner irgendwie
anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?
Da beim Upload das Oszi nicht reagiert.
Thomas O. schrieb:> Hier nochmal 2 Screenshots des von mir beschriebenen Verhaltens, dass> der Signalbeginn ungewollte nach rechts rutscht wenn man etwas rein> zoomen möchte.
Muß ich mir mal ansehen, im Stop-Modus hatte ich das nicht getestet.
> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?> Da beim Upload das Oszi nicht reagiert.
Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du
möchtest die Anzeige dann auch auf dem Screenshot haben :-)
Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren
die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird
es dann nicht mit übertragen. Ich check das nochmal.
Gruß Hayo
Hallo,
>> (Thomas:)>> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie>> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?>> Da beim Upload das Oszi nicht reagiert.>>(Hayo:)> Beim Screenshot geht es (wahrscheinlich) leider nicht, es sei denn Du> möchtest die Anzeige dann auch auf dem Screenshot haben :-)>> Ich hatte auch schon drüber nachgedacht. Ich wollte nochmal probieren> die Textausgabe in die Layer-Zwischenspeicher zu schreiben, evtl. wird> es dann nicht mit übertragen. Ich check das nochmal.
Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten
wir doch dafuer verwenden koennen?
Falls dies nicht geht koennten wir, da wir Zeilenweise abarbeiten,
nach ein paar Zeilen ganz oben eine entsprechende Mitteilung mit
Fortschrittsbalken einblenden. Erstere Option waere offensichtlich
viel eleganter.
Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3]
und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp)
auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben,
stellt sich aber heraus, dass die nirgendwo verwendet werden.
Koennen also weg.
Niklas
Thomas O. schrieb:> Wäre es möglich die Dateiübertragung auf den Rechner irgendwie> anzuzeigen? Blinkendes "Upload" evtl. sogar mit % Balken im Oszi Screen?> Da beim Upload das Oszi nicht reagiert.
IMO reicht es, wenn z.B. die LED über dem "Universal"-Regler blinkt. Ich
halte es für übertrieben, dafür große Texte im Display einzublenden.
Sooo lange dauert es nun auch nicht.
Man könnte natürlich in der Zwischenzeit auf dem Screen in einer
weiteren Zeichenebene TETRIS spielen. ;-)
@Niklas
Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden,
warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird.
Gruß
Rainer
Niklas O. schrieb:> Es gibt doch noch die unbenutzten Memory-Planes. Diese muessten> wir doch dafuer verwenden koennen?
Ich dachte da an die Buffer_Planes. Die werden irgendwann vor der
Screenausgabe mit den Hauptplanes verodert.
>> Beim kurzen Nachschauen fielen mir gerade die Konstanten Color[7][3]> und clYellow, clCyan usw. und clCHI bis clCursor in tc_vars.(h/cpp)> auf. Ich haette vermutet dass die dazu dienen die Planes einzufaerben,> stellt sich aber heraus, dass die nirgendwo verwendet werden.> Koennen also weg.
Ist erledigt
Hayo
Kleiner Zwischenstand aus dem Hackerkämmerlein,
ich bin gerade beim Autoscale. Dass das bislang so einigermaßen
funktionierte ist eher Zufall. Das ist ein einziges Rumprobieren was der
Kerl da veranstaltet hat. Nichts mit Hand und Fuß - also wie gehabt.
Ich bin dran...
Hayo
@Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu
sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder
eine blinkende LED gemacht wird ist egal.
Hallo,
Rainer:
> Wo du da wieder am forschen bist, läßt sich vielleich auch herausfinden,> warum die "Disabled"-Ebene nicht mit den Screenshots übertragen wird.
Ach, da brauch' ich nicht lange forschen. Da diese Ebene beim
Schwarz-Weiss Screenshot zu sehen ist und die S/W-Routine auch
die Memory Planes (3 Stueck) anschaut, entgegen der Farb-Routine,
wird es eine dieser 3 Planes sein.
Im Screenshot-Programm hab' ich wohl als Kommentar zu den
Memory-Planes geschrieben "not yet determined".
Das ist schon laenger her (Mitte 2009 iirc).
Ist jedoch kein Problem zu beheben: eine Zeile in der Firmware
und vier Zeilen im Screenshot-Programm.
Thomas:
> @Rainer W.: Ja deine Idee finde ich auch gut, mir geht es nur darum zu> sehen das das Oszi beschäftigt ist. Ob das über eine Screenausgabe oder> eine blinkende LED gemacht wird ist egal.
Okay, dann lassen wir eine LED blinken.
Niklas
P.S.: Bin momentan zeitlich ausgelastet.
Ab April ist aber wieder Luft.
Hallo nochmal,
bin gerade dabei, mir das Spektrum aus einem Signalgenerator in der
FFT anzuschauen und dies zu dokumentieren.
Ich habe die Cursor angezeigt um die Grundfrequenz und Amplitude
zu vermessen. Jetzt ist der Sinus "leider" so sauber, dass die drei
Kaestchen unten die restlichen Frequenzanteile komplett verdecken.
Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT
entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info
Feld anzuzeigen? Im normalen non-Math Modus ist das ja egal, dort
schiebt man sich die Traces halt nen Stueck hoeher.
Zusatz: Man kann natuerlich durch mehrfachen Druck der
Cursortaste die drei Kaestchen ausblenden und sieht die Werte
noch ganz unten, aber es gibt sicher auch Situationen wo man
die Deltas herausstellen will.
Niklas
Niklas O. schrieb:> Eine Idee: Waere es vllt. sinvoll, diese Kaestchen bei der FFT> entweder wahlweise oben/unten oder die Werte gar rechts im FFT-Info> Feld anzuzeigen?
Wenn dann würde ich rechts bevorzugen.
> Zusatz: Man kann natuerlich durch mehrfachen Druck der> Cursortaste die drei Kaestchen ausblenden und sieht die Werte> noch ganz unten,
Das fand ich bislang ausreichend aber man könnte natürlich mal auf die
obige Lösung umschwenken.
Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der
Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase
übertragen wird (gibt es nicht mehr), sondern der korrespondierende
Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide).
Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand
anlegen?
Gruß Hayo
Hallo Hayo,
> Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der> Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase> übertragen wird (gibt es nicht mehr), sondern der korrespondierende> Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide).>> Machst Du die Anpassung im Screenshotprogramm, oder soll ich da Hand> anlegen?
Das kann ich machen. Ich schaue mal zu das ich moeglichst bis
Mittwochabend eine neue Version vom Screenshot-Programm
und den entsprechenden Firmware-Diffs fertig bekomme mit den
Features die ich in
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
beschrieben habe.
Niklas
So nach mehreren Tagen rumgefrickel mit der Autoscale-Funktion sieht es
jetzt ziemlich gut aus. Es werden jetzt alle Arten von Signalen sicher
erkannt und je nach Anzahl der Kanäle richtig skaliert und auf dem
Schirm einsortiert. Den richtigen Triggerlevel gibt es natürlich auch
dazu.
Wenn Niklas mit seinen Erweiterungen fertig ist, kann ich das zu einer
richtig schönen neuen Version zusammenschnüren.
Gruß Hayo
Hi Hayo,
gut hört's sich an.
Hast du folgende Bugs bei der "Math"-Bedienung zufällig schon
gesehen/abgestellt?
- Wenn im Untermenü "Setting" der "Scale"-Regler aktiv ist, leuchtet die
LED überm Universalregler nicht und außerdem ist "Offset" nicht
aktivierbar.
- Wenn die Berechnungsart "1*2" aktiv ist, taucht im Untermenü
"Settings" auf dem "Scale"-Button und rechts davon noch Datenmüll auf.
Ganz vielen Danke für deine unermütliche Arbeit an der Firmware.
Gruß
Rainer
@Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis
aktivieren?
In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach
rechts gezeichnet wird, soll das so sein?
Hallo,
ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal
verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im
Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut,
wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen
könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt.
Gruß
Thomas O. schrieb:> @Hayo: Ließe sich der Roll Mode auch in der 500mSek Zeitbasis> aktivieren?
Leider nein. Ich hatte das schon mal probiert, aber das Timing ist dann
so sensibel dass jede Benutzeraktion am Gerät das Signal verfälscht und
außerdem braucht ein ADC-Durchlauf gerade etwas länger, als die
Abtastzeit in dieser Zeitbasis erfordert.
> In Shift Mode ist mir aufgefallen das immer eine horizontale Linie nach> rechts gezeichnet wird, soll das so sein?
Stört das? Man könnte es evtl. ändern wenn das ein Problem ist.
Gruß Hayo
Gerd schrieb:> Hallo,>> ich habe die 1.2.BF.2.15 drauf und beim Zoomen im angehaltenen Signal> verschiebt sich die Triggerposition, bzw. ich lande ganz wo anderst im> Speicherbereich als ich ursprünglich gesehen habe. Ich fände es gut,> wenn man hier entweder um den Triggerpunkt oder um die Bildmitte zoomen> könnte. D.h. der Triggerpunkt oder die Bildmitte als Fixpunkt.
Hi Gerd,
so was Ähnliches hatte auch Rainer schon gepostet. Den Fix gibt es mit
dem nächsten Release.
Gruß Hayo
Hallo Hayo,
> Übrigens müßte durch meinen aktuellen Umbau der Timebasesteuerung der> Timebasewert angepasst werden, da jetzt nicht mehr die RealTimebase> übertragen wird (gibt es nicht mehr), sondern der korrespondierende> Timebase_Idx bzw. TB Index (siehe Timebasetable im Programmers Guide).
ich hab jetzt gesucht und gesucht, wo finde ich denn diesen
"Programmers Guide"? Ich habe wohl Programming Maps gefunden
auf der alten Google Seite, aber die laesst er mich nicht
runterladen ("W2000A Programming Maps V3.03.zip The page you
navigated to does not exist.").
Niklas
Hi Niklas,
sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle
Version immer in das Doc-Verzeichnis des Downloads.
Diese hier gehört zum letzten Release.
In der Timebase Table findest Du die Spalten für die Indizes.
Gruß Hayo
Hi Hayo, Falk, Guido, rowue, Niklas O., KB, Michael D., and guys all!
I am back after a long time, I have to update me on the progress, so I
will eagerly read the old messages.
But I'd like to write some things.
@ Hayo
First, thanks You very, very much Hayo for the great job and free time
You provided generously to us!!!
I installed the new 1.2.BF.2.15 and later beta version release and they
work well, so Hayo thank You very much for the really amazing great work
done!!!
As usual I am speechless, RESPECT to You and all other who
contribuited!!!
It is impressive, it seems to me to use a new DSO!!!
If I did not see at it with my eyes I can not believe at it, really
incredible!!!
No words, RESPECT to You, branadic, Falk, Guido, rowue, Niklas O., KB,
Michael D., Jürgen, eProfi, rawi and all other who contribuited!!!
Sorry if I forgot someone, really sorry.
As I already wrote I have to update me, and then about the old things I
would like to remind you:
@ Michael D.
Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source
Firmware (Teil3)"]
> Ich hätte da mal einen Vorschlag:> im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x> Messbereiche zur Verfügung!> Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern> und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja> voranden.
I think this is really a great idea.
Then there would be more, but first I want to document me about past
developments in order to avoid repeating what has already been treated.
I want to understand better the situation.
Vielen Dank!!!
Gruß Luc
Luc schrieb:
Hi Luc,
welcome back :-)
> Michael D. schrieb: [Beitrag "Wittig(welec) DSO W20xxA Open Source> Firmware (Teil3)"]>>> Ich hätte da mal einen Vorschlag:>> im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x>> Messbereiche zur Verfügung!>> Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern>> und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja>> voranden.>> I think this is really a great idea.
This issue is stored in the "development queue". But there are some more
points of interest. So we must see which of them are solved first.
In the new release coming out soon You will find multiple bug fixes and
improvements. Niklas made several improvements for the screenshot
function, and I completely redesigned the Autoscale function.
Additionally I implemented a new zerolevel behavior inspired by Niklas.
So You can look forward to the next release for You will like it!
By the way, did You notice the new functions which came with the last
releases? If not -> read the "Special Functions.txt".
Regards Hayo
Hallo Hayo,
> sorry ich hatte den Namen etwas falsch formuliert. Ich packe die aktulle> Version immer in das Doc-Verzeichnis des Downloads.
Genau da wo ich nicht gesucht habe :)
Anbei w2000a-screenshot.cpp mit nachgetragenen Werten. Dabei fiel mir
noch auf das wir nicht konsequent mit den Begrifflichkeiten sind, ich
gebe da bislang die Samplingrate als "timebase_str" und "timebase_num"
aus. Habe ich jetzt noch nicht geaendert.
Niklas
Hi Niklas,
Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge
geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht
nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte,
habe ich das erstmal nicht übernommen.
Kannst Du mir da einen Tip geben wfür das gut ist?
Gruß Hayo
Und noch ein kleines Problem:
Unter Windows bricht der Compiler ab mit fer Fehlermeldung
- 179 ....converting to int from double
Verdächtiger ist hier folgende Konstruktion:
FOREACH(OUTF( ( ( (data[j*p_numchact(para)+i] - 128) /* X - 256/2 */
* (p_chscalef(para, chlist[i]) / 1000.0) /* Factor */
- p_chvzero(para, chlist[i])) /* VirtualZero */
/ 50.0 ) /* 50px/div */
* -1 /* invert */
* p_chrange(para, chlist[i]).d /* Range */
/ rescalef)
, p_numchact(para));
Gruß Hayo
Hallo Hayo,
> Du hast in der Methode void FloatStr::Init() die Parameterreihenfolge> geändert (int In_AfterDot, int In_MaxLength). Da ich den Grund nicht> nachvollziehen konnte und das auch diverse Auswirkungen haben dürfte,> habe ich das erstmal nicht übernommen.
Da gibt es keinen Grund fuer, ich habe da glaube ich noch die beiden
neuen protected Variablen initialisieren wollen und die Uebergabe
zwischendurch erweitert und dann offensichtlich falsch
wiederhergestellt.
In der Eile gestern ist mir das im Diff dann nicht aufgefallen.
> Unter Windows bricht der Compiler ab mit fer Fehlermeldung> - 179 ....converting to int from double> Verdächtiger ist hier folgende Konstruktion:> FOREACH(OUTF [..]
Zeile 179 ist ganz woanders. Ich kann den Fehler gerade nicht
nachvollziehen. GCC 4.5.2 unter MinGW hat nichts auszusetzen.
Bitte kompiliere ohne -Werror usw..
Niklas
Alles klar,
alles andere habe ich auch schon eingebaut. Es fehlen nur noch einige
abschließende Tests.
Ich habe übrigens die Autoscale-Funktion mittlerweile soweit, dass sie
stabil von 1Hz - 140MHz arbeitet.
Damit komme ich erstmal klar (und Ihr hoffentlich auch) ;-)
Gruß Hayo
Hallo Hayo,
für die Bedienoberfläche habe ich noch zwei Vorschläge, die den neuen
Glanz noch steigern könnten:
1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung
eigentlich konsequent, wenn man die Grid-Helligkeit auch durch
mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der
Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg
grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für
den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist.
2. Im Eingangskanal Soft-Menü habe ich einen Vorschlag für einen zweiten
Modus der "Dispatch" Funktion:
a) Analogsignal-Modus (so wie bisher) und
b) Digitalsignal-Modus, bei dem die Nulllinien alle eine halbe
Kanalbreite tiefer landen. In Hardware::DispatchTraces könnte z.B.
abhängig von der Anzahl der aktiven Kanäle (inkl. Math) ein Offset
berechnet werden, um den alle Nulllinien nach unten verschoben werden.
Aktivieren könnte man diesen Digitalsignal-Modus über Doppel-Push auf
"Dispatch Channels".
Wie ist die allgemeine Meinung dazu?
Gruß
Rainer
Hallo Rainer,
das sind sehr interessante Vorschläge mit Praxisbezug. Ich prüfe mal was
sich davon mit vertretbarem Aufwand umsetzen läßt.
Danke für die Anregung
Hayo
@Niklas
Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht
richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden
Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden.
Hast Du da evtl. eine Idee?
Gruß Hayo
Hi,
> 1. Im "Display" Soft-Menü wäre es im Sinne einer einheitlichen Bedienung> eigentlich konsequent, wenn man die Grid-Helligkeit auch durch> mehrfaches Drücken der Grid-Taste erhöhen könnte (wie bei der> Quick-Measure Parameterauswahl). Außerdem finde ich die Abstufung arg> grob, vielleicht wären fürs Drücken 20%-Stufen nicht schlecht oder für> den Regler sogar 10%, falls das ohne großen Zirkus umsetzbar ist.
Dem Stimme ich zu, das die "Gridabstufung" zu grob ist!
Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt
nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden,
käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem
Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist!
Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine
Sache!
...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!!
Gruß Michael
Michael D. schrieb:> Dem Stimme ich zu, das die "Gridabstufung" zu grob ist!
Da muß ich aber erst noch prüfen ob eine feinere Abstufung technisch
machbar ist. -> ist in Arbeit
> Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt> nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden,> käme man aus dem tasten garnicht mehr raus, da finde ich das mit dem> Drehgeber rationaler, was ja beim Delaymodus schon der Fall ist!
Ich glaube Rainer meinte das als Zusatzoption. Mal sehen...
> Das mit den "Rastersprüngen", wenn man schneller dreht, ist eine feine> Sache!> ...auch wenn der Drehgeber manchmal rumzickt, klasse Idee!!!
Ja ich hab mich inzwischen auch schon dran gewöhnt, am rumzicken ändert
das leider nichts. Der Grund ist auch immer noch nicht ganz klar.
- sind es die Drehgeber?
- ist es der lahme Prozessor?
Wer weiß...
Gruß Hayo
Michael D. schrieb:> Nur die Abstufungen per Knoppdruck zu bediehnen, begeistert mich jetzt> nicht so, wenn da jetzt mehrere Helligkeitsstufen zur Verfügung stünden,
@Michael,
darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler
sollte alternativ funktieren, damit man die Helligkeit auch direkt
verringern kann. Die Frage war nur, ob man dabei ohne großen Aufwand für
den Regler andere Stufen als für die Taste verwenden kann.
Gruß
Rainer
@Rainer
> darum kamen mir für Tasten 20%-Stufen ganz passabel vor. Der Regler> sollte alternativ funktieren, damit man die Helligkeit auch direkt> verringern kann.
Achso, als zusätzliche Alternative für's "Grobbe" ?!? Das wäre dann auch
ok!
@Hayo
> Tja das werd ich mal versuchen rauszufinden. Wenn es geht kriegt Ihr es> auch...
...au ja
Gruß Michael
Edit: Hast du was am Quickmeasure was gedreht?
> Edit: Hast du was am Quickmeasure was gedreht?
Nein habe ich nicht. Aber ich habe für Euch was zum Drehen - nämlich am
Helligkeitsregler.
Es ist natürlich nicht die Helligkeit die man da regelt, sondern der
Farbton. Da unser W2000A nicht mit allen Display-Steuerleitungen
arbeitet stehen nur begrenzt viele Farben zur Verfügung.
Um es kurz zu machen - es gibt tatsächlich nur 3 Abstufungen pro Farbe.
Ich kann Euch aber anbieten verschiedene Farbtöne zur Verfügung zu
stellen wenn Euch das interessiert.
Welche Werte da zur Verfügung stehen könnt Ihr mit dieser Version selbst
ausprobieren. Die Farbwerte werden via Terminal ausgegeben.
Die Neuerungen sind natürlich auch schon an Bord. Ihr könnt ja schon mal
testen, vielleich findet Ihr noch Fehler die ich übersehen habe.
Viel Spaß
Hayo
@Hayo
ich habe mal ein bisschen Grid-Farben gedreht...
Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66%
(0x2a) könnte ich mir als Abstufung die 0x1a vorstellen.
Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen
auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die
Sache eher unübersichtlich macht. Da habe ich nichts gefunden.
Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die
Belegung her?
Gruß
Rainer
Rainer W. schrieb:> ich habe mal ein bisschen Grid-Farben gedreht...
schrill oder...?
> Die Auswahl ist ja mehr als besch.... eiden. Zwischen 33% (0x15) und 66%> (0x2a) könnte ich mir als Abstufung die 0x1a vorstellen.
ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor.
Ich wollte mal ähnliche Farben nebeneinander in ein Array stopfen damit
man bein hin und her schalten die Unterschiede besser sehen kann.
> Im hellen Bereich zwischen 66% und 100% (0x3f) kommt man beim Ausweichen> auf bunte Grid-Farben schnell an die Kanalfarben ran, so dass es die> Sache eher unübersichtlich macht. Da habe ich nichts gefunden.
Ging mir auch so
> Kann man die RGB-Werte der LUT irgendwo nachlesen, oder wo kommt die> Belegung her?
Ich hab da momentan nichts, aber unsere Hardware Spezis hatten dazu
glaube ich was auf SFN veröffentlicht. Da muß ich bei Zeiten mal nach
suchen.
Aber - gute Nachrichten, mir ist es gelungen beim Screenshot ein Popup
einzubauen ohne dass dieses mit übertragen wird.
Gruß Hayo
Hayo W. schrieb:> ist die 0x1A nicht identisch mit 0x2A? Kam mir jedenfalls so vor.
0x2A ist ein sauberer Grauton, während 0x1A das Gelb zu sein scheint,
das auch oben für den Hintergrund der Bereichsanzeigen verwendet wird.
Vielleicht wirkt es dadurch ein bisschen dezenter als das 66%-Grau.
Unter den gegebenen Umständen sollte man dann da vielleicht im Moment
nicht zu sehr drüber nachgrübeln.
@eProfi
gut zu wissen, aber alleine wegen der Gridfarbe an der Hardware
rumzuschrauben ist mir doch etwas viel Zauber
Gruß
Rainer
Hi Hayo, hier mal eine kleine Rückmeldung!
Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind.
Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung.
Die Gridfarben werden im Screenshot nicht mit aufgezeichnet?
Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf
den Combitrigger?
Gruß Michael
Michael D. schrieb:> Hi Hayo, hier mal eine kleine Rückmeldung!>> Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind.> Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung.
Ich bau das auch mit ein, dann hat man was für's Auge
> Die Gridfarben werden im Screenshot nicht mit aufgezeichnet?
Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte
den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das
darstellen.
> Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf> den Combitrigger?
Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es
Bedenken?
Und in der Final-Version gibt es das Ganze auch noch mit
Fortschrittsanzeige, so wie auch beim Screenshot.
Gruß Hayo
Hayo W. schrieb:> Michael D. schrieb:>> Hi Hayo, hier mal eine kleine Rückmeldung!>>>> Also, ich finde das ganz witzich, das die Gritfarben veränderbar sind.>> Jedenfalls, hat man schon mal mehr Auswahl als vorher zur Verfügung.> Ich bau das auch mit ein, dann hat man was für's Auge>
...genau, tut ja nicht weh!
>> Die Gridfarben werden im Screenshot nicht mit aufgezeichnet?>> Nein, die Farben des Bildes werden vom PC-Programm vorgegeben. Man müßte> den Farbwert für das Grid zusätzlich übertragen, dann ließe sich das> darstellen.>
nun ja, ist ja nicht soo wichtig!
>> Die "Autoscale-Funktion" funzt soweit prima...schaltet automatisch auf>> den Combitrigger?>> Korrekt, das hat sich bei meinen Tests am Besten bewährt. Gibt es> Bedenken?>
nö, ich find's gut! Der Combitrigger, ist so oder so genial und man ist
dann auf der sicheren Seite
> Und in der Final-Version gibt es das Ganze auch noch mit> Fortschrittsanzeige, so wie auch beim Screenshot.>
Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon
als "Flash" drinnen!
...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich
habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und
bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!?
> Gruß Hayo
Gruß Michael
> Fein, wann kann man denn so damit rechnen? Ich habe die letzte Ram schon> als "Flash" drinnen!
Ich hoffe morgen oder Übermorgen.
> ...kann das sein, das die Encoder unterschiedlich Empfindlich sind? Ich> habe mal ein wenig mit der "Gridhüpperei" (geniale Sache) gespielt und> bin der Meinung, das der 2.Kanal nicht so rumzickt, wie der Erste?!?
Das würde darauf hindeuten, dass es tatsächlich an den Encodern liegt
(Billigschrott???)
Gruß Hayo
Ok,
damit das Warten nicht zu lang wird:
- die Fortschrittsanzeigen für Screenshot und Autoscale sind drin
- Double Push Funktionalität beim Autoscale Button
- Es gibt einen neuen Button "Send Measure" im Quick Print Menü,
dahinter steckt Niklas neue Measure Funktion.
- die Farbpalette für das Grid läßt sich durch Druck auf den
Grid-Intensitätsbutton ändern.
In die Final will ich noch einige Goodies einbauen. Mal sehen wie lange
ich brauche. testet schon mal, dann kann ich evtl. Fehler gleich mit
wegbügeln.
Gruß Hayo
moin Hayo,
was iss eigentlich mit der 'vernachlaessigten' singel funktion
geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten
ein schoenes & erfolgreiches WE
Charly
Charly B. schrieb:> moin Hayo,>> was iss eigentlich mit der 'vernachlaessigten' singel funktion> geworden? ist die jetzt ok ? denn die brauch i am allerwichtigsten
Sollte stabil laufen. Im Mode/Coupling Menü gibt es die Möglichkeit im
Submenü das Verhalten einzustellen. Probier mal aus und sag Bescheid
wenn etwas nicht funktioniert.
Gruß Hayo
Hayo W. schrieb:> - die Farbpalette für das Grid läßt sich durch Druck auf den> Grid-Intensitätsbutton ändern.
Moin Hayo,
verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten
vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann?
Da hätte ich jetzt einen ganz ketzerischen Vorschlag:
- 1 konfigurierbare Palette mit z.B. 4 Werten
- Umschalten zwischen den Paletteneinträgen auf Tastendruck
(für normale Bedienung)
- Festlegung der Paletteneinträge über Drehgeber
(zur Konfiguration)
- Abspeichern der Palette in den Geräteeinstellungen.
Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte.
Schönen WE
Gruß Rainer
Rainer W. schrieb:> verstehe ich das richtig, dass du da jetzt 10 Paletten à 4 Werten> vorgegeben hast, zwischen denen man auf Tastedruck umschalten kann?
Jupp, und hier die Werte:
GridColorArray[10][4] =
{{0x00, 0x15, 0x2A, 0x3F}, //white
{0x00, 0x01, 0x02, 0x03}, //red
{0x00, 0x04, 0x08, 0x0C}, //green
{0x00, 0x05, 0x0A, 0x0F}, //yellow
{0x00, 0x10, 0x20, 0x30}, //blue
{0x00, 0x14, 0x18, 0x2C}, //light blue
{0x00, 0x11, 0x12, 0x13}, //violet
{0x00, 0x16, 0x17, 0x2B}, //pink
{0x00, 0x06, 0x0B, 0x1B}, //orange
{0x15, 0x1A, 0x2A, 0x3F}}; //test
Das sind so ziemlich alle Werte die eine sinnvolle Kombination ergeben.
> Da hätte ich jetzt einen ganz ketzerischen Vorschlag:> - 1 konfigurierbare Palette mit z.B. 4 Werten> - Umschalten zwischen den Paletteneinträgen auf Tastendruck> (für normale Bedienung)> - Festlegung der Paletteneinträge über Drehgeber> (zur Konfiguration)> - Abspeichern der Palette in den Geräteeinstellungen.
:-) Jetzt willst Du es aber genau wissen...
> Dann könnte jeder sich seine Palette zurechdrehen, wie er möchte.
Mein Vorschlag ist erstmal für alle die selber kompilieren können:
tragt Euch in das Array oben Eure eigenen Werte ein und wenn Ihr eine
gute Kombination gefunden habt übernehme ich die gerne in die offizielle
Version.
Gruß Hayo
Noch ein Hinweis an die unermüdlichen Tester:
Beim Autoscale werden alle Suchschritte via Terminal ausgegeben, so dass
man alles genau nachvollziehen kann.
Gruß Hayo
Hallo Hayo,
gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber
den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die
Idee (stammte sie von Niklas?) finde ich übrigens sehr gut.
Zu den Screenshots:
Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu
bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine
Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder
geht das per Paramter auf der PC Seite?
Die Autoscale-Funktion hat bei ersten Tests gut funktioniert, natürlich
muss man etwas Geduld haben aber das lässt sich beim Nios wohl nicht
ändern. Allerdings würde es mir persönlich besser gefallen, wenn die
Funktion die Zeitbasis so einstellen würde, dass eine Signalperiode auf
dem Display zu sehen ist. Beim Test mit dem Rechteckgenerator des Oszis
stellten sich 10ns ein, d.h. 12mal Zeitbasis umschalten bevor man eine
Periode sieht. Das ist aber sicher Geschmackssache.
Ansonsten habe ich einige neue Funtionen entdeckt, die ich gar nicht
mitbekommen hatte, da hat sich in letzter Zeit doch wieder gewaltig was
getan - klasse.
Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf
10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den
Default evtl. darauf setzen.
GrußKürzlich haben wir übrigend in der Arbeit an unserem Oszi der 40 000
Euro Klasse feststellen müssen, dass der stinknormale Flankentrigger
nicht der zuverlässigste ist...da macht unser 300 Euro Oszi gar keine
schlechte Figur.
Ein schönes Wochenende euch allen!
Michael
Hi Hayo
I have tested the latest firmware from yesterday. The new Autoscale
works great, and the custom grid palette is an excellent idea.
Unfortunately I'm not able to use the panning knob when in single shot:
I acquire a waveform, I can zoom with the timebase knob, but I'm not
able to move around with the smaller delay knob. With 2.15 this was
working.
Sorry if this issue was addressed before, anbd thank you for all your
efforts.
Be well,
Andrea
ich noch mal,
bei der Autoscale-Funktion, kann man das Signal hoch u. runter bewegen,
aber nicht mehr nach links u. rechts, auch wenn ich auf Cursor oder
Quickmeasure gehe...
Gruß Michael
??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht?
@Michael H.
also noch mal: Schalter "-a" ist der bestätigungsbeep, Schalter "-b" die
permanente BMP Ausgabe. "-c4" ist Comport und dem entsprechend
anzupassen.
noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die
Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!?
Gruß Michael
Michael D. schrieb:> ??? ...wo ist denn mein Beitrag für die Batchdatei hin??? Gelöscht?
komisch - scheint verschwunden zu sein
> noch was, drücke ich "About Oszilloscope" und wieder zurück, ist die> Gridfarbeneinstellung hinüber! Wird wohl nicht gespeichert?!?
Ist noch beta, daher ist noch nicht alles wie es sein soll. Aber danke
für den Hinweis, da muß ich noch ran.
Gruß Hayo
moin moin Hayo,
hatte heut morgen die 2.18 beta aufgespielt, leider dauert
das Calibrate Offsets sehr lange (einige Minuten) und danach war
keine X-Linie mehr sichtbar und auch keine Signale werden mehr
angezeigt. :(
hab die mal einen rs232 output vom start an ueber Calibr. Offsets
mitgeschrieben, vielleicht hilfts ja oder hab i was falsch
gemacht ?
vlG
Charly
Hi Charly,
habe die 2.18 drauf und das Calibrieren dauert gerade mal 6 Sek.! Hast
du mal Default Setup gedrückt?
Aprorpos...ich dachte es liegt am Autoscale, dem scheint aber nicht so.
Nach Default Setup, kann ich die Signale trotzdem nicht nach links oder
rechts verschieben, hoch u. runter geht, was'n da los?
Ist das nur bei mir so, oder kann das noch Jemand bestätigen?
Gruß Michael
moin moin Michael,
ja, ich habe auch default setup gedrueckt, sieht man auch im Log-File,
i denke/hoffe Hayo kann sich da ein Bild machen was schief gelaufen
ist. i warte halt auf das naechste release
vlG
Charly
Hi Hayo,
- zur Quick Measure Datenübertragung habe ich gleich eine Fragen:
Gibt es schon eine offizielle Protokollbeschreibung für die lachenden
Männchen, die einem auf dem Terminal zwischen den Daten entgegenkommen
oder ist das noch 'in progress'?
- Die fehlende Wirkung des X-Position (Pan) Reglers auf den sichtbaren
Signalausschnitt kann ich bestätigen.
- Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send"
beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch.
Allerdings macht das Screenshot Programm unter Win direkt einen Abgang,
wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?)
Der Fortschrittsbalken beim Screenshot ist super-chic!
Schönen Abend und Gruß
Rainer
ich habe mir mal die Mühe gemacht und bis hinunter zur 2.12 geflasht.
Mit dem FTDI-Dongle dauert das zwar jedes mal 170Sek., aber was
soll's...
Ab der 2.13 tritt das Problem auf. Mit der 2.12 kann ich mit den
Signalen von links nach rechts u. umgekehrt wandern!
gruß Michael
Hallo, moin moin,
danke für die zahlreichen Rückmeldungen.
zur X-Verstellung:
- da habe ich doch leider das Coding etwas überoptimiert und eine Zeile
zuviel weggehauen bei der ich nicht mehr ganz sicher war wozu ich die
gebraucht hatte - jetzt weiß ich es wieder :-)
Als Workaround könnt Ihr im Pretriggermenü "Keep Value" einstellen, dann
geht es wieder.
@Charly
Dein Problem konnte ich nicht nachstellen, bei mir funktioniert es
super. Dein Log zeigt mir, dass die ADC bei Dir nicht losgelaufen sind -
warum kann ich leider nicht sagen. Mich würde interessieren ob das bei
Dir reproduzierbar ist.
Ich stelle gleich noch mal eine korrigierte beta hier rein die Ihr
testen könnt.
Gruß Hayo
Moin Hayo,
bei Einzeltrigger nach einer TB-Umschaltung sind noch Überreste (?) des
alte Kanal 3/4-Problem vorhanden.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
Beim ersten Trigger nach einer Umschaltung der TB wird auf Kanal 3+4
nichts aufgezeichnet. Hattest du da nochmal drüber nachgedacht?
Gruß
Rainer
Ja da hatte ich schon etliches ausprobiert - leider ohne Erfolg.
Das muß also erstmal schuldig bleiben. Wie bei anderen Bugs kann es aber
durchaus sein, dass ich im Rahmen anderer Änderungen darüber stolpere.
Hayo
@Hayo
nach dem Flashen waren beide X-Lines da nur halt verschoben,
dann Calibrate und weg waren sie, hab das geraet mehrfach
aus/ein geschaltet und Calibrate versucht, leider ohne
erfolg. :(
Gibt es eigentlich eine neuere Soft zum Flashen
unter W7/64 ?, i hab immer noch einen uralt Programmer
v. Wellec und der brauch ewig
vlG
Charly
Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du
nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es
eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht.
Habt Ihr Anderen da Überblick?
Hayo
auch moin moin, uns fehlt hier eine Stunde...;)
Das "Pre Trigger" Menu habe ich ja voll verpeilt! Da geht ja was.
Ich nehme alles zurück, passt schon.
Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2
Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen
zu lassen, ist das möglich oder eher unpraktisch?
Gruß Michael
> Mit dem Support von Win64 bin ich nicht so vertraut. Im Prinzip mußt Du> nur Perl zum Laufen kriegen, damit das Upload-Skript funktioniert. Ob es> eine 64 Bit Variante von Active Perl gibt weiß ich momentan nicht.> Habt Ihr Anderen da Überblick?
Habe ich mir gerade mal verschafft!
Es gibt eine neue Release Ver. von Active-Perl 5.8
Betriebssysteme sind unter Anderem auch 64bit angegeben, siehe Shot!
bitteschön...
Hier der Link:
http://www.activestate.com/activeperl
gibts irgendwo eine Beschreibung wie was wann seriell
gesendet wird f. das flashen ? event. kann man das ja
selber proggen, oder gehts mitlerweile per USB und
i hab das beste verpasst ?
vlG
Charly
Kleiner Tip für alle die den Überblick über die aktuellen
Sonderfunktionen verloren haben:
In der Datei "Special Functions" im Doc-Verzeichnis sind alle Funktionen
beschrieben. Die Datei wird mit jedem Release upgedatet.
Gruß Hayo
Michael D. schrieb:> Ein kleiner Vorschlag: Ich fände es ganz praktisch die X1, X2 u. Y1, Y2> Achsen im Curser-Menu nach schnellerem drehen, grössere Sprünge machen> zu lassen, ist das möglich oder eher unpraktisch?
Gute Idee
Gruß Rainer
Hi Charly,
ich muß mich korrigieren, die letzte Release ist die 5.12, besser man
nimmt diese!
und nein, es funzt im Moment nur über den Serialport!
Aktive-Perl installieren, ausführen und im Perl-Package-Manager das
Win32-Serialport-0.22-Package installieren( muß aber auch separat
heruntergeladen werden!
Anbei mal ein Shot, wie das auszusehen hat
Ich hatte mal irgenwo eine Anleitung gepostet, finde die aber im Moment
nicht...
Gruß Michael
So, das war jetzt etwas mühselig die ganzen kleinen Bugs zu finden.
Ich habe Eure Hinweise alle abgearbeitet und hoffe dass nicht mehr
allzuviel falsch läuft.
- Autoscale -> sucht jetzt schnellere Zeitbasen damit weniger
Perioden auf dem Schirm sind
-> DC-Offset Erkennung (Digitalsignal)
- Dispatch -> DC-Offset Erkennung (Digitalsignal)
- Grid -> Colorpaletten werden jetzt richtig eingestellt und gespeichert
(mein Favourit ist die hellblaue Palette, das erinnert mich
an mein Analog-Oszi)
-> zum Testen gibt es den Testswitch 2 (shift + Y) der sich via
Terminal umschalten läßt.
aus -> normale Intensitätsverstellung
an -> per Drehgeber können die Farben einzeln eingestellt
werden
- X-Verstellung (panning) geht wieder korrekt
Gruß Hayo
Hallo Hayo,
super, dann kann man ja noch mal Grid-Farben drehen.
Die "Intelligenz" der Dispatch gefällt mir auch sehr gut.
Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem
Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine
Chance. So wie es jetzt funktioniert, muß anscheinend immer ein neues
Signal erfaßt werden, damit sich das Signal verschiebt.
@Michael - Hier in Stuttgart scheint inzwischen wieder die Sonne :-)
Schönen Sonntag
Rainer
Hamburg - auch sonnig! Habe gerade meine Sommerreifen draufgezogen...
> Beim Panning wäre es eigentlich schön, wenn man damit auch bei einem> Einzelsignal durch den Speicher rutschen könnte. Siehst du dafür eine> Chance.
Wie ist das gemeint mit dem Einzelsignal?
Habt Ihr noch was gefunden was klemmt?
Gruß Hayo
Hayo W. schrieb:> Wie ist das gemeint mit dem Einzelsignal?
Damit meint ich ein einmal erfaßtes Event, also kein periodisches
Signal.
Wenn das DSO auf Norm Trig steht und ein Event erfaßt hat, muß man erst
auf STOP-Taste gehen, damit sich das Signal horizontal auf dem Schirm
verschieben läßt. Wenn man nicht auf STOP geht, muß man erst ein neues
Signal erfassen, damit des Panning eine Wirkung auf die Signalposition
hat.
Das mit dem STOP hatte ich nicht gepeilt. Ist ein bisschen umständlich,
aber nicht so wild.
Schönen Abend
Rainer
Ich hänge mit der ct leider 6 Hefte hinterher - ich programmiere einfach
zu viel, da kommt man nicht mehr zum Lesen.
Aber ich habe mal eine Frage, bei mir sind die Spikes auf Kanal 3 + 4
teilweise so heftig, dass kein Autoscale auf diesen Kanälen funktioniert
wenn diese die Triggersource sind. Ist das bei Euch auch so?
Auf Kanal 1 + 2 ist alles ok.
Gruß Hayo
Wetere Erkenntnisse:
- Die Spikes treten nur bei warmgelaufenen Gerät auf -> also ein
thermisches Problem (hatten wir ja früher schon vermutet).
Ich werde da mal nachforschen wie man das wegkriegt, habe
auch schon eine Idee.
- Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer
als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf,
die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht
das nicht. Ich suche noch nach einer Lösung.
Gruß Hayo
Hayo W. schrieb:> - Autoscale -> auf Kanal 3 + 4 bei einer Eingangsspannung größer> als 15 Vpp tritt anscheinend eine Übersteuerung der Eingangsstufe auf,> die eine Timebaseerkennung verhindert. Auf Kanal 1 + 2 geschieht> das nicht. Ich suche noch nach einer Lösung.
Kann das eventuell mit dem Kanal 3/4 Erfassungsproblem nach TB
Umschaltung zusammenhängen. Deine Autoscale Suchroutine wird doch auch
an der TB drehen, ein Signal erfassen (wollen) und das dann auswerten.
Nur so ein Gedanke ....
Das Problem ist die grundsätzliche Vorgehensweise. Für die
Timebasermittlung
wird in den 10mV Bereich geschaltet, damit die Flanken möglichst steil
sind und man sie besser zählen kann.
Das funktioniert auch ganz gut, nur auf Kanal 3 + 4 scheint dann ab 15
Vpp eine Übersteuerung einzusetzen und die ADC sind dann auf
Vollanschlag aber nur nach unten.
Gruß Hayo
Hayo,
zur Entspannung habe ich noch eine "Oberflächenrauhigkeit" für dich:
Wenn man "Display Persist" aktiviert hat und dann "Autoscale" startet,
bleibt nach dem Ende vom Autoscale der alte Müll auf dem Bildschirm
stehen.
Da wäre noch ein feines Plätzchen für ein Clear Display nachdem
Autoscale seine Arbeit beendet hat.
Die Spikes auf 3 + 4 scheinen immer genauso so hoch wie das Signal zu
sein, zumindest bei einem Rechteck. Daraus schließe ich eigentlich, dass
es sich um ein sporadisches Adressierungsproblem handelt, so dass ab und
zu korrekt gesamplete Daten an der falschen Stelle im Speicher landen.
Wo auch immer das passiert ...
Gruß
Rainer
@Hayo,
beim Autoscale in der 2.19 beta bin ich gerade noch auf Signale
gestoßen, bei denen sich der Algorithmus verläuft:
Signale: Probe Comp an 3, Gnd an 4
ergibt: 100 us/div, 500 mV/div, 10 mV/div (ok)
Wenn ich die Signale vertausche, also
Signale: Gnd an 3, Probe Comp an 4
endet das bei: 50 ns/div, 10 mV/div, 10 mV/div (Unfug)
Eigentlich ist das Signal an Ch4 ja vernünftig.
Da die Signalamplitude mit 1 Vpp eher friedlich ist, scheint da im
Algorithmus noch was schief zu gehen und eher nicht dein 15V-Problem zu
sein. Der gleiche Test mit Ch. 2 + 4 führt oft zum gleichen Ergebnis.
Schönen Abend
Gruß
Rainer
Hallo Rainer, danke für Deinen ausführlichen Testbericht. Bin gerade vom
Griechen zurück und arbeite schnell noch die Mails ab.
Dein geschilderrtes Problem liegt mit ziemlicher Sicherheit an der
reihenfplge der Abarbeitung.
Der Autoscale der 2.19 arbeitet so:
Spannungsbereich auf 10mV, dann den ersten aktiven Kanal (Reihenfolge
1,2,3,4) auf brauchbare Timebases prüfen. Wenn eine brauchbare Timebase
gefunden wird, dann übernehmen. Sonst auf Default 50ns einstellen,
weitere Kanäle werden nicht geprüft.
Dann wird mit dieser Timebase für alle anderen aktiven Kanäle der
richtige Spannungsbereich gesucht.
In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven
Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet.
Die Triggersource wird automatisch angepasst. Wenn kein Sigal gefunden
wird dann wird Default eingestellt.
Kanäle ohne Triggerbares Signal werden auch nicht mehr auf
Spannungsbereich geprüft.
Damit ist wahrscheinlich dann auch Dein Problem erledigt.
Gruß Hayo
Hayo W. schrieb:> In der 2.20 beta kann der Autoscaler schon mehr. Hier werden alle akiven> Kanäle solange auf ein triggerbares Signal durchsucht bis er was findet.> Die Triggersource wird automatisch angepasst.
Ich sehe, du bist schon wieder ein ganzes Stück weiter.
Bei der Suche nach einer Triggersource kann man vielleicht davon
ausgehen, dass der Benutzer schon den richtigen Triggerkanal gewählt
hat. Wenn der Algorithmus auf diesem Kanal anfängt, hat er eine große
Chance, dass er schon richtig liegt und die Suche gegenüber blindem
Durchlaufen aller Kanäle verkürzt wird.
Ich bin gespannt auf die 2.20
Gruß Rainer
Hallo,
in der 19er springt der Trigger bei angehaltenem Signal schon viel
weniger, wenn ich die Zeitbasis umstelle. Von 10ms auf 5ms wechselt er
aber immernoch die Position im Signal. Sonst schon viel besser geworden.
Hallo,
Michael H. schrieb:> gerade habe ich ein wenig mit der neuen Beta gespielt, konnta dabei aber> den Knopf zum Senden der Messdaten nicht im QuickPrint Menü finden. Die> Idee (stammte sie von Niklas?) finde ich übrigens sehr gut.
Die Idee stammt von August.
> Zu den Screenshots:> Was muss ich tun, um per Doppeldruch auf Quickprint wieder BMPs zu> bekommen? Mit "save to bmp" klappt es zwar, aber gibt es eine> Möglichkeit, das auch für den Doppeldruck als Standard zu setzen? Oder> geht das per Paramter auf der PC Seite?
Wie Michael D. schon schrieb: Per Parameter -b
> Achja da fällt mir noch was ein: ich habe meine Tastköpfe fast immer auf> 10:1, wie sieht es bei anderen Leuten hier aus? Denn dann könnte man den> Default evtl. darauf setzen.
Mhm, ich hab's jetzt nicht ueberprueft, aber sollte nicht die letzte
Einstellung des Kanals beibehalten werden, d.h., einmal einstellen
auf 10:1 Teiler und damit hat's sich?
Ansonsten:
Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich
kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt.
Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz"
Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung
x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal
mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO
verglichen.
Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD
(inkl. Versand) Tastkopf. Die Traces sind etwas verschoben,
da ich den Versatz nocht nicht wieder ueber die Delays im
Utility-Menue kompensiert habe. Man sieht's aber auch
"mit blossen Augen" ohne Cursor recht gut ;)
Niklas
Rainer W. schrieb:> - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send"> beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch.> Allerdings macht das Screenshot Programm unter Win direkt einen Abgang,> wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?)
Mhm, hast Du die aktuelle Version die ich oben dem Hayo gepostet habe?
Eine aeltere wird irgendwas in Richtung
1
w2000a-screenshot: Internal Error: Unhandled dumptype in retrieve() (at 4): 4
sagen.
> Der Fortschrittsbalken beim Screenshot ist super-chic!
ACK, gut gemacht Hayo ;)
Hayo W. schrieb:> Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht> richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden> Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden.>> Hast Du da evtl. eine Idee?
Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass
das in den Memory-Planes gezeichnet wird, und diese werden beim
Farb-Screenshot gar nicht ausgewertet/uebertragen.
Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme
aber erst am Wochenende dazu nachzusehen.
Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim
Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2
nicht nachvollziehen konnte.
Niklas
Niklas O. schrieb:> Rainer W. schrieb:>> - Der "Send Measure"-Softkey im Quick-Print Menu ist nur mit "Send">> beschriftet. Ist das Absicht? Die Funktion finde ich sehr praktisch.
Nein, ist auch schon behoben.
>> Allerdings macht das Screenshot Programm unter Win direkt einen Abgang,>> wenn man aus Versehen die "Send Measure"-Taste erwischt. (@Niklas?)
Ich habe jetzt eine WIN32 .exe compiliert indem ich die Option -Werror
rausgenommen habe. Läuft bei mir ohne Probleme. Ich gebe die beim
nächsten Download mit.
>> Der Fortschrittsbalken beim Screenshot ist super-chic!>> ACK, gut gemacht Hayo ;)
Danke :-)
> Hayo W. schrieb:>> Wie schon hier angemerkt wurde wird die UI_Plane1 (hellgrau) nicht>> richtig im Screenshotprogramm ausgewertet. Übertragen wird sie auf jeden>> Fall. Ich habe da mal kurz drübergesehen, konnte aber nichts finden.>>>> Hast Du da evtl. eine Idee?>> Meine Vermutung auf die Beobachtung von iirc. Rainer war ja, dass> das in den Memory-Planes gezeichnet wird, und diese werden beim> Farb-Screenshot gar nicht ausgewertet/uebertragen.
Das kann ich ich vorab mal checken.
> Sollte es die UI_Plane1 sein liegt das Problem schwerer. Ich komme> aber erst am Wochenende dazu nachzusehen.>> Welche GCC-Version hast Du unter MinGW bei Dir eigentlich? Beim> Kompilieren kamen bei Dir ja Fehler die ich mit der iirc. 4.5.2> nicht nachvollziehen konnte.
Keine Ahnung, hab gerade kein Windows laufen, schau ich mal bei
Gelegenheit nach
Gruß Hayo
Also die Memory Planes werden überhaupt nicht benutzt, ich habe sie
daher gelöscht. Der Einzige UI-Layer der einen Buffer benutzt ist der
UI-Layer 2 (schwarz). Es liegt also an etwas Anderem.
Gruß Hayo
Ok Fehler gefunden.
Ich habe mal ein Testbild generiert und versendet. Man sieht das alle
Planes korrekt übertragen werden. Nur im Screenshot-Programm wird die
falsche Farbe zugeordnet. Die Buttons haben dann die gleiche Farbe wie
die Schrift. Das ist wie ein Eisbär im Schnee.
Also muß nur die Farbe in Grau geändert werden und alles ist gut. Ich
werde das mal testweise machen.
Gruß Hayo
Das Testbild könnt Ihr Euch auch ansehen - das erscheint wenn man übers
Terminal shift + C eingibt. Danach muß man das DSO aber resetten, da es
dann stehenbleibt.
Dieses Testbild habe ich dann einfach mal in einer Testversion in den
Screenshot mit eingebaut.
Man kann auch schön den Pixelfehler in der UI Plane 1 sehen.
Gruß Hayo
So es gibt auch eine neue Screenshot Version. Es doch nicht nur die
Farbe, ich mußte auch die Layerreihenfolge ändern. Aber jetzt
funktioniert es. Daher werden die neuen Versionen (FW + Screenshot)
nicht mehr rückwärtskompatibel sein. Dank Niklas schicker
Versionsabfrage aber ja kein Problem.
Gruß Hayo
@Kurt
ich lade gleich hier das neue Major Release hoch. Du solltest Deine
Screenshotversion entsprechend anpassen mit der Layerreihenfolge. Ich
habe da auf Firmwareseite aber bei Deinen Routinen noch nichts geändert.
Ich würde dann die neue Reihenfolge und die Fortschrittsanzeige einbauen
wenn Du das möchtest.
Gruß Hayo
Ok hier ist es das neue Release.
Was ist neu?
- redesigned autoscale function with new TB search strategy setup in
the autosacle menu.
- new double push oprion for autoscale button for slow TB search
- new screenshot version with corrected layers
- new progress indicator for screenshot and autoscale
- added Flat Top window for FFT
- new zeroline adjustment
- new grid colors which can be set by pushing grid intensity button
in display menu
For further details please read the changelog and the file Special
Functions.txt
Gruß Hayo
Noch ein kurzer Hinweis:
Da die neuen Menüs Ihre Startwerte aus dem Flash beziehen kann es sein,
dass beim ersten Aufruf falsche Werte eingetragen sind. Das erledigt
sich nach dem ersten Aufruf der Menüs aber von selbst.
Hayo
Hallo Torsten,
ich habe mal die neue Firmware auf mein zweites DSO gespielt und kann
auch da die Probleme nicht nachvollziehen. Alles funktioniert bestens.
Mein Vorschlag zur Vorgehensweise:
- Gerät ausschalten und wieder anschalten
- ins Utility Menü wechseln
- Default Setup
- dann das Calibration Set <Standard> explizit auswählen, auch wenn
es schon auf dem Button angezeigt wird
- Terminal starten damit man die Ausgaben sehen kann
- Kalibrieren
Die Terminalausgabe in eine Datei kopieren und hier posten.
Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale
Menu für TB Search ist völlig vergurkt und richtet sich auch nicht
selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch
aus?
Gruß Hayo
Hallo Hayo,
welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes?
Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige
einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den
Planes.
Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert. Die
Neuerungen beim DUMPCSV brauchst du noch nicht bei mir einbauen, die
muss ich mir nochmal genauer ansehen. Auch beim Send Measure werde ich
mal sehen müssen on ich das übernehmen kann.
Mfg,
Kurt
Hayo W. schrieb:> Was mir aber eben bei meinem zweiten DSO aufgefallen ist, das Autoscale> Menu für TB Search ist völlig vergurkt und richtet sich auch nicht> selbst. Bei meinem ersten DSO ist das nicht so. Wie sieht das bei Euch> aus?
Hi Hayo,
danke für den inflationären Versionssprung. Bei meinem W2024A gibt es
nach einem "Default Setup" weder mit "Calibrate Offset" noch mit dem
Autoscale "TB Search" Menü irgendetwas zu meckern.
Die Lösung mit TB Search auf Trig Source finde ich sehr gut. Bin
gespannt, was sich noch alles so getan hat.
Gruß
Rainer
Hallo Jungs,
danke für die Rückmeldung. Bin gerade vom Training und wie so oft vom
Griechen zurück.
@Torsten
Danke für das Log. Ich habe eine Idee wo ich suchen muß. Wenn ich was
finde liefere ich schnellstmöglich einen Fix.
Stell mal vor dem Kalibrierungslauf den Trigger auf Auto! Wenn es dann
funktioniert weiß ich was es ist.
Gruß Hayo
Hallo,
gerade die v3.0 ins Flash geladen. Sieht gut aus!
Was womoeglich auch fuer die anderen relevant sein koennte
(obgleich ich da nicht wirklich einen Erklaerung fuer habe):
Nach manchen Firmwareupdates habe ich ploetzlich staerkeres
Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4)
auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein,
wie es auch gerade wieder passiert ist. Das laesst sich bei
mir dann beheben durch Laden eines Komplettdumps vom DSO
im Auslieferungszustand von den Wittigs. Danach dann die
neue Firmware, Rauschen ist weg.
Das Screenshotprogram warnt wegen des unverhofft hohen
Versionssprungs zwar, das kann aber getrost ignoriert werden.
Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung
gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei
Sourceforge dokumentieren.
@Hayo:
> [Testbild]> Man kann auch schön den Pixelfehler in der UI Plane 1 sehen.
Oeh, Pixelfehler?
Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut
das die Layer einzeln in Dateien abgelegt wurden, so dass man
diese dann bei Darstellungsproblemen einzeln untersuchen kann.
Das ist dann irgendwann weg gefallen.
Macht es Sinn das als Spezialfunktion wieder einzubauen?
Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam,
was viele unter Windows nur wegen der GERMSloader.pl bei sich
installiert haben: Besteht Interesse an einem einfachen
Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne
grossen Aufwand realisieren. Es gab aber auch mal ein Tool fuer
Windows mit GUI, was ist eigentlich daraus geworden?
Niklas
P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf
aus China in Stellung 1:1 eine hoehere Bandbreite hat
als die Welecs?
Ab sofort nehme ich die Vorbestellungen für den USB-Host an. Weitere
Infos auf
http://sourceforge.net/apps/trac/welecw2000a/wiki/Vinculum#Sammelbestellung
(Der Rest des Artikels wurde auch aktualisiert, insbesondere die Eagle
Dateien!)
Bei Fragen oder Anregungen meldet euch bitte hier im Forum oder per mail
(SF Adresse).
Mfg,
Kurt
Hallo!
Ich hätte enormes Interesse an der USB Erweiterung!
(sorry dass ich so reinplatze, aber ich verfolge die Entwicklung immer
mal wieder nebenbei, tausend Dank an alle Beteiligten!)
Fragen:
- Werden USB-Sticks > 2GB unterstützt (Habe das Problem regelmäßig an
mittelalten Teks)
- Welche Gehäusemodifikationen muss ich vornehmen? Habe gerade keine
Vorstellung, wie die Platine in "echt" da reingehört. Aber ich habe
jetzt den HW-Thread auch nur überflogen - steht das irgendwo? Sorry,
wenn ich das übersehen habe, ich dachte nur ich melde mich gleich bevor
die Dinger weg sind ;)
Bzw. - Wenn ich schon "blöd" frag: Vllt. gibt es ja wieder mal
"huckepacks" in der nächsten Zeit. Gäbe es vllt. jemanden mit mehr
"Fingerspitzengefühl" und "Ästhetik" wie mir, der mir mein 2Kanal Gerät
umrüsten würde? Selbstverständlich gegen anständiger Bezahlung.
Hab leider keine anonyme E-Mail, aber wer evtl. Zeit für sowas hat kann
hier ja eine Möglichkeit der Kontaktaufnahme Posten :)
Beste Grüße,
Pat
Hi pat,
reinplatzen darfst du, ich habe ja ausdrücklich darum gebeten. ;-)
pat schrieb:> Werden USB-Sticks > 2GB unterstützt
Höchstwahrscheinlich ja, die VNC2 Firmware untestützt auch FAT32. Ich
kann es aber noch nicht testen da ich meinen großen Stick irgendwo
verbummelt habe.
pat schrieb:> Welche Gehäusemodifikationen muss ich vornehmen?
Wenn du ein externes 12V Netzteil verwendest, keine. Willst du den
USB-Host vom Oszi aus versorgen musst du eine kleine DC-Buchse einbauen
und irgendwo an die 12V Leitung löten.
pat schrieb:> Habe gerade keine> Vorstellung, wie die Platine in "echt" da reingehört.
In ein externes Gehäuse. Siehe o.g. Link (über deinem Post) auf den
SF-Artikel.
pat schrieb:> Vllt. gibt es ja wieder mal> "huckepacks" in der nächsten Zeit.
Wird es definitiv geben. Als Teilesatz von mir, evtl. inkl. Platine. Das
muss ich aber noch mit Bernhard klären.
pat schrieb:> Hab leider keine anonyme E-Mail,
Das ist schlecht. Ich brauche eine mail mit der Vorbestellung von dir,
sonst verliere ich den Überblick.
Mfg,
Kurt
Hi Niklas,
Niklas O. schrieb:> Nach manchen Firmwareupdates habe ich ploetzlich staerkeres> Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4)> auf den Kanaelen, insbesondere scheint das bei 1 und 2 zu sein,> wie es auch gerade wieder passiert ist. Das laesst sich bei> mir dann beheben durch Laden eines Komplettdumps vom DSO> im Auslieferungszustand von den Wittigs. Danach dann die> neue Firmware, Rauschen ist weg.
Hattest du vor dem Rückspielen der Orig-FW die üblichen "Default Setup"
und "Calibrate Offset" einmal durchlaufen lassen?
> Rainer W. hatte glaube ich auch noch nach einer Protokollbeschreibung> gefragt. Ich werde das in der naechsten Zeit mal im Wiki bei> Sourceforge dokumentieren.
Das wäre prima, eilt aber nicht. Die Quick Measure Ausgabe macht schon
wieder Lust auf mehr. Zwei Dinge fallen mir da spontan ein:
- Ausgabe mehrerer Messungen in eine Datei mit Time-Stamp, jeweils eine
Messung pro Zeile
- Automatische Ausgabe bei jedem Trigger -> eine Datei
> P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf> aus China in Stellung 1:1 eine hoehere Bandbreite hat> als die Welecs?
Von der 1:1 Messung war ich schwer beeindruckt und habe mich nur
gewundert, das die W2022 im Moment in der eBucht ohne Tastköpfe für um
die 200 über'n Tisch gehen.
Hi Kurt,
auch ich melde hiermit Interesse an. Ich bin zur Zeit nur noch
unschlüssig ob ich einen oder zwei haben möchte. Auch ich hatte geplant
das Teil ins Gerät einzubauen.
Gruß Hayo
Hallo Hayo,
hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne
Erfolg.
Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf
und dann die 3.0.
Gruß
Torsten
Niklas O. schrieb:> Nach manchen Firmwareupdates habe ich ploetzlich staerkeres> Rauschen (ich meine nicht die fiesen Spikes auf 3 und 4)
Das liegt daran, dass ich bei manchen FW-Versionen das Flash
zurücksetzen muß um neue Variable zu initialisieren. Das betrifft aber
nur die Hardwareeinstellungen und die Offsets (ADC + DAC). Dadurch wird
dann das Rauschen stärker. Da muß man nur einfach die
Hardwareeinstellungen neu machen und einmal kalibrieren - fertig.
> @Hayo:>> [Testbild]>> Man kann auch schön den Pixelfehler in der UI Plane 1 sehen.>> Oeh, Pixelfehler?
Ja, die UI_Plane1 hat einen Pixelversatz von 32 Pixeln im Videospeicher,
die am Ende (rechts) abgeschnitten werden und vorne (links) eingefügt
werden.
Das sieht man aber nur auf dem DSO, nicht im Screenshot, da im Screensh.
die Pixel korrekt wiedergegeben werden.
> Apropos, sag mal: Ganz am Anfang hatte ich das ja so gebaut> das die Layer einzeln in Dateien abgelegt wurden, so dass man> diese dann bei Darstellungsproblemen einzeln untersuchen kann.> Das ist dann irgendwann weg gefallen.>> Macht es Sinn das als Spezialfunktion wieder einzubauen?
Ja unbedingt. Das war ein Grund, warum ich solange an der BF-Version
festgehalten habe.
> Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam,> was viele unter Windows nur wegen der GERMSloader.pl bei sich> installiert haben: Besteht Interesse an einem einfachen> Flash/RAM-Loader fuer Windows als .EXE?
Ach hier ein unbedingtes ja! Denn viele etwas unerfahrene User scheuen
sich davor das Perl zu installieren.
> P.S.: Irritiert es egtl. nur mich dass der billig-Tastkopf> aus China in Stellung 1:1 eine hoehere Bandbreite hat> als die Welecs?
Ich dachte zuerst Du hättest Dich mit der Angabe der Kanäle vertan. Aber
dann stimmte das also doch! Strange!
Gruß Hayo
Torsten W. schrieb:> Hallo Hayo,> hab mal mit der Triggereinstellung etwas herumgespielt, leider ohne> Erfolg.> Als nächtes spiele ich mal das Orginaldump (wenn ichs noch finde) auf> und dann die 3.0.
Warte noch mal. Ich habe gerade die zweite Compilation fertig. Da sollte
der Fehler behoben sein, genau wie das Menüproblem im Autoscale-Menü,
das aber nur bei 2-Kanalgeräten auftritt!
Da habe ich wieder eine Altlast unseres WELEC-Programmierers gefunden
die mir bislang nicht aufgefallen war.
Gruß Hayo
Kurt Bohnen schrieb:> Hallo Hayo,> welchen Sinn hat das umkopieren der UI_Planes in die Buffer_Planes?
Da die Fortschrittsanzeige direkt in den Videospeicher geschrieben wird
aber nicht mit übertragen werden soll, kopiere ich den Inhalt des
Videospeichers vorher in die Bufferplanes und übertrage dann statt des
Videospeichers die Bufferplanes.
> Es wäre toll wenn du in alle 3 UC_ Funktionen die Fortschrittsanzeige> einbauen könntest und auch bei UC_SCREENSHOT die Änderungen bei den> Planes.
Ich habe die Fortschrittsanzeige nur in die Screenshot-Routinen
eingebaut, da die Datentransferroutinen so schnell sind, dass es hier
überflüssig ist.
> Der B/W Screenshot hat sich Plane mäßig anscheinend nicht geändert.
Hatte ich nur vergessen, da ich die B/W Funktion selbst nicht nutze -
hab ich aber jetzt nachgerüstet.
Gruß Hayo
Second compilation out now!
I'm sorry for the bugs I didn't saw in the first comp.
In der zweiten Kompilation sollten jetzt alle gemeldeten Fehler
beseitigt sein.
@Kurt
Deine Screenshot-Routinen habe ich auch erweitert.
Gruß Hayo
Hi,
@Niklas
> Das laesst sich bei> mir dann beheben durch Laden eines Komplettdumps vom DSO> im Auslieferungszustand von den Wittigs. Danach dann die> neue Firmware, Rauschen ist weg.
Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm)
modifiziert?
> Ansonsten: Da vor kurzem auch nochmal was wegen ActivePerl hochkam,> was viele unter Windows nur wegen der GERMSloader.pl bei sich> installiert haben: Besteht Interesse an einem einfachen> Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne> grossen Aufwand realisieren.
Ja, immer her damit! Mit dem Germsloader scheint es bei manchen Usern
immer noch Probleme zu geben, da wäre das eine gute Alternative!
Perl nimmt jede Menge Platz weg und es ist auch ein wenig umstandlich
mit der Installation.
Gruß Michael
auch hallo Hayo,
...hast du jetzt was am Quickmeasure gedreht?
Jetzt habe ich ohne Signal auf Kanal 1 -Pk-Pk 1,04V und auf Kanal 2
sogar Pk-Pk 1,14V !
Wenn man mal schnell was messen will, ist das schon ein bißchen viel,
oder?
Voher hatte ich so um die 160mV, schwankend...aber über 1Volt, finde ich
heavy.
Anbei mal ein Shot
LG Michael
Hallo,
@Michael:
> Wie weg? Weg ohne Filter? Hattest du die Widerstände (33 Ohm u. 150 Ohm)> modifiziert?
Ich meinte mit "weg" natuerlich das zusaetzliche Rauschen. Die
Eingangsstufen sind unmodifiziert. Auch kein Averaging oder
Noise Filter eingeschaltet.
@Hayo, Rainer:
Default-Setup habe ich gemacht. Calibrate Offset benutze ich
dauernd da der GND-Level staendig wegdriftet.
Ich habe gerade mal gemacht was ich beschrieben habe, das Ergebnis
seht ihr in den Screenshots. Der Unterschied ist minimal. Vllt.
haengt es auch gar nicht damit zusammen. Ich hatte das vor laengerer
Zeit aber schonmal heftiger. Ob ich davor wirklich Firmwareupdate
gemacht habe weiss ich nicht mehr. Insgesamt hab' ich die Prozedur
auch erst 2-3mal gemacht.
Niklas
> Besteht Interesse an einem einfachen> Flash/RAM-Loader fuer Windows als .EXE? Das liesse sich ohne> grossen Aufwand realisieren.
Wäre gut.
Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der
org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout
ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann
aber doch noch durch.
Ein Aufspielen der 1.2.BF.3.0 Flash war überhaupt nicht machbar, so ab
7% war immer wieder Schicht.
Mir z.Z. unverständlich, die Ram-Version konnte ich aber einwandfrei
uploaden und sie funktionierte.
Das Skope bootete jetzt aber nicht mehr in die alte Version, ein paar
Zeilen waren ja bereits überschrieben. Nichts ging mehr. Nach etlichen
weiteren vergeblichen Anläufen mit dem GERMSLoader die Flash-Variante
doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser
spielte, zum Glück, die TomCat.flash ein.
Zu evtl. Fehlern in dieser Version kann ich nichts sagen, dazu fehlt mir
im Moment noch die Erfahrung mit dem Gerät.
Hayo W. schrieb:> Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation> bedauerlicherweise doch noch etliche Zinken drin waren.
Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern.
Niklas
Torsten W. schrieb:> Hallo Hayo,> die C2 funktioniert nun auch bei mir bestens. Herzlichen Dank auch!> Woran lag es das das gerätespezifisch war?
Beim Autoscale Menü lag es daran, dass für die 2-Kanalgeräte bestimmte
Menüeinträge bei der Initialisierung geändert werden (z.B. werden bei
den Sourcen Kanal 3 + 4 gelöscht weil nicht vorhanden). Dabei hat der
WELEC-Programmierer aberr nicht aufgepasst und mittels Bufferoverflow
Werte in benachbarten Speicherbereichen überschrieben.
Bei der Kalibrierung war es nicht geräteabhängig sondern eher
zufallsbedingt. Ich hatte bei den Leseroutinen nur einige Kleinigkeiten
"optimiert". Da bei mir der Fehler nicht auftrat hab ich natürlich auch
nicht weiter gesucht.
Durch Deinen Beitrag bin ich aber dann drauf gestoßen, dass ich da einen
Fehler eingebaut hatte.
Gruß und danke
Hayo
Niklas O. schrieb:> Hayo W. schrieb:>> Ich hoffe Du die neue 3.0 C2 eingespielt, da in der ersten Compilation>> bedauerlicherweise doch noch etliche Zinken drin waren.>> Meinst Du mich damit? Das war nicht die C2, noch die 3.0 von gestern.
Nein ich meinte stone.
Aber auch Dir sowie allen Anderen würde ich empfehlen die C2 zu
verwenden und nicht mehr die erste Kompilation. In SFN habe ich die auch
schon gelöscht, hier geht das leider nicht.
Gruß Hayo
stone schrieb:> Ich hatte große Schwierigkeiten mit dem GERMSLoader ein Backup der> org-Firmware zu erstellen. Die Verbindung brach dabei x-Mal mit Timeout> ab. Irgendwann, ich kann nicht mehr nachvollziehen warum, lief es dann> aber doch noch durch.> [..]> doch noch hochzuladen, probierte ich endlich den WelecUpdater. Dieser> spielte, zum Glück, die TomCat.flash ein.
Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler?
Klingt fuer mich mehr nach Problem mit Verbindung als dass der
GERMSLoader etwas falsch macht. Probier mal nen anderes und
kuerzeres Kabel.
Den WelecUpdater hab' ich als episch langsam in Erinnerung. Ich
weiss nicht was der da veranstaltet, wenn er das aber saulangsam
rueberschiebt erklaert das dann vielleicht dass es mit dem bei
Dir funktionierte.
Niklas
Aber mal was ganz Anderes.
Ich habe um ein neues Akkuladegerät auf korrekte Funktion zu testen mal
eine Ladekurve aufgezeichnet.
Probant war ein 1,2V Mignon Akku. Man sieht schön die Entladekurve in
den ersten drei Divs, dann die Ladekurve und zum Schluß die
Erhaltungsladung nach dem Delta U Buckel. Die Spannung die da vom Cursor
angezeigt wird stimmt natürlich nicht. Der untere Cursor liegt bei ca.
1V der obere bei ca. 1,6V.
Ergebnis Ladegerät funktioniert - und das DSO auch ;-)
Gruß Hayo
> Mhm, was fuer ein Kabel verwendest Du? USB-seriell-Wandler?> Klingt fuer mich mehr nach Problem mit Verbindung als dass der> GERMSLoader etwas falsch macht. Probier mal nen anderes und> kuerzeres Kabel.
Ist ein normales RS232 Kabel von meinem AVR STK500 Board an einer RS232
Schnittstelle. Damit gab es bisher keine Probleme. Aber das es an dem
Kabel liegt ist trotzdem nicht auszuschliessen. Ein Gegentest ist z.Z.
nicht möglich da ich leider noch kein andres habe.
Mich wundert dann aber warum es mit der .ram ohne Probleme funktioniert.
Mit dem Welec-Updater habe ich grad die C2 raufgespielt. Stimmt, es ist
damit langsam, hat aber funktioniert.
Nur z.Info, die Versuche liefen mit:
WinXP Pro SP3
ActivePerl 5.12.3 Build 1204
und Win32-SerialPort-0.22.
@Niklas
ich habe mal bei mir das Rauschen analog zu Deinem Screenshot getestet.
Nach dem Kalibrieren liegen die Werte im gleichen Rahmen (so um 6mV).
Hat also wohl eher nichts mit dem Rückspielen des Flashs zu tun denke
ich.
Gruß Hayo
Hallo Hayo,
mit der aktuelen BF 3.0 C2 bin ich bei der inversen Erfassung mit Kanal
1 auf ein sehr merkwürdiges Feature gestoßen. Zum Vergleich liegt das
selbe Signal am normal dargestellten Ch2.
Am linken Rand taucht ein falscher Wert ("Flanke") auf (Bild:
Messung...) und wenn man auf STOP geht und das Anzeigefenster nach
rechts verschiebt, kommen merkwürdig nach unten versetzte Daten ins Bild
(Bild: Pan_...).
Eingangssignal ist Probe Comp (passiert aber genauso mit anderen
Signalen). Wenn man dagegen Ch2 invertiert, ist alles gut. :-)
Gruß
Rainer
p.s. Die Screenshots wurden mit w2000a-screenshot 0.97 erstellt und
nicht nachbearbeitet - sicher ist sicher. ;-)
@Hayo,
denke bitte daran mir die mail wegen dem USB-Host zu schicken. ;-)
Ich wollte gerade die neuesten Änderungen in meine Firmware übernehmen.
B/W funktioniert aber nicht richtig. Da schon in der UC_SCREENSHOT_BW()
die Schwarz/Weiß Werte zusammengebaut werden vermute ich den Fehler
dort.
Die Gegenprobe mit dem screenshot zum PC scheitert leider daran:
1
- Receiving a monochrome screenshotError: screenshot data version newer on DSO than known here in receive_screen(), exiting.
hmpf,
> Nein, da war ich nicht dran. Hast Du Dein Gerät hardwaremäßig richtig> eingestellt und auch kalibriert?
kennst mich doch, mach das jedes mal, auch resette ich das Teil mehrmals
bevor ich pöpel!
Wie sieht's denn bei den Anderen so aus?
Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active
Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die
Einstellungen für die 24 u. oder 33 Ohmler?
Zum Germsloader über die RS232 Schnittstelle: Ich selbst habe Win XP auf
dem Lappi sowie auf dem Hauptrechner Athlon Phanom 9500, SP2(Laptop) SP3
(Athlon) funzt mit der eingebauten RS232 sowie mit dem Adapter(FTDI)!
Wichtig sind die Comport-Einstellungen!!! Diese müssen oder sollten
immer überprüft werden, d.h. 115kb , Datenbits=8, Parität=non(keine),
Händshake(Flussteurung)= none(keine), Stopbit=1
Hat mal ein Gerät darauf zugegriffen, kann es vorkommen, daß der Port
nicht, oder noch nicht freigegeben ist, dann zickt das Ganze und man muß
den Rechner komplett neu hochfahren!!!
Das sind jetzt meine Erfahrungen, die ich hier weiter gebe kann.
...habe bis jetzt jedes Miststück zum laufen gebracht, unter Anderem
auch das LEON3 Design! Wie ist denn da eigentlich der Fortschritt? Das
was ich bisher aufgespielt hatte, war schon sehr beachtlich, schade,
wenn das einschlafen würde...
Gruß Michael
Hi Hayo, Niklas O. and all!
I take just peeping through, I am in a hurry, so apologize me.
First:
@Hayo and all who involved in the Welec project:
I installed the new 1.2.BF.3.0_C2 release and I'm trying it.
I have few time and I was able to give only a superficial glance, but
this new release seem to me very, very impressive!!!
Modifications and improvements are so many and such that I make it hard
to use the oscilloscope.
It is as if I were using a new DSO and I have to read the instruction
manual for understand how to use it.
Options and settings are significantly increased compared to a few
previous versions, have been added feature that I couldnt even imagine
could be implemented in the Welec DSO!!!
The DSO seem me to be more fast and especially for me now it is less
noisy, a lot less noisy!!!
Then the calibration is now super precise than ever on mine W2022A and
W2012A.
For me also the trigger behavior is better now.
I repeat, very, very impressive!!!
Over the weekend I'll try to find time to do some testing instrument.
That said, Hayo and all who involved I thank You very, very much for
this new jewel, I have no words, RESPECT, RESPECT, RESPECT!!!
Niklas O. schrieb:
>Wo Du Tastkoepfe erwaehnst... Wegen eines Analogoszis hab' ich>kuerzlich nen "100 MHz" Tastkopf aus China von Dealextreme bestellt.>Der ist vor ein paar Tagen eingetroffen, und, da ich dem "100 MHz">Sticker nicht traue und es Angaben bzgl. Anstiegszeig/BW in Stellung>x1 und x10 schlicht nicht gibt, hab' ich diese doch gleich kurz mal>mit den Original Welec "200 MHz" grob am Rechtecksignal des DSO>verglichen.>>Resultat seht ihr in den Screenshots. Kanal 2 ist der 6 USD>(inkl. Versand) Tastkopf. Die Traces sind etwas verschoben,>da ich den Versatz nocht nicht wieder ueber die Delays im>Utility-Menue kompensiert habe. Man sieht's aber auch>"mit blossen Augen" ohne Cursor recht gut ;)
About this I tried with the W2012A probe in CH1 and W2022A probe in CH2
of my W2012A (screenshoot 1) and then I exchanged them in the channels
(screenshoot 2), both are set x1 so like also the DSO's channels:
W2012A's probe win on the W2022A.
The square wave is the inner DSO probe calibrator and both probes are
correctly matched.
I have to investigate further, I have to try with the W2022A.
Now I run away.
Hayo again many thanks to You and all, really thanks very much to all
You!!!
Vielen Dank!!!
Luc
Hallo Kurt,
hab es schnell noch mal gerichtet. Die UI Planes 3 + 4 dürfen nicht mit
übertragen werden, da sie die anderen Planes überdecken.
Weiterhin habe ich das Übertragungsprotokoll für B/W an die neueste
Version angepasst - sollte also keinen Abbruch mehr geben.
Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei
das korrigierte Coding und die Kompilation 3.
Gruß Hayo
Hayo W. schrieb:> Oha, das ist ja merkwürdig.> Da muß muß ich wohl mal ran.
Vielleicht war das Problem doch vor dem Oszi und du mußt da nicht noch
mal ran. Mein letztes "Default Setup" war vor dem Einspielen der 3.0 C2.
Nachdem ich das jetzt nachgeholt habe, benimmt sich auch der invertierte
Kanal 1 anscheinend richtig.
Dafür bin ich drauf gestoßen, dass bei im Single Shot mit Einstellung
"Invert" erfaßten Signalen das Invertieren anscheinend auf allen Kanälen
ignoriert wird. Beim STOP, wo der gleiche Effekt auftrat, hattest du das
ja schon repariert.
Gruß Rainer
Hayo W. schrieb:> Ergebnis der aktuellen Änderungen siehst du auf den Screenshots. Anbei> das korrigierte Coding und die Kompilation 3.
Super. Danke!
Gute Nacht.
Moin Hayo,
Hayo W. schrieb:> Oha, das ist ja merkwürdig.> Da muß muß ich wohl mal ran.
Gestern Abend war es wohl doch schon etwas spät.
Langer Rede kurzer Sinn: Der Fehler mit den falsch dargestellten
invertierten Daten beim Pan ist doch echt und betrifft alle 4 Kanäle in
gleicher Weise, was schon mal beruhigend ist.
Reproduzieren läßt sich das (jetzt mit BF 3.0 C3) wie folgt:
ProbeComp an Ch1..4 - Default Setup - Autoscale -
AutoPreTrigger "Trace Middle" - Invert Ch1..3 (Bild Mess...) - STOP -
Pan nach links oder rechts (Bild Pan...)
bringt dann falsche Daten zur Anzeige.
Das Ding mit der normalen Darstellung eines invertierten Kanals beim
Single Shot sieht man ebenfalls mit obigen Einstellungen. (Bild
Single...)
Für die ScreenShots habe ich Ch4 als Referenz nicht invertiert, der
Effekt tritt dort aber genauso auf.
Gruß
Rainer
Hallo Rainer,
das Problem sitzt nicht vor dem Gerät. Es ist tatsächlich ein Fehler,
den ich auch schon gefunden habe. Auch die Lösung habe ich mir schon
überlegt. Leider ist es ein grundsätzliches Problem und die Lösung
erfordert einen etwas größeren Umbau. Bin ich aber dran...
Gruß Hayo
@Michael
> man muß den Rechner komplett neu hochfahren!!!
Das kann es sein!
Ich hatte nur die Schnittstelle im Gerätemanger ausgetragen und dann
neue Hardware suchen lassen. Auf die Parameter habe ich geachtet.
Ich reiche mal den Fix für den Invertion Bug nach.
Es gibt da zwei Lösungsansätze. Zum Einen die einfache Lösung die
Performance kostet aber gut und problemlos funktioniert, zum Anderen die
aufwändige und auch fehlerträchtigere Variante die aber deutlich
performanter ist.
Ich habe erstmal die langsamere Lösung eingebaut um auf die Schnelle
eine fehlerfreie Lösung biten zu können. An der Optimierung arbeite ich
dann in der nächsten Zeit.
Gruß Hayo
Hayo W. schrieb:> Ich reiche mal den Fix für den Invertion Bug nach.
Das ging ja fix mit dem Fix.
Wenn du an der optimierten Lösung arbeitest, hast du dann ein Auge auf
das letzte Byte am Ende vom Speicher, dass im Moment bei invertierten
Kanälen im Display als unschöner Spike erscheint, wenn man das Fenster
ganz nach rechts schiebt. (Ch1 im Anhang)
In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte
w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die
Zusammenarbteit mit dem Argument:
" - Receiving trace...
* Receiving parameters...Error: trace parameter format newer on DSO
than known here in receive_trace(), exiting."
verweigert.
Und noch etwas (wahrscheinlich aber bekannt): Die großen Spikes auf
Ch3/4 scheinen immer synchron zu kommen.
Schönes Wochenende
Gruß
Rainer
Hallo Rainer,
> In den CSV-Daten konnte ich mir das nicht ansehen, weil die letzte> w2000a-screenshot 0.97 beim Drücken von "Save CSV" oder "Save ASCII" die> Zusammenarbteit mit dem Argument:>> " - Receiving trace...> * Receiving parameters...Error: trace parameter format newer on DSO> than known here in receive_trace(), exiting.">> verweigert.
die Header-Groesse die das DSO dem Programm uebermittelt ist
um ein Byte zu klein. Als Version liest es jetzt den
Index des Pretriggers. Wie das jetzt zustande kam weiss ich nicht.
Ob mein letzter Patch gg. Firmware von mittlerweile anno dazumal,
versionsgeschichtlich gesesehen, schon den Fehler hatte oder
zwischendurch noch was geaendert wurde weiss ich nicht, ist
aber auch egal.
Workaround, ohne Firmware neu zu kompilieren, waere nen
para_len++; in receive_trace() vom Screenshotprogramm vor
dem malloc().
Niklas
Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der
jetzt korrekt unterstützt, auch auf Kanal 3+4?
Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren
Rand. Kanal 1+2 sind OK.
Kurt Bohnen schrieb:> Was war eigentlich der letzte Stand bezüglich des DAC LTC2602? Wird der> jetzt korrekt unterstützt, auch auf Kanal 3+4?
Wird komplett unterstützt, automatisch!
> Die Nulllinien kleben bei mir immer am oberen, manchmal auch am unteren> Rand. Kanal 1+2 sind OK.
Dann ist beim Einlöten was schiefgelaufen.
Hayo
Hayo W. schrieb:> Dann ist beim Einlöten was schiefgelaufen.
Stimmt. Ein Pad hatte kein Zinn angenommen. Ich hätte nicht nur per
Lupe, sondern auch per Mikroskop kontrollieren sollen.
Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet
wie du. ;-)
Niklas O. schrieb:> Workaround, ohne Firmware neu zu kompilieren, waere nen> para_len++; in receive_trace() vom Screenshotprogramm vor> dem malloc().
Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich
ist Hayo mit dem nächsten Update aber wieder schneller. ;-)
Rainer
Kurt Bohnen schrieb:> Dafür habe ich aber die alten LTC2612 nicht so bestialisch geschlachtet> wie du. ;-)
Na prima, was machst Du jetzt damit? Klebst Du Ihn in einen Bilderrahmen
und hängst eine Lupe daneben damit man ihn sich ansehen kann? ;-)
Übrigens gehe ich immer nach dem Motto vor: Für eine gute Sache muß man
auch mal Opfer bringen!
Den zweiten hab ich übrigens heil raus gekriegt, aber was ich damit
machen soll weiß ich auch nicht...
Gruß Hayo
Rainer W. schrieb:> Danke für den Tip. Das läßt sich vielleicht hinkriegen. Wahrscheinlich> ist Hayo mit dem nächsten Update aber wieder schneller. ;-)
Ich arbeite dran :-)
Hayo
Gute Sonntag Hayo and guys all!
@Hayo and all who involved in the Welec project:
I installed the new 1.2.BF.3.0_C4 release and I played with it.
For the way I use the DSO I have not found defects, the new
1.2.BF.3.0_C4's release works like a charm.
It is fast, stable and for me it is also a lot less noisy and much more
precise.
Even AUTO SCALE works well, but I must point out something perhaps
already You know.
As usual, I specify that this report is not intended as a critique of
the good work You Hayo and all who involved in the project have done,
but only like a remark.
In most cases the AUTO SCALE works very well, quickly and accurately,
but the signals in a particular range of frequencies are displayed
incorrectly.
I tried with my RF sine wave generator and for example with 80MHz, 25MHz
and 12.5 MHz frequency's signals I got the screenshots You can see.
This actually is not much of a problem, You can fix it by manually
adjusting.
I must stress that AUTO SCALE's function in previous releases never
worked so well, so even like it is now it still a huge leap forward from
the original Welec/Wittig's implementation!
So Hayo and all who involved I thank You a lot for this new bug fix
release that make me happy in the DSO usage, again I have no words,
RESPECT, RESPECT, RESPECT!!!
Good also for Grid Intensity / Grid Color and Quick Print menu.
Very well and much impressive the Auto Pretrigger / Pre Trigger Setup
and Manual Trigger / Single Trigger Setup menu where settings's number
and improvements are so many and such that them are not commonly
available even in high-end DSO!
In the end just one last thing, I did not understand how use the "Send
Measure" button, how it work?
Vielen Dank!!!
Gruß Luc
Wie versprochen,
Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder.
@Luc
Thanks for Your detailed report. I will check it!
>In the end just one last thing, I did not understand how use the "Send>Measure" button, how it work?
When using the Cursor or Quick Measure function there are displayed
additional values on the screen. These values are sent to a file if You
push the Send Measure button. This is working only with activated
cursors!
Gruß Hayo
Hi Hayo,
die inversen Signale sehen ja jetzt aus wie eine eins. Da habe ich mit
meiner Bemerkung doch deinen Ehrgeiz geweckt. Die Bemerkung war aber
nicht als Aufforderung gemeint, jetzt sofort den Compiler anzuschmeißen.
Ich hoffe, du hast das nicht falsch verstanden.
Vielen Danke
Gruß
Rainer
Nein nein, Du muß jetzt kein schlechtes Gewissen haben. Aber so ein
Fehler in der Firmware ist wie ein unausgedrückter Pickel.
Irdendwie muß man da ran und das beseitigen ;-)
Davür gebe ich mir jetzt auch die Badewanne - verdienterweise.
Gruß Hayo
seht ihr irgendwie eine Möglichkeit den Spannungsabfall an einem Shunt
über 2 Kanäle zu messen (also Kanal 1 vor dem Shunt und Kanal 2 nach dem
Shunt) und am Oszi dann eine Stromkurve anzuzeigen?
Guten Abend Hayo and guys all!
Hayo W. schrieb:
>Wie versprochen,>>Pixelfehler bei Invertion behoben, .csv funktioniert auch wieder.
Hayo, super danke für blitzschnelle Updates!!!
Klasse!!!
Hayo You really are tireless and very kind, so thanks You very, very
much Hayo for the great job and free time You provided generously to
us!!!
I immediately installed the newest 1.2.BF.3.0_C5 version.
For me the problem with the INVerted channels is solved, thank You,
really thank You very much Hayo!!!
RESPECT!!!
However, at the risk of appearing rude, I would like to point out one
thing.
I do not know if it also happened with previous versions, I do not even
know if it happens only with my DSO.
But I have noticed that when I activate the INV's function then the
tracks suffer from a certain offset, especially in my case the CH2.
Please look at the screenshot.
The two images refer to the CH1 and the CH2 shorted to GND.
The NORMAL image shows the tracks that are superimposed on the zero
line.
The INV image shows the tracks set to INVerted mode that are not on the
zero line, especially the CH2's track even if also CH1's track is a
little bit raised by the zero line.
The oscilloscope was switched on for about 2 hours and it had reached
thermal equilibrium when I made the two screenshots
As usual this my report is not intended as a critique but only like a
remark.
@Hayo, @Niklas O.
Hayo, really thank You very much for your kind explanation about the
"Send Measure" function.
Now I understand and I must to say it is a very usefull function.
Of course I also thank Niklas O. for it because if I am not wrong, He
has suggested it.
So, Niklas O. RESPECT!
Vielen Dank!!!
Gruß Luc
bin jetzt heute erst dazu gekommen habe jetzt die 3.0_C5 drauf, die
Fortschrittsanzeige ist echt klasse. Bin auch der Meinung das die
Anzeige noch einen Tick schneller geworden ist.
Mir ist noch ein Fehler aufgefallen, kurze Beschreibung: Ich habe im
Singlemodus auf die ansteigende Flanke getriggert, Pretrigger ist egal
hatte verschiedenen Werte zw. 200 nSek und 4µSek(Standart) ausprobiert.
Alle paar Messungen hat man diese negativen Spikes auf Kanal 1. Auf dem
nicht mal ein Tastkopf angeklemmt war.
Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich
habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel
Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit
wäre doch absolut ausreichend.
Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich
fände es gut wenn man die Übertragenen Dateien in einen festgelegten
Ordner speichern könnte. Im Moment ist es ja so ich lade mir eine neue
Firmware runter entpacke sie und es wird ein neues Verzeichnis erstellt,
wenn ich jetzt die dazugehörige Screenshot.exe aus diesem Verzeichnis
starte landet das Bild in diesem Verzeichnis. Beim nächsten
Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht
könnte man das Programm so gestalten das es eine Systemvariable
durchsucht und sich dort ein festgelegtes Verzeichnis ausliest.
Mit Systemvariable meine ich z.B. die Festlegung wie
temp=C:\TEMP
tmp=C:\TEMP
SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot
so wäre es egal aus welchem Verzeichnis ich die Screenshot.exe aufrufe
oder welche Version sie hat, die Shots landen immer im vorgegebenen
Verzeichnis.
Thomas O. schrieb:> Firmwareupdate dann wieder in einem anderen Verzeichnis. Vielleicht> könnte man das Programm so gestalten das es eine Systemvariable> durchsucht und sich dort ein festgelegtes Verzeichnis ausliest.
Hi Thomas,
mit der -f option geht das Abspeichern von Screenshot in einem festen
Verzeichnis auch ohne Systemvariable.
Beispiel für den Aufruf, um unter Windows die Dateien in C:\bilder
abzuspeichern, wäre z.B.
w2000a-screenshot.exe -a -f c:\bilder\
Gruß
Rainer
Hello,
Luc schrieb:> About this I tried with the W2012A probe in CH1 and W2022A probe in CH2> of my W2012A (screenshoot 1) and then I exchanged them in the channels> (screenshoot 2), both are set x1 so like also the DSO's channels:> W2012A's probe win on the W2022A.> The square wave is the inner DSO probe calibrator and both probes are> correctly matched.
This is especially strange because according to the
specs that came with the Welec probes, the 100 MHz and 200 MHz
versions should both have the same rise time/bandwidth on
1:1. The 200 MHz probe seems to perform poorly. I don't
have the means to fuly measure the 1:10 bandwith, but I strongly
suspect it isn't quite 200 MHz as advertised.
I don't have the Welec probes spec sheet at hand at this moment,
I will have to scan and upload it at a later time.
Niklas
Hallo,
Thomas O. schrieb:> Zu der Übertragung der BMP. Ich finde die Dateigröße sehr groß also ich> habe es gerade als PNG umgewandelt aber als BMP ist die 640x480 Pixel> Datei 901kb groß. Kann man hier die Farbtiefe begrenzen? Denke 4 Bit> wäre doch absolut ausreichend.
Ja, 4 Bit mit Palette waere ausreichend. Der Grund, warum das
Screenshot-Programm aus den proprietaer RLE komprimierten Daten,
die das DSO sendet, ueberhaupt BMP macht, statt das fuer diese Anwendung
praedestinierte PNG-Format, ist allein, dass dies der einfachste Weg
ist.
BMP, PPM und so weiter sind sehr einfach ohne Hinzunahme von externen
Libraries usw. zu schreiben.
Ich hab' mir nicht angesehen, in welcher Groessenordnung es
Aufwand waere 4-bittige BMPs zu schreiben, dennoch halte ich das
fuer einen Schritt zu kurz. Die Dateien waeren immer noch 150kB
gross, satte 145kB groesser als noetig. Wenn, dann sollten wir
eine Loesung ueber externe passend lizensierte Libraries suchen und
konsequent PNG schreiben.
> Dann habe ich noch einen Wunsch bezüglich des Screenshot Programms. Ich> fände es gut wenn man die Übertragenen Dateien in einen festgelegten> Ordner speichern könnte. [..]
Wie Rainer auch schon schreibt gibt es genau dafuer den Schalter -f.
> Mit Systemvariable meine ich z.B. die Festlegung wie> temp=C:\TEMP> tmp=C:\TEMP> SCREENSHOT=C:\Eigene Dateien\Thomas\Bilder\Screenshot
Systemvariablen, wie geht man da unter Windows eigentlich mit um?
Soweit ich weiss muss man da unter Windows auf "My Computer" rechts
klicken, dann "Properties", dann im neuen Fenster auf den Reiter
"Advanced" wechseln, dort dann "Environment Variables" anklicken
und im neuen Fenster kann man dann endlich den Kram setzen.
Was ich sagen will: Zu kompliziert. Angesichts dessen, dass
ich, wie schonmal angedeutet, in Zukunft plane, auch eine
Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit
den Standort dieser irgendwie global festzulegen. Unter
unixoiden Betriebssystemen ist btw. systemweit /etc und per-User
in Dotfile unter ~/ bzw. in ~/.config/ Standard.
Vorschlaege?
Niklas
Luc schrieb:> I do not know if it also happened with previous versions, I do not even> know if it happens only with my DSO.> But I have noticed that when I activate the INV's function then the> tracks suffer from a certain offset, especially in my case the CH2.
Hi Luc,
the offset of inverted signals is not specific to your DSO. To me it
looks like a gain error. The offset depends on the position of the
trace. Traces at the top don't show any offset, those at the bottom do.
I am confident Hayo will catch it.
Gruß
Rainer
Niklas O. schrieb:> Was ich sagen will: Zu kompliziert. Angesichts dessen, dass> ich, wie schonmal angedeutet, in Zukunft plane, auch eine> Konfigurationsdatei zu benutzen, suche ich noch nach ner Moeglichkeit> den Standort dieser irgendwie global festzulegen. Unter> unixoiden Betriebssystemen ist btw. systemweit /etc und per-User> in Dotfile unter ~/ bzw. in ~/.config/ Standard.
Hi Niklas,
unter Windows gibt es z.B. die vordefinierte Environmentvariable
"APPDATA" die auf das Verzeichnis "Anwendungsdaten" des Benutzers zeigt.
Mit C kommt man an den Pfad vermutlich über Aufruf von getenv("APPDATA")
dran. Die Alternative wäre ein Eintrag in der Registrierdatenbank.
Gruß
Rainer
Hi Niklas O., Rainer W. and guys all!
Niklas O. schrieb:
>This is especially strange because according to the>specs that came with the Welec probes, the 100 MHz and 200 MHz>versions should both have the same rise time/bandwidth on>1:1. The 200 MHz probe seems to perform poorly. I don't>have the means to fuly measure the 1:10 bandwith, but I strongly>suspect it isn't quite 200 MHz as advertised.
In the parallel to the 1Mohm oscilloscope input impedance there are for
example, 30pF (the value is written on the oscilloscope) and even in
parallel you still have the capacitive value of the cable (such as
another hundred of pF).
Do not put any attenuation, this total capacitive value will in parallel
with the voltage to be measured.
To reduce the capacitive load (cable + oscope), the first thing you can
think is to put an R in series, for example a 9Mohm, so the measured
circuit sees a more high impedance and the signal is divided by 10.
But this only works in DC.
In AC, the two R and two capacitors form a low pass filter that cuts to
about 1.4 Mhz.
To extend the system bandwidth (ie to put on the oscilloscope a tension
that is 1/10 of what is measured with the probe even at high frequency)
it must be put in parallel to the 9Mohm R a capacitor of 130 pF divided
by the ratio of resistors (9 in this case).
In this way a capacitor of about 15pF removes the low-pass effect and
the probe can work until at frequencies far greater (about hundreds of
megahertz).
The 9Mohm R and the compensation capacitor are in the probe.
To fix the exact capacitive ratio's values (which must be equal to that
of the resistors), need somewhere to put a small variable capacitor with
which to calibrate the tolerances that may to exist.
If instead of divide by 10 should be divided by 100, the values become
99Mohm and 1.5 pF: this explains why often the probes that go (were) to
more high frequency had an attenuation of 100:1 and so why the x1 probes
have a frequency response limited compared to the x10 probes.
Said that, perhaps the behavior of the W2022A probes is caused from an
incorrect setting of the second trimmer.
In fact, according to the instructions of my analog oscilloscope probes
(they are x10 probes with a 300Mhz bandwidth), they must be tuned by a
1Khz and 1Mhz square wave with not more than 4ns's rise time.
In my case the problem may depend on this but I must investigate
further.
I will try to use the W2022A probes that are credited as 200Mhz
bandwidth on my 150Mhz analog oscilloscope who is provided with 300Mhz
probes and which has a suitable calibrator for calibration.
However, the probes provided by Welec / Wittig with the W2012A are the
same as those provided by LeCroy with its WaveAce series DSO.
I'm sure because I use them where I work.
Niklas O. schrieb:
>I don't have the Welec probes spec sheet at hand at this moment,>I will have to scan and upload it at a later time.
Me too I have not the data sheet handy.
I think it would be useful and interesting.
Thanks in advance Niklas O.
Rainer W. schrieb:
>the offset of inverted signals is not specific to your DSO. To me it>looks like a gain error. The offset depends on the position of the>trace. Traces at the top don't show any offset, those at the bottom do.>I am confident Hayo will catch it.
Thank You very much for the useful information and explanation Rainer
W.!
I hope someone can fix the problem.
Vielen Dank!!!
Gruß Luc
Hello Luc,
the entire "operator's manual" for the probes is attached. According
to it, the rise time on x1 should be 23.3ns for both types of probes.
> Said that, perhaps the behavior of the W2022A probes is caused from an> incorrect setting of the second trimmer.
Since there's no description how to use those I never touched them.
(I've got two seperate ones in the box near the BNC.)
The attached manual contradicts itself, it mentions that the
input capacitance can be compensated "Within the box cover located
near the BNC (W202 Probe)", but on the next page under
"Compensation and Adjusting the Probe" it explicitly tells to
compensate with the trimmer on the body of the probe. It fails
to mention that the probe needs to be put into 1:10 divider.
Niklas
Hi Luc,
the INV-offset is the result of the combination of the DAC-scale factor
and screen drawing scale factor. It has to be adjusted more precisely.
But this is not so easy because of thermal drift and differences between
the DSOs.
If You want to measure precisely You have to center the trace in the
screen middle. In this positon there are no offsets because it is the
virtual zero.
Regards Hayo
@Niklas
Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot:
Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die
aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht
implementiert.
Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern
in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine
recht schnelle Sache.
Man müßte nur das Flag mit if (USTB_Mode != USTB_OFF) abfragen und dann
anstatt des normalen Signalspeichers den USTB-Speicher übertragen.
Die übertragene Länge wird jetzt ja schon zwischen 4K und 16K
unterschieden. Käme noch 600 hinzu.
Was sagst Du?
Gruß Hayo
Hallo Hayo,
Hayo W. schrieb:> Ich hätte noch mal einen Wunsch bzw. Vorschlag zum Screenshot:>> Bei der Aufnahme meiner Akku-Ladekurve hätte ich mir gerne die> aufgezeichneten USTB-Werte runtergeladen. Das ist aber momentan nicht> implementiert.>> Im USTB-Modus liegen die Werte nicht im normalen Signalspeicher, sondern> in einem separaten USTB-Speicher. Es sind 600 Werte (Bytes), also eine> recht schnelle Sache.> [..]> Was sagst Du?
Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die
Aufnahme ueber noch laengere Zeitraeume interessant, also sowas
was ein Trace Recorder macht. Es gibt da z.B. Leute die ueber
Tage hinweg Daten von einer Heizungsregelung loggen. Bei einem
4-Kanal Geraet kann das durchaus schon interessant sein.
Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme
an die 600 Werte sind im Moment zugleich das Maximum was gespeichert
werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue
Werte ueberschrieben?
Hier koennte man zum einen die Werte direkt "Realtime" mit dem
Screenshot-Programm aufzeichnen lassen, zum anderen muesste doch
auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen
im Flash abzulegen und am Ende abzurufen?
Mein Plan sieht nun wie folgt aus:
- zunaechst Flash-Upload-Programm fuer Windows erstellen mit
minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich
nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen
erweitert werden
- im Screenshot-Programm:
- kontinuierliches Loggen von den Measurement-Daten
- USTB-Speicher download
- Evaluation bzgl. direktes Speichern als PNG
- Dokumentation Uebertragungs-Protokolle
(in absteigender Prioritaet)
Niklas
Niklas O. schrieb:> zunaechst Flash-Upload-Programm fuer Windows erstellen mit> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen> erweitert werden
Warum war der Welec Updater so langsam, kann man den nicht
beschleunigen?
Niklas O. schrieb:> - Evaluation bzgl. direktes Speichern als PNG
Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei
BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
ja wenn die Konfigurationsdatei global festgelegt wird wäre das super.
Sonst muss man immer die config.ini vom alten ins neue
Screenshot-Verzeichniss verschieben oder die Screenshot.bat jedesmal um
das eigene Verzeichniss ergänzen. Es wäre wünschenswert diese Globale
festlegung ändern zu können da nicht jeder mit den Standart APPDATA
Verzeichnissen arbeiten. Meine Eigenen Dateien sitzen z.B. auf einem
2ten Laufwerk.
Niklas O. schrieb:> - Evaluation bzgl. direktes Speichern als PNG
Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng
Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich,
um direkt die PNGs abzuspeichern.
http://netpbm.sourceforge.net/
Gruß
Rainer
Kurt Bohnen schrieb:> Niklas O. schrieb:>> zunaechst Flash-Upload-Programm fuer Windows erstellen mit>> minimaler GUI (File-Open Dialoge usw.), erst einmal wirklich>> nur Upload-Funktion, kann dann spaeter um Download/Backup-Funktionen>> erweitert werden> Warum war der Welec Updater so langsam, kann man den nicht> beschleunigen?
Wir sprechen doch von dem Ding der Wittigs, oder?
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload
Da steht auch was von 25 Minuten. Ich hab' das Wittig-Ding
zuletzt Anfang 2009 oder so gearbeitet, also kurz nachdem
ich mein Scope bekam.
Haben wir davon ueberhaupt den Sourcecode?
> Niklas O. schrieb:>> - Evaluation bzgl. direktes Speichern als PNG> Auch BMPs haben eine Lauflängenkodierung. Die funktioniert nur nicht bei> BottomUp-BMPs. Das sollte aber für den PC-screenshot kein Problem sein.
Ja, das habe ich mir auch noch nicht angesehen. Ich weiss nicht,
wie effizient die wirklich ist. Ein kurzer Versuch in Gimp mit
Reduzierung auf 16 Farben Palette und RLE zugeschaltet bringt mir
ein File mit 36kB Groesse. Ob das noch mit zu rechtfertigem
Aufwand zu Fuss gemacht werden kann, oder man da besser eine
externe Library nimmt, muss ich schauen.
Notieren wir also mal "Evaluation BMP mit optimierter Palette u. RLE"
in meine ToDo-Liste.
Niklas
Thomas O. schrieb:> ja wenn die Konfigurationsdatei global festgelegt wird wäre das super.> Sonst muss man immer die config.ini vom alten ins neue> Screenshot-Verzeichniss verschieben
Hi Thomas
man kann doch einfach eine Batch-Datei irgendwo ablegen, in der eine
einzige Zeile mit dem aktuellen Screenshot Programmverzeichnis und dem
Bilderverzeichnis drinstehen, ohne irgendetwas zu verschieben und zu
kopieren, z.B.
"C:\Programme\Screenshot-0.97\w2000a-screenshot.exe" -a -f C:\Bilder\
IMO ist man damit flexibler, da man sich für jeden Zweck eine passende
Start-Datei zurechtlegen kann.
Rainer W. schrieb:> Niklas O. schrieb:>> - Evaluation bzgl. direktes Speichern als PNG> Kennst du das Netpbm Toolkit? Möglicherweise sind die im PnmToPng> Konverter (Umwandlung PPM in PNG) genutzen Bibliotheken auch hilfreich,> um direkt die PNGs abzuspeichern.> http://netpbm.sourceforge.net/
Ja, kenne ich (hab' ich glaub' ich auch in der README.txt
empfohlen zur Konvertierung ;)), jedoch bislang nur mit den
Kommandozeilen-Tools gearbeitet.
Niklas
im Moment sieht es bei mir z.B. so aus
E:\Treiber\Welec\1.2.BF.3.0_C5\Screenshot_0.97
davor war es
E:\Treiber\Welec\1.2.BF.3.0_C2\Screenshot_0.97
und da man ja immer die neueste/dazugehörige Screenshot.exe nutzen will
startet man die Scrennshot.exe aus dem neuerem Verzeichniss.
Oder evtl. wirds ja mal E:\Treiber\Welec\1.2.BF.3.0_C6\Screenshot_0.98
und dann darf man jedesmal die .bat Datei anpassen.
Deswegen würde ich mir wünschen das jede zukünftige Screenshot.exe sich
am gleichem Punkt im System die gewünschten Einstellungen holt.
Hat nichts mit faul zu tun sondern eher mit Comfort das man nicht immer
alles anpassen muss.
Was sagen denn die anderen dazu, vielleicht gibt es ja bessere
Vorschläge das ganze zu lösen.
Mein Ansatz war, die aufrufende(n) Batch-Datei(en) an einem festen Ort
stehen zu haben, so dass man bei irgendwelchen Updates mit dem
Verzeichnis der neuen Version gar nicht weiter in Berührung kommt,
sondern nur einmal den Programmpfad in der Batch-Datei anpassen muß.
Wenn das Bilderverzeichnis an einer festen Stelle im System liegt,
verbaut man sich den Weg zu projektbezogenen Speicherorten und ist dann
bei jedem Screenshot am rumschieben. Es ist halt die Frage, ob man öfter
Screenshots macht oder öfter Updates vom Programm einspielt.
Gruß
Rainer
Hallo zusammen,
wie wäre es denn, das Screenshot-Programm zuerst nach einer ini-Datei
z.B. in "Eigene Dateien" (bzw. $HOME) suchen zu lassen und die Parameter
dahin zu verlegen. Wenn es da keine passende ini-Datei gibt, sucht man
noch im lokalen Verzeichnis (des Programms) und Vorrang haben immer die
mitgegebenen Parameter. Damit kann man z.B. die exe auch per Doppelklick
aufrufen und die Einstellungen bleiben unabhängig von der Version
gleich.
Viele Grüße,
Rainer
Hallo,
(sitz' im Zug und habe keine Zugangsdaten, daher Post als Gast)
Kurt Bohnen schrieb:> Niklas O. schrieb:>> Wir sprechen doch von dem Ding der Wittigs, oder?>>>> http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload>> Die Wittig Software lief über USB. Unser Welec Updater aber über RS-232.> Sourcecode haben wir auch:> http://sourceforge.net/apps/trac/welecw2000a/brows...
Okay. Da gibt's dann das Problem dass ich weder Pascal
beherrsche noch die Entwicklungsumgebung dafuer habe.
Wie sieht es jetzt aus? Reicht uns das Programm, moechte
vllt. jemand anderes sich dem annehmen der entsprechende
Moeglichkeiten besitzt, oder soll dennoch ein weiteres
Upload-Programm her?
Niklas
Niklas O. schrieb:> Hallo Hayo,> Ja, das werde ich einbauen. Bei USTB-Sachen waere vllt. auch die> Aufnahme ueber noch laengere Zeitraeume interessant, also sowas> was ein Trace Recorder macht.
Ja das ist machbar.
> Ich hab' noch nicht auf unserem DSO mit der USTB gearbeitet, ich nehme> an die 600 Werte sind im Moment zugleich das Maximum was gespeichert> werden kann (Hartverdrahtet im FPGA), danach wird dies durch neue> Werte ueberschrieben?
Nein, es ist nicht das Maximum und auch nicht hart verdrahtet. Die
USTB-Funktion ist ja eine reine Softwarefunktion die ich nachgerüstet
habe.
Zur Zeit steht ein 1200 Byte Buffer pro Kanal zur Verfügung von dem aber
nur 600 Byte genutzt werden. Ich könnte aber auch deutlich mehr zur
Verfügung stellen. Ich hatte auch schon überlegt ob es Sinn macht dass
man durch den Speicher scrollen kann (so wie in den normalen TB)
> Hier koennte man zum einen die Werte direkt "Realtime" mit dem> Screenshot-Programm aufzeichnen lassen,
Ja, ist auch eine Möglichkeit, jeden Abtastwert einzeln zu übertragen um
eine Langzeitmessung zu realisieren.
> zum anderen muesste doch> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen> im Flash abzulegen und am Ende abzurufen?
Ebenfalls eine Möglichkeit...
Platz ist im Flash noch genügend vorhanden!
Gruß Hayo
Hi Niklas O., Rainer W., Hayo and guys all!
Niklas O. schrieb:
>the entire "operator's manual" for the probes is attached.
Thank You Niklas O., at this time my DSO packaging is not handy.
The document is very interesting.
Niklas O. schrieb:
>According to it, the rise time on x1 should be 23.3ns for>both types of probes.
I had forgotten these values.
23.3nS means something like a 15MHz bandwidth, seem to me quite
optimistic.
Even more curious the x10 values where the bandwidth is precisely 100MHz
and 200MHz just like the W2012A and W2022A to which the probes are
provided with.
For the W201 I'm sure it is very similar or the same Chinese
manufactured probe supplied by LeCroy DSO with its WaveAve 224 model
DSO.
The model provided by LeCroy is called PP016 and it is claimed as a
300MHz probe.
The only visual difference between the W201 and PP016 is a sticker label
on the latter where it says the 300MHz bandwidth.
The PP016 is not a good probe, it is quite fragile, often it breaks even
though it is always handled with care: where I work has happened twice
within the first month of use.
I have to make checks.
Niklas O. schrieb:
>Since there's no description how to use those I never touched them.>(I've got two seperate ones in the box near the BNC.)
About the second capacitor on the W2022A probe, I know for a fine
adjustment I must set two capacitor for RF compensation with my analog
oscilloscope's probes.
These two capacitors are on BNC plug, a third capacitor is located on
the probe body and it is for the LF compensation.
The probes adjustment need a 1KHz and 1MHz square wave with a rise time
no more than 4nS and it is done in this way:
1) Connect probe to a 1 kHz square wave signal and adjust LF
compensation trimmer for optimum square wave response.
2) Connect probe to a 1 MHz square wave signal and adjust HF
compensation trimmer(s) for optimum square wave response.
I guess also with W202 Welec's probes is the same.
I have to check.
Unfortunately my oscilloscope analog probes are fixed at x10 and can not
be switched to x1.
However I have other probes switchable x1 and x10.
I was also thinking of building a pulse generator with rise and fall
times of about 300ps.
With an such instrument would be simple to evaluate the probes
bandwidth.
It could also be used to assess the bandwidth of W201xA and W202xA DSO
without worrying too much about the linearity lack of the front-end,
thing that makes hard performing a such measure in the Welec DSO.
But perhaps this is not a suitable place for this because there is a
"hardware section", so apologize me.
Niklas O. schrieb:
>The attached manual contradicts itself, it mentions that the>input capacitance can be compensated "Within the box cover located>near the BNC (W202 Probe)", but on the next page under>"Compensation and Adjusting the Probe" it explicitly tells to>compensate with the trimmer on the body of the probe.
The welec's manuals are always a little foggy. ;-)
Niklas O. schrieb:
>It fails to mention that the probe needs to be put into 1:10 divider.
This is really a serious lack!
But who is not a newbie should know it.
@Hayo.
Very well Hayo, thank You very much for the kindly explanation.
Now with the Rainer W.'s help and your help I understand how it works
and I know there is a way to avoid it.
I understand is not so easy to fix the problem due the thermal drift and
differences between the DSOs, but now I know a simple way to avoid it.
I can say the problem is gone for me, so thanks very much to Rainer W.
and You Hayo: RESPECT!!!
Vielen Dank!!!
Gruß Luc
@Niklas
Bau mal noch nichts um im Screenshot. Ich habe mir was überlegt wie ich
den USTB-Betrieb etwas "aufbohren" kann und den 16K Signalspeicher
nutzen kann. Und der wird ja schon übertragen.
Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu
scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie
schnell ich das eingebaut kriege.
Gruß Hayo
Kurzer Tipp an alle die Windows 7 64 Bit einsetzen:
Dieser USB- Seriell Adapter funktioniert einwandfrei und auch die
Screenshot- Funktion läuft damit super:
http://www.amazon.de/gp/product/B003AVQ00A/ Digitus DA-70156
Da ich mir selber einen abgesucht habe bis ich einen Adapter gefunden
wurde der unter W7 gut läuft denke ich dass das dem einen oder anderen
nützlich sein könnte.
Hallo zusammen,
Hayo W. schrieb:>> zum anderen muesste doch>> auch die Moeglichkeit bestehen, da die Werte bei langen Aufzeichnungen>> im Flash abzulegen und am Ende abzurufen?>> Ebenfalls eine Möglichkeit...>> Platz ist im Flash noch genügend vorhanden!>> Gruß Hayo
Haupsache es bleibt noch genügend Platz im Flash für Save und Restore
der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal
wieder an einem PC vorbei komme :-)
Gruß Jürgen
Hi,
> Apropos kalibibrieren, Im Kalibriermenu steht Standart= is' klar, Active> Probe= Is' auch klar, Set 3 und 4= is' nicht klar! Sind das die> Einstellungen für die 24 u. oder 33 Ohmler?
mein Anfrage ist wohl etwas unter gegangen?!?
---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.---
Gruß Michael
Jürgen schrieb:> Haupsache es bleibt noch genügend Platz im Flash für Save und Restore> der Kurven! Da brauche ich nämlich keine extra Hardware, bis ich mal> wieder an einem PC vorbei komme :-)
Keine Sorge,
die haben Ihre eigenen reservierten Segmente. Es sind aber noch einige
64K Segmente frei.
Gruß Hayo
Michael D. schrieb:>> ---Set 3 und Set 4, wüsste ich gerne, was es damit auf sich hat.---
Ist einfach nur eine Bezeichnung, mir fiel nichts Besseres ein. Es sind
einfach nur vier verschiedene Kalibriersets die man auswählen kann. Die
ersten Beiden habe ich einfach mal Standard und Active Probe genannt.
Es ist einfach nur so, dass die Kalibierung unter dem gerade
eingestellten Set abgespeichert wird. Man kann auch eine kalt/warm
Kalibrierung abspeichern oder eine mit einem vorher auf den Eingang
gelegten DC-Offset, was auch immer. Mann kann dann ohne neue
Kalibrierung zwischen den Werten hin und herschalten. Du kannst auch als
Standardkalibrierung Set 3 verwenden, das ist echt egal.
Ich habe bei mir auf allen 4 Sets die normale Kalibrierung drauf, damit
ich da nicht versehentlich falsche Werte eingestellt habe.
Gruß Hayo
Hi Niklas O. and guys all!
@Niklas O.
About the W2022A's probe, I will be brief because this is not the right
place.
I did the tests and in the x1 position the rise time is about 30nS
(10MHz bandwidth) while the rise time is about 15nS (about 20MHz
bandwidth) with the W2012A's probe.
In the x10 position the W2012A's probes are like my 250MHz Hameg's
probes, so about 200MHz bandwidth.
Instead in the x10 position the W2022A probes are best of my 250MHz
probes by Hameg, they have better rise and fall time response, so they
are a 200MHz probes for sure.
The W2022A probes are optimized to high frequencies work and W2012A
probes for low frequencies.
The W201 probes by Welec/Wittig and PP016 probes by LeCroy are the same,
same rise and fall time.
LeCroy claim they like a 300MHz bandwidth probes, their performances are
same of my 250MHz bandwidth probes by Hameg, so no bad.
But W202's probes for the W2022A are better than both PP016 and W201,
great!
Vielen Dank!!!
Gruß Luc
Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-(
Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch
für Linux anbieten.
Viele Grüße
Mit TomCat.ram getestet.
* Opening COM1 (115200,8,N,1)... success
* Asking the user to put the DSO into GERMS loader, if not already
done...
* Uploading firmware to DSO
- @line 134 |writing to DSO| |reading response|
Bis dahin funktionierte es bei mir, dann hängt er sich auf.
Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
Hallo nochmal,
Hayo W. schrieb:> @Niklas> [16K Samples fuer UTSB]> Dazu kommt dann noch die Möglichkeit durch den USTB-Speicher zu> scrollen. Das Konzept dazu habe ich schon fast fertig. Mal sehen wie> schnell ich das eingebaut kriege.
Das klingt doch gut!
@Luc:
Thank you kindly for your explanations and tests! It is good
to know that the W202 probes actually are usable for high
frequency.
stone schrieb:> [..]> - @line 134 |writing to DSO| |reading response|>> Bis dahin funktionierte es bei mir, dann hängt er sich auf.> Die Verbindung ist ok, Gegentest mit GERMSloader.pl hat funktioniert.
Du warst der mit den Uebertragungsproblemen, oder?
Ich hab' da noch kein Timeout eingebaut und keine erneuten
Uebertragungsversuche wie (ich glaube) der GERMSloader.pl macht,
auch fange ich Schreibfehler nicht ab. Bei Dir wartet das Programm
nach Uebertragung von Zeile 134 auf das '+' von GERMS. Wenn da
100% CPU Usage sein sollten liegt das daran das ich da noch die
ComTools.cpp nutze (wie das Screenshot-Programm unter Windows auch)
was nur Polling kann (in ner Schleife dauernd fragen "ist jetzt was
da?").
Ich wuerd' daher noch gerne Berichte von anderen hoeren.
(Selber testen kann ich nicht weil ich keinen Windows-Rechner
mit serieller Schnittstelle habe und jegliche USB-seriell-Wandler
die ich habe nicht unter Windows tun (oder ich stelle mich zu bloed an).
Fritz Richter schrieb:> Ich hab auch noch eins, irgendwie war ich wohl zu langsam :-(> Aber eins wird ja nun funktionieren, bei Bedarf könnte ich das dann auch> für Linux anbieten.
Haettest Dich vorher melden sollen dass Du auch was vorhast,
dann haette ich mir das Suchen in MSDN heute Nachmittag sparen
koennen :)
Bei einer kurzen Suche zu Deinem Namen hab' ich diesen
interessanten Beitrag von 2009 gefunden:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"
Hast Du das danach noch weiter verfolgt?
Bei Deinem Programm koenntest Du noch einbauen dass es
in der Dropdown-Liste nur Ports anzeigt die auch existieren,
zudem kann der Fall dass ein Port existiert aber schon
durch ein anderes Programm geoeffnet ist abgefangen werden
und evtl. entsprechend angezeigt.
Womit hast Du das entwickelt, btw.? Wundert mich gerade
warum es so gross ist.
Wenn Du Lust/Zeit/Interesse hast koenntest Du eine GUI
fuer das Screenshot-Programm machen. Die Core-Funktionalitaet
wollten wir eh ausgliedern. GUI bzw. Konsolen-Variante wuerden
dann auf entsprechende C-Funktionen zugreifen die dann
Trace, Screenshot, usw. liefern.
Niklas
Niklas O. schrieb:> Schaut mal ob das funktioniert.
Hallo Niklas,
die Übertragung einer .ram unter WinXP SP3 über einen Prolific
USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert.
Gruß
Rainer
Niklas O. schrieb:> Bei einer kurzen Suche zu Deinem Namen hab' ich diesen> interessanten Beitrag von 2009 gefunden:> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"> Hast Du das danach noch weiter verfolgt?>> Bei Deinem Programm koenntest Du noch einbauen dass es> in der Dropdown-Liste nur Ports anzeigt die auch existieren,> zudem kann der Fall dass ein Port existiert aber schon> durch ein anderes Programm geoeffnet ist abgefangen werden> und evtl. entsprechend angezeigt.>> Womit hast Du das entwickelt, btw.? Wundert mich gerade> warum es so gross ist.
Du meinst das USB?
Ich war damals ziemlich entsetzt über die erreichbare Geschwindigkeit,
es war deutlich langsamer als seriell, deshalb hatte ich es erstmal
frustriert sein gelassen.
Deinen Vorschlag mit den existierenden Comports habe ich noch eingebaut.
Programmiert habe ich das mit Delphi, weil ich gerade nix anderes zur
Hand hatte, deshalb wahrscheinlich die Größe.
Hi Niklas,
> Hallo Niklas,> die Übertragung einer .ram unter WinXP SP3 über einen Prolific> USB-Seriell Wandler (Treiber V. 2.0.13.130) hat gut funktioniert.> Gruß> Rainer
...dito,
habe das Teil von HAMA mit dem FTDI drinnen, funzt wunderbar und es gibt
kein gezicke!
Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in
Sekunden, wie es beim Germsloader der Fall ist?!?
Gruß Michael
Hallo!
Mich würde mal interessieren, was es beim NIOS Design für
Debugmöglichkeiten gibt.
Ich bin in der Firma zufällig beim RTEMS Betriebssystem auf einen gdb
Stub gestossen und überlege, dass ich den gdb stub und RTEMS für das
LEON3-Zeug benutzen werde. Falls es was besseres oder einfacheres beim
NOIS Design gibt, wäre ich dem gegeüber auch sehr offen.
Übrigens scheint das Changelog im Trac nicht mehr ganz am neuesten Stand
zu sein.
MfG
Alexander
Hallo Nochmal!
Ich habe jetzt mein zweites Preview Version 1.1 auf im Sourceforge zum
Download bereit gestellt.
Das Ausprobieren ist gefahrlos, da ich den FLASH-Speicher nicht benutze
oder verändern kann. Nach dem man das Gerät komplett Ausgeschalten hat,
ist alles wieder wie es vorher war.
Ausprobieren auf eigene Gefahr (, die es praktisch nicht gibt)!
Das FPGA-Design ist jetzt schon in einem sehr brauchbaren Zustand.
Die Firmware ist hingegen noch in einen sehr frühen Stadium und für den
normalen Einsatz nur bedingt geeignett.
http://sourceforge.net/projects/welecw2000a/files/LEON3%20FPGA%20Design/Previews/
Dennoch bietet sie eine GUI, manuelles Einstellen der Zeitbasen, der
analogen Spannungsbereiche, und es kann der DAC-Offset analog
eingestellt werden.
Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro
Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design.
Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle.
Die Sprünge der Offsets bei den 5er,2er und 1er sind durch das analoge
Frontend bedingt und fehlen hier noch im Gegensatz zu der Firmware für
den Nios Softcore.
Im AUTO Trigger Mode ist die Bildwiderholrate langsam, falls nichts zum
Triggern gefunden wurde.
Die Spannungsverstärkung ist auch noch nicht kalibriert.
MfG
Alexander
Gute Sonntag an alle und Niklas O.
Niklas O. schrieb:
>anbei der erste Wurf des Firmware-Upload-Programmes fuer Windows.>Schaut mal ob das funktioniert.
Niklas, thank You very much for the masterpiece and free time You kindly
provides to us: RESPECT!!!
I have tried your software and it works like a charms both through
direct serial connection than via MANHATTAN's usb to serial converter.
My equipment are:
computer Pentium IV@3GHz with operating system Windows XP Home Edition
SP3 and hardware version 8C7.0.C of W2022A's model DSO.
Through a usb to serial converter it is little slower than direct serial
connection, but this even with Perl Script, so it is normal.
I do not want to appear rude and I do not want to criticize your
excellent work, but I would say that the software is very detailed in
describing the operations to be done but it not warn you when it ended
(the Perl Script at the end thank for the fishes so the user understands
the operations are successfully completed).
Repeat, this my reporting is not intended as a criticism but it is
simply for knowledge, so apologize me.
Niklas O. RESPECT!
Vielen Dank!!!
Gruß Luc
Wow, is ja Wahnsinn, was sich inzwischen überall getan hat.
Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und
Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das
Leon-Design selber hat ja ein unglaubliches Potenzial!!!
Als reiner Nutzniesser noch einmal einen besten Dank an alle. Ist schon
echt klasse, dass das Welec jetzt inzwischen voll brauchbar ist und mit
dem Leon Design sogar noch Best-Of-Class werden könnte (mal vom analogen
Teil abgesehen).
Michael
Hallo,
Michael D. schrieb:> Ganz hilfreich wäre noch die Angabe der verbleibenden Downloadzeit in> Sekunden, wie es beim Germsloader der Fall ist?!?
Jupp. Baue ich noch ein.
Luc schrieb:> [..] but I would say that the software is very detailed in> describing the operations to be done but it not warn you when it ended> (the Perl Script at the end thank for the fishes so the user understands> the operations are successfully completed).
Yes. It will open a MessageBox saying that the operation is finished
but I forgot to write that info on the console, too.
Michael schrieb:> Wow, is ja Wahnsinn, was sich inzwischen überall getan hat.>> Beim Leon Design erscheint es jetzt langsam sinnvoll, wenn Hayo und> Kollegen mal schauen würden, ob sie die Firmware portiert bekämen. Das> Leon-Design selber hat ja ein unglaubliches Potenzial!!!
Ich stimme zu, allerdings glaub' ich nicht, dass wir da an ein
"Portieren"
der Firmware denken koennen. Ganz abgesehen vom unterschiedlichen
FPGA-Design ist da immer noch jede Menge Furcht erregende Altlast drin.
Ich finde aber, dass es nun an der Zeit ist mitzuwirken und die GUI
aufzubauen. Da ich ein 4-Kaeneler habe muss ich zum Ausprobieren
des Leon-Designs nochmal auf und Front ab und Loetbruecke rein. Ich
hoffe ich komme mal die naechste Zeit endlich dazu.
alex008 schrieb:> Die digitalen Filter HW-Filters und die 8kSamples Speichertiefe pro> Kanal sind die größte Verbesserung gegenüber dem NIOS-FPGA-Design.
Mhm, nur 8kSa?
> Da ich nur ein 2-Kanalteil habe, unterstütze ich hier auch nur 2 Kanäle.
Im FPGA-Design generell oder nur in der Firmware?
Niklas
Hallo Niklas!
Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie
ist auf 2 Kanäle mit 16 Bit Daten eingestellt.
Falls man auf 8 Bit, 1 Kanal umstellt hat man 32kSamples. Mehr geht
nicht, da der Cyclone II "nur" ca. 56 kByte zu Verfügung hat, und der
LEON3 mit seinen Registerwindows und seinem Cache auch eine ganze Menge
an RAM-Blöcken braucht.
Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so
viele FPGAs (2 statt 1) nutzt.
Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei
unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt.
Des weiteren ist der Messdatenpuffer auf den Roll-Mode ausgelegt, jedoch
wird das von der Firmware noch nicht unterstützt. Ein entsprechender
DMA, mit dem 20MSamples/sec beim Roll-Mode theoretisch möglich sind, ist
im FPGA-Design angedacht, aber noch nicht drinnen.
MfG
Alexander
alex008 schrieb:> Die 8 kSamples ergeben sich im Moment aus der Firmwarekonfiguration. Sie> ist auf 2 Kanäle mit 16 Bit Daten eingestellt.
Wie machst Du das mit den 16 Bit?
> Das 4-Kanalmodell hat den doppelten internen Speicher, da es doppelt so> viele FPGAs (2 statt 1) nutzt.
Habe ich das richtig mitgekriegt, dass Kanal 3 + 4 zur Zeit FPGA-seitig
noch nicht unterstützt werden?
> Das NOIS-Design kann da bei den meisten Samplinraten weniger. Nebenbei> unterstützt es hardwaremässig nicht alle Samplingraten, die es anzeigt.
Vor allem gibt es aus unbekannten Gründen einen ziemlichen Sprung
zwischen 25MSa und 250MSa was ziemlich unpraktisch ist. da die
dazwischenliegenden Samplingraten auf Kosten der effektiven
Speichertiefe geht.
@Niklas
Die effektive Speichertiefe ist beim NIOS-Design nur bei <=50ns/div
16KB. Bei den anderen Zeitbasen sorgt der Zoomfaktor dafür, dass nur ein
Teil der 16KB bzw. 4KB im normalen Betrieb genutzt werden.
Dafür stehen die ungenutzten Werte im Stopmodus und im Delayedmodus für
weitere (schnellere) Zeitbasen zur Verfügung.
Gruß Hayo
Alex, klasse! Das sieht ja schon richtig gut aus.
Wir müssen dem Alex mal einen 4Kanäler sponsorn...
Vorher wird das mit mir und der Leon-Firmware nix. Ich würde echt gern
selber dran mitarbeiten, aber mir fehlt die Zeit.
Nur am Rande, bestimmt hatte schon mal jemand die Idee, ich frage
trotzdem: Wäre es eigentlich möglich, aus dem Welec ein DPO (statt
momentan DSO) zu bauen? Also eines was kontinuierlich abtastet und in
der Kurvendarstellung statt Einzelwerten entsprechend breitere
Verteilung anzeigt? Ich habe zugegeben noch nicht mit sowas gearbeitet,
fände ein "analogeres" Feeling gut. Derzeit nehme ich fast immer mein
Hameg statt dem Welec, da weiß ich was ich sehe, falle nicht auf
Unterabtast-Artefakte rein.
Jörg
ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte
mal fragen ob sich das vielleicht auch integrieren lässt.
1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1,
2, 3 oder 4 auftritt.
2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals
steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
Hi Niklas O., alex008, Hayo and guys all!
Niklas O. schrieb:
>Yes. It will open a MessageBox saying that the operation is finished>but I forgot to write that info on the console, too.
Niklas O., thanks so much for your kind explanation!
@alex008
Alex008, really very impressive your work who it also make user friendly
the approach to the LEON 3 Design: RESPECT!!!
I will try to explore the question, thank You very much Alex008 and all
who are involved with the LEON 3 NIOS design: again RESPECT!!!
@all who can answer
I update my W2022A to the latest 1.2.BF.3.0_C5 firmware revision and
with it I experimented the spikes problem, this is known as spikes that
affect both channels simultaneously.
Now with the same software release on mine friend's W2012A it seems less
noisy, as I already written, and no spikes problem.
Instead my W2022A seems to me less noisy also, but there is the spikes
problem I never seen before on my W2022A.
Normally I could set "Factory" or "Hi Frequency" in the hardware menu
without problem, now only "TEST 5" give some improvement but do not
entirely eliminate the problem.
So I ask myself:
My W2022A is hardware version 8C7.0C while my friend's W2012A is
hardware version 8C7.0B, but what the difference is?
Could this be the cause of the problem?
And what means 8C7.0C, 8C7.0B, 8C7.0L, 8C7.0G and so?
Are they perhaps the NIOS revision?
I know Hayo have W2022A hardware version 8C7.0G or 8C7.0L
(http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument), so
He test firmware with it and due the differences between the DSOs I
understand is not so easy for He to release a firmware that will work on
all W202XA and W201XA Welec's revisions, although he usually succeeds in
this.
@Hayo
Hardware's menu settings are used to eliminate ringing problems plaguing
some Welec's DSO, precisely the spikes's problems.
Broadly, what are the affected parameters?
I mean the inside firmware parameters to be adjusted to eliminate the
spikes
Vielen Dank!!!
Gruß Luc
Hallo Hayo,
eine Frage zur FFT:
Im Zeitbereich schaltet ja zwischen "Ablenkgeschwindigkeit" 5 us/div und
10 us/div die Abtastrate zwischen 250 MSa/s und 25 MSa/s um. In der FFT
springt dann die Frequenzskala direkt von 15.62 MHz/div auf 1,56
Mhz/div. Aus der Abtastung ergibt sich natürlich dieser Sprung, aber für
die Ablesung wäre es manchmal gut, ggf. per Zoom Zwischenwerte
einstellen zu können. Habe ich da etwas übersehen oder geht das (noch?)
nicht?
Gruß
Rainer
@Luc
The hardware version consists of three single values:
tc_hw_version, tc_production_lot1, tc_production_lot2
Only 8C7 (tc_hw_version)is the real hardware version! This value is read
from the FPGA. The values after the dot are stored in the protected
flash (tc_production_lot1, tc_production_lot2). This are values which
where set by WELEC while programming the flash.
Maybe the values after dot are not correct in my W2022A because I
restored my flash after an upload crash from another DSO (I think is was
from Falk).
Do You have a screenshot of Your spike problem?
Regards
Hayo
Hi Hayo, Niklas O. and guys all!
Hayo W. schrieb:
>Only 8C7 (tc_hw_version)is the real hardware version!
Hayo as always You are very kind!
I thank You very much for the explanation and for your patience!
Hayo, You are great!
So ultimately be always the same review worked at different times
without substantially differences.
For me this is very interesting, thank You Hayo!
Hayo W. schrieb:
>Maybe the values after dot are not correct in my W2022A because I>restored my flash after an upload crash from another DSO
Well Hayo, but the batch is not relevant if there are not other
differences.
If I understand correctly means that comparing different hardware
revisions the only difference is related with the production batches
fields.
Is this correct?
This means uploading an hardware revision rather than another in the DSO
make no difference.
Certainly when the LEON 3 design will be implemented in full there will
be a standard environment that perhaps will help the compatibility
between the different DSO, this I think.
Hayo W. schrieb:
>Do You have a screenshot of Your spike problem?
Hayo, spikes are very fast and random, very difficult to capture.
I unable to get it directly, so in order to capture they I had to enable
the persistence of the display.
The result is visible in the two attached screenshots named Spike1.jpg
and Spike2.jpg.
However, I noticed my W2022A has a bit crazy behavior.
AUTOSCALE do not work correctly, the AUTOSCALE_probe.jpg pic show the
result of the function with the signal for the probes compensation: very
crazy!
Other pics show the behavior without signal on CH1 and CH2: also very
strange.
@Niklas O., @Hayo
I tried to reload the same firmware via Perl Script but I have not
solved the problems.
I had updated the W2022A using the fwupload.exe software released by
Niklas O.
Now,
Niklas O. schrieb:
>Yes. It will open a MessageBox saying that the operation is finished>but I forgot to write that info on the console, too.
But when I upgrade I have no get the message, so I wrote:
Luc schrieb:
> [..] but I would say that the software is very detailed in> describing the operations to be done but it not warn you when it ended> (the Perl Script at the end thank for the fishes so the user understands> the operations are successfully completed).
So, might be this related?
I would like to make it clear that I do not write these things to blame
Niklas O. or others for what happens to me but only for knowledge
because this maybe can help to prevent a recurrence of the problem also
to other.
I am sure that Niklas O. has done a great job and I thank him again for
the amazing fwupload.exe software and for free time He kindly provides
to us, Niklas O. RESPECT!!!
I hope not to seem rude and above all not be misinterpreted.
I even do not expect a solution, I will only document the fact.
Repeat this is for knowledge, I do not write these things to blame
Niklas O. or others but only because this maybe can help to prevent a
recurrence of the problem also to other.
I hope all You understand what I mean, what I want to say.
However, I'm sure I can certainly solve by loading a previous revision
of the Hayo's firmware, so really no problem for me, I do not think my
W2022A was permanently ruined ! :-)
Vielen Dank!!!
Gruß Luc
Hi, bin grad (Ihr ahnt es schon) vom Griechen zurück, diesmal allerdings
zwecks 10. Hochzeitstag. Trotzdem ist noch kurz Zeit für eine Antwort
(ist halt die beste aller Ehefrauen!).
@Rainer
Es gibt leider (aus unerfindlichen Gründen) einen Sprung zwischen 250MSa
und 25MSa. Das Ganze wird im laufenden Betrieb durch den Zoomfaktor
zwischen 10 und 25 kaschiert. Das ist natürlich suboptimal. Ich habe
auch schon mit diversen Registerwerten experimentiert, aber ohne Erfolg.
Anscheinend haben die Jungs (Wittigs) es voll vergeigt! Die einzige
Abhilfe die mir da so in den Sinn kommt ist das LEON3 Design. Mit dem
NIOS Design läßt sich da wohl wenig ändern.
Gute Nacht
Hayo
Hallo!
Ich habe eine mögliche Erklärung zu den unterschiedlichen Speichertiefen
bei den verschiedenen Samplingraten im NIOS Design.
Es scheint mir so, dass beim NOIS Design jeder ADC einen Puffer von 4 kB
oder 4 kSamples hat.
Bei 500 MS/s werden nur 2 ADCs benutzt, weshalb auch nur 2*4 kB Speicher
zur Verfügung stehen.
Bei 250 MS/s wird nur ein 4kB Speicher benutzt.
Um nun die 1,2,4,10, ... Teilung zu schaffen, ohne dass der vertikale
Gridabstand verändert wird, muss wenn nur ein 4kB Speicher verwendet
wird, die erste Teilung einen Faktor 10 aufweisen.
250MS/s / 2,5 Samples = 100MS/s geht nicht mit Samples verwerfen, die
das NIOS Design sicher nicht hat.
Möglicherweise gibt es auch die 50MS/s Teilung nicht, da der 4kB
Speicher mit hoher Warscheinlichkeit mit 16 Bit @ 125 MHz beschrieben
wird, und das dem FPGA-Entwickler zu schwierig oder zu aufwendig war.
Im Unterschied hat das LEON3 design einen 32 kB Puffer, welcher nach der
Dezimierung mit oder ohne HW-Filter ist, und kein einziges Sample Jitter
auf irgendein Triggerevent hat.
@LUC
To be shure you do not have a hardware fault (soldering) try the LEON3
design. It does have an glitch trigger which can trigger downto one
sample long gliches with every samplingrate (also @ 1 GS/s)!
The HW-Filters must be turned off for this!
@Thomas
Einen OR-Trigger habe ich im Moment noch nicht drinnen, die
Triggereinheit ist aber so modular aufgebaut, dass eine Nachrüstung
relativ einfach wäre.
Die Bandbreitenbegrenzung im DLM2000 unter 100MHz wird laut Aussage
eines Yokogawa Vertreters auch mit ähnlichen digitalen Filtern gemacht,
wie die HW-Filters bei mir!
MfG
Alexander
@Hayo: Also hat die Triggerung nicht mit dem Nios Design zu tun, gibs da
einen Baustein in Hardware der sich darum kümmert, oder wie meinst du
das mit modularer Triggereinheit.
@Axel
Wenn ich mit Datenrate und Tracelänge nachrechnet, scheint es so, dass
bis einschließlich 10 us/div (25 MSa/s) eine Speichertiefe von knapp 4
kSa pro Kanal verwendet wird, ab 5 us/div (250 MSa/s) komme ich dann auf
16 kSa pro Kanal, d.h. das ist noch eine andere Sache als das Reduzieren
des ADC Interleaves von 4..2..1 ADC. Hayo kann das bestimmt bestätigen.
@Hayo
Da man an den Samplingraten vermutlich erstmal nicht drehen kann, zielte
meine Bemerkung zum 1:10 Sprung in der Frequenzachse eigentlich mehr in
Richtung Zoom-Funktion für die FFT. Bei 1024 gerechneten Punkten wären
ein 2:1 Zoom sicher drin, ein 4:1 Zoom eventuell nicht schön, aber
darstellbar. Früher gab es ja schon mal die Frage nach einer Art
Frequenzlupe. Ohne neue Berechnung von Frequenzdaten, könnte man sowas
vielleich in der Anzeige auf Basis der bestehenden Daten umsetzen.
Gruß
Rainer
@Thomas
die Triggerung ist größtenteils hardwareseitig (ADC, FPGA)
implementiert. Das schränkt die Möglichkeiten firmwareseitig etwas
nachzurüsten ziemlich ein. Beim LEON3 hat Alex zum Beispiel die
Möglichkeit ein Oder-Glied in die Triggerlogik des FPGA einzufügen,
diese Möglichkeit habe ich beim NIOS nicht. Ich kann also nur mit dem
arbeiten was bei der Firmware ankommt und das ist nur die Triggerung
eines einzelnen Kanals zur Zeit.
@Rainer
Zur Zeit verwende ich für die FFT nur die realen Abtastraten, Daher auch
der Sprung zwischen 250 und 25MSa. Ich könnte natürlich stattdessen die
virtuellen Abtastraten des Zeitbereichs verwenden, dann hätte man eine
feinere Abstufung. Dazu müßte ich dann wie beim Zoom die nicht
benötigten Abtastwerte weglasssen. Das wäre machbar. Ich seh mal was da
geht. Zur Zeit bin ich noch ziemlich mit dem Umbau der USTB-Funktionen
beschäftigt.
Gruß Hayo
Hallo zusammen,
wegen der Sammelbestellung:
Es sind immer noch zu wenig Interessenten. Beim USB-Host erst 5 Leute.
Dann wollen noch 4 Leute Teile für die Huckepackplatinen und auch noch
Platinen. Die Teile sind natürlich kein Problem, wohl aber die <10
Platinen die eine Bestellung unwirtschaflich machen.
Ich würde vorschlagen die Sammelbestellung (USB-Host+Huckepack2) solange
offen zu halten bis Hayo die Firmware angepasst hat. Dann werden sich
sicherlich noch mehr Interessenten melden.
Gibt es Meinungen/Einwände dazu?
Mfg,
Kurt
Gute Sonntag an alle und alex008, Kurt Bohnen, Thomas O. und Hayo.
alex008 schrieb:
>@LUC>To be shure you do not have a hardware fault (soldering) try the LEON3>design. It does have an glitch trigger which can trigger downto one>sample long gliches with every samplingrate (also @ 1 GS/s)!>The HW-Filters must be turned off for this!
Thanks for the suggestion alex008!
As I have already written, I am sure my W2022A is not dead and it is
just a loading error.
I already load an old Hayo's firmware release in to W2022A and spikes
problem is gone, so I am pretty sure the W2022A is ok and it has no
problem.
On the other hand I have similar experiences with firmware upgrades
asthe my work even covers these issues, so nothing new for me.
The problem is due to hardware incompatibility or loading error or both.
Returning to your kind suggestion, I have installed the LEON3 design in
my W2022A.
It is very easy, maybe because I use Quartus and similar software daily
when I work but it is very easy to do!
To be honest, I was able to easily install the NIOS LEON3 design and its
software, but I was not able to do any measure due the fact I am unable
to do even simple thing like move traces, so they are always in a bad
position on the screen, I am only able to move the trigger level,
nothing other.
I am able to set some parameters like probe attenuations, time base's
factor, vertical amplitude's factor, set the trigger source, set the
trigger slope and so, but nothing other.
Signal track are very clean and noiseless, but seems to me like they are
be fixed.
However, I repeat I was unable to make use of the DSO with the LEON 3
design installed on it, I am so sorry.
Is there no a user manual that explains how to use it?
What mean LEON or FPGA UART setting?
For me the LEON 3 DEMO design is really very user friendly to put in to
the DSO, although then I was not able to properly use the DSO I invite
everyone to try the LEON 3 design, if only because it is very easy and
safe to install it in the DSO: You load the LEON 3 in the DSO, You try
it and once You turned off and on the oscilloscope everything is back as
it was before without a trace!
Really very cool, so thank You very much to You alex008 and all who is
involved with the LEON 3 design's development: RESPECT!!!
However moving forward, to more accurately test the hardware of my
W2022A I decided to hurt me and I reinstalled the original 1.4 version
by Wittig/Welec! ;-)
A blast from the past, a return to youth! ;-))
After having played a little with the good old Wittig/Welec firmware, go
running to update the DSO to the latest 1.2.BF.3.0_C5 firmware release!
;-)))
Now spikes are come back like in a nightmare!
My goodness, this is really a wonderful and unforgettable Sunday! :-)
In the end seems the 1.2.BF.3.0_C5 firmware do not like at my W2022A so
I make a downgrade!
@Kurt Bohnen
What is the >Huckepack2?
@all
Thomas O. schrieb:
>ich habe gerade bei Yokogawa folgende Triggerarten gesehen und wollte>mal fragen ob sich das vielleicht auch integrieren lässt.>>1. "Oder-Trigger" die erste Flanke triggert egal ob diese auf Kanal 1,>2, 3 oder 4 auftritt.>2. Flankentrigger der in Abhängigkeit von Low/High eines anderen Kanals>steht, so könnte man z.B. bei I2C aufs Start Bit triggern.
In the Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)
weitererGast schrieb:
>>> Ist eigentlich schon implementiert, dass man auch auf einen Kanal>>> triggern kann der ausgeblendet, aber dennoch angeschlossen ist? Das>>> missfiel mir am Anfang gewaltig. Manchmal muss man wegen der>>> Übersichtlichkeit schlichtweg auch mal den zu triggernden Kanal>>> ausblenden.
Antonio schrieb:
>> I don't understand, what you mean?>> Also Hayo's answer isn't clear for me, please help about this.
Hayo W. schrieb:
>What he meant is, that triggering should be possible on channels which>are inactive. But to realize that I have to change the source channel>selection logic because the actual logic switches off the source channel>if it becomes inactive and searches for the next available active>channel automatically.
Subject matter in some ways similar.
Vielen Dank!!!
Gruß Luc
mir ist gerade etwas in den Sinn gekommen und da wollte mal fragen ob
das praktizierbar ist.
Ein differentielles Signale anzuzeigen also Kanal 1 mit Kanal 2 zu
verrechnen und ab einer Differenz größer X das eigentliche Signal
darzustellen dazu wäre es vielleicht sinsvoll die gespeicherten Werte
rechts zu schieben um die Auflösung zu verringern und dann miteinander
verrechen.
Viellicht läßt sich sogar eine 3 Oszilinie zw. Kanal 1 und 2 Zeichnen.
http://www.kfztech.de/kfztechnik/elo/can/bmw1.JPG
Hi Leute,
ich weiß man hört im Augenblick nicht viel von mir. Aber ich ich bin
trotzdem dabei. Zur Zeit bin ich noch an den USTB-Funktionen dran.
Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte.
@Luc
I fixed the spike problem caused by the hardware setting "High Frequ". I
changed the register setting and it seems to work.
Hayo
Thomas O. schrieb:> ich sehe gerade das die Subtraktions-Funktion dabei ist, muss mal> schauen ob sich das so gut auf digitale Signale anwenden lässt.
Zum Glück sind die Digitalsignale eine Teilmenge der Analogsignal.
:-)
Hallo Hayo,
mal noch eine Frage etwas anderer Natur. Wäre es denkbar die Auflösung
des Scopes zu 9bit hin zu treiben?
Ich glaube die Diskussion hatten wir schon mal an irgendeiner Stelle.
Ich stelle mir das so vor:
- Sampledurchgang 1:
Es wird gesamplet wie bisher
- Sampledurchgang 2:
Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2
LSB erhöht ist.
- Zusammenführen der Daten aus Sampledurchgang 1 und 2
Mir ist klar das das auf dem Bildschirm keinen Unterschied machen wird,
jedoch beim Export der Daten auf einen PC wird das einen Unterschied
machen, weil dann die höhere Auflösung zur Verfügung steht.
Ließe sich das grundsätzlich realisieren?
branadic
branadic schrieb:> - Sampledurchgang 1:> Es wird gesamplet wie bisher>> - Sampledurchgang 2:> Die Spannung am DAC wird soweit erhöht, dass das Signal am ADC um 1/2> LSB erhöht ist.>> - Zusammenführen der Daten aus Sampledurchgang 1 und 2
Das Problem sind das Zusammenführen der Signale und die Wiederholrate.
Die Wiederholrate wird massiv einbrechen, da
1. doppelt so viele Sampledurchgänge pro Frame benötigt werden
2. vor jedem einzelnen Sampledurchgang der DAC justiert werden muß, was
noch viel mehr Zeit kostet, da vor dem nächsten Sampledurchgang solange
gewartet werden muß bis der DAC (und OP Amp) gesetzt und eingeschwungen
ist.
Das Zusammenführen ist insofern problematisch, dass es einen sehr
präzisen Trigger erfordert, da sonst das Signal in Horizontalrichtung
unscharf wird. Man erkauft sich dann vertikale Präzision mit
horizontaler Unschärfe.
Wie das aussieht kann man sich ansehen wenn man ein Signal mit steiler
Flanke auf dem Bildschirm hat und dann auf persistente Anzeige schaltet.
Gruß Hayo
Hallo Hayo,
ich hab mir schon fast gedacht, dass das auf Basis des Nios nicht
klappen wird.
Es wird wirklich Zeit, dass der Leon das Licht der Welt erblickt, denn
da steht auch der Trigger wie eine eins und ließe, aufgrund seiner
Geschwindigkeit, solche Spielereien ebenfalls zu.
branadic
Hi Hayo, Kurt Bohnen and guys all!
@Hayo
First, thanks You very, very much Hayo for the free time You provided
generously to us and for have fixed the spike's problem!!!
Hayo, I installed your latest great job, the new 1.2.BF.3.0_C6.
It is very impressive, as always You are right the spikes are gone!:
RESPECT!!!
I setted hardware configuration as "High Frequency" and "1,25 Gain" and
no more spikes!
You are great, so thank You very much again for the excellent job done:
RESPECT!!!!!!!
I know the work must not have been easy, so as usual I am speechless!!!
Kurt Bohnen schrieb:
>It's (the "Huckepack2") the second collective order of the>pickabackboard parts (and PCB).
Hello Kurt Bohnen, thank You for your kind explanation.
What You wrote it is very interesting for me and I guess for many other
also.
How can I place a purchase order?
How can I pay the materials?
How much is it shipping included?
Is there a possibility to purchase a Vinculum VNC2 USB-Host also?
And the power supply shield?
Please, let me know, I guess it is very interesting also for many other
people.
Thank in advance.
Mit Freundlichen Grüßen,
Luc
Hello LUC,
sorry for my late answer.
I am happy to read you did try the LEON3 design.
For your measuring problem:
The LEON3 design software is not ready to use for daily operation.
Their is no DC offset calibration available at the moment.
And because the original analog frontend was made with poor quality you
have to set the dc offset with the offset gain button and the offset
wheels before you can measure anything.
I have put a video about setting the dc offset on a previous entry from
10.04.2011 here.
The signal quality can be improved with the HW-Filters.
Alexander
hat außer mir noch jemand Probleme mit Timebase >1s/div mit der 3.0 C6
oder wurde da irgentwas geändert, ich habe einige Versionen
übersprungen. Bekomme keine Aktualisierung mehr mit den Sekunden-
Einstellungen.
Hi BLUE
I have a worrying problem on my W2012.
While today I tried to adjust the course to display a horizontal drive a
TVC suddenly the track of the instrument has become fixed and immobile,
but clean (not even a pixel out of place). Of course not display any
picture nor the TEST SIGNAL.
I say that at the time of the defect, the tip was removed from the
circuit.
I reinstalled an earlier version that was installed
but the defect remains. Channel 2 still works
Sorry for the language
wailer schrieb:> Hi Hayo> I have a worrying problem on my W2012.> While today I tried to adjust the course to display a horizontal drive a> TVC suddenly the track of the instrument has become fixed and immobile,> but clean (not even a pixel out of place). Of course not display any> picture nor the TEST SIGNAL.> I say that at the time of the defect, the tip was removed from the> circuit.> I reinstalled an earlier version that was installed> but the defect remains. Channel 2 still works> Sorry for the language
Hi Kurt Bohnen, alex008, wailer, and guys all!
Kurt Bohnen schrieb:
>Details zur Sammelbestellung gibt es jetzt hier:>http://sourceforge.net/apps/trac/welecw2000a/wiki/...
Very well Kurt Bohnen, great job!
Kurt Bohnen thank You very much for your kind support!
You are really a big one, RESPECT!!!
alex008 schrieb:
>sorry for my late answer.>I am happy to read you did try the LEON3 design.
Hi alex008, no apologies, I must thank You for the great work and free
time You provided generously to us: RESPECT!!!
alex008 schrieb:
>For your measuring problem:>The LEON3 design software is not ready to use for daily operation.>Their is no DC offset calibration available at the moment.>And because the original analog frontend was made with poor quality you>have to set the dc offset with the offset gain button and the offset>wheels before you can measure anything.>I have put a video about setting the dc offset on a previous entry from>10.04.2011 here.
Ok alex008, I understand, so thank You a lot for the kindly and useful
explanation.
alex008 schrieb:
>The signal quality can be improved with the HW-Filters.
I am currently away from my computer and I have no to hand Quartus, so I
can not try but in the weekend I will try for sure.
Thank You again alex008!
wailer schrieb:
> I have a worrying problem on my W2012.> While today I tried to adjust the course to display a horizontal drive a> TVC suddenly the track of the instrument has become fixed and immobile,> but clean (not even a pixel out of place). Of course not display any> picture nor the TEST SIGNAL.> I say that at the time of the defect, the tip was removed from the> circuit.> I reinstalled an earlier version that was installed> but the defect remains. Channel 2 still works> Sorry for the language
Hi wailer, seem to me to understand perhaps you damaged your DSO while
performing a measurement on a TV color set.
Is it correct?
I think already I read You somewhere and I guess You are Italian, so I
try to write Italian to facilitate the understanding.
Italian translation:
Ciao wailer, mi sembra di capire che tu hai danneggiato il tuo DSO
effettuando una misura su un televisore a colori.
E' corretto?
Mi pare di averti già letto da qualche parte e che tu sia italiano, per
cui provo a scrivere in italiano per facilitare la comprensione.
@ all
Due to high voltage on some point inside a color television set, is
unfortunately possible you damaged your DSO for true.
How much is great the signal amplitude on which You done the measure?
Was the probe setted x1 or was it setted x10?
Sorry, but due to the exceeded in the maximum input voltage for analog
inputs is possible the DSO is now broken.
Please weiler, tell us more about what you done.
Italian translation:
A causa dell'alta tensione presente in alcuni punti di un televisore a
colori è purtroppo possibile che tu abbia realmente danneggiato il DSO.
A quanto ammonta l'ampiezza del segnale sul quale hai effettuato la
misura?
Come era impostata la sonda, x1 o x10?
Spiacente ma a causa del superamento dei valori massimi consentiti per
gli ingressi analogici è possibile che il DSO sia adesso guasto.
wailer per favore facci sapere di più circa quello che hai fatto.
Mit Freundlichen Grüßen,
Kind regards,
Cordiali saluti,
Luc
Luc grazie
Preciso che il probe non era a contatto con i circuiti del TVC
Sul TVC il trasformatore di EAT era smontato (assente)Quindi non poteva
esserci Alta Tensione.
Il pilotaggio (driver) di riga ha come Vpp 12-15 volts
Il blocco del Input 1 è avvenuto cercando di regolare il Time Base
Posso ora dire che il problema era software ed è RISOLTO.
Con WELECUPDATER ho reinstallato il firm originale (avevo Backup)
e il DSO ha ripreso a funzionare. Successivamente ho aggiornato alla
3.0C6
del grande HAYO .Ora tutto sembra funzionare.
Prima del blocco avevo notato che il DSO a volte si bloccava ed era
necessario riavviarlo
English Version:
Thanks Luc
Specify that the probe was not in contact with the circuitry of the TVC
The TVC transformer EAT was removed (absent), then there could be high
voltage.
The pilot (driver) has the Vpp line 12-15 volts
The input block 1 occurred trying to set the Time Base
I can now say that the problem was software and ubuntu.
With WELECUPDATER I reinstalled the original signature (I Backup)
and the DSO has resumed operation. Then I upgraded to 3.0C6
Hayo's great. Now everything seems to work.
Before the block I noticed that the DSO sometimes crashed and had to
restart
Hi there,
I'm just back from holiday in Spain. In the "outback" (Alicante) where I
spent my time, I had no internet connection. This is the reason why my
answer is coming a little bit later.
@wailer
You solved Your problem by yourself - well done!
@elec + Rainer
Tut mir leid wenn im USTB-Bereich Probleme auftreten. Da sind dann wohl
doch schon einige Änderungen mit reingerutscht. Zur nächsten Version
wird ohnehin alles im USTB-Bereich umgekrempelt, dann hat sich das auch
erledigt. Sonst Notfalls downgraden auf auf eine ältere 3er Version. Die
C4 oder C5 müßte doch noch funktionieren oder?
@Kurt
Muß ich irgendwas machen wegen der Bestellung, oder warte ich bis ich
von Dir eine Nachricht bekomme?
Gruß Hayo
Hayo W. schrieb:> Tut mir leid wenn im USTB-Bereich Probleme auftreten.
Hallo Hayo,
kein Problem - mit der C5 läuft USTB wie gewohnt. Bezüglich Spikes -
die, die synchron auf Ch3 und 4 auftreten - konnte ich zwischen C5 und
C6 übrigens keinen rechten Unterschied feststellen.
Gruß
Rainer
Die Unterschiede sieht man auch nur bei Hardwareeinstellung "High
Frequ". Wenn man dann ein Rechtecksignal mit der steigenden Flanke
mittig positioniert (z.B. bei 100ns) und auf persistente Anzeige
schaltet dann sieht man die Spikes synchron auf Kanal 1 + 2.
Gruß Hayo
Hallo Hayo,
wie oben schon geschrieben sind weitere Fakten zur Bestellung auf
http://sourceforge.net/apps/trac/welecw2000a/wiki/collectiveorder
nachzulesen.
Die offene Deadline gibt es damit nicht wieder 10 Nachzügler kommen,
nachdem die Huckepackplatine von der Firmware unterstützt wird.
Mfg,
Kurt
Guten Abend an alle.
With a friend, I'm trying to assess the bandwidth of the W2022A and
W2012A.
It is not so easy, just completed the measures I will explain the matter
in detail in the Hardware forum.
At this moment I would to talk about some things maybe to be already
known.
I built a pulse generator which has Rise and Fall time so fast that I
can not measure them with precision.
The best oscilloscope I could use to calibrate the pulse generator has a
bandwidth of 500MHz, but it is inadequate to measure the Rise and Fall
times of pulses, which should be less than 300ps, so I preferred to
compare the performance of the W2022A and W2012A compared with those of
other oscilloscopes with known characteristics.
Seems to me the W2022A is better than the W2012A, better frequency and
amplitude response.
About this last I am not sure due the linearity lack of the Welec.
However I noticed some things.
A) With the Welec's oscilloscopes, in order to make better measure I
must put the trigger level just below the peak of the pulse otherwise
the waveform is continually moving.
But in this way the signal amplitude increases considerably compared to
when the trigger level is set lower.
In short, the size of the displayed signal depends on the position of
the trigger threshold, if the trigger threshold is low, the amplitude of
the signal is so and the waveform is moving, whereas if the amplitude is
high it becomes high itself and the waveform is more steady.
I had never noticed this thing before, but maybe it is always been so.
B) Seem to me when the Rise or Fall time are less than 1nS, in the Quick
Measure is show 0,00S not allowing to know which is the measured in
true.
Ok, it exist the cursors, but also this thing I had never noticed
before, but maybe it is always been so.
C) Both W2022A and W2012A have the 1.2.BF.3.0_C6 firmware.
About this, I have no more spikes problem, but during the measurements I
have noticed that "High Frequency" setting in Hardware menù is good for
show the inner probe compensation signal but it is inadequate for the
fast pulse, so I must to switch it to Test3 to perform the measure: by
setting Test3 I can visualize both slow and fast waveform optimally, for
me is the better choise with my W2022A and W2012A.
Now, I know the 1.2.BF.3.0_C6 firmware fix the spike's problem caused by
the hardware's setting "High Freq" by changing the register setting.
Have others noticed this?
Seems to me strange the better choice is now other than "High Freq"
setting, also "Factory" works well without spikes problem.
About this, I tried a downgrade on both W2022A and W2012A and i noticed
no spikes when I connect an external signal generator, while there are
spikes using the internal probe compensation signal.
So, I do not know if it was a case or not, but could spikes really be
caused by noise coming from the power supply?
Mit Freundlichen Grüßen,
Luc
Hi Luc,
thanks for Your detailed report about pulse response. It would be
interesting to find out how the C5-Version with the old High Frequ.
setting is working. Maybe I rename the Test 3 setting like "Pulse" or
something in this way as hint to use this for quick signals.
In the moment I'm a little bit short in time, so I have to stave You off
in relation to the next version.
But don't worry - it will go on.
Kind regards Hayo
@all
Hi Leute,
bin zur Zeit etwas im Stress und muß Euch leider erstmal etwas
vertrösten bis zur nächsten Version. Aber nicht verzagen, es geht auf
jeden Fall weiter.
Bis dahin genießt das schöne Wetter
Gruß Hayo
Hello Hayo,
I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy
occures with these settings:
ADC :High freq Pregain 1.25 Filter IIR1 .With C6 the accuracy is 1dB
less and settings are different.
Just one question ,I can't see anymore the higher resolution in the
frequency counter,is it possible to see
1 kHz at 100 Mhz carrier?
Regards,
Alex
Hi Alex and guys all!
Alex schrieb:
>I tested the W2022a with FW c2/C5 at 100 MHz 100mV, the best accuracy>occures with these settings: ADC :High freq Pregain 1.25 Filter IIR1
It would be possible to see some screenshots, please?
I mean a screenshot for each acquisition mode: noise filter off, noise
filter smooth, noise filter strong, noise filter IIR 1 stage, noise
filter IIR 2 stage and noise filter IIR 3 stage.
Due the filter switch in STOP mode this is easy to do.
However, should not the best results be obtained without filters?
Alex schrieb:
>With C6 the accuracy is 1dB less and settings are different.
It would be possible to know how the DSO is set for better performances
in this case, please?
@Alex
Alex, is your W2022A a standard version or a modified version?
Thanks in advance.
Mit Freundlichen Grüßen,
Luc
Hello,
my W2022A is standard.About the screenshot Let's wait the next version
from Hayo.
Without any filter at 50MHz and upper the noise cause a level peak error
because,up to now,there isn't a sin interpolation available.
I only tried C6 ,anyway works well up to 50MHz and fix some issue, now
I'm using the previous on the lab.
Sandro(Alex)
Hi Alex(Sandro) and guys all!
Alex schrieb:
>my W2022A is standard.
Thank You for the answer!
Alex schrieb:
>About the screenshot Let's wait the next version from Hayo.
Thank You Alex, You are very kindly, then I will wait.
Alex schrieb:
>Without any filter at 50MHz and upper the noise cause a level peak error>because,up to now,there isn't a sin interpolation available.
I know, it was my intention to talk about this.
Alex, You tested your W2022A with a 100 MHz 100mV, I guess a leveled
signal generator, so have You noticed that signal amplitude depend on
the trigger treshold?
I mean, when the trigger treshold is not a bit below the waveform's peak
it is then continually moving and lower level than when the trigger
level is just below the waveform's peak and it is itself more steady and
its level has much more great amplitude.
In short, the size of the displayed signal depends on the position of
the trigger threshold, if the trigger threshold is low, the amplitude of
the signal is so and the waveform is moving, whereas if the amplitude is
high it becomes high itself and the waveform is more steady.
Maybe it is due sin(X/X) lack, maybe it is for ather reasons...
I tested both W2012A and W2022A up to 170MHz and they work well, if it
were not for a lack linearity problem and poor representation due up to
now there is not a sin(X/X) interpolation available.
From my test on high frequencies the W2022A is better than the W2012A.
Both W2012A and W2022A I tested are not modified unit, they are standard
manufactured by Welec.
Alex schrieb:
>I only tried C6 ,anyway works well up to 50MHz and fix some issue, now>I'm using the previous on the lab.
Can you kindly tell us how your W2022A is set for the better
performances with the C6 release?
I mean the Hardware menu's settings and the Filter setting in the Aquire
menu.
Thanks in advance.
Mit Freundlichen Grüßen,
Luc
Hallo Leute
Ich habe vor ein paar Tagen ein Welec W2024A geerbt.
Nach der ersten Euphorie kam nach einem Vergleich mit meinen anderen
Oszis schnell die Ernüchterung. (Ich Arbeite sonst mit einem Hameg
HM1005 und einem Tektronix TDS 340).
Gestern habe Ich mich dann getraut die Kiste zu Flashen dabei ist mir
aufgefallen das eure Flashsoftware ein Problem mit unterschiedlichen COM
Ports zu haben scheint. Zuerst auf COM 1 kam immer wieder die Meldung
wie oben beschrieben mal Abbruch in Zeile 30 mal in 234 u.s.w. ein
Neustart des PC konnte auch nicht helfen, nach ca. 20 missglückten
versuchen habe Ich dann mein Glück mit COM 2 Probiert und da
funktioniert es immer. (Die W2000 Update Software funktioniert bei mir
überhaupt nicht b.z.w. behaupte immer „File not Found“). Ich habe jetzt
die Letzten 3 Versionen eurer Firmware ausprobiert und muss sagen Ihr
habt ganze Arbeit geleistet Kompliment!!!! Mir ist aber auch aufgefallen
das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch
angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version
3.0_C6“
Mache Ich hier etwas falsch oder liegt das an den (Noch nicht
vorgenommenen Hardware Änderrungen)? Ich habe leider keine
Bedienungsanleitung und alles was Ich im Netz gefunden habe ist in
English und beinhaltet sicher auch nicht eure Änderrungen.
Gibt es vielleicht eine Bedienungsanleitung die einem Einsteiger die
Funktionen des Geräts erklärt? Ich habe gesehen das ihr eine Huckepack
Platine entworfen habt wenn das möglich ist würde Ich mich an der
Sammelbestellung noch ganz gerne beteiligen.
Ich hoffe meine Erfahrungen helfen euch weiter.
Gruss Rudi
Hallo Rudi,
> (Die W2000 Update Software funktioniert bei mir> überhaupt nicht b.z.w. behaupte immer „File not Found“).
die originale Upd-Software ist Schrott, dauert auch viel zu lange!
Am schnellsten ist der Germsloader, da muß aber das komplette Paket
heruntergeladen werden...
Hier der Link für die neuen Downloader, müssen nicht installiert werden
und funktionieren einwandfrei:
---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"> Mir ist aber auch aufgefallen> das die angezeigten Spannungen nicht korrekt sind b.z.w. ca. 60% zu hoch> angezeigt werden. Aus 10 V PK-PK werden bei mir 16V PK-PK. „Version> 3.0_C6“
Ich habe auch im Leerlauf so um die 400-600mV Pk-Pk(bei jeder Version),
egal welchen Filter ich einschalte...Hayo wird's schon richten :-)
> Ich habe gesehen das ihr eine Huckepack> Platine entworfen habt...
Schick mir mal eine PM, habe einen kompletten Satz inkl. Platinen
abzugeben.
Gruß Michael
Hallo
Ja genau diese Uploader habe Ich benutzt!!!
Bei offenen Eingängen ist das mehr oder weniger Normal da kommen
natürlich Einstreuungen rein oder Leck ströme an den Sperrschichten der
Eingangs OPs bei anliegendem Signal sind 60% Abweichung aber nicht
akzeptabel mal schauen wie es nach dem Hardwareupdate aussieht.
Rudi
Was für ein Signal hast du denn eingespeist? Das Welec ist zwar kein
Präzisionsgerät aber 60% Abweichung hat es definitv nicht solange man
sich nicht in höheren Frequenzbereichen bewegt.
Gruß
Michael
Hallo,
ich habe ein 4-Kanal-Welec (W2014A, sofern das überhaupt eine Rolle
spielt) abzugeben.
Das Gerät besitzt das Schirmblech aus galvanisch verzinntem Stahlblech,
die DACs sind bereits auf die 16 bit Version umgerüstet und Kanal 4 ist
für die Huckepackplatine vorbereitet, sprich die originale Eingangsstufe
ist entfernt.
Die anderen Kanäle besitzen die 24.9 Ohm (0.1%) Widerstände vor den
ADCs.
Zum Scope kommen drei fertig aufgebaute sowie vier nicht bestückte
Huckepackplatinen hinzu.
Zum Gerät gehören die vier Tastköpfe.
Als Bonus gibt es einen meiner selbstgebaut aktiven Tastköpfe V4b dazu.
Bei Interesse mailt einfach an: branadic [ed] users (punkt) sf {punkt}
net
branadic
Müssen wir uns Sorgen machen?
Das klingt ja fast nach Projektaufgabe! :-(
Alex braucht dringend einen 4Kanäler, finde ich. Wenn das Leon-Design
mit 4 Kanälen arbeiten würde wäre ich schon längst mit Feuer und Flamme
dran am Software-schreiben.
Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal
50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu?
Jörg
Jörg H. schrieb:> Ich würde Alex auch einen Teil des Gerätes sponsorn. Ich tue schon mal> 50€ in den virtuellen Pott. Machen noch mehr mit? Wie stünde Alex dazu?
Ich bin dabei, Betrag unbenannt. Warten wir auf Alex.
Ach ja, Hayo hatte sich ja irgendwie gegen jedes Sponsering
ausgesprochen - da würde ich aber noch viel mehr hin überweisen (wenn
Interesse ;-))
Viele Grüße,
Egberto
Jörg H. schrieb:> Müssen wir uns Sorgen machen?> Das klingt ja fast nach Projektaufgabe!
Genau das ist es. Ich möchte Projektleichen loswerden und für mich zählt
das Welec mittlerweile dazu. Ein kurzer Abriss:
Im Oktober/November 2009 haben Walter und ich die erste Version der
Huckepackplatine entworfen und gelayoutet, im Februar 2010 wurde die
erste Version dann vorgestellt und vermessen. Dieser Version sind drei
weitere Versionen gefolgt.
Im Dezember letzten Jahres wurde der Einbau der finalen Version
dokumentiert und die erzielten Möglichkeiten vorgestellt.
Bis heute hat die Huckepackplatine keine Softwareunterstützung erfahren
und ich sehe offen gestanden auch nicht, dass sich daran was ändern
wird.
Auch das Leon-Design wird noch eine ganze Weile brauchen. Alex ist
mittlerweile berufstätig und zeitlich eingeschränkt, nicht zuletzt dank
Freundin.
Im Laufe des Projektes sind unzählige Leute, die anfangs mit Eifer dabei
waren, heimlich still und leise untergetaucht und waren nicht mehr
gesehen.
Als Walter das Projekt verlassen hat gab es einen kurzen Aufschrei und
die Unterstützung der Huckepackplatine ist in der Prioritätenliste ganz
nach oben gerutscht. Davon ist nicht viel über geblieben.
Salz macht aus Wasser noch lange keine Suppe und die Änderungen an der
Firmware mögen Hayo wichtig erscheinen, aber mir genügen diese schon
lang nicht mehr, zu viel Schein, zu wenig echte Funktionalität, viel zu
viel für das Auge.
Für mich steht das Projekt seit der Fertigstellung der Huckepackplatine
still. Unzähliges Nachfragen, wann die Huckepackplatinenansteuerung in
Angriff genommen wird, hat nicht den Erfolg gebracht.
Daher meine Entscheidung, ich bitte diese zu verstehen.
branadic
Aber das ist doch kein Grund die Flinte ins Korn zu werfen.
Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja
unbezahlbarer Aufwand drin.
In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber.
Letztes Wochenende hätte ich meine Huckepackplatinen fast bestückt, wenn
mir ein Kollege nicht das Equipment abgezogen hätte. Steht auf jeden
Fall noch auf der Liste.
Supportest du den Einbau noch, auch wenn du selber keine Platinen hast?
Jörg
Jörg H. schrieb:> Aber das ist doch kein Grund die Flinte ins Korn zu werfen.> Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja> unbezahlbarer Aufwand drin.
Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg
eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene
regelmässig.
Meine Empfehlung: nicht groß drüber nachdenken.
/Hannes
¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht
ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."
Johannes S. (johannes_s94) schrieb:
> Das legt die Vermutung nah, dass der plakative Ausstieg> eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene> regelmässig.
Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein.
Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930"
Aber deswegen nicht entmutigen lassen und vor allem nicht um Gnade
winseln.
Grüße
Klaus Bauer
Jörg H. schrieb:> Aber das ist doch kein Grund die Flinte ins Korn zu werfen.> Ich würde meine Basteleien nie für Geld verkaufen, da steckt ja> unbezahlbarer Aufwand drin.> In diesem Fall fände ich es auch etwas unfair euren "Kunden" gegenüber.
Hallo Jörg,
die Entscheidung muss man mir überlassen. Ich habe genug Baustellen zu
bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und
gern verzichten.
Jörg H. schrieb:> Supportest du den Einbau noch, auch wenn du selber keine Platinen hast?
Klar, das hat Walter angeboten und das gilt für mich gleichermaßen.
Johannes S. schrieb:> Eben. Und genau das legt die Vermutung nah, dass der plakative Ausstieg> eher ein Statement¹ ist. Sowas gibt es (auch) in der Open-Source-Szene> regelmässig.>> Meine Empfehlung: nicht groß drüber nachdenken.>> /Hannes>> ¹) Das Statement lautet: "Ihr nehmt mich und meine Arbeit nicht> ausreichend ernst/wichtig, also hab ich euch nicht mehr lieb."Klaus Bauer schrieb:> Stimmt, das scheint bei manchen Leuten an der Tagesordnung zu sein.>> Beitrag "Projekt: DDS basierter Funktionsgenerator mit AD5930"
Noch einmal, ich bin niemandem Rechenschaft schuldig und die
Entscheidung treffe ich ganz allein für mich, dazu brauche ich kein
Feedback von irgendwelchen Leute die meinen sich nur aktiv beteiligen zu
müssen, wenn man mit dem Knüppel auf jemanden hauen kann und sonst nicht
konstruktives beitragen. Die Gründe für meine Entscheidung sind auch
ganz allein meine Sache und hat euch nicht zu interessieren.
Ich euch, lasst jedwede Unterstellung oder Verleumdung meiner Person,
das gilt insbesondere für Johannes S. und Klaus!
Danke, branadic
branadic (Gast)schrieb:
> Ich habe genug Baustellen zu> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und> gern verzichten.
Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder
muß
man mit unfertigen Projekten weiterleben.
Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten)
Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen
welche danach nutzlos sind.
Darüber sollte mal nachgedacht werden.
Gruß
Klaus
Klaus Bauer schrieb:> branadic (Gast)schrieb:>>> Ich habe genug Baustellen zu>> bedienen, da kann ich auf die ein oder andere Dauerbaustelle gut und>> gern verzichten.>> Frage: Entsteht mal aus den vielen "Baustellen" was produktives, oder> muß> man mit unfertigen Projekten weiterleben.> Ich finde es unfair gegenüber den (nicht technisch Entwicklungsbegabten)> Leuten hier Hoffnungen vorzugaukeln, worauf diese sich Bauteile zulegen> welche danach nutzlos sind.> Darüber sollte mal nachgedacht werden.>> Gruß>> Klaus
Ich kenn dich nicht und habe mir dir nichts zu tun, ich bin dir zu
nichts verpflichtet und wenn du der Meinung bist technisch unbegabt zu
sein, so steht es dir frei das zu ändern! Aber versuche nicht mich für
deine Unfähigkeit in die Verantwortung zu ziehen!
Es wurde keine Hoffnung vorgegaulkelt, sondern eine Lösung erarbeitet.
Diese Lösung hat bisher keine Unterstützung gefunden und damit ist das
Thema Welec für mich beendet. Alle Imformationen zur Huckepackplatine
sind veröffentlicht worden und für jedermann frei zugänglich, was willst
du eigentlich noch? Hast du auch nur eine Minute mit in die Entwicklung
gesteckt? Du hast doch bisher alles mundgerecht bekommen, ohne selbst
etwas beigetragen zu haben!
Ich versteh gar nicht, warum hier von der "Knüppeltruppe" so ein Wind
gemacht wird. Andere Mitwirkende haben sich irgendwann einfach nicht
mehr gemeldet. Hat da jemand was gesagt?
Als Walter sich vom Projekt verabschiedet hat, hat da irgendwer das
Motzen angefangen? Warum wird jetzt wo ich klipp und klar sage das ich
keine Lust mehr auf dieses Langzeitprojekt habe, weil ich ein Messmittel
brauche und keine Entwicklungsplattform, so ein Wind gemacht?
Die Huckepackplatine ist fertig entwickelt und muss nur noch eingebaut
und durch die Software unterstützt werden.
Noch einmal ganz klar für dich Klaus, lass die Unterstellungen gegenüber
meiner Person. Du musst mit keinem meiner Projekte leben, ich bin nicht
zu deiner Unterhaltung da. Die Entwicklung der Huckepackplatine ist
abgeschlossen!!! Abgeschlossen!!!
Das Welec bleibt aber eine Baustelle, solange das neue FPGA-Design mit
der neuen Firmware nicht die neue Basis bilden und die Huckepackplatine
unterstützen. Ich möchte nicht mehr länger warten bis das so weit ist,
weil ich, ich sage das noch einmal, ein Messmittel und nicht länger eine
Entwicklungsplattform brauche. Ich hoffe das ist jetzt auch endlich bei
dir angekommen.
Statt in Foren zu pöbeln solltest du die Energie lieber dazu verwenden,
dich in die Themen einzuarbeiten, um selbst auch mal etwas, wie du es so
schön formuliert hast, produktives beizutragen!
Frage: Ist das jetzt endlich auch bei dir angekommen?
branadic
Ich habe großen Respekt vor branadic, hayo, alex und all den andern die
dieses Projekt so weit gebracht haben, danke. Ich kann auch nicht
verstehen, dass manche Leute jetzt hier rumpöbeln, gerade über Menschen
die sich hier besonders eingebracht haben.
Ich habe das Projekt gern verfolgt, dass es jetzt vorläufig nicht
weitergeht ist bedauerlich. Alle die wie ich bis jetzt sich nicht aktiv
an der Entwicklung beteiligt haben, aber Interesse am Fortgang haben,
können sich jetzt an die eigene Nase fassen.
@branadic: Willst du dein Welec Equipment nicht liebe einmotten, wäre
doch schade wenn hier doch noch was zustande kommt und du nicht davon
profitieren würdest.
Gruß
Stefan
Kleiner Vorschlag am Rande: ímmer wenn man veröffentlichte Oszillogramme
in Fachzeitschriften oder sonstwo sieht, sieht man auf den ersten Blick
dass es sich um ein Bild eines Tektronix Geräts handelt weil in der
linken oberen Ecke das "Tek" steht. Wie wäre es wenn sowas auch hier
gemacht würde? Ich fänds lustig. Besonders wenn sich manche Leute auf
einmal fragen: was ist das denn für ein Hersteller? Das sieht ja richtig
gut aus von Funktionsumfang und Design her...
Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
moin,
> Falls es umgesetzt werden sollte fragt sich nur: was für ein Kürzel?
Gute Idee! Als Kürzel käme ja eigentlich nur " WT " in Frage...
Ansonsten fände ich die "Sinuskurve" ganz schick...
branadic (Gast) schrieb:
> Frage: Ist das jetzt endlich auch bei dir angekommen?
Antwort : JA, ich hoffe bei all den anderen nicht so technisch
hochbegabten auch.
Klaus
Hallo!
Ich finde es auch sehr schade, dass wir keine neuen Entwickler für das
Open Source Projekt mehr finden.
Unsere zwei größten Mankos sind, dass wir einerseits zu wenig im
Internet präsent sind, und dass den meisten Open Source Entwicklern die
Kompetenzen für so eine Embedded Systems Programmierung fehlt.
Leider schauen die meisten Personen nur auf den kurzzeitigen Erfolg, da
man mit dieser Strategie die größten positiven Rückmeldungen bekommt.
Mit Hayos Verbesserungen der Software mit dem originalen FPGA-Design ist
leider die Warscheinlichkeit von Nachschub an Entwicklern für das
LEON3-FPGA-Design stark geschrumpft.
Hayo hat es geschafft, dass die meisten Nutzer mit dem Oszilloskop
zufrieden sind.
Was aber klar ist, dass dieses Oszi so niemals überall so gut oder
besser wie die Markenoszilloskope sein wird.
Branadic hat mit Walter meiner Meinung nach eine sehr gute Arbeit beim
analogen Frontend gemacht.
Wenn ich bei der Entwicklung des LEON3-Zeug schon weiter wäre, hätte ich
das sicher schon integriert.
Schließlich sollte man möglichst versuchen, die eingebrachten
Fähigkeiten und Arbeitsleistungen anderer möglichst versuchen zu
Integrieren und zu Ergänzen, da man sonst irgendwann nur mehr alleine
weiter entwickelt.
MfG
Alexander
Hallo zusammen.
Ich hätte folgenden Vorschlag: schreiben wir doch (von mir aus ich)
einen Artikel für das embedded projects journal. Da erreicht man Leute,
die sich für Open Source begeistern und durchaus auch sehr fähige
Menschen, jedenfalls gibt es dort immer wieder ganz interessante
Projekte.
Man könnte auch versuchen, Alex' Weg fortzuführen und Professoren
kontaktieren, um Diplomanden für das Projekt zu gewinnen.
Ich z.B. habe nach wie vor guten Kontakt zu einem Professor, der selbst
in Sachen VHDL sehr versiert und auch aktiv ist - der könnte evtl.
Studenten dafür gewinnen. Denn meiner Erfahrung nach wollen viele was in
Richtung VHDL machen, finden aber kein passendes Thema in der Industrie.
Mir ging es übrigens auch so, genauso wie einem Masterstudenten den wir
zur Zeit in der Arbeit beschäftigen. Leider habe ich selsbt keine Zeit
um einen wirklich sinnvollen Beitrag zu leisten aber das könnte doch ein
Weg sein...
Eure Meinung?
Gruß
Michael
>Da erreicht man Leute,>die sich für Open Source begeistern und durchaus auch sehr fähige>Menschen
Zumindest an der Firmware hier ist es sehr schwer sich zu beteiligen.
Die letzte Aktualisierung des Codes in Sourceforge ist 6 Monate her
(stammt noch von mir) und den Quellcode hier rauszusuchen wird sich auch
keiner antun. Zumindest hatte ich darauf irgendwann keine Lust mehr und
habs einfach gelassen.
Von daher mach es für mich keinen Sinn, Leute extra für die Firmware
anzuwerben.
In diesem Sinne.
Hallo Michael!
Deine Idee mit dem embedded projects journal finde ich sehr gut.
Ich würde mich sehr über so einen Beitrag freuen.
Vor allem sollte betont werden, dass sich das Welec Oszilloskop quasi
als Open Source Prototyping Plattform sehr gut eignet (Verfügbarkeit,
Doppelnutzen,...).
Unser langfristiges Ziel ist ein vollkommen offenes Oszilloskop mit
hoher Qualität zu schaffen. Zur VHDL- und Firmware-Entwicklung schadet
die mäßige Signalqualität nicht.
Weiters sollte auf die Möglichkeit der Adaptierung auf hochauflösenenden
ADCs hingewiesen werden (Doku dazu gibts aus Mangel an Interesse im
Moment keine).
Übrigens ist der Zustand des VHDL-Design wirklich schon reif für ein
Release.
Das größte Manko liegt an der Firmware, die noch weit von einem Release
entfernt ist.
Die Dokumentation habe ich im Moment auch nur sehr minimalistisch
ausgeführt, da den zuküftigen Softwareentwicklern fertig programmierte
Hardwareschnittstellen mehr bringen und ich zugleich die von mir
geschriebene Hardware testen kann.
@Stefan: Die Originalsoftware verbessern bringt nur den Wittigs und den
Besitzern des Welec was, sonst niemanden.
MfG
Alexander
Hallo Alex.
Es ist ja toll, dass du das VHDL Design schon zur Einsatzbereitschaft
gebracht hast, dafür zolle ich dir meinen größten Respekt!
Dann werde ich mal zusehen, dass ich einen Artikel entwerfe. In Bezug
auf dein VHDL/Leon3 Design werde ich dann vermutlich aber auf dich
zukommen müssen, da ich darüber leider noch nicht sonderlich viel weiß.
Ich könnte mir vorstellen, dass einige Leute bei dem Projekt Open Source
Oszi hellhörig werden, hoffentlich täusche ich mich da nicht.
Wenn die Programmiermaschine Hayo wieder mehr Zeit hat, kann er sich ja
vielleicht auch mit dem Thema Leon3 beschäftigen, dann wären
Fortschritte garantiert, allerdings wäre es dann natürlich toll wenn es
mit svn klappen würde...
Ich finde es übrigens ziemlich schade, dass branadic aufgegeben hat.
Vielleicht wird es ja trotzdem noch was mit der Huckepack Unterstützung,
dann wäre die Arbeit von ihm und Walter nicht vergebens gewesen.
Gruß
Michael
Von mir auch nochmal ein großes Danke an die die hier mitbearbeitet
haben und werden.
Ihr habt aus dem Scope ein für mich verwendbares Werkzeug gemacht. Ich
beschäftige mich mit Elektronik nur als Hobby und nicht beruflich,
konnte so leider hier auch nichts beitragen - aber von eurem Einsatz
profitieren.
Für das Geld, das es mich die Anschaffung gekostet hat, habt ihr und das
umsonst, den Nutzen des Gerätes für mich mehr als verdoppelt. DANKE
Ich hoffe, dass es weitergeht und wünsche allen hier beteiligten
mindestens so viel Spaß am Hobby, wie es mir bereitet.
Hi @ all.sich
I'm just alive, so don't worry! Work will go on soon...
Hallo allerseits,
leider hatte ich in letzter Zeit etwas wenig von selbiger für unser
Projekt. Mit Bedauern lese ich, dass Branadic sich aus dem Projekt
zurückzieht. Ich weiß, dass sich das mit der Hardwareunterstützung etwas
hinzieht.
Ich möchte aber nochmals darauf hinweisen, dass zeitweilige
Entwicklungspausen kein Grund zur Besorgnis sind. Da ich berufstätig bin
ist die Zeit manchmal etwas knapp. Die beste aller Ehefrauen ist da
wirklich sehr tolerant, wenn man bedenkt wieviel Zeit ich schon in das
Projekt gesteckt habe.
Ich möchte ebenfalls darauf hinweisen, dass ich das Ganze aus reinem
Spass an der Sache mache. Ich könnte mir ohne Weiteres auch ein 3000,-
Euro Gerät kaufen wenn es mir darauf ankäme. Nur würde das keinen Spaß
machen!
Zu den beschriebenen Problemen:
- das mit den falschen Messwerten werde ich mal prüfen und ggf.
korrigieren
- ich stelle in den nächsten Tagen mal eine weitere Compilation bereit
bei der die USTB-Bereiche wieder gehen.
Noch einen sonnigen Tag
Hayo
So, die Platinen sind bestückt. Hat deutlich länger gedauert als ich
dachte, mit Bauteilgröße 0402 ist das doch sehr fummelig. Gut das Kurt
etwas Reserve in die Tütchen gepackt hat, ein paar von den Sandkörnern
sind mir aus der Pinzette gehüpft, natürlich auf nimmerwiedersehen.
Nun habe ich den Compiler vorgewärmt und Hayos Software in der Version
C6 zum Üben durchkompiliert. Spricht eigentlich was dagegen, die im
Sourceforge-Branch "bf" einzuchecken, zur ggf. gemeinsamen Arbeit? Dort
liegen anscheinend ältere Sourcen. Ich kenne die Arbeitsweise hier
zugegeben nicht.
Ich Noob suche mir gerade zusammen, wie denn die Ansteuerung der Platine
zu machen wäre, bin für Starthilfe dankbar.
Ist diese Schaltplanänderung von Kurt aktuell? Trägt das auch für
4Kanäler?
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Wenn ich das recht deute wird aus dem 16-Bit Schieberegister aus U23/U21
dann ein 24-Bit Schieberegister U23/U21/U24. Die Chip-Selects der
Eingangsstufen werden daraus gewonnen. Sind die anderen Ausgänge von U24
obsolet? Macht das FPGA auch 24-Bit breite Shifts? Um unsere
Chip-Selects wieder wegzunehmen muß U24 neu "befüllt" werden. Machen die
Takte dann nicht unsere Daten im LMH651 kaputt?
Mir ist auch noch nicht klar, wie SPI von der Software aus bedient wird.
Wie werden die von U25 erzeugten Chip-Selects programmiert, wie die
Anzahl der Shifts eingestellt? In der Software wird fleißig auf
serdata->np_piodata zugegriffen, der Transfer anscheinend mit
serstartsw->np_piodata ausgelöst.
Jörg
Ich antworte mir mal selbst, mit meinen Forschungsergebnissen von
gestern. Bin durch Hardware und Software gekrochen.
Die SPI-Hardware im Nios-Design macht mehr selbst als ich dachte. Der
Chip-Select Adressdecoder U5 wird vom obersten Hex-Digit des
Registerwerts serdata->np_piodata eingestellt, genau genommen Bits
22:20. Die Länge des Schiebetransfers ist entweder immer 24 Bit, oder
(was ich nicht hoffen will) von den Bits 22:20 abhängig. Die DACs
brauchen 24 Bit, die Schieberegisterketten 8 oder 16.
Um das genauer rauszufinden muß ich mir da Drähte anlöten, zum Logic
Analyzer, um das im Betrieb zu messen.
Den Anschluß der Huckepackplatinen stelle ich mir daher etwas anders
vor.
Ich hoffe das FPGA schiebt auch 24 Bit an Daten wenn Register Bits 22:20
gleich Null sind, also keiner von den bestehenden Chip Selects aktiv
ist. Dann können wir die Platinen direkt an SPI Clock und Data
anschließen, nicht hinter ein Schieberegister. Auf den Platinen müssen
die Pullups entfallen oder vergrößert werden, denn die SPI-Signale sind
wegen der Transistorschaltung Q9,Q10 speziell nach low recht schwach.
Den Schieberegistern habe ich ein Stück weit hinterhergemessen. In
Brunos Bestückungsplan "Analog-Input-Part_assignment_V3_4.pdf" ist eine
Diskrepanz zum Schaltplan, die mich in die Irre führte. Sein U21 ist in
Wirklichkeit U23. U21 ist auf der anderen Platinenseite, unter dem
Abschirmkäfig von Kanal 1.
Wo ich gerade bei den Bauteilbezeichnungen der Schieberegister bin: Das
im Plan unbeschriftete MC4094 (unterhalb vom 74HCT238, der U23 wäre) ist
U22. Weiter rechts und nicht mehr im Bild sind zwei weitere
Schieberegister, wie die heißen weiß ich noch nicht. Wieder auf der
anderen Seite, nahe der seriellen Buchse ist U26.
Ich bin glücklicher Besitzer eines Stereomikroskops, zum Löten der
Platinen sehr nützlich. Gestern habe ich Sittenstrolch damit den
Schieberegistern zwischen die Beine geguckt um zu sehen welche
Ausgangsleitungen tatsächlich noch unbeschaltet sind. Wir brauchen ja 4
Stück für die Chip Selects der Eingangsplatinen. Der Schaltplan ist da
noch recht unvollständig. Auf der den Chips der Oberseite gehen von
allen Ausgängen Leiterbahnen weg, die sind also anscheinend alle belegt.
Auf der Unterseite sind insgesamt 6 Ausgänge frei, aber ungünstig
verteilt, jeweils 3 bei U21 und U26, an verschiedenen Positionen. Dann
nehmen wir wohl besser Ausgänge die an die alten Eigangsstufen gehen und
deshalb obsolet werden.
Wie störempfindlich sind die neuen Eingangsstufen eigentlich? Sollte man
die besser mit in die Abschirmkäfige löten? Dann sähe es auf der Platine
vielleicht auch nicht so schlimm aus, das Gebastel wäre versteckt.
So long,
Jörg
Hallo Jörg,
ich sehe Du kniest Dich da voll rein. Wenn Du firmwareseitig
Unterstützung brauchst sag Bescheid.. Ich kann Dir dann die Stellen
sagen an denen Du im Coding eingreifen mußt.
Gruß Hayo
@Hayo:
Danke, ich melde mich. Du meinst warscheinlich die Funktion
Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach
Eingangsstufe.
Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man
als Kennung anders brücken könnte? Dann brauchen wir keinen
Konfigurationsdialog ob alte oder neue Eingangsstufe.
@All:
Ich messe gerade mit dem Logicanalyzer wie das FPGA denn den SPI
bedient. Leider tut es das bereits maßgeschneidert für die jeweilige
Empfangskette, nicht generisch. Die Anzahl der erzeugten Bitclocks ist
genau passend, 8 Bit für Chip Selects mit einem Schieberegister, 16 Bit
für Chip Selects mit zwei Schieberegistern, 24 Bit für die
DAC-Chipselects. Für letzere wird Enable während der Bits gehalten, für
die Schieberegister ist es ein Strobe hinter den Bits. Von daher klappt
es nicht, irgendwelche Register umzuketten oder sich dahinter zu hängen.
Für Adressbits = 0 wird gar kein Signal erzeugt.
Ich habe aber eine Art Lücke gefunden: Für die eigentlich nicht
vorhandenen Adressen 8 und 9 (der Demux kümmert sich nur um 0 bis 7)
werden auch Daten rausgetaktet, und zwar 16 Bit wie für 2
Schieberegister. Der Adressdekoder U25 kriegt eine 0, erzeugt dann also
keinen verwendeten Chip Select. Eigentlich genau das was ich suchte,
außer das wir 24 Bit brauchen. Man muß so eine Adresse also zweimal
beschreiben.
So long,
Jörg
Hallo Jörg!
Es freut mich zu lesen, dass du für die nette Huckepack-Platine eine
Software-Unterstützung dazufügst. Das ist für mich aus Respekt für die
geleistete Arbeit von unseren Analogtechnikern ein muss.
Das der NIOS die SPI Ansteuerung in Hardware gemacht hat, schreckt mich
ein wenig und erklärt auch ziemlich, weshalb das noch nicht vorher
(erfolgreich) in Angriff genommen wurde. - Selbst ich habe nur das eine
Oszi und keinen Logic-Analyser zur Hand.
Anfangs hatte ich die SPI Ansteuerung auch beim LEON3 Design in Hardware
vorgesehen.
Während ich die Software-Treiber dafür schrieb, fiel mir aber auf wie
blöd so eine zugescheiderte Ansteuerung in einem möglicht portablen
FPGA-Design ist, und habe das ganze auf GPOs zurückgebaut.
MfG
Alexander
Jörg H. schrieb:> @Hayo:> Danke, ich melde mich. Du meinst warscheinlich die Funktion> Hardware::SetSwitches(). Dort werde ich verzweigen müssen, je nach> Eingangsstufe.
Jupp, eine (ganz kleine) Verzweigung ist schon drin für Gain 1,25.
Ansonsten habe ich alles kommentiert was sich mir so an Funktionen
erschlossen hat. Der WELEC-Programmierer war mit Kommentaren und Doku
ziemlich geizig...
> Gibt es auf der Tastenplatine eigentlich noch freie Eingänge, die man> als Kennung anders brücken könnte? Dann brauchen wir keinen> Konfigurationsdialog ob alte oder neue Eingangsstufe.
Keine Ahnung, die Idee ist gut, aber ich finde das mit dem Konfigmenü
auch nicht so schlimm.
Gruß Hayo
Muss man überhaupt unterscheiden? Wer die Huckepackplatine
nicht hat, den stört doch das Bitgewackel nicht. Und wer
den ursprünglichen Eingang nicht nutzt, dem kann doch egal
sein, wie der eingestellt ist?
Guido schrieb:> Muss man überhaupt unterscheiden? Wer die Huckepackplatine> nicht hat, den stört doch das Bitgewackel nicht. Und wer> den ursprünglichen Eingang nicht nutzt, dem kann doch egal> sein, wie der eingestellt ist?
Ich widme eine Steuerleitung der alten Eingangsstufe um, zu einem Chip
Select für die neue. Von daher stört es, diese Leitung muß penibel
bedient werden. Und wenn man (wie ich) nicht alles auslötet, dann muß
der letzte Analogschalter der alten Stufe offenbleiben, sonst muß man
ihn entfernen.
Die neue Eingangsstufe hat zudem mehr Möglichkeiten, das könnte man in
Zukunft nutzen. Die Verstärkung ist fein einstellbar, die
Bandbreitenbegrenzung hat mehrere Stufen.
Der SPI-Bus kann nicht lesen, nur schreiben, die Einstellungen erfolgen
blind. Sonst ginge das damit ganz gut.
Man könnte das Oszi theoretisch über das gemessene Signal "erfühlen"
lassen, welche Eingangsstufe es hat.
Aber erstmal muß es überhaupt funktionieren. Ich komme frühestens am
Wochenende dazu.
@Hayo: Viele Variablen werden ins Flash geschrieben und davon wieder
gelesen, und da gibt es noch auskommentierte Lücken. Ich habe nun 4
Flags neu eingeführt, die pro Kanal anzeigen ob alte oder neue
Eingangsstufe. Kann ich mir eine solche Lücke aussuchen, oder muß das
aus irgendwelchen Kompatibilitätsgründen frei bleiben?
Jörg
Ich such Dir mal 4 raus. bzw. da es ja eine long Variable ist, könnte
man natürlich auch alle vier Flags in einen Speicherplatz mergen.
-> ich sag gleich bescheid
Hayo
Also da es sich ja um eine feste Hardwareinformation handelt gehört das
ja eigentlich ins Protected Flash. Du könntest die Flags ab
Speicherplatz 80 ablegen.
Wenn Du die Flags lieber ins normale Config Flash schreiben willst würde
ich empfehlen die Werte in der jeweiligen Kanalsektion unterzubringen.
Da bieten sich z.B. an: Speicherplatz 74/92/110/128 -> also nicht
zusammenmergen.
Gruß Hayo
Ein kleines Statusupdate zur Eingangsplatine:
Sie funktioniert, und ich habe sie softwaremäßig "unter Kontrolle". Zwar
noch nicht an allen Stellen der Software, bei Spezialitäten wie
Autorange arbeitet die nämlich an ihren eigenen Funktionen vorbei. Es
sind auch noch keine Kalibrierwerte drin und keine
Konfigurationsmöglichkeit. Ich habe die Einstellungen welcher Kanal
welche Eingangsstufe hat aber immerhin schon wie von Hayo vorgeschlagen
im Protected Flash abgelegt.
Der Anschluß an SPI kann leider doch nicht so wie von mir vorgeschlagen
erfolgen. Der Chip auf der Eingangsstufe mag es nicht, wenn ich ihm zu
lange Datenworte sende. Ich hoffte, er ignoriert die überzähligen Bits,
aber stattdessen akzeptiert er das ganze Datenwort nicht.
Nun wurde es doch "SPI over SPI", Bitbanging mit den bereits über SPI
angesteuerten Registerausgängen. Ist nicht schlimm, nichts wird
langsamer, der Zugriff paßt locker in die Zeit die eh auf die Relais
gewartet wird. Etwas blöd ist nur, daß man sich 2 Signale von der
anderen Seite der Platine holen muß.
An der Hardware der Platinen ist noch Feintuning nötig. Momentan sind
das kleine UKW-Sender, sie schwingen etwas. Andre und sogar Walter
helfen mir netterweise (siehe Skype-Chat), die kriegen das bestimmt hin.
Wenn ich in dieser Software rumfummele kriege ich Zustände. Eigentlich
wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion
hätte und sich dran halten würde. Aber hier sind die Dinge unnötig
kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was
von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den
seriellen Download. Es juckt, da neu anzufangen und eine Codebasis zu
schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem
Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten
beider zugegeben nicht. Hayo, wärst du dabei?
Grüße,
Jörg
Hey Jörg,
ich finde es klasse, welche Fortschritte du erzielst. Nicht nur, dass es
mich freuen würde, wenn die vier Platinchen auf meinem Schreibtisch
irgendwann einsetzbar wären, es freut mich auch für Walter und branadic,
wenn ihre Arbeit Früchte trägt.
Tolle Sache!
Gruß
Michael
Hallo ihr Teilnehmer an der Sammelbstellung der Bauteile für die
Huckepackplatine!
Es hat seitens Digikey einen Fehler beim abpacken gegeben. Aus diesem
Grund sind die Widerstände in 0402 mit 6k8 und 220k vertauscht!
Vor dem bestücken solltet ihr zumindest diese beiden Werte nochmal
nachmessen.
Falls ihr schon bestückt habt und Ersatzwiderstände braucht schicke ich
euch diese kostenlos zu.
Mfg,
Kurt
Hallo an alle,
tut mir leid, dass Ihr momentan so wenig von mir hört. Bin die nächsten
zwei Wochen in Thailand. Melde mich danach wieder. So muß jetzt zum
Flughafen.
Bis dann
Hayo
Hi there,
gruss aus dem sonnigen Thailand - es ist kurz vor 20:00 Uhr und es sind
30 Grad hier - schwitz!
Nach einer Woche Strand habe ich jetzt auch den Kopf wieder frei und
habe eine menge Ideen bezueglich (Umlaute gibts hier nicht auf der
Tastatur) der neuen USTB-Engine. Alles was mir einfiel habe ich
natuerlich sofort am Strand direkt auf das gute alte Offlinemedium
Papier niedergeschrieben. Wenn ich in einer Woche zurueck bin werde ich
mal wieder etwas Bewegung in die Sache bringen.
Vielleicht ist dann ja auch Joerg schon soweit das seine neue
Hardwareansteuerung mit einfliessen kann (sz gibt es auch nicht).
Lasst Euch solange auch die Sonne auf den Bauch scheinen
Gruss Hayo
Don't worry!
I got some new ideas in the meantime on the beach... :)
I will be be back soon and looking forward to go on with the new
version.
Be relaxed and enjoy the summer time meanwhile
Hayo
p.s. going to the beach now to get some more good ideas :)
Hayo W. schrieb:> es ist kurz vor 20:00 Uhr und es sind 30 Grad hier - schwitz!
Hallo Hayo,
erwartest du jetzt soetwas wie Mitleid? ;-)
Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand
verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu
sein. Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar
Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen
lassen.
Gruß
Rainer
Rainer W. schrieb:> Hallo Hayo,> erwartest du jetzt soetwas wie Mitleid? ;-)
Nicht wirklich - aber fuer einen Norddeutschen ist das hier schon eine
harte Nummer mit den Temperaturen. Da heisst es langsam bewegen oder
besser garnicht.
> Gut, dass du neue Kräfte sammeln kannst und eine schöne Zeit in Thailand> verbringst. Wenn ich dich so höre, scheint der WAF von Paperwork ok zu> sein.
Unbedingt! Die beste aller Ehefrauen hat ca. 24 kg Kriminalromane dabei
und ist froh wenn sie in Ruhe lesen kann - da eroeffnen sich mir
ungeahnte Moeglichkeiten ;-)
> Bei Cursor-Anzeige und Delay-Fenster haben sich auch noch ein paar> Dinge gezeigt, die sich hoffentlich mit deinem Insiderwissen abbiegen> lassen.
Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da
schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das
Coding mal auf SFN ansehen.
Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der
RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft? Ich
hatte leider noch keine Zeit dazu.
Gruss Hayo
p.s. es ist garnicht so leicht an nichts zu denken ;-)
Dann will ich mal was gegen mögliche Langeweile tun. Ich habe die BF.3.0
C5 drauf, weil bei der C6 irgendwas (USTB?) gar nicht lief.
Hayo W. schrieb:> Lass hoeren, welche Probleme gibt es da? Vielleicht kann ich mir da> schon ein paar (offline) Gedanken machen. Notfalls kann ich mir hier das> Coding mal auf SFN ansehen.
1. Wenn man das (sogenannte) Delayed Fenster geöffnet hat, haben die
dort dargestellten Cursorpositionen nichts mit der Realität zu tun. Im
Screenshot (CursorPos_Delayed) liegt das Fenster in der rechten Hälfte
des Signale. Die beiden Cursur x1 und x2 stehen im Main an der ersten
steigen Flanke bzw. 80 µs dahinter, also außerhalb des Delayed-Fensters.
Die im "Delayed"-Fenster dargestellten Cursor sind im richtigen Abstand,
aber an einer völlig falscher Position dargestellt.
Gerade ist mir aufgefallen, das möglicherweise für die Cursordarstellung
im Fenster einfach auf die falsche Bezugsposition zugegriffen wird: Ein
Cursor, der im "Main" dicht vor dem Fensteranfang steht, wird im
"Delayed" kurz vor dem Fensterende eingezeichnet. (CursorPos_Delayed2)
2. Wenn man die Cursorposition verdreht, werden oft die Zahlenwerte
nicht aktualisiert (z.b. X2 in CursorValue_wrong). Erst wenn man nach
einer Gedenksekunde (gefühlte 3s?) den Universalregler noch einmal etwas
dreht, springen die angezeigten Zahlenwerte auf den richtigen Wert
(CursorValue_ok.png). Wenn man ohne die genügend lange Pause immer
wieder die Position verdreht, findet gar kein Update statt.
>> Es gab doch vor einigen Wochen die Meldung, dass bei Quickmeasure der> RMS-Wert nur die Haelfte anzeigt. Hat das mal jemand ueberprueft?
Das sieht IMHO gut aus, bei AC-Signal ist RMS = 1/2 Peak-Peak
(RMS_ok.png)
Ich wünsche euch noch schöne Tage in Thailand und gutes Tüfteln
Gruß Rainer
So die Angebetete laesst sich am Strand grillen, da hab ich mal die Zeit
genutzt um den Hotelrechner zu maltraetieren. Schnell mal die
wichtigsten Programme installiert und das Coding runtergeladen - so kann
man ja nicht arbeiten ;-)
@Rainer
Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider
grundsaetzlich etwas langsam. Im Delayed-Modus muss man da noch etwas
mehr Geduld haben, da noch mehr bremsende Grafikausgabe dazukommt. Die
Cursorpositionen kann ich aber leider erst zu Hause am Geraet
ueberpruefen - also in 3 Tagen :)
@Joerg
Jörg H. schrieb:> Wenn ich in dieser Software rumfummele kriege ich Zustände.
Willkommen in meiner Welt ;-)
Du Solltest Dir mal den Spass machenb und Dir das alte Origanalcoding
ansehen. Da bekommt man direkt Ausschlag im Gehirn. Mittlerweile ist das
ja schon einigermassen strukturiert.
> Eigentlich> wäre das ja ganz einfach, wenn man eine vernünftige Hardwareabstrakion> hätte und sich dran halten würde.
Ich hatte mal angedacht einen Hardware Abstraction Layer (HAL) zu bauen,
es dann aber aus Performancegruenden wieder verworfen.
> Aber hier sind die Dinge unnötig> kompliziert, vieles ist für die 4 Kanäle 4 mal codiert (schon mal was> von Arrays gehört?). Das bläht den Code auf und man wartet lange auf den> seriellen Download.
Das war zu Anfang noch viel schlimmer. Ich habe zig hunderte Zeilen
"blinden" copy & paste code rausgeschmissen und durch Schleifen bzw.
Arrays ersetzt -> to be continued...
> Es juckt, da neu anzufangen und eine Codebasis zu> schaffen, die bis auf eine Hardwareschicht unverändert auch auf dem> Leon-Design laufen könnte. Ich kenne die Features und Spezialitäten> beider zugegeben nicht. Hayo, wärst du dabei?
Ich hatte davon erstmal abgesehen, weil die Hardware (WELEC FPGA-Design)
des NIOS voellig undokumentiert ist und man vorher die Funktionalitaeten
genau ermitteln muesste. Um schnell brauchbare Ergebnisse zu bekommen
habe ich mir dann immer einige Hotspots gesucht die ich dann Stueck fuer
Stueck ueberarbeitet habe.
Ich hatte mir das fuer das LEON-Design eine entsprechende
Implementierung vorgenommen da es hier wohl eine komplette Doku der
Funktionen geben wird.
Grundsaetzlich waere ich aber dabei. Das duerfte allerdings eine ganze
Zeit dauern bis wir da was lauffaehiges zusammen haben.
So muss jetzt Coctails besorgen...
Gruss Hayo
Hayo W. schrieb:> Danke fuer die Info. Im Cursor-Modus ist der Werte-Refresh leider> grundsaetzlich etwas langsam.
Langsam wäre ja nicht sooo schlimm, aber der Werte-Refresh kommt garnicht, wenn man den Drehregler nach den mindestens 3 s nicht noch
einmal bewegt.
Gruß Rainer
Hayo W. schrieb:> ... Im Cursor-Modus ist der Werte-Refresh leider grundsaetzlich> etwas langsam.
So, nach etwas Probieren scheint das Update-Problem deutlich klarer.
Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der
Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem
Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das
Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei
Reglerbegung wieder ein Werte-Update angestoßen.
Ich hoffe, der Sun-Downer hat gemundet.
Gruß Rainer
Rainer W. schrieb:> So, nach etwas Probieren scheint das Update-Problem deutlich klarer.> Wenn man den Cursor anfängt zu bewegen, findet einmal ein Update der> Werte statt. Beim Weiterdrehen wird dann nur noch der Cursor auf dem> Bildschirm bewegt, aber anscheinen kein Flag mehr gesetzt, was das> Update anstößt. Erst wenn man die 3s-Pause gewartet hat, wird bei> Reglerbegung wieder ein Werte-Update angestoßen.
Ok, das ist ein guter Hinweis, da kann ich gleich mal das Coding
durchstoebern nach den Verdaechtigen. Hier ist dank Regenzeit bedeckter
Himmel mit kraeftigen Schauern - das Ganze bei 33 Grad. Da bietet sich
ein kleiner Code-Review geradezu an :)
> Ich hoffe, der Sun-Downer hat gemundet.
Hat er. Geht doch nichts ueber einen Kaipi bei der Waerme.
Nebenbei habe ich mir auch noch Gedanken zum Thema Triggerlevel gemacht.
Es wurde ja schon mehrfach kritisiert, dass der Triggerlevel beim
Umschalten des Spannungsbereiches nicht konstant bleibt sondern
stattdessen die Position auf dem Bildschirm. Das fuehrt dazu das der
Level beim Umschalten jedesmal seinen Wert aendert - anders als bei
einem analogen Oszi zum Beispiel.
Grundsaetzlich liesse sich ein konstanter Level schon implementieren,
aber das Problem ist, dass das Triggerlevel-Register nur 8 Bit breit ist
sprich 256 Werte abbilden kann. Das wuerde dazu fuehren, dass beim
Herunterschalten aus einem hohen Spannungsberech der Trigger in die
Begrenzung faehrt und der angezeigte Level nicht mehr mit dem
tatsaechlichen Trigger uebereinstimmt.
Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die
momentane Loesung also technisch bedingt.
Ich hatte mir allerdings ueberlegt ob ich einen "partiell konstanten"
Triggerlevel implementiere, der z.B. beim Hochschalten von niedrigen zu
hohen Spannungsbereichen konstant bleibt. Das Ganze natuerlich per
Triggermenue auswaehlbar.
Werd mal sehen ob das brauchbar ist.
Gruss Hayo
Hi there!
Hayo W. schrieb:
>Der Triggerlevel ist also vom Spannungsbereich abhaengig. Daher ist die>momentane Loesung also technisch bedingt.
Hi Hayo.
Could this be related to the fact that with the Welec's oscilloscopes,
the displayed signal's size depends on the position of the trigger's
threshold?
If the trigger's threshold is low, the signal's amplitude is so and the
waveform is moving, whereas if the amplitude is high it becomes high
itself and the waveform is more steady.
I noticed this when I tested both the W2022A and W2012A for the pulse
responce.
Please, refer to my previous message here
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
Mit Freundlichen Grüßen,
Luc
Hallo Hayo et al,
ich bin selber kurz vor Urlaub, da versuche ich doch mal eine Übergabe
bevor ich die Software nicht mehr wiedererkenne, mit Hayos neuem
Tatendrang!
Der Status zur neuen Eingangsstufe ist wie folgt:
- Im Gehäuse eingebaut habe ich keine Oszillation oder Einstreuung mehr.
Das lag an meinem offenen Aufbau, der hat sich die Signale der
Tastenplatine eingefangen.
- Die Eingangsstufen sind empfindlich. Wogegen ist noch unbekannt, ESD
oder Überspannung. In einem Meßbereich ohne die Relais-Vorteiler habe
ich mir bei Kalibrierübungen mit kleiner Gleichspannung je den
Eingangs-FET zerschossen. Mittlerweile habe ich von Kurt Ersatzteile und
kann die unter kontrollierteren Bedingungen zerstören. ;-)
- Jede Platine verbrät etwa ein Watt, größtenteils am Verstärkerchip.
Der wird in freier Luft über 100°C heiß, in der engen Gehäuseposition
sicher mehr. Wärmekontakt zu dem Stahlblech wäre gut, da liegt er eh
fast an.
- Die Hardwareansteuerung ist in der Software vollständig (Basis BF 3.0
C6), inklusive Programmierung der verschiedenen Gains (1/2/5) und der
Bandbreitenbegrenzung.
- die zur veränderten Empfindlichkeit passenden Skalierwerte in den
Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe
Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen.
- an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch
nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir
derzeit hart reincompiliert.
- Die Software kann keinen echten "Mischbetrieb" der verschiedenen
Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben
diskussionswürdig, ob das überhaupt sein soll und kann. An diesem
prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.
Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins
Flash kommen) und pro Kanal anzeigen, ob neue oder alte Eingangsstufe.
Das wird in Hardware::SetSwitches() abgefragt und je nachdem die neue
oder alte Routine aufgerufen.
Das führt aber nicht so recht weiter, man müßte die Flags überall
abfragen, wo derzeit die Variable "GainIdx" bewertet wird. Zu allem Übel
wird an GainIdx auch noch "herumgefummelt", in Hardware::AutoScale()
wird der vorübergehend auf 1 gesetzt.
In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also
ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen
"ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe
noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und
2er Bereiche, und einen für die 5er Bereiche. (BTW, die Indizes sind
ungünstig, wären besser vertauscht, damit der innere Zugriff schnell
geht. Der letzte Index sollte die 0..255 Tabelle sein. Ferner würde ich
diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann
alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die
Zeichenschleife das nicht tun.)
Nun ja, auch diese Tabelle müßte ich verdoppeln (einmal pro
Eingangsstufe), vor dem Speicherverbrauch schreckte ich noch zurück. Mit
einer Tabelle pro Kanal landet man da allerdings auch.
Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht
korrigiert:
1.) in Hardware::RestoreFromFlash()
statt:
Hardware::SetSwitches(2, -1);
besser:
Hardware::SetSwitches(2, Selected_Voltage_CH2);
2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf,
das tut dem Chip wohl nicht gut. Nur nebenbei, in meinen Projekten habe
ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte
Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem
Timeout, verhindert versehentliches Dauer-Schreiben.
3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß
aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die
Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl
ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am
Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich
drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach
Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt.
Genug für heute, den Sourcecode hänge ich morgen an.
Grüße an nah und fern,
Jörg
Hallo,
wird mir jetzt zeitlich doch arg knapp, deshalb kann ich hier nur noch
einen "Snapshot" hochladen. Ich wollte dass eigentlich noch besser
aufbereiten.
Jörg
Back from Thailand!
Und auch schon wieder aktiv...
@Luc
I guess it is another matter, but I will check this. Thanks for Your
hint.
@Jörg
Das sind eine ganze Menge Hinweise und offene Fragen. Ich werde die mal
durcharbeiten und versuchen alle zu prüfen/beantworten. Mal sehen was
ich schon einbauen kann. Schönen Urlaub.
Gruß Hayo
Hi there!
Welcome back Hayo!
@Hayo
I guess it also and about another matter, I noticed that waveforms shape
are crude and not smooth compare to other DSO when I tested both the
W2022A and the W2012A for the pulse responce.
Is maybe this due to the sin(X/X)'s lack?
I guess the poor graphic representation problem might just to be due up
to now there is not a sin(X/X) interpolation available.
What about this?
Gute Sonntag für alle.
Mit Freundlichen Grüßen,
Luc
Hallo allerseits,
kurzer Report zum aktuellen Stand. Die neue USTB-Engine läuft bereits.
Zur Zeit mache ich noch Fein-Tuning und implementiere die neuen Menüs.
(den Fehler in der alten C6 der die USTB-Funktion blockiert hat habe ich
gefunden und beseitigt).
Wer das in der Zwischenzeit für sich korrigieren möchte:
- in der hardware_t.cpp -> Methode Start_Record habe da leider was
"kaputt optimiert". Richtig muß es so aussehen:
void Hardware::Start_Record(void)
{
if(acq_ready->np_piodata == 0x01)
{
la_pulse->np_piodata = 0x01; //stop record Port On
la_pulse->np_piodata = 0x00; //stop record Port Off
}
READADC(1);
if (NumberOfChannels == 4) // JK
{ READADC(3); } // JK
ADC_Data_Available = 0;
adc_started = true;
start_acq->np_piodata = 0x01; //start record Port On
start_acq->np_piodata = 0x00; //start record Port Off
//printf("Start Record\r\n");
}
Zu den neuen Errungenschaften von Jörg bin ich noch nicht gekommen, ist
aber im nächsten Final Release auf jeden Fall mit drin.
Auch die Cursor und die Werteanzeige im Delayed Modus stehen noch auf
dem Pflichtenzettel.
@Luc
Hi, I'm sorry but until now I didn't check Your problem because I'm
working on the new USTB engine which is just working with its main
functions. I will check that and - if possible - fix it for the next
main release.
Gruß / regards
Hayo
Hayo W. schrieb:> Vorab noch ein Fix zum Spikeproblem dass Luc gemeldet hatte.
Diese FW-Revision hab ich jetzt auf dem 2024 drauf und kämpfe gerade ein
wenig mit der Single-Shot-Funktion. Wahrscheinlich verstehe ich nur an
der Bedienphilosophie etwas verkehrt, vielleicht kann mir ja einer auf
die Sprünge helfen.
Ich habe auf Ch1 mit 2V/div und bei 10MSa/s (glaube ich, ich habe da gar
nicht so genau drauf geachtet, weil ich einfach nach optischen
Gesichtspunkten so lange dran gedreht habe, bis das Signal schön
formatfüllend aussieht ;-)) an einem CAN-Bus gehorcht und wollte das
Datagramm direkt nach dem Einschalten fangen.
Also habe ich den Single-Knopf gedrückt und beim ersten Versuch fängt
das Scope die erste Flanke meistens wunderschön (das klappt aber nicht
immer, und das auch ganz ohne für mich nachvollziehbares Muster). Wenn
ich Single erneut drücke, um die nächste Flanke zu fangen, steht das
Scope ewig scharfgeschaltet da und der Singleknopf leuchtet rot. Ich
habe es noch ab und zu hinbekommen, dass wieder eine Flanke gefangen
wird, wenn ich (teils mehrmals) Run/Stop drücke und dann erst wieder
Single.
Der Triggerlevel steht ca. bei 60-70% der Signalamplitude. Wenn ich das
Ganze mit Tippen des Tastkopfes an Probe Comp versuche, klappt das
Fangen auf jeden Fall öfter, aber auch nicht immer. Daraus schließe ich,
dass es entweder mit der Abtastrate zu tun hat oder ich irgendwas
verkehrt mache.
Wo klemmt's?
Hallo Johannes,
da ich sowieso gerade die Start/Stop Funktion für die neue USTB-Engine
überarbeite, kann ich mir das mal ansehen. Kann sein, dass der Fix den
ich oben als Code gepostet hab das Problem schon löst.
Ansonsten bräuchte ich noch Deine Triggereinstellungen. Am besten einen
Screenshot mit dem Triggersubmenü drauf (Quick Print doppelt drücken)
posten.
Ansonsten komme ich gut voran obwohl es noch einiges anzupassen gibt.
Gruß Hayo
Das große Schweigen im Walde...
Um nicht den Verdacht zu nähren ich würde faul rumhängen hier ein kurzer
Zwischenstand. Ich bin seit drei Wochen fleißig am Programmieren und es
hat sich sehr viel getan. Aktueller Versionsstand ist 3.3 beta. Bis zum
Final Relase 4.0 HE gibt es aber noch viel zu tun. Ich hoffe ich bin zum
Ende der Sommerpause fertig. Da dürfte wieder für jeden was dabei
sein...
For our "out country" friends... ;-)
I'm working hard on the next final release 4.0 HE. Many things have been
changed or fixed. I hope to be ready after german holidays. I think You
will like it...
Gruß / regards
Hayo
der Hayo, es lebt... :-))
und 'nein', du bist wohl das Letzte, der Letzte, was faul rum hängt. :-)
Mal eine kleine Kostprobe von dem, was du verändert hast?
Ansonsten wünsche ich noch einen schönen Sonntach!
Gruß Michael
Moin moin,
da ich gerade größere Umbauten an der Menüstruktur vornehme, ist die 3.3
zur Zeit nicht lauffähig.
Daher hier die 3.2 beta die schon Einiges zu bieten hat. Bitte beachten
- da sich recht viel geändert hat mußte ich wieder einen Config-Reset
durchführen. Ihr müßt also beim ersten Start neu kalibrieren und die
Hardwareeinstellungen neu machen.
Hier in Kürze die Neuerungen:
- Math gefixt
- Zeichenroutinen sind nochmals schneller geworden
- es gibt eine neue Funktion "Center Window" im Displaymenü, die den
Bildschirmausschnitt bei normalen TB auf den Pretrigger zentriert und
bei USTB auf den aktuellen Samplezeitpunkt.
- neue USTB-Engine V2.1 mit 16K Signalbuffer. Sehr viel höhere
Zeitgenauigkeit, unterstützt Memorybrowser, volle
Zerolevelunterstützung, Math-Unterstützung, Quick Print Datenübertragung
wird unterstützt, Invertierung wird unterstützt,
Details im changelog
Über Vorabtestberichte und Fehlerreports freue ich mich natürlich wie
immer.
Gruß und viel Spaß
Hayo
@Charlie
Die kleineren Fixes und Änderungen und auch die Hardwareunterstützung
von Jörg kommen erst wenn die größeren Umbauten beendet sind. Daher auch
der beta-Status.
Gruß Hayo
Kann das sein, das die Screenshot 0.97 vom 31.03.2011 nicht mehr so
recht will?
Es ist egal ob ich Com1 oder Com4 angebe, mit den Parametern habe ich
auch schon experimentiert.
Das Programm liest kurz aus und geht dann wieder zu!
Gebe ich z.B. Com4 an, obwohl das DSO an Com1 hängt, bleibt das
Dos-Fenster offen und wartet wahrscheinlich auf eine Antwort vom Oszi.
Kann das Jemand bestätigen?
Gruß Michael
EDIT. Achso, habe die neue Beta druff!
...noch was: Ich wollte gerade die 3.0C6 zurückspielen und habe die
Messstrippe abgezogen. Gemessen wurde ein 16MHz Rechteck mit 2V/Div
1GSa/s 50nS, da blieben auf dem rechten Bildrand einige Messreste
stehen.
Hallo Hajo,
gut dass das Wetter nicht zu sommerlich ist, und du zum Programmieren
kommst.
Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen
wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung
Hallo Rainer,
> Michaels Beobachtung kann ich bestätigen.
Da bin ich ja beruhigt.
Sach mal, hast du nix besseres zutun als am DSO rumzuspielen? :-)))
Ok, Spass beiseite...ich habe die C6 noch mal zurück gespielt und da
funktioniert alles wie soll, schade, wollte heute Abend ein paar
Messbilder mit den neuen Funtionen schiessen...
@Rainer,
Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten
Seite?
EDIT: Ich habe das mit der C6 gleich mal gestest, da bleiben keine Reste
im Schirm!
Gruß Michael
wo wir schon dabei sind...
Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt,
d.h. schaltet man bei der C6 die Filter ein, von off bis Strong, geht
der Pk-Pk Spannungswert hübsch mit runter, während bei der Beta der
Peakwert oben bleibt, trotzdem die Spitzen des Signals weggebügelt sind.
Beispiel, siehe Shots von der C6. Von der Beta gehen ja leider keine...
Gruß Michael
Hallo Michael,
Michael D. schrieb:> Hast du auch nach dem Messen(beta), Reste der Messungen auf der rechten> Seite?
Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei
5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch?
Die Quick Measurements auf Basis der gefilterten Werte halte ich auch
für praktischer.
@Hayo,
USTB ist ja nicht wieder zu erkennen, fein, fein!
Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und
"Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an.
Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und "USTB Disp."
könnten eigentlich disabled sein, wenn man nicht im USTB Ablenkbereich
ist. Oder bist du noch nicht bei solchen Oberfkächenfeinheiten?
Gruß
Rainer
Hi Leute,
hier ist ja auf einmal wieder richtig was los! Also Eins nach dem
Anderen:
- die Screenshotfunktion hat sich nicht verändert. Die Versionserkennung
läuft irgendwie ins Leere, muß ich mal prüfen. Danke für die Info. Wenn
ich da weiter bin stelle ich eine korrigierte Version zur Verfügung.
> Kleine Frage: Was ist der Unterschied zwischen Mode "Shift Forward" und> "Roll Forward"? So auf ersten Blick fühlt sich das für mich gleich an.
Ja zu Anfang schon, aber sobald das Bufferende erreicht ist fängt der
Rollmode wieder von vorn an (circular buffer) während der Shift mode
alle Daten je nach eingestellter Richtung nach vorne oder hinten aus dem
Buffer rausschiebt. Da das Schieben etwas mehr Rechenzeit braucht kann
es bei TB = 1s und 4 aktiven Kanälen etwas hakelig werden. Also
möglichst im Schiebebetrieb bei TB = 1s nur 2 Kanäle benutzen oder in
den Rollmode umschalten.
> Wo du gerade an den Menüs bist: Die Tasten "USTB Mode" und> "USTB Disp." könnten eigentlich disabled sein, wenn man nicht im USTB> Ablenkbereich ist.
Die Menüs werden komplett umgebaut, die USTB-Popups verschwinden in
einem eigenen USTB-Submenü.
> Im Quichmeasure werden z.B. die Pk-Pk Werte nicht richtig angezeigt,
hmmm, da hab ich eigentlich auch nichts geändert. Muß irgendein
komischer Nebeneffekt sein. Werd ich mal prüfen, danke.
Hi,
> Ich habe zwar keine 16 MHz hier, aber mit dem Probe Comp Signal bei> 5ns/div sehe ich nichts. Beobachtest du damit den Effekt auch?
das hatte ich auch bei niedrigeren Frequenzen, vielleicht hätte ich das
DSO mal aus u. wieder einschalten sollen, evt. könnte das der Grund
sein.
Ich habe jetzt wieder die C6 drauf.
Und da haben wir wieder das alte Problem mit den unterschiedlichen
Signalquellen.
Und deswegen mein Vorschlag an dieser Stelle:
Ich habe hier einen schicken Rechteckgenerator mit einem Mega48
zusammengebaut, der nicht viel grösser ist, als ein 2x16er LCD-Display.
Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am
Pinout des Mega48/88, TTL-Pegel.
Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS.
Sehr kostengünstiger Aufbau und sehr genau, vorallem kein Signalgezappel
auch bei nicht so Hf-Gerechter Umgebung.
Mein Vorschlag wäre, diesen Generator als allgemeines Messequipment für
das Welec zu verwenden, dann wären wir nicht immer nur auf die 1kHz
beschränkt und würden auf einer breiteren und einheitlichen Linie
fahren.
Wäre das für euch interessant???
Wenn ja, dann könnte man dafür noch einen separaten Thread aufmachen, wo
denn auch z.B. diverse Messergebnisse vom Welec, die mit diesem
Generator gemacht wurden, eingestellt werden. ;-)
> Die Quick Measurements auf Basis der gefilterten Werte halte ich auch> für praktischer.
Das meine ich aber auch, wenn ich meine Filter einsetze, dann möchte ich
das auch angezeigt bekommen, also 5,25V und nicht 6,62V Peak to Peak wie
auf den Shots weiter oben zu erkennen ist.
Gruß Michael
Das hört sich ganz gut an, aber da ich mit umfangreichem Equipment in
der Richtung ausgestattet bin ist das für mich erst mal nicht so
interessant.
Gruß Hayo
Ich noch mal,
Ich habe die Beta noch mal aufgesetzt.
Nach mehrmaligen 'Default Setup', sowie komplett ein u. ausschalten,
sind die oben genannten Effekte plötzlich weg, sehr merkwürdig, aber um
so besser!
Screenshot geht aber trotzdem nicht, da habe ich jetzt alles Mögliche
getestet, ich bekomme keinen Shot.
Edit: Die 0.91 geht, allerdings nur beim Doppelpush und Ausgabe BMP.
Bei allen anderen Knöppen kommt ein 'internal Error'
Gruß Michael
Noch mal EDIT: Ich dachte eher daran, das wir dann alle auf der gleichen
Ebene wären. Gleiches Oszi, gleiche Messfrequenzen, das war so der
Gedanke.
Das du natürlich anders ausgestattet bist, war klar, hat aber nicht
jeder zur Verfügung.
So, war heute hyperaktiv... ;-)
Die übelsten Bugs sind beseitigt. Die neue Menüstruktur ist schon
eingebaut. Soweit ich getestet habe ist das stabil. Aber bestimmt ist
mir da noch irgendwo was durchgerutscht, wer findet es zuerst?
Die neue Struktur könnt Ihr Euch im Programmersguide auf dem Blatt für's
Menu ansehen. Alles was gelb ist, ist neu.
Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug
Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine
Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm
aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen.
Jetzt ist der Debug Mode jedenfalls wieder an.
So jetzt gehts mit der besten aller Ehefrauen zum Griechen... (verdient)
Gruß Hayo
Hallo Hayo,
bezüglich Unterschied zwischen USTB Roll vs. Shift bin ich mit Blindheit
geschlagen.
Einziger Unterschied den ich gesehen habe:
Wenn ich das DSO auf Ch1 mit 1s/div bei 500mV/div das Probe Comp Signal
(Noise Filter off, perm. Display) samplen lasse (ich weiß - wildes
Aliasing) passiert nach gefühlten 5-6 min folgendes:
Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch
auf Reset (z.B. via Soft-Btn)
Roll Forward Mode: Springt wieder in den Anfangszustand mit
rüberlaufendem T-Marker, um dann normal weiter zu samplen.
Tritt das bei anderen auch auf?
Michael D. schrieb:> Das Teil rennt von 0,1 - 16MHz bzw. 32MHz(aufgepumpt, regulär 10MHz) am> Pinout des Mega48/88, TTL-Pegel.> Das Rechteck hat eine Rise- u.Falltime von ca.3-4nS.
@Michael
Am schönsten wäre für Testzwecke, <träum>wenn man hinter Probe Comp den
Ausgang eines kleinen DDS Generators rausführen würde, der mit an der
DSO Software dranhängt. </träum>
Zeig doch mal, wieviel HW-Aufwand du für deinen kleinen Generator
betrieben hast? Wie kommst du auf den hohen Takt (Prozessor quälen)?
Ich verwende immer gern den miniDSS (KISS)
http://www.myplace.nu/avr/minidds/index.htm
Gruß
Rainer
Jörg H. schrieb:> - die zur veränderten Empfindlichkeit passenden Skalierwerte in den> Tabellen "ScaleFactor[]" und "DAC_ScaleFactor[]" fehlen noch. Ich habe> Messungen gemacht, hatte aber noch keine Zeit das dort einzubauen.
Da werde ich erstmal Dummywerte eintragen. Genauere Werte müßtest Du
dann nachliefern.
> - an der Benutzeroberfläche habe ich nichts gemacht. Man kann also noch> nicht einstellen, ob man neue Eingangsstufen hat. Das habe ich mir> derzeit hart reincompiliert.
Das werde ich wie von mir schon vorgesehen über die Einstellung "Addon"
im Hardwaremenü machen.
> - Die Software kann keinen echten "Mischbetrieb" der verschiedenen> Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben> diskussionswürdig, ob das überhaupt sein soll und kann. An diesem> prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.
Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges
verkomplizieren. Ich tendiere erstmal zu nein.
> Ich habe zwar 4 Flags eingeführt (HasNewInputStage[4], die auch ins> Flash kommen) und pro Kanal anzeigen,
wie Du schon sagtest gibt es diverse Stellen die ebenfalls betroffen
wären.
> In einem weiteren Versuch habe ich ein Array GainIdx[4] gemacht, also> ein Wert pro Kanal. Damit kam ich bis zu den Lookuptabellen> "ScaleLookupTable[]" für die Anzeige, die quasi statisch sind. Ich habe> noch nicht verstanden, warum es davon 2 Satz gibt, einen für die 1er und> 2er Bereiche, und einen für die 5er Bereiche.
Weil 1er und 2er den gleichen Scalierungsfaktor haben und der 5er einen
anderen.
> (BTW, die Indizes sind> ungünstig, wären besser vertauscht, damit der innere Zugriff schnell> geht. Der letzte Index sollte die 0..255 Tabelle sein.
Muß ich mal checken und evtl. anpassen
> Ferner würde ich> diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann> alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die> Zeichenschleife das nicht tun.)
Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin
etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man
könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der
Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version
reinkriege.
> Ein paar Bugs habe ich noch gefunden, ohne Rücksprache noch nicht> korrigiert:>> 1.) in Hardware::RestoreFromFlash()> statt:> Hardware::SetSwitches(2, -1);> besser:> Hardware::SetSwitches(2, Selected_Voltage_CH2);
Stimmt, habe ich im Zuge der neuen Startupsequenz mit korrigiert
> 2.) Hardware::Start_Up() ruft immer AMDFlash::Write_Config_Flash() auf,> das tut dem Chip wohl nicht gut.
Hier wird der Config-Backupsektor refreshed. Das muß daher bleiben. Dem
Chip sollte das nichts machen. Bis der davon Schaden nimmt hast Du wohl
schon den 100sten Netzschalter verschlissen. Während des Betriebes wird
auch bei jeder neuen Einstellung ins Flash geschrieben. Das sollte das
Flash locker mitmachen. Ich schreibe bei mir seit drei Jahren so oft ins
Flash wie wohl kein normaler User sonst. Da funktioniert aber immer noch
alles tadellos.
> Nur nebenbei, in meinen Projekten habe> ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte> Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem> Timeout, verhindert versehentliches Dauer-Schreiben.
Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich
tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der
ganze Config-Sektor neu geschrieben werden da immer nur sektorweise
gelöscht werden kann.
> 3.) Die Offsetregler verhalten sich bei Extremwerten komisch, ich weiß> aber nicht wo der Bug ist. Bei Kanal 3 kann ich den "überdrehen", die> Offsetspannung springt von positiv nach negativ und umgekehrt. Ist wohl> ein numerischer Wraparound. Bei Kanal 4 bleibt der Wert wie erwartet am> Anschlag kleben, aber ich kann noch in eine Art wirkungslosen Bereich> drehen. D.h. weitere Drehung hat zwar keinen Effekt, muß aber auch nach> Umgekehr wieder zurückgelegt werden bevor der Offset wieder sinkt.
Muß ich mal checken, ob ich das nachgestellt kriege.
Gruß Hayo
Rainer W. schrieb:> Shift Forward Mode: Das Scope friert vollständig ein und hört nur noch> auf Reset (z.B. via Soft-Btn)
Stimmt, da ist noch was buggy. Hat aber schon mal funktioniert. Muß ich
mal suchen.
> Roll Forward Mode: Springt wieder in den Anfangszustand mit> rüberlaufendem T-Marker, um dann normal weiter zu samplen.
Soll ja auch so sein. Am Besten den Memorybrowser dauerhaft aktivierren,
dann sieht man immer wo man sich gerade im Buffer befindet.
Gruß Hayo
Hayo W. schrieb:> Am Besten den Memorybrowser dauerhaft aktivierren,
Guter Tip. Dann ist mir der Unterschied auch klar.
Der Hänger im Shift-Mode(bei 1s/div nach 5 min) passiert demnach, sobald
das Bufferende erreicht ist.
Rainer
Ich hab da nochmal getestet.
Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte
so groß ist, daß in der Zwischenzeit der nächste Interupt vom
Acquisition-Timer kommt und damit die weitere Ausgabe unterbindet.
Irgendwann gibt es dann wahrscheinlich einen Stacküberlauf.
Ich werde wohl den Signalbuffer im Shiftmode drastisch verkleinern
müssen, zumindest in den Bereichen 1s 2s 5s.
Gruß Hayo
Hayo W. schrieb:> Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte> so groß ist
Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch
schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig.
Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus,
d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein
Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-)
Gruß
Rainer
Rainer W. schrieb:> Hayo W. schrieb:>> Der Hänger passiert, weil der Rechenaufwand beim Schieben der 16000 Byte>> so groß ist>> Mmmh, über Ringpuffer/Pointer als Lösung hast du wahrscheinlich auch> schon nachgedacht. 16k zu schieben ist in der Tat etwas lästig.
Nachgedacht schon, aber mir war das im ersten Anlauf etwas aufwändig.
Eventuell muß ich mir da aber doch noch mal das Hirn verrenken, leider
hab ich noch nie so eine Konstruktion machen müssen. Bei meinen
Signalprozessoren gab es da immer eine Hardwareimplementierung für.
> Wie sieht es eigentlich mit einer Single-Shot Steuerung für USTB aus,> d.h. entweder Trigger-Event oder Taste "Single" und dann wird genau ein> Puffer voll aufgezeichnet - ohne Einfrieren meine ich ;-)
Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du
ein Sample? Oder einen ganzen Pufferdurchlauf?
Gruß Hayo
Hayo W. schrieb:>> - Die Software kann keinen echten "Mischbetrieb" der verschiedenen>> Eingangsstufen, mit dazu passender Skalierung. Ist zugegeben>> diskussionswürdig, ob das überhaupt sein soll und kann. An diesem>> prinzipiellen Problem scheitere ich erstmal und übergebe an Hayo.>> Tja das ist die Frage, brauchen wir Mischbetrieb? Das würde einiges> verkomplizieren. Ich tendiere erstmal zu nein.
In der Endversion bin ich auch der Meinung das nicht, aber momentan
fände ich es schön, vergleichen zu können. Zugegeben kann man das auch
nacheinander tun, mit zwei Softwaren. Da habe ich mich etwas in die Ecke
gedacht.
>> Ferner würde ich>> diese Tabelle dynamisch berechnen, bei Bereichsumschaltung neu, und dann>> alles mit rein, incl. Clipping auf Displaygrenzen. Dann braucht die>> Zeichenschleife das nicht tun.)>> Die Berechnung dauert so lange, dass ich befürchte, dass die ohnehin> etwas zähe Reaktion auf die Drehregler dann noch zäher wäre. Aber man> könnte es natürlich mal testen. Die Clipping-Prüfung könnte man in der> Tat verlagern, muß mal sehen ob ich das noch mit in die neue Version> reinkriege.
Dann sollten wir mal an der Berechnung arbeiten, damit die
Zeichenfunktion Gas geben kann. Vermutlich braucht sie deshalb so lange,
weil sie in Fließkomma rechnet? Da könnte ich mir vorstellen bestenfalls
die Endwerte in float auszurechnen und die Gerade dazwischen mit was
Bresenham-artigem. Es sind ja nur 256 Werte, das sollte sehr schnell
gehen. Könnte ich mich drum kümmern.
>> Nur nebenbei, in meinen Projekten habe>> ich mir angewöhnt, Flash oder EEPROM erst zu vergleichen, nur echte>> Veränderungen zu schreiben. Zudem nicht sofort, sondern nach einem>> Timeout, verhindert versehentliches Dauer-Schreiben.>> Das ist hier nicht nötig, da nur ins Flash geschrieben wird, wenn sich> tatsächlich was geändert hat und dann muß beim Schreiben ohnehin der> ganze Config-Sektor neu geschrieben werden da immer nur sektorweise> gelöscht werden kann.
Ach so, du vergleichst den Sektor vor dem Schreiben und brichst ab wenn
gleich? Sehr gut, dann habe ich nichts gesagt. :-)
Jörg
Hayo W. schrieb:> Das hört sich nach einer guten Idee an. mit ein Puffer voll meinst Du> ein Sample? Oder einen ganzen Pufferdurchlauf?
Damit meine ich 16k (oder wie viel das z.Z. ist) messen, quasi das was
z.Z. beim Shift Mode mit 1s/div bis zum Einfrieren passiert, so dass man
Daten aufzeichnen kann, ohne sich darum zu sorgen, dass die ersten
Samples wieder überschrieben oder rausgeschoben werden.
Gruß
Rainer
Hallo,
ich meld' mich auch mal wieder.
Rainer W. schrieb:> Michaels Beobachtung kann ich bestätigen. Da sind sich die Versionen> wohl nicht ganz einig. Ich bekomme vom w2000a-screenshot die Meldung> * Connecting to DSO and retrieving version information... done> - found hardware version: 1C9.0.L> - found model: W2024A> Error: This version needs at least firmware version %d.%d, but you've got %d.%d.> [..] [zu Firmwareversion 3.2 beta]Hayo W. schrieb:> Zum Screenshot - da hatte ich in der seriellen Kommunikation den Debug> Mode abgeschaltet, da dieser immer bei einer Tastatureingabe eine> Rückmeldung rausschickt. Anscheinend erwartet das Screenshotprogramm> aber diese Rückmeldung immer. Muß ich mal bei Gelegenheit anpassen.
Ich hab' mir das gerade mal angeschaut mit der 3.2 beta. Das
Problem liegt in der letzten for-Schleife in dsoinfo(). Sonderzeichen,
darunter auch \n, schreibe ich als \0 in das info-Array. Nun frage
ich ab, ob das gerade betrachtete Zeichen eben \0 ist und teste,
ob etwas verwertbares bzgl. Versionsangaben gefunden werden kann. Da
mit Debugausgaben anfangs etwas "Muell" kommt, ist der Fall *p == '\0'
fuer den ersten vom DSO uebermittelten Nutzdaten-String, naemlich
"FW: 1.2.hayos.version", gegeben. Ohne Debugausgaben wird der String
ignoriert und erst die darauf folgenden betrachtet.
Kurzfristiger Bugfix ist, vor der einlesenden while-Schleife statt:
1
i = 0;
2
while (i < ISIZE-1 && (c = rdchar(com)) != '+') {
zu setzen:
1
info[0] = '\0';
2
i = 1;
3
while (i < ISIZE-1 && (c = rdchar(com)) != '+') {
Im Anhnang der Quelltext von v0.97 (aus der FW 3.0 ZIP-Datei)
mit genau dieser Aenderung. Leider habe ich gerade keine
Moeglichkeit das fuer Windows zu kompilieren, liefere ich
nach.
Niklas
Hallo Hayo,
mit der Beta friert ständig mein Schirm ein.
Wenn ich das Signal abziehe, bleibt es auch bestehen und, oder es
bleiben Reste.
Bei den unteren Messbereichen so 250ms bis 50µS gehen die Messungen sehr
schleppend und kommen ständig in's stocken. So richtig fix geht es erst
wieder bei 1GSa also 500nS los, alles was darunter ist, ist eine
Katastrophe.
USTB geht und dann wieder nicht. Bleibt einfach stehen und dann
irgentwann mal weiter oder auch nicht...
Ich wollte dir das nur mal berichten, da ich ja weiß, das du kaum zum
Messen kommst. Der Rainer hat dieselben Probleme.
Wenn du möchtest, kann ich dir mal ein paar Screenshots schicken, da
stehen dann auch alle Werte drinnen. Das jetzt hier zu beschreiben,
würde den Rahmen sprengen.
Einen schicken Abend noch,
Gruß Michael
Hi, bin erst jetzt wieder vom Griechen zurück, durch das viele
Programmieren komme ich gar nicht mehr zum selber kochen...
Ich habe die USTB-Engine noch mal überarbeitet - die aktuelle Version
ist jetzt 2.2.
Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine
Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte.
Einfrieren sollte eigentlich nichts mehr. Einige andere Sachen habe ich
auch noch optimiert.
Weitere Änderungen / Neuerungen stehen noch an.
Danke für die Rückmeldungen, wie immer sind weitere Reports von Euch
stets willkommen!
Gruß Hayo
Hayo W. schrieb:> Der Shift-Modus steht jetzt erst ab 5s/Div zur Verfügung und hat eine> Puffergröße von 1200 Byte anwachsend zu höheren TB bis 16 KByte.
Hallo Hayo,
die Puffergröße, die im Shift-Mode bewältigt werden kann, müßte doch
sowohl von der Samplerate, als auch von der Anzahl der aktiven Kanäle
abhängen - so ganz banal gedacht. Würde man beim 4 Kanaler dann nicht
ungünstigstenfalls einen Faktor vier bei der Einkanalaufzeichnung
verschenken, wenn man das rein an der Samplerate festmacht?
Oder hab' ich das zu einfach gedacht?
Gruß
Rainer
Im Prinzip hast Du recht, aber bei meinen Tests hat sich erwiesen, dass
die Anzahl der Kanäle nicht ganz so ausschlaggebend war als dass sich
der Aufwand gelohnt hätte die Anzahl der Kanähle zu berücksichtigen.
Soll heißen, dass selbst bei noch kleinerer Puffergröße (600 Byte =
Screenbreite) im Dreikanalbetrieb die Sache ins Stocken kam (1s/Div und
2s/Div), geschweige denn der Math-Modus ging. Der etwas größere Sprung
von 2s/Div auf 5s/Div reicht dagegen um alles stabil bei 1200 Byte
Puffergröße laufen zu lassen.
So wie es jetzt ist habe ich eigentlich schon das Maximum rausgeholt.
Am Memorybrowser könnt Ihr Übrigens immer gut die aktuelle Puffergröße
erkennen.
Gruß Hayo
Hallo,
im Anhang das neue Kompilat des Screenshot-Programms v0.97
mit dem Fix fuer den Bug im Zusammenhang mit abgeschalteten
Debug-Modus in der Firmware (v3.2 beta). Hayo kann dann in
zukuenftigen Versionen wieder den Debug-Modus abschalten.
English:
New compilation of the screenshot program v0.97 with a fix
regarding a bug that was found when the debug mode is turned
off in the firmware (as in v3.2 beta). In v3.3 beta and
v3.4 beta Hayo temporarily turned debug back on for this
reason. No other changes.
For more information and sourcecode see
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
Niklas
Hallo Hayo,
die 3.4beta, läuft gut. Ich habe gleich noch mal den USTB-Modus getestet
mit einem 0,23Hz Rechteck(Pulsweite 50:50) auf 1s, 2s und 10s.
Anbei 3 Shots.
Jetzt bleibt aber bei den Smooth und Strong-Filtern das Signal stehen
(Test 2kHz). Es friert nur das Signal ein, nicht das komplette DSO.
Wenn ich die Filter tausche bzw. ausschalte, läuft's wieder!
Getestet habe ich noch die 3 anderen Filter StageI bis StageIII. Da
läuft alles so wie es soll.
Ich hoffe, es nützt dir was.
Hallo Niklas,
Die Shots sind mit deiner neuen screenshot-fix gemacht, funzt wunderbar.
Tolle Arbeit und ein Lob von mir.
Gruß Michael
Ooouuhh,
das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die
Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war.
Die eigentlichen Filterroutinen werden auch garnicht angesprungen.
Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer,
weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich
jetzt beseitigt.
Danke für den Hinweis!
Gruß Hayo
Hayo W. schrieb:
> Ooouuhh,
aaaaahh...
>> das hatte ich bislang noch nicht bemerkt weil ja im USTB-Mode die> Filterung keinen Sinn macht und deshalb bei mir abgeschaltet war.
Das der da keinen Sinn macht, macht ja Sinn...
bei den Messungen weiter oben, war der auch garnicht eingeschaltet,
fällt mir gerade ein!
Eben habe ich das noch mal provoziert, sobald eines der Filter aktiv
ist, geht da nüscht mehr.
>> Die eigentlichen Filterroutinen werden auch garnicht angesprungen.> Leider verbiegt mir der aktivierte Filtermodus aber die Signalpointer,> weswegen da eine Menge Schrott auf dem Bildschirm erscheint. Habe ich> jetzt beseitigt.
Fein!
Jetzt zickt nur noch der 'Smooth' und der 'Strong' Filter, im "nicht"
USTB-Mode. Die Stages I-III sind ok!
>> Danke für den Hinweis!
Bitte!
>> Gruß Hayo
Gruß Michael
Und hier ist wieder das Sonntagabend-Event!
Wie von versprochen habe ich mir das Gehirn verrenkt weil die Lösung mit
den kleinen Puffergrößen im Shift Mode etwas unbefriedigend war.
Herausgekommen ist eine Lösung mit sich gegeneinander verschiebenden
Speicherbereichen statt einer Verschiebung der Daten selbst.
Dazu brauchte ich aber viel Speicher, so dass ich die Speicheraufteilung
geändert habe. Das Ergebnis kann sich sehen lassen:
- 16KB in allen ultra slow TB für den Shift Mode
- 32KB sind möglich im Roll Mode!
Die Speichertiefe ist einstellbar im USTB-Menü (8KB/16KB/32KB). Von
Rainer angeregt habe ich einen speziellen Single Mode für USTB
implementiert.
Quick Print und Save/Recall unterstützen aber nur (8KB/16KB)
Gruß Hayo
Hallo Hayo,
ich habe deine 3.5Beta gleich mal getestet.
Das mit dem Smooth u. Strong Filter hat sich schon gebessert.
Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz
Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's
stocken.
Bei nur einer Flanke geht's ab wie Schmitt's Katze. Die StagesI bis III
gehen nach wie vor wunderbar...what's the Different?
Ich wünsche dir noch einen schönen Sonntag
Gruß Michael
Ich noch mal,
habe gerade noch den USTB-Mode mit ---275Hz--- getestet und zwar mit
1,2,5 und 10Sek.
Irgendwie stimmt da was nicht, 1s ist ein wenig voll?
Die 2s sind wieder schön gemalt, 5s füllt sich wieder und bei 10s ist
das Signal wieder ok, oder habe ich das Messprinzip nicht verstanden?
Anbei die Shots mit den Einstellungen!
Gruß Michael
Hi,
sowas nennt sich Aliasing. Die Messfrequenz ist viel zu hoch für die
Abtastrate. Ich teste da mit 0,05Hz. Heißt ja nicht umsonst Ultra Slow
Time Base.
Das Andere muß ich noch mal prüfen. Ist auch noch beta Status. Bis zum
stable Release muß ich noch ordentlich testen. Je mehr Ihr jetzt schon
findet, desto schneller gehts!
Bis dann
Hayo
Hallo Hayo,
ganz große Klasse mit dem radikal geänderten Speicherkonzept in den USTB
Modes. Der Single-Shot ist auch sehr fein.
Nach ein bisschen probieren sind mir noch folgende Kleinigkeiten
aufgefallen:
- Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine
Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das
konzeptionelle Problem dabei. Vielleicht hat jemand die geniale Idee.
Eine Möglichkeit, die mir spontan einfällt, wäre im Browser ein
hinterlegter Balken der den Speicherfüllstand anzeigt, aber es wäre
natürlich schöner, wenn man dafür nicht wieder etwas neues erfinden
müßte.
- Bei der Bedienung im Main/Delay Menü finde ich es persönlich
unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü
hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es
nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu
tauschen.
Und noch ein Punkt:
- Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang
zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin
ist.
Nochmal ein dickes Lob für deine tolle Arbeit.
Gruß
Rainer
Rainer W. schrieb:> - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine> Anzeige, die über den Speicherfüllstand informiert. Ich sehe wohl das> konzeptionelle Problem dabei.
Ja sowas ging mir auch schon durch den Kopf - allerdings noch ohne gute
Idee
> - Bei der Bedienung im Main/Delay Menü finde ich es persönlich> unpraktisch, dass es zwei verschiedene Tasten sind, um ins USTB Submenü> hinein und heraus zu kommen (Softkey 5 bzw.6). Die Frage ist, ob es> nicht ergonomischer wäre, z.B. die Softkeys "USTB" und "Browse" zu> tauschen.
Da hast Du natürlich recht, die Idee hatte ich auch schon, war aber noch
zu "faul", werde ich aber noch machen.
> Und noch ein Punkt:> - Im USTB Single Shot halte ich es für sinnvoll, den Speicher zu Anfang> zu löschen, damit nicht irgendwelcher Müll in der Aufzeichnung mit drin> ist.
Da hatte ich auch schon überlegt, hatte aber gedacht, dass es dann nicht
möglich ist nachträglich den Single Shot zu aktivieren ohne die
bisherigen Ergebnisse zu verwerfen. Kann ich aber noch einbauen.
> Nochmal ein dickes Lob für deine tolle Arbeit.
Das schlechte Wetter in Norddeutschland machts möglich...
Gruß Hayo
Michael D. schrieb:> Hallo Hayo,> ich habe deine 3.5Beta gleich mal getestet.> Das mit dem Smooth u. Strong Filter hat sich schon gebessert.> Sobald ich aber mehr als eine Flanke, (z.B. 1MHz, 6MHz oder 9MHz> Rechteck) auf dem Display habe, kommt die Signalmessung wieder in's> stocken.
Ok hab's! In dem Bestreben das letzte Quentchen Performance rauszuholen
hab ich leider mal wieder was kaputt-optimiert. Ist schon korrigiert und
kommt mit der 3.6 beta.
Danke für den Report
Hayo
So, hier auch gleich die bereinigte Version.
- Filterproblem gefixt
- Browser Button und USTB-Button getauscht
- Bufferrefresh bei Single Shot
Als Nächstes werde ich mal Eure älteren Bug-Reports abarbeiten und dann
die neue Hardwareansteuerung von Jörg einbauen. Dann steht dem neuen
final Release nichts mehr im Wege.
Gruß Hayo
Rainer W. schrieb:> - Beim Shift Mode, speziell beim Single Shot vermisse ich jetzt eine> Anzeige, die über den Speicherfüllstand informiert.
Da fällt mir ein, dass der Memorybrowser da schon mal weiterhilft, denn
da wird der aktuelle Samplezeitpunkt im Speicher durch das Triggersymbol
angezeigt. Wenn das Triggersymbol ans Speicherende läuft wird der
Singleshot ausgelöst. Das gilt allerdings nur für den Rollmode. Beim
Shiftmode läuft ja das Ende des Signals gegen das Speicherende, und
dafür gibt es momentan noch kein Zeichen. Wäre aber eine Überlegung
wert.
Gruß Hayo
Hallo Hayo,
Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir...
Die Filter funzen todschick, ich benutze gerade den Smooth-Filter sehr
oft und für's Grobbe dann mal schnell den Strong für die obere
Müllbeseitigung, denn dafür sind diese sehr praktisch!!!
Ok, das mit dem USTB hätte ich mir denken können.
Sind denn die Messungen hier:
---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
dafür ok?
Man sieht sieht auf den Shots auch den Browser wie er sich füllt, das
dauert schon seine Zeit bis der voll ist, einige Minuten.
Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf
den Shots messe ich mit z.B. 0,23 Hz.
Gruß Michael
Michael D. schrieb:> Super***** Arbeit, ich bin begeistert, bekommst 5 Sterne von mir...
Cool, dann bin ich jetzt 5 Sterne Programmierer... ;-)
> Ok, das mit dem USTB hätte ich mir denken können.> Sind denn die Messungen hier:> ---Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"> dafür ok?
Das kann man nie genau anhand des Bildes sagen. Im Prinzip muß das
Signal bezogen auf die Abtastfrequenz bandbegrenzt sein (und zwar auf
halbe Abtastfrquenz).
> Was ist denn die oberste bzw. unterste Messgrenze für den USTB-Mode? Auf> den Shots messe ich mit z.B. 0,23 Hz.
Dazu hat mal ein genialer Mensch namens Nyquist eine schlaue Idee
gehabt. Nennt sich Abtasttheorem. Das besagt. das die Abtastfrequenz
mindestens doppelt so hoch sein muß wie die höchste auftretende
Signalfrequenz, damit das Signal korrekt wiederhergestellt werden kann.
Wenn das nicht erfüllt ist entstehen sogenannte Scheinfrequenzen
(Aliasfrequenzen) woher auch die Bezeichnung Aliasing stammt.
Die Abtastfrequenz wird ja in der Statusleiste angezeigt. Bei 1s/Div ist
sie beispielsweise 50Sa/s -> nach der Theorie ist da also die
Grenzfrequenz (oder auch Nyquistfrequenz) 25Hz. In der Praxis liegt sie
jedoch weit darunter, mindestens bei 1/4 der Abtastfrequenz, da Du sonst
auf dem Bildschirm nix Vernünftiges erkennen kannst.
Unser Oszi ist Beispielsweise mit einer Abtastfrquenz von max. 1MSa/s
gesegnet, hat aber nur eine (theoretische) Bandbreite von 200MHz/100MHz
was schon zeigt wie Theorie und Praxis zu bewerten sind.
Den Rest kannst Du Dir ja selbst zusammenreimen. Viel Spaß beim
nachrechnen.
Im Prinzip kannst Du also den USTB-Bereich mit Frequenzen ab 5Hz abwärts
sinnvoll testen - mit 0.23Hz bist Du also schon gut dabei!
Gruß Hayo
So, ich mal wieder,
hallo allerseits. Die letzten Tage habe ich den Fehlerreport von Rainer
(11.7.2011) abgearbeitet. Zur Erinnerung, es ging um den (fehlenden)
Refresh der Cursor-Daten. Dabei bin ich auf eine Menge Unrat gestoßen.
Insofern freue ich mich über die neue Betaversion besonders. Ich habe
die Assemblerroutinen für den Menüaufbau komplett überarbeitet und
mengenweise performancehemmende Leichen entsorgt. Neben der erfreulichen
Tatsache, das jetzt die Cursorwerte prompt und schnell angezeigt werden
ist auch der gesamte Menüaufbau beschleunigt worden.
Die aktuelle Beta läuft nach meinen bisherigen Erkenntnissen so stabil,
dass ich empfehlen würde sie erstmal dauerhaft zu flashen da sie
gegenüber den 3.0 Cx Versionen doch deutliche Vorteile zu bieten hat.
Über Fehlerreports freue ich mich natürlich trotzdem.
Gruß Hayo
Ach ja noch als kleiner Nachschlag,
für alle die gerne selbst Performance-Messungen durchführen wollen habe
ich einen dauerhaften Framecount eingebaut der gleichzeitig mit der
Tastenkombination Shift+K über Terminal ausgegeben und resettet wird.
Gruß Hayo
Den ersten Fehler habe ich dann auch selbst entdeckt wie es aussieht.
Der Pretriggerwert wird bei TB-Wechsel nicht korrekt refreshed - erst
beim Druck auf den Button..
Ist natürlich schon in Arbeit...
...Version 3.8 is coming soon...
Hayo
Damit die Anderen wissen, was der Hayo meint, habe ich mal 2 Shots
gemacht.
Im 1. Shot ist das Terminal zu sehen mit all seinen Befehlen, mit denen
man das Welec fernsteuern kann.
Ausser Shift+k ist noch nicht beschrieben, geht aber und ist auf dem 2.
Shot zu sehen!
Gruß Michael
EDIT: Ach ja, unten auf der Statusleiste sind die Parameter für die
RS232 zu sehen. (Stopbit 1, Handshake none)
Doch, der Framecounter ist schon beschrieben, man muß schon genau
hinsehen ;-)
Einfaches Vorgehen bei der Messung:
- Uhr mit Sekundenzeiger bereithalten
- bei Nulldurchgang des Sekundenzeigers Shift + K drücken
- nach 60 Sekunden erneut Shift + K drücken
Als Ergebnis hat man die Frames pro Minute, die je nach Anzahl der
Kanäle und zusätzlicher Funktionen variieren.
Hayo
Und die nächste beta, die aber jetzt schon recht stabil ist. Was hat
sich getan?
ich habe den zweiten Teil von Rainers Fehlerreport (11.7.2011, da war
ich noch in Thailand) abgearbeitet.
Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert.
Beim Prüfen der Berechnung bin ich auf eine völlig verwurstete Formel
gestoßen die um Zehn Ecken mit zig Hilfsparametern die Position extrem
rechenaufwändig und falsch berechnet.
Die neue Formel errechnet die Position mit drei Parametern viel
schneller und richtig! Alle überflüssigen Parameter und Matrix-Arrays
habe ich gelöscht, da diese nur hierfür benutzt wurden.
Das Ganze gilt ebenso für die QM-Delayed Cursor (z.B. bei Rise Time
Berechnung im Delayed Mode).
Gruß Hayo
Für die nächste Beta überarbeite ich gerade die Zeichenroutine für das
Pretrigger-Zeichen im Haupt und Delayedfenster, da es hier manchmal
Darstellungs-/Löschfehler gibt.
Gruß Hayo
Fast Vector:
- 2 Kanäle -> 475fpm
- 4 Kanäle -> 247fpm
Accurate:
- 2 Kanäle -> 419fpm
- 4 Kanäle -> 221fpm
Pixel:
- 2 Kanäle -> 511fpm
- 4 Kanäle -> 262fpm
Das ist in allen Bereichen zwischen 10 - 20fpm schneller als bei den
3.0Cx
Für fps alles durch 60 teilen.
Ansonsten baue ich gerade die Hardwareunterstützung für die neue
Eingangsstufe ein.
Gruß Hayo
Hallo,
schlechte Nachrichten bei mir.
Mein 4 Kanaler versagt den Dienst. GUI funktioniert, aber
keine Anzeige der Eingangssignale. Alle Traces werden
in der Mitte gezeichnet, Verschieben dieser ist auch
nicht moeglich.
Da mich es wunderte, warum auch die Relais nicht klicken beim
Wechsel der Ranges, hab' ich mir mal das Netzteil und das
Spannungsversorgungs-Board angeschaut. Dabei fiel auf, dass
ein Bauteil, was fuer mich nach einer Induktivitaet/Spule
aussieht, abgeraucht ist.
Es handelt sich im folgenden Foto um das weisse Bauteil
direkt am linken Rand (bei den schwarzen Leitungen die
zum LCD-Inverter Board fuehren). Bei mir war das Bauteil
schwarz (wohl auch vor dem Abrauchen schon ;)), duerfte
aber irrelevant sein.
http://sourceforge.net/apps/trac/welecw2000a/raw/attachment/wiki/Hardware/inverter.JPG
Vor dem Bauteil liegen 6.2V an. Das ist (bzw. war) bei mir auch
Versorgungsspannung vom Original-Luefter (den hab' ich aber
bereits durch einen anderen getauscht, welcher direkt an den 12V
vom Netzteil angeschlossen ist). Hinter dem defekten Bauteil liegen
im Betrieb nur ungefaehr 0.5V an.
Frage an Euch: Um was fuer ein Bauteil handelt es sich mit welchen
Werten? Wenn jemand das mal ausmessen koennte waere ich ihm sehr
dankbar.
Niklas
Hallo Niklas,
die Frage wäre einfacher zu beantworten wenn der link funktionieren
würde. ;-)
Abgesehhen davon gehört das doch eher in den Hardware Thread.
Beitrag "Wittig(welec) DSO W20xxA Hardware"
MFG,
Kurt
Hallo Allerseits,
ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0 und
prüfe die bisher gemeldeten Fehler. Aktuell prüfe ich das Verhalten des
Single Shot, da hier einige Meldungen in der Vergangenheit waren.
Momentan kann ich aber keine Auffälligkeiten entdecken. Wenn Ihr noch
Fehler entdeckt habt dann bitte melden. Bezüglich Trigger bitte immer
auch mit den aktuellen Einstellungen des Triggermenüs.
Gruß Hayo
Moin Hayo,
Hayo W. schrieb:> Es wurde zu Recht die fehlerhafte Position der Delayed Cursor moniert.
Die synchronisierten Cursor im Delayed Fenster geben ein völlig neues
Arbeitsgefühl und die Anzeige der Cursor Position sowieso. Klasse ;-)
Hayo W. schrieb:> ich bin gerade bei den Abschlußarbeiten für das neue Release 4.0
Da hätte ich noch die kleine Schönheitoperation mit dem völlig
deaktivierten Kanal Menü, falls du da seit der 3.8 nicht schon dran
warst:
Wenn man einen Kanal abschaltet, wird das Soft Menü völlig deaktiviert.
Sinnvoller wäre vielleicht, es auf einen der aktiven Kanäle zu schalten,
oder zumindest die "Dispatch Channel"-Taste freizugeben, damit man die
verbleibenden Kanäle bequem neu anordnen kann.
Frohes Schaffen, wo Hamburg anscheinend von der Wochenendhitzewelle
verschont bleibt ;-)
Gruß
Rainer
Hallo Hayo,
bei der Darstellung im Delayed Fenster gibt es noch einen Bug mit dem
Datenzugriff. Wenn man bei aktivem und weit links liegendem Delayed
Fenster die TB langsamer schaltet, wird u.U. auf ungültige Daten
zugegriffen. Das sieht dann aus wie im beigefügten Screenshot.
Der Fehler läßt sich wie folgt provozieren:
Default Setup, Signal z.B. ProbeComp an Ch1 mit 200mV/div, TB 1 ms/div,
Delayed aktivieren, TB_Delayed 200µs/div, Fenster ganz nach links,
TB_Delayed 500µs/div.
-> et voilà ...
Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann
anscheinend vor dem Anfang des Sample-Speichers. Bei TB-Umschaltung muß
man evtl. einfach das Fenster so verschieben, damit das nicht passiert.
Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende
Kontrolle stattzufinden.
Gruß
Rainer
Alles klar, danke.
Werd ich mal genauer unter die Lupe nehmen. Allerdings muß ich heute
noch unsere Viper spazieren fahren, da morgen schon wieder Regen
angesagt ist.
Gruß Hayo
Rainer W. schrieb:> Hallo Hayo,> Der Anfang des im Delayed Fenster dargestellten Datenbereichs liegt dann> anscheinend vor dem Anfang des Sample-Speichers.
Ja, ist korrekt.
> Bei TB-Umschaltung muß> man evtl. einfach das Fenster so verschieben, damit das nicht passiert.
Es fehlt ein Limiter, der das Fenster wieder zurückschiebt wenn die
Grenze außerhalb des Speichers liegt.
> Wenn das Fenster ganz ganz rechts liegt, scheint eine entsprechende> Kontrolle stattzufinden.
Nein, das sieht nur so aus weil da noch etwas mehr Speicher am Ende ist
der dann dargestellt wird. Aber das ist so auch nicht korrekt. Muß auf
jeden Fall korrigiert werden, bin schon dran...
Gruß Hayo
Hallo Hayo,
ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der
3.6 geht noch alles.
Hast du eine Idee woran das liegen könnte?
Mfg,
Kurt
Hallo Kurt,
was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion?
Ich habe da nichts dran geändert (zumindest bei 3.6/3.7 noch nicht),
allerdings habe ich jetzt beim Dump die Pointer auf das Signal geändert
weil ich das komplett umgestellt habe.
Ach ja, jetzt fällt es mir wieder ein. Ich habe den Debug-Mode im
Comm-Interface abgeschaltet. Der hat bei externen Befehlen immer ein
Echo zurückgegeben. Das Problem hatten wir ja auch mit unserem normalen
Screenshot, der wollte zuerst auch nicht mehr, aber den hat Niklas ja
entsprechend angepasst.
Kann es das sein?
Gruß Hayo
@Rainer
Problem ist gefixt,
Danke für den Hinweis. Die Menüsteuerung für das Channelmenü wollte ich
eigentlich nicht ändern. Dein Einwand dass man erst zum nächsten Kanal
umschalten muß ist zwar korrekt, aber der Sinn der Logik ist ja dass man
durch mehrfaches Drücken den Kanal ein und ausschalten kann (toggeln)
ohne das man zwischendurch in ein anderes Kanalmenü umgeleitet wird aus
dem man dann wieder zurückspringen müßte.
Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so
einfach umzusetzen, da das Menü immer komplett deaktiviert oder
aktiviert wird.
Gruß Hayo
Hayo W. schrieb:> was genau funktioniert denn nicht? Bzw. wie verhält sich die Funktion?
Genau kann ich das noch nicht sagen. Am Mikrocontroller sind die Debug
Möglichkeiten leider sehr begrenzt.
Ich werde weitersuchen.
Hayo W. schrieb:> Die Idee mit der Dispatch-Taste ist nicht schlecht, aber nicht so> einfach umzusetzen, da das Menü immer komplett deaktiviert oder> aktiviert wird.
Das ist ein schlagendes Argument ;-)
und spricht für die erste Lösung. Beim (Re-)Aktivieren eines Kanals wird
ja auch jetzt schon, egal welches Menü angezeigt wird, automatisch auf
das Channel-Menü für den neu aktivierten Kanal gewechselt, so dass das
Zurückspringen jetzt schon funktioniert und das Ganze mit der
Toogle-Philosophie prima zusammenpasst.
Gruß
Rainer
Greetings to everyone, but especially to Hayo
I installed the new beta release from 04 to 08.
In going from FFT: Fn 500Mhz to: Fn12.50Mhz, the DSO crashes.
There is no way to unlock it.
moin moin Hayo,
im Singel Mode ist 'Stop' im display immer an.
Ist die TB recht langsam merkt man nicht ob getriggert wurde
da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es
machbar RUN/STOP beim triggern einzuschalten und nach dem
Bildaufbau die Single Taste zu loeschen ?, und nochmal die
Frage, ist es nicht machbar das man im Single Mode die TB
veraendern kann solange noch nicht getriggert wurde ?, immer
in den Run Mode zu schalten dafuer ist etwas umstaendlich (und
nutzt die Tasten ab ;) )
vlG
Charly
Charly B. schrieb:> moin moin Hayo,
Hi Charly
> im Singel Mode ist 'Stop' im display immer an.
Ja, der Displayaufbau ist so langsam, dass man das nicht genauso schnell
darstellen kann wie mit den LED.
> Ist die TB recht langsam merkt man nicht ob getriggert wurde> da RUN/STOP erst nach dem Bildaufbau aufleuchtet, waehre es> machbar RUN/STOP beim triggern einzuschalten und nach dem> Bildaufbau die Single Taste zu loeschen ?,
Den hab ich irgendwie nicht ganz verstanden. Ich habe mir das mal bei
200ms/Div angesehen und fand eigendlich alles ganz normal. Die
Umschaltung von Single nach Stop geschieht genau in dem Moment in dem
das Triggerereignis auftritt. Kann man sehen wenn man die Zusatz-LED
aktiv hat (oder ersatzweise die Channel-LED)
> und nochmal die> Frage, ist es nicht machbar das man im Single Mode die TB> veraendern kann solange noch nicht getriggert wurde ?, immer> in den Run Mode zu schalten dafuer ist etwas umstaendlich (und> nutzt die Tasten ab ;) )
Muß ich nochmal prüfen, ist aber nicht ganz einfach, da sich das unter
Umständen mit den virtuellen TB im Stop-Modus beißt.
Gruß Hayo
Kurt Bohnen schrieb:> Hallo Hayo,> ab der 3.7 funktionieren meine screenshot Routinen nicht mehr. Mit der> 3.6 geht noch alles.
Hat sich komplett erledigt. Da die USB-Host Firmware etwas umfangreicher
und anscheinend auch langsamer geworden ist gab es wohl Timingprobleme.
Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung
liegt Kanal 2 um 2 Pixel zu hoch. Außerdem befindet sich am rechten Rand
für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3.
Das angehängte Bild bitte ausreichend vergrößern.
Mfg,
Kurt
moin moin Hayo,
so kann man den 'Fehler' reprodzieren:
utility, Default Setup
TB auf 200ms, trigger so einstellen das er vom testsignal
triggert, jetzt auf Single, dann kurz mit dem TK das
Testsignal antippen und beobachten
vlG
Charly
Kurt Bohnen schrieb:> Außerdem befindet sich am rechten Rand> für Kanal 2 nicht das GND Symbol sondern eine verstümmelte 3.
Bei Kanal 3 und 4 setzt sich das dann fort. Das Gnd-Symbol ist immer zu
sehen, aber darunter tauchen komische Dinge auf.
Debei ist mir aufgefallen, dass direkt unterhalb des schwarzen
Zeichenfeldes, also direkt oberhalb der Soft-Menü Tasten oft Reste von
den Feldern für die Quick Measurement Daten bzw. die berechneten
Curserdaten zu sehen sind. Die Feldreste entstehen z.B. wenn man Quick
Measurement aktiv hat und dann über Utility ein Default Setup auslöst.
Aber das ist wohl eher etwas für einen langen Winterabend ;-)
Gruß
Rainer
Rainer W. schrieb:> Debei ist mir aufgefallen, dass direkt unterhalb des schwarzen> Zeichenfeldes, also direkt oberhalb der Soft-Menü Tasten oft Reste von> den Feldern für die Quick Measurement Daten bzw. die berechneten> Curserdaten zu sehen sind. Die Feldreste entstehen z.B. wenn man Quick> Measurement aktiv hat und dann über Utility ein Default Setup auslöst.>> Aber das ist wohl eher etwas für einen langen Winterabend ;-)
Ouh, das ist ein ganz alter Fehler, da habe ich noch ein schlechtes
Gewissen. Irgendwie geht da das Zählen der Zeilen nicht glatt auf
oder sowas.
Nabend,
@Kurt
> Trotzdem habe ich noch 2 kosmetische Fehler gefunden: Bei GND-Kopplung> liegt Kanal 2 um 2 Pixel zu hoch.
Das kann ich bestätigen! Das ist war aber auch bei "fast" allen
Vorgängerversionen auch so und ist nicht nur bei der GND-Kopplung so,
zumindest ist das bei mir der Fall.
Ja ja, die Nulllinie war ja schon immer ein Problem...
@Guido,
> Ouh, das ist ein ganz alter Fehler, da habe ich noch ein schlechtes> Gewissen. Irgendwie geht da das Zählen der Zeilen nicht glatt auf> oder sowas.
...wieso hast du da ein schlechtes Gewissen???
Das passiert aber auch manchmal bei anderen einstellungen, das da mal
ein paar Reste auf dem Schirm bleiben.
LG Michael
Hi Leute,
danke für die Rückmeldungen. Leider bin ich gestern und heute bei
Kundenterminen und komme daher zu nichts. Werde mal morgen alles unter
die Lupe nehmen (im wahrsten Sinne).
Gruß Hayo
Michael D. schrieb:> ...wieso hast du da ein schlechtes Gewissen???
Weil ich da mal dran war. Wenn ich mich recht entsinne habe ich den
Fehler nach Abschalten der Cursor noch behoben, beim Quickmeasure
und anderen Fällen nicht mehr. Ist arg lange her.
Grüße, Guido
Kein Grund das schlechte Gewissen zu bemühen, schließlich war das doch
eine echte Hilfe, dass Du die Stellen zum Beheben der Pixelfehler schon
mal gefunden hattest. Ich wäre da sicher so schnell nicht zu gekommen.
Ich schau mal ob ich das für das neue Release beheben kann.
Gruß Hayo
So hab das mal geprüft, Guido - Kopf hoch, alles ist gut. Das Löschen
funktioniert einwandfrei, Du bist also rehabilitiert. Nur wenn man
direkt aus den Cursorfunktionen ein Defaultsetup auslöst, dann werden
die Felder nicht ordnungsgemäß gelöscht, da es ja keine normale
Beendigung der Funktion ist. Kann ich aber nachrüsten.
Gruß Hayo
So, Überreste sind beseitigt....für immer im Null Device!
Und an den Nulllinienmarkierungen bin ich auch grad dran. Ist mir erst
jetzt aufgefallen dass da teilweise Nonsense steht. Zum Beispiel ist
immer das Groundsymbol auf der linken Seite zu sehen was ja überhaupt
keinen Sinn macht. Das muß anders werden...
Hayo
... und das wird es auch. Ich habe jetzt alle Bitmaps überarbeitet und
die Formate korrigiert. Das sieht schon ganz gut aus. Meine Frau hält
mich schon für etwas verschroben, da ich mit der Lupe versuche in den
Oszi-Bildschirm reinzukriechen :-)
Gruß Hayo
Ha, der Hayo...
dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von
5m Entfernung!!! Ich weiß, das war jetzt böse... :-)
Was is'n mit der Mess-ID. "Welec", so wie "TEK", "Hp", "Rigol" ?
Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit
was da gemessen worden ist! Kannst du das mit einbauen, oder ist das
zuviel Akt? Dachte nur, wo du schon dabei bist... :-/
Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster
wäre, hatten wir aber schon mal angesprochen, wollte nur mal in
Erinnerung rufen.
Gruß Michael
Michael D. schrieb:> Ha, der Hayo...> dafür brauchst du eine Lupe? Die 2 Pixel an der Zerolinie sehe ich von> 5m Entfernung!!! Ich weiß, das war jetzt böse... :-)
Respekt, dann hast Du gute Augen. Zugegebenermaßen lassen meine seit
zwei drei Jahren immer mehr nach. Deswegen ist mir das mit den falschen
Anzeigen auch nicht weiter aufgefallen. Shit...
> Was is'n mit der Mess-ID. "Welec", so wie "TEK", "Hp", "Rigol" ?> Die haben das immer chic oben links in der Ecke, da weiß man gleich, mit> was da gemessen worden ist! Kannst du das mit einbauen, oder ist das> zuviel Akt? Dachte nur, wo du schon dabei bist... :-/
Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden?
> Was noch total fein wäre, das beim "QM" noch ein viertes Messfenster> wäre, hatten wir aber schon mal angesprochen, wollte nur mal in> Erinnerung rufen.
Ist nicht vergessen, gibt es aber noch nicht mit diesem Release, ich
hoffe Ihr könnt das verschmerzen. Sonst wird die ja auch nie fertig. Ich
wollte eigentlich wenn Ihr da nichts Grobes mehr habt heute das neue
Release raushauen. Also wenn Ihr noch was habt dann hurtig, bald ist
Anzeigenschluß...
Gru0 Hayo
Ist die Unterstützung der Eingangsplatinen schon drin?
Wenn ja ging das an mir vorbei, deshalb habe ich die Betaversionen
bisher noch nicht angefasst.
Jörg
Hallo Hayo,
> Das hab ich nicht so ganz verstanden. Wo willst Du die ID einblenden?
ähem, immer noch oben links, in der Ecke?!?
Ok, ich habe mal auf die Schnelle nach ein paar Beispielen geschaut...
guggst du!
Gruß Michael
Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der
Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und
siehe da - da stehen die Informationen von Kanal 1.
@Jörg
Ja die Hardwareunterstützung ist im Final Release drin.
Gruß Hayo
Michael D. schrieb:> Wo willst Du die ID einblenden?
Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn.
Interessant wäre sowas für die Screenshotfunktion. Ob das dann besser am
PC oder im Welec vor der Übertragung eingeblendet werden soll kann ich
allerdings nicht beurteilen, da ich dazu die SW zu wenig kenne.
Als weiteres Gutie für das final Release habe ich noch am
Rotary-Interface rumgeschraubt und die Geschwindigkeit bei TB-Wechsel
und Spannungsbereichwechsel erhöht. Bislang war das doch arg zäh,
besonders bei langsamen Zeitbasen. Das fühlt sich jetzt schon viel
besser an.
Gruß Hayo
Hayo schrieb:
> Dann hatte Dich doch richtig verstanden. Meine Frage kam weil da an der> Stelle kein Platz ist um eine ID auszugeben - guggst Du auf WELEC und> siehe da - da stehen die Informationen von Kanal 1.
...hab' ich 'geguggt' und weiß ich ja! Vielleicht kann man den Krempel
ein
Stück nach rechts rutschen?!?
War ja nur so eine Idee, weil fast alle DSO's das haben.
Wenn es zuviel Aufriss ist, dann lassen wir das...
> Das Einblenden auf dem Screen bringt ohnehin keinen Informationsgewinn.
Achso? Hm, wenn von DSO's Fotos geschossen werden, weiß man gleich mit
was da gemessen worden ist! Finde ich schon informativ.
> Interessant wäre sowas für die Screenshotfunktion. Ob das dann besser am> PC oder im Welec vor der Übertragung eingeblendet werden soll kann ich> allerdings nicht beurteilen, da ich dazu die SW zu wenig kenne.
Da wäre Beides auch zu begrüssen, da ja Screenshots eh ein kleineres
Dateiformat haben, als Fotos.
Ist ja jetzt nicht so Lebenswichtig!
Gruß Michael
Und hier ist sie, die diesjährige Holiday Edition.
Und wieder hat sich sehr viel getan. Dank Eurer Hilfe beim Testen und
Analysieren konnte die Firmware wieder ein ganzes Stückchen verbessert
werden. Die neuen Funktionen sind in der Special Functions.txt
beschrieben.
Ansonsten einfach hier fragen.
Viel Spaß
Hayo
p.s. aufgrund der Komplexität kann sich der eine oder andere Fehler
natürlich trotzdem noch eingeschlichen haben. Dann gebe ich natürlich
kurzfristig eine neue Kompilation raus.
Hallo Hayo,
Ich habe deine Holiday Edition gerade mal geflasht und schon mal ein
wenig getestet.
Shot 1:
Kanal 2 GND-Coupling, ist die Linie jetzt 2 Pixel zu hoch...die Lupe war
staubig! :-)
Shot 2:
Im Quick Measure steht bei beiden Kanälen Peak to Peak auf 0 Volt beim
GND-Coupling, das ist prima!
Shot 3:
Im Quick Measure steht auf Kanal 1 Peak to Peak 625mV u. Kanal 2 auf 1
bis Teilweise 1,5 Volt, bei AC-Coupling! Ich glaube, das ist too much.
Die Spannungen bleiben, egal welchen Filter ich dazu schalte. Kann das
noch Jemand bestätigen?
Was meinst du?
Gruß Michael
Ok, es sind die "bösen" einer u. zweier Skalen, die ja das extreme
Grundrauschen mitbringen, dann kann das hinkommen. Die Filter werden in
dem Fall also nicht berücksichtigt.
Wäre es möglich, das die Filter, die ja das Rauschen unterdrücken, bei
der Messung mit einzubeziehen? Das soll heissen, wenn ein starker Filter
ausgewählt ist, sollte das QM das wissen, ist das möglich?
Gruß Michael
Hayo W. schrieb:> @Jörg>> Ja die Hardwareunterstützung ist im Final Release drin.
Ich war gerade im Begriff nachzufragen, was denn die "Final Release"
ist, ob die "Holiday Edition" (Weihnachtsausgabe?) schon sowas ist.
Nun habe ich in den Code geguckt und meine Hinterlassenschaften
gefunden. ;-)
Es sind eher zu viele (weil ich dir das so hastig abgekippt habe): Der
Testcode in hardware_t.cpp kann und sollte raus, das sind die Definition
und Aufrufe von porttest().
Ferner ist in ADDON_SetSwitches() noch etwas mit #if 0 auskommentierter
Code, der kann auch entsorgt werden, sowie die auskommentierten
printf().
Nun sollte ich wohl mal bald die Skalierungsfaktoren bestimmen?
Danke und Grüße
Jörg
@Michael
warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann
hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei
Gelegenheit mal nach.
Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da
stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das
nicht aufgefallen.
@Jörg
Die Addon-Unterstützung ist ja erstmal auch nur für Dich, da außer Dir
noch keiner die Teile eingebaut hat. Wenn Du da den Feinschliff gemacht
hast übernehme ich das einfach in die nächste Version.
By the way - wie findet Ihr die neuen Bitmaps? Achtet auf das schicke
Average-Zeichen beim Triggerkanal. Und es wird jetzt auch rechts ein
DC-Symbol eingeblendet.
Gru0 Hayo
hmm...
> warum hast Du das nicht vorhin gesagt, das sind doch alte Fehler, dann> hätte ich da schnell nochmal einen Fix gemacht. Naja, ich schieb das bei> Gelegenheit mal nach.
Ich hatte das wohl irgendwo da oben schon mal abgelassen, jetzt hatte
ich auch nicht mehr daran gedacht, ausserdem will ich dir nicht ständig
auf die "Nüsse" gehen...
> Zur Zeit werden bei QM wohl nach die alten Speicherbereiche gelesen, da> stehen aber nur die Rohdaten drin. Da ich QM selten nutze ist mir das> nicht aufgefallen.
Ich finde das QM sehr praktisch für das schnelle Ablesen.
Beim Analogen muß man ja erst mal die 'Kästen' abzählen! Und ja,
manchmal mache ich mir's halt einfacher, dafür ist es ja da.
Na klar ist mir das neue DC u.AC-Symbol aufgefallen, ist jetzt schön
lesbar!
Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch
mal ein Bildchen...
Ok, hier noch ein paar Fehler:
1.Shot:
Im USTB-Modus, bleiben Reste auf dem Schirm, wohin ich auch schalte, die
bleiben!
2.Shot:
Ich gehe auf 1GSa/s 50ns und die Reste bleiben!
Ausserdem bleiben die Symbole 'Roll Forward' und 'Step' stehen.
Dasselbe passiert auch umgekehrt, gehe ich in den USTB-Modus, bleibt
oben der Combitrigger und noch andere Bröckchen stehen.
Gruß Michael
und jetzt in's Bett!
Hallo zusammen,
erstmal vielen Dank für den großen, dauerhaften Einsatz für die
Firmware.
Beim Erforschen der neuen Version sind mir einige Dinge aufgefallen:
Die obigen Bilder sind mit GND-Kopplung auf 1 und dem Testsignal an 2
entstanden.
Im USTB läßt sich die Kopplung nicht umstellen. Das Menü (GND, DC, AC)
verschwindet sofort wieder.
Die ganze Bedienung im USTB ist exterm zäh. Das Übertragen eines
Screenshots dauert ewig (192s gegenüber 15s normal).
Der Shift-Mode (USTB) verschiebt die Nullinie des GND-gekoppelten
Signals nach unten (bei Reverse doppelt so weit wie bei Forward).
Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich
erwarten würde...
Oder interpretiere ich was falsch?
Viele Grüße,
Rainer
Ok danke für die Rückmeldungen,
ich sehe es gibt noch was zu tun. Mal sehen ob ich dieses Wochenende
noch eine bereinigte Version rausgeben kann.
Gruß Hayo
Michael D. schrieb:> Average-Zeichen??? Wie, wo ist das? Hab' ich da was übersehen? Mach doch> mal ein Bildchen...
Ja, einfach Average einschalten, dann erscheint am Triggerkanal das
Symbol.
Gruß Hayo
Rainer H. schrieb:> Die Summierung (1+2) verstehe ich, (1-2) ist zumindest nicht das was ich> erwarten würde...> Oder interpretiere ich was falsch?
Was würdest Du denn erwarten? Ich finde das sieht doch gut aus, wenn man
davon absieht, das die Skalierung etwas ungünstig gewählt ist. die
sollte möglichst auch bei 500mV liegen um vernünftige Ergebnisse zu
kriegen.
Gruß Hayo
Hallo Hayo,
wie wäre die Einführung eines Math-Zero-Pfeils? Dann könnte man
schneller beurteilen ob die Ergebnisse stimmen.
Für die Mathematik werden doch sicherlich die spannungsbezogenen Werte
verrechnet und nicht die Binärwerte!?
Ohne das jetzt ausprobiert zu haben, aber lässt sich Math aus skalieren?
Falls ja wäre eine Anzeige in irgendeiner Ecke praktisch.
branadic
> Ja, einfach Average einschalten, dann erscheint am Triggerkanal das> Symbol.
Ha! Ich hab's gefunden...
Was heißt "Infinite(unendlich)" in Bezug auf den Average-Mode?
Gruß Michael
nimmt man diese Minusfunktion eher für differentielle Signale oder evtl.
auch für Strommessungen also Spannung vor und nach Shunt? Lässt sich da
vielleicht eine Invertierung einbauen.
Beispiel Spannung vor Shunt(0,1Ohm) 1V und danach 0,95V = 0,05V / 0,1
Ohm = 0,5A
bei höherem Spannungsabfall (höherer Stromfluss) soll jetzt das Signal
auf dem Oszi steigen anstatt ab zufallen oder funktioniert es evtl.
einfach die Kanäle zu wechseln so das 0,95-1V gerechnet wird?
Hallo Hayo,
Du hast völlig Recht. Irgendwie hab ich die Einstellungen während des
Tests unbewußt verändert. Also blinder Alarm. Sorry.
Allerdings ist mir beim Testen noch aufgefallen, dass im USTB mein
GND-gekoppeltes Signal 1 ziemlich Amok läuft.
Viele Grüße,
Rainer
Ja die Groundkopplung ist noch nicht für USTB implementiert. Ich habe
aber gerade die 4.1 in Arbeit in der alle genannten Punkte bereits
behoben sind. Ich mache nur noch schnell etwas Feinschliff, dann gibts
die neue Version gleich hier.
Gruß Hayo
Hab auch gleich noch ne Kleinigkeit gefunden. Wenn man "About
Oszilloscope" drückt wird hinterher nicht alles korrekt wuieder
hergestellt. Das ist aber auch schon ein alter Bug. Hat wohl noch keiner
so richtig bemerkt.
Wird natürlich behoben...
Hayo
Ahhh,
das Quickmeasure weiß es jetzt auch, das da ein Filter an ist!
Grafikreste gibt es auch keine mehr.
Ich bin begeistert, nun gibt's den 7.Stern ******* für Hayo!!!
LG Michael
...und das ist noch nicht alles. In der 4.2 die gerade entsteht habe ich
auch schon mit der Wiederherstellung nach dem Info Screen (Splash)
aufgeräumt. Man startet daher jetzt endlich genauso wie man das Gerät
ausgeschaltet hat bzw. wie es vor dem Info-Screen war.
Gruß Hayo
Hallo Hayo,
in der Kombination von USTB mit der Display Einstellung "Persist", wobei
jetzt einmal dahin gestellt sei, ob das irgendwofür sinnvoll ist,
merkwürdige Signale.
Mit festen +5V am Eingang sieht mit Persist-Mode "off" alles normal aus,
bis auf den 0 -> 5V Sprung ganz am Anfang. Ungefähr in der Mitte des
Bildschirms habe ich dann den Persist-Mode, bei immer noch konstanten 5V
am Eingang, aktiviert und erhalte den "Lattenzaun" (Bild). Wenn man dann
innerhalb der Aufzeichnung Persist kurz aus- und wieder einschaltet,
wird der richtige konstante 5V Pegel angezeigt, bis man einmal kurz das
Signal auf 0V runternimmt, dann wird wieder der Lattenzaun aufgebaut.
Hast du eine Idee, wo das herkommt?
Gruß Rainer
Jupp, hab ich. Am Gridende geht ja der Pegel von 5V wieder runter auf
0V, da am Gridende ja der aktuelle Acquisitionzeitpunkt ist und vorher
anscheinend nichts in den Puffer geschrieben wurde. Dieser Sprung von 5
auf 0V wird dann durch die persistente Darstellung weiter durchgereicht.
Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten
Durchlauf mit 5V hattest wird das sicher nicht mehr auftreten, da ja
dann schon der 5V Pegel im "Ringpuffer" steht und es keinen Sprung mehr
gibt.
Gruß Hayo
p.s. ich beiß mir hier gerade die Zähne an der FFT aus. Alles andere
kehrt super wieder in den Ursprungszustand zurück nach einem Restart -
nur die FFT nicht, die klemmt danach. Soon Mist...
Hayo
Hayo W. schrieb:> Wenn Du das Ganze machst nachdem Du vorher schon einen kompletten> Durchlauf mit 5V hattest ...
Das stimmt. Dann ist das wohl so ...
Dafür hat sich bei mir gerade die Triggerlinie in den oberen
Bildschirmbereich mit den Meßbereichsanzeigen verirrt.
1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt,
knabbert das "T" ganz links ein bisschen an der "1" in der obersten
Zeile
2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu
negativen Werten schiebt, wandert die gestrichelte Line und das "T"
incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des
gleichfarbigen Kanals verschwindet auch ganz. Das sieht so aus, als ob
das Clipping für den Triggerlevel die Invertierung nicht berücksichtigt.
Nach unten wird die Triggerverschiebung nämlich sauber begrenzt.
In dem Inset sieht man das schön vergrößert ;-)
Den FFT-Restore wirst du schon knacken.
Gruß Rainer
Hallo Hayo und alle an der Weiterentwicklung unseres Scopes
Interessierten.
Zuerst meine Gratulation für die neue USTB-Version. Hat bei mir schon
nützliche Dienste geleistet. Anbei ein Screenshot mit einem kleinen Bug,
der sich sicher leicht beheben lässt.
Ich bewundere auch die Geduld mit der Hayo alles anpackt und unser Gerät
inzwischen zu einem (zumindest in meiner Werkstatt) nicht mehr
wegzudenkenden Instrument gemacht hat. Dafür vielen Dank.
Manfred
Manfred,h schrieb:> Anbei ein Screenshot mit einem kleinen Bug,> der sich sicher leicht beheben lässt.
Bei mir wird die Periodendauer richtig angezeigt. Wie erzeugst du den
Fehler?
Gruß Rainer
Hallo Manfred,
es freut mich zu hören, dass Dir die Firmware gute Dienste leistet.
Danke für den Hinweis, ist natürlich auch schon behoben. Da hatte ich
die Rundungsroutine ungeschickterweise erst nach der Einheitenermittlung
aufgerufen, das ist aber jetzt korrigiert.
Gruß Hayo
Hallo Hayo,
erstmal Danke für Deine tolle Arbeit!
Ich hab hier noch 2 Dinge aus der 4.1HE:
Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen
Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen.
Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die
screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi
selbst :-(
Gruß Jürgen
Jürgen schrieb:> Nach dem Ein- und Ausschalten von "Quick Meas" bleiben die horizontalen> Cursoren stehen. Lassen sich aber mit "Cursors" Betätigung löschen.
Ist in der neuen Version behoben -> danke
> Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die> screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi> selbst :-(
Das kann ich mir leider nicht erklären. Bei mir läuft der Screenshot
einwandfrei auf zwei verschiedenen Rechnern und auf Windows und Linux.
Was läuft da bei Dir schief???
Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas
aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?
Gruß Hayo
Hayo W. schrieb:>> Ich bekomme irgendwie keinen Screenshot mit der 4.1HE mehr hin. Die>> screenshot.exe beendet sich nach ungefähr 30% der Ausgabe vom Oszi>> selbst :-(> Das kann ich mir leider nicht erklären. Bei mir läuft der Screenshot> einwandfrei auf zwei verschiedenen Rechnern und auf Windows und Linux.> Was läuft da bei Dir schief???
Habe mir das eben nochmal genauer angesehen. Zunächst gleiche Reaktion.
Habe dann im Verzeichnis der screenshot.exe eine Datei
".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es
wieder :-)
Sorry - Hat mich auch gewundert, daß hier Screenshots gepostet
wurden....
Übrigens gefällt mir die alte Statusleiste viel besser!!! Die neue ist
doch zu verspielt und nicht so "technisch"!
Gruß Jürgen
> ".~lock.trace-0001.csv#" gefunden und erstmal gelöscht. Danach geht es> wieder :-)
ach, wo kommt die denn her? Wurde die irgendwie generiert?
Hallo Hayo,
ich habe mir den Screenshot mal 5 Minuten lang angeschaut und mußm dem
Jürgen zustimmen! Als Designer, würde ich das aber nicht komplett
zerschlagen. Wie sieht's denn aus, wenn man da 3 Blöcke daraus macht?
Z.B. ein Block für die Kanäle mit Spannung, der nächste Block 1GS/x 20ns
und den dritten Block mit dem Rest? Dann wäre da nicht so viel 'Unruhe'
in der Grafik!
Gruß Michael
Ich sehe schon, das spaltet evtl. die Gemeinde. Ich kann mal einen
Testschalter einbauen, damit man zwischen den Darstellungen auswählen
bzw. testen kann.
Gruß Hayo
Leider zu früh gefreut :-( Das war nicht die Ursache.
Es geht wieder nicht. Habe noch kein Schema entdecken können. Mal
funktioniert es und mal nicht.
Ich hätte jetzt zwei Verdächtige hier bei mir:
Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34
- Port.
Ich hab mal bei stehendem DSO-Bild mehrere Screenshots mit einem
Terminalprogramm aufgenommen. Etwa 1 von 10 Aufzeichnungen hat eine
andere Länge ??? Kann das sein?
Hajo, halte Dich aber damit erstmal nicht auf. Ich muss das DSO wohl mal
zu meinem PC tragen und dort testen.
Moin Hayo,
Hayo W. schrieb:> Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas> aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?
ich finde die alte Version einfach klarer.
@Michael
Dein Kompromiß wäre eine ernste Überlegeung wert.
Noch mal ein dickes Lob speziell für das jetzt endlich richtig
benutzbare Delay-Fenster.
Gruß Rainer
Hayo W. schrieb:> Anbei ein Screenshot der neuen Version. Ich habe die Statusbar etwas> aufgemotzt. Findet dass Euer Wohlwollen, oder ist das zu verspielt?
Hallo Hayo,
auch kann mich für das neue Design nicht begeistern. Zu unübersichtlich
- es fehlt irgendwie eine klare Linie.
Gruß,
Bernd
Jürgen schrieb:> Ich hätte jetzt zwei Verdächtige hier bei mir:> Laptop mit Dualcore CPU, besch.. USB-Seriell Konverter am Expresscard/34> - Port.
Es bleiben die zwei Verdächtigen. Nr.2 würde ich mit Vorurteil(?) als
Hauptverdächtigen bezeichnen..
Hab mit einem anderen Rechner getestet: Screenshot geht einwandfrei.
Ich bitte um Entschuldigung, weil man ja eigentlich hier erst posten
sollte, wenn man solche einfachen Dinge durch Test ausgeschlossen hat
... :-O
Freue mich schon auf die neue Version!
Gruß Jürgen
@Jürgen
Kein Problem, lieber einige Rückmeldungen mehr als weniger. Nur so
kommen wir weiter.
Ich sehe schon, die Tendenz geht gegen die neue Statusleiste. Ich gebe
zu ich bin auch etwas unentschlossen und schwanke zwischen nettem Design
und besserem Kontrast.
Ich warte nochmal ab, aber es sieht so aus als würde das neue Design
wieder sterben....:-(
Hat ne Menge Arbeit gemacht. Aber man muß halt experimentieren.
Hayo
Rainer W. schrieb:> Dafür hat sich bei mir gerade die Triggerlinie in den oberen> Bildschirmbereich mit den Meßbereichsanzeigen verirrt.
Ist erledigt.
> 1. Wenn man nach Default Setup den Triggerlevel ganz nach oben schiebt,> knabbert das "T" ganz links ein bisschen an der "1" in der obersten> Zeile
Ist erledigt.
> 2. Wenn man einen Kanal invertiert und dann den Triggerlevel zu> negativen Werten schiebt, wandert die gestrichelte Line und das "T"> incl. Pfeil munter hinter den Kanalnummern längs und die Nummer des> gleichfarbigen Kanals verschwindet auch ganz.
Ist erledigt.
>> Den FFT-Restore wirst du schon knacken.
Ist erledigt
Hier die Vorabversion der 4.2 die schon alle Fixes beinhaltet aber noch
mit der neuen Statusleiste daherkommt. Vermutlich die einzige Version
mit dieser Statusleiste.
Gruß Hayo
mir gefällt auch die alte Version der Statusleiste besser. Ich würde
diese gerne mal mit dem Hintergrund zur Schrift invertiert sehen, sieht
bestimmt auch nicht schlecht aus. Vielleicht den Schalter dafür
einbauen.
Um das Gute aus beiden Welten (schickes Design und hoher Textkontrast)
zu verbinden, habe ich hier mal grob eine Version skizziert, die den
bisherigen helleren Farbton als Texthintergrund beibehält und eine
dunklere Farbe als Basishintergrund verwendet. Ob Einzelfelder oder
Gruppenfelder sei jetzt mal dahingestellt. Die Menüzeile (und
Meß-/Cursorparameter) könnten dazu passend eingefärbt werden, wobei man
mal gucken muß, ob mit der verfügbaren Farbpalette guter
Hintergrundkontrast zum Zeichenfeld und Farben für den 3D-Effekt unter
einen Hut zu bringen sind.
Gruß Rainer
ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W
bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen
das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht
auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso
weniger Helle Balken man auf dem LCD hat.
moin Rainer,
deine Version gefälllt mir ganz gut, vielleicht noch ein ganz helles
Grau im Hintergrund, mal schauen, wie das kommt...
(hast du meine letzte PN nicht bekommen?)
moin Thomas,
deine Version kommt auch ganz gut! Evtl. noch einen Dunkelgrauen
Hintergrund, sodas man sieht, wo der Messbereich vom Schirm aufhört?
Wenn das machbar wäre sich die Farbgebung, je nach Lichtverhältnissen
anpassen zu können, wäre das ein Highlight. Natürlich nur dann, wenn die
Perfomance nicht darunter leidet!
Gruß Michael
ich finde die Abtrennung zum Messbereiches ist doch durch das
Raster(Rahmen) gegeben. Anderst würde es das ganze optisch drücken
wodurch es kleiner aussieht.
Thomas O. schrieb:> ich habe mir das so vorgestellt wie auf der rechten Seite. Also S/W> bietet doch den höchsten Kontrast und viele Professionelle Oszis zeigen> das auch so an also ohne eingefärbten Hintergrund. Ich finde es sieht> auch geräumiger aus. Und Nachts ist es dann auch nicht so grell umso> weniger Helle Balken man auf dem LCD hat.
Also nachts ohne Licht nutze ich das Oszi recht selten :-) Aber
ansonsten stimme ich dir voll zu: so ists am besten ablesbar und es
sieht nicht so vollgequetscht aus. Ich finde es ohne eingefärbtem
Hintergrund am besten.
hallo thomas,
der linke Shot sieht gut und aufgeräumt auf.
Wo du schon dabei bist, nimm mal verschieden Grautöne und setze die mal
als komplette Leiste (ohne die Kästen), hinter die weisse Schrift...mal
schauen, wie das kommt!
Gruß Michael
> welche Kästchen meinst du die der Menüpunkte?
Nö.
Ich meinte die obere Leiste, ohne die Kästchen mit einem mittleren oder
dunklen Grau, aber durchgehend von links nach rechts...vielleicht sollte
man einige Grautöne mal testen?!?
Ich finde den linken Shot auch nicht schlecht! Und überhaupt finde ich
die Schwarz-Weiß-Kombination schon ansprechend, ist nicht so verspielt.
Was mir gut gefällt, ist die '1 Pixel' breite Kontur., die ist schön
dezent und nicht so aufdringlich.
Ich bin schon ganz gespannt!!! Wie machst das denn mit den Shots,
spielst du da im Code?
Gruß Michael
EDIT: Mit der Scwarz-Weiß Kombination, könnte man im Display-Menu
zwischen positiv u. negativ, je nach Sichtverhältnissen hin u.
herschalten?!? Da wäre dann für fast jeden was dabei, oder?
noch mal EDIT: Die Kästchen im unteren Bereich, würde ich auf jeden Fall
lassen...
Hallo allerseits,
bin gerade erst nach Hause gekommen. Hier ist ja ganz schön was los.
@Michael
Die Bilder sind Kopien von meinem Shot. Achte mal auf die Signale. Die
Bilder sind einfach mit einem Bildbearbeitungsprogramm manipuliert
worden. Ist aber eine gute Idee um mal ein Gefühl für die Farben zu
kriegen.
@Charly
Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter
Bugfix residiert sondern unter Change Request. Habe ich aber auf dem
Zettel stehen.
(Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?)
@all
Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich
irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß
Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar
nicht :-).
Wenn man die Statusleiste in schwarz/weiß realisiert böte sich
zusätzlich die Option die weißen Zeichen in den Gridlayer zu schreiben,
was die Möglichkeit bietet die Helligkeit zu verstellen und auch die
Farbpalette im Display-Menü einzustellen - so wie bei der FFT wenn das
s/w Layout aktiv ist.
Gruß Hayo
>Wie machst das denn mit den Shots, spielst du da im Code?
Wie Hayo schon sagte, mit dem Bildbearbeitungsprogramm, ich nehme mit
mit der Pinzette eine Farbe und Fülle dann einen Buchstaben oder einen
Bereich mit der selektierten Farbe, etwas unprofessionell, aber
Paint.net was ich gerne benutze, hat keine Funktionen wie Farbe
ersetzen.
Mir gefällt auch dieser verspielte Hintergrund nicht einfach Schwarz
wäre schonmal ein Vorteil, die Schriftfarben sind nebensächlich. Es
erinnert mich immer ein meinen Sat-Receiver mit klicki-bunti Oberfläche.
Hallo allerseits,
also ich hab da eben ganz andere Probleme :-(
Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?
Hajo, da scheint etwas durcheinander geraten.
Gruß Jürgen
all
> Ich finde allerdings zuviel schwarz/weiß nicht so gut, da fühle ich mich> irgendwie in alte Zeiten zurückversetzt als es nur schwarz/weiß> Fernseher bzw. Displays gab. Kennen viele von Euch wahrscheinlich gar> nicht :-).
pfff, is' klar! bin auch schon fuffzich und kein
Schwarz-Weiß-Denker :-)))
Ok, das letze Layout von Thomas finde ich schön übersichtlich.
Mein Vorschlag:
Die obere Anzeige mit Hintergrundbalken, Schrift ohne Kästchen und die
untere Reihe mit Kästchen.
Schriftfarbe für unten u. oben in einem Auswahlmenu veränderbar.
Hinntergrundfarbe für oben u. unten ebenfalls veränderbar,dann bräuchte
man quasi nur 2 Scrollmenus im Displaymenu, geht das?
Dann wäre für Jeden was dabei und das Welec wäre in der Klasse schon mal
'einmalig'!
Was meinst du, oder ist das zuviel Aufriss?
Gruß Michael
> Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?
Ich habe das Teil gerade mal an.
Stimmt, da geht erst mal nix! Erst wenn man den entsprechenden Button
gedrückt hat, dann lassen sich die Zeiten verstellen...
Ich hab's jetzt noch mal getestet, immer mal die Knöppe drücken, dann
tut sich was, dauert halt ein wenig bis die Zeiten umspringen...
Ist schon nicht so ganz ohne...
Die gelben Buttons habe ich inzwischen schon wieder rausgenommen nachdem
die allgemeine Stimmung eindeutig dagegen war.
Wie wärs mit einer Testmöglichkeit für den monochromen Status. Die
Umschaltung geht mit Shift + D via Terminal. Default ist allerdings die
normale Darstellung.
Gruß Hayo
na klar!
Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da
steht alles, ausser Shift+D da steht noch: not available!
Auf dem Screenshot steht alles drauf, guggst du hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil4)"
Gruß Michael
Michael D. schrieb:> na klar!> Comterminal öffnen, Parameter eingeben, verbinden, "h" eintippen und da> steht alles, ausser Shift+D da steht noch: not available!
Wie jetzt? Da steht * Monochrome switch : Shift + D *
-> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael?
Steht der Gang zum Augenarzt an?? ;-)
Bitte berücksichtigt, dass in der monochromen Darstellung noch nicht
alles 100%ig funktioniert, da ist noch das Stopzeichen das stehen bleibt
und die Kanalnummern hinterlassen Spuren...
Soll halt zum Testen sein. Wenns gefällt kann ich das immer noch
verbessern.
@Thomas
Du brauchst ein Terminalprogramm. Unter Linux benutze ich immer Minicom.
Unter Windows ist Teraterm mein Favorit. Gibt es frei zum Download hier:
http://sourceforge.jp/projects/ttssh2/releases/
Gruß Hayo
> Wie jetzt? Da steht * Monochrome switch : Shift + D *
ja, steht 'jetzt' da, aber nicht auf dem Link von meinem Shot...
> -> das ist jetzt schon Dein zweiter Aussetzer! Was ist los Michael?
nö, noch der Erste...dumdidum
> Steht der Gang zum Augenarzt an?? ;-)
unter Anderem... :-(
Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine
Vorverdauung!!!
Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit
der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor
lassen?
(Ich denke mal, das das nur mal auf die Schnelle war für's Testen?)
Gruß Michael
Michael D. schrieb:> Schon zurück vom Griechen??? Du isst zu schnell, denk' an deine> Vorverdauung!!!
Ist zu Fuß nur 10 Minuten entfernt...
> Ich habe mal kurz getestet, gefällt mir nicht so. Die Schrift wird mit> der Gridhelligkeit heller u. dunkler! Kann man das Grid aussen vor> lassen?
Geht auch, müßte mal sehen welcher Layer sich da anbietet.
> (Ich denke mal, das das nur mal auf die Schnelle war für's Testen?)
Korrekt, das ist nur um mal zu checken ob das ne Option ist. Der normale
Status bleibt auf jeden Fall, alles Andere würde ich optional machen
über irgendein Menü oder Schalter.
Gruß Hayo
Jürgen schrieb:> Hallo allerseits,>> also ich hab da eben ganz andere Probleme :-(>> Wieso geht denn nun die Zeitverstellung im Pulse With Modus nicht mehr?> Hajo, da scheint etwas durcheinander geraten.
Leider habe ich da einen ganz üblen Bug in die Rundungsroutine
eingebaut...
Danke für den Hinweis, Abhilfe kommt so schnell wie möglich.
Gruß Hayo
für die Spektrum Darstellung, gab es doch mal mehrere Anzeige-Modi (ich
glaube so 5 Stck.)die man mit dem Drehgeber auswählen konnte, wo ist das
denn hin?
Momentan ist da Win: Rectangle als feste Darstellung angegeben.
Gruß Michael
Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen
zweiten Druck auf den FFT-Button.
Ist nicht optimal - weiß ich. Deshalb werde ich auch automatisch ins
FFT-Menü verzweigen wenn die FFT gewählt wird.
Gruß Hayo
Für alle die nicht so genau wissen wie das mit dem Terminal funktioniert
hier eine Beschreibung, die ab jetzt auch bei den Releases mit dabei
ist.
Hayo
So hier die 4.2 mit dem verbesserten Monochrome Status.
Es wird jetzt der cremefarbene Layer benutzt statt des Gridlayers. Der
weiße Layer geht leider nicht da dieser einen Darstellungsfehler hat der
Probleme auf der linken Seite verursacht.
Ich finde ja eigentlich den Gridlayer besser...
Gruß Hayo
Hayo W. schrieb:> Leider habe ich da einen ganz üblen Bug in die Rundungsroutine> eingebaut...>> Danke für den Hinweis, Abhilfe kommt so schnell wie möglich.>> Gruß Hayo
Hallo Hayo, das wäre super!
Ich hab mal im Teil 3 unseres Firmware Threads gesucht, was da noch so
alles zur Triggerung anlag und in der 4.2pre schon realisiert ist:
Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010, ist
realisiert
Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht
realisiert
bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi
12.09.2010, nicht realisiert
und als "nice to have":
auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu
können, von weitererGast 30.09.2010
Nur, damit es nicht vergessen wird :-)
VG Jürgen
Jürgen schrieb:> Hallo Hayo, das wäre super!
Schon geschehen - s.o.
> Ich hab mal im Teil 3 unseres Firmware Threads gesucht, was da noch so> alles zur Triggerung anlag und in der 4.2pre schon realisiert ist:
Ja hab ich auch schon, aber das ist schon etwas unübersichtlich.
> Holdoff-value auf <=134ms begrenzen, von rawi 29.10.2010, ist> realisiert
Korrekt, das ist schon drin
> Bei Pulse Width Holdoff zwingend auf Off setzen, ich 28.8.2010, nicht> realisiert
Oh, den hatte ich allerdings nicht mehr auf der Pfanne -> nehme ich auf
> bei Pulse Width den Pretrig auf Softbutton 6 setzen, von rawi> 12.09.2010, nicht realisiert
Den auch nicht -> kann ich einbauen
> und als "nice to have":> auch den aktuellen Triggerkanal nur aus der Anzeige ausblenden zu> können, von weitererGast 30.09.2010
Den hatte ich noch auf der Pfanne, bin aber noch am überlegen wie man
das am sinnvollsten einbaut.
> Nur, damit es nicht vergessen wird :-)
Alles klar, danke.
Gruß Hayo
> @Charly>> Sorry, da hatte ich noch nichts gemacht, da das bei mir nicht unter> Bugfix residiert sondern unter Change Request. Habe ich aber auf dem> Zettel stehen.> (Du meintest doch die Verstellung der Zeitbasis im Single Mode oder?)
ja das waehre mir am alllerwichtigsten, aber i dachte mir schon das
da noch nix ist, aber die anzeige das ein Triggerevent da war
im Single mode sollte zeitnah sein, im moment ist es so das
es angezeigt wird wenn der Schirm geschrieben wird,
so kann man den 'Fehler' reprodzieren:
utility, Default Setup
TB auf 200ms, trigger so einstellen das er vom testsignal
triggert, jetzt auf Single, dann kurz mit dem TK das
Testsignal antippen und beobachten, erst nach ueber 2 Sekunden
wechselt run/stop auf Rot und die "LED4" Flackert,
meiner meinung nach sollte run/stop direkt beim Triggern auf
Rot und wenn alles aufgezeichnet ist Single von rot auf gruen
Da ich viel im Single Mode arbeite hab i im moment keinen
anhaltspunkt zu sehen ob schon getriggert wurde oder ob das
Oszi noch wartet.
So, i hoffe i habe mich nicht zu kompliziert ausgedrueckt
vlG
Charly
Ok, danke Charly,
ich sehe mir das noch mal genau an.
Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer
und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es
aussehen könnte.
Hayo
Da die Pulsweitentriggerung hier einige Male aufkam habe ich die mal
getestet (hab ich sonst nie benutzt) und festgestellt dass die bis auf
die "Größer" Funktion überhaupt nicht funktioniert. Da ich nicht weiß
wie weit oder ob überhaupt diese Funktionen hardwareseitig implementiert
sind kann ich höchstens mal versuchen das softwaremäßig nachzurüsten ->
schade eigentlich.
Hayo
Danke für die neue Version, Hayo!
Allerdings funktioniert die Pulsweitentriggerung noch nicht wie
gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware.
Z.B. funktioniert die Triggerung am besten nach einem "Center Channel
x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben
oder unten verschoben werden. Danach erfolgt keine Triggerung mehr.
Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach
die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und
"Pulse Width" und es funzt wieder.
Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung
des Triggerwertes.
Gruß Jürgen
Hayo, hab gerade Deinen Post gelesen.
Die Pulsweitentriggerung funktioniert sehr wohl. Es funktioniert ausser
"kleiner" normalerweise alles recht gut.
Also bitte nicht in SW nachrüsten sondern gangbar machen! :-)
Ich habe oben ja versucht anzudeuten, woran es hängt.
Die im Bild gezeigte Impulsform wird überwiegend stabil angezeigt.
Gruß Jürgen
Hayo W. schrieb:> Leider sind aber die Register überhaupt nicht dokumentiert. Da heißt es> zu experimentieren.
Nun, abgucken ist hier aber erlaubt. Habe mir vorhin die originale Welec
V1.4 nochmal "angetan" und vergleiche damit die Registerbelegungen.
Unterschied z.B. V1.4 ctrl_reg: 1807 BF4.2 : 1207
Die Funktion "<" geht dort auch nicht. Zumindest fängt diese Version
sogar den ganz kleinen Impuls aus meiner Beispielimpulsfolge stabil.
Das hängt aber sicher auch mit der Signalhöhe, Triggerpunkt usw.
zusammen, da der FPGA ja etwas zum Auswerten braucht.
In der V1.4 läßt sich aber .B. die Triggerung in beiden Richtungen durch
Verstellen von Triggerhöhe und/oder Pulsweite wieder starten.
Gruß Jürgen
Hi Hayo,
> Du suchst nicht zufällig das FFT-Menü? Das erreichst Du durch einen> zweiten Druck auf den FFT-Button.
Ganz zufällig, habe ich mir da einen Wolf... :-(
...und genau, das habe ich gesucht! Nicht zu fassen, wäre ich nie drauf
gekommen. Wo ist das dokumentiert?
Die obere Leiste in Monochrome kommmt gut, gefällt mir! Die setzt sich
noch schön vom Grit ab.
Gruß Michael
Jürgen schrieb:> Allerdings funktioniert die Pulsweitentriggerung noch nicht wie> gewünscht. Irgendwelche Ausgaben fehlen noch an die Hardware.> Z.B. funktioniert die Triggerung am besten nach einem "Center Channel> x". Danach kann die Nulllinie des Kanales nur ca. +- 100 mV nach oben> oder unten verschoben werden. Danach erfolgt keine Triggerung mehr.> Am Besten geht es, wenn man die Triggermarke auf 0,0V stellt und danach> die Nullinie hoch oder herunter kurbelt. Danach drückt man "Edge" und> "Pulse Width" und es funzt wieder.> Ich denke es fehlt da noch die Nachführung des DAC bzw. die Nachführung> des Triggerwertes.
So, ich hoffe ich hab das Problem gefunden :-) Hab mal die Variablen bei
Edge und Pulse Width verglichen, wenn man nur den Kanal hoch und
hinunter schiebt.
Ich denke es fehlt das Update des trg_val_CHI_reg. Dieser Triggerwert
bestimmt die Stelle im Signal, wo die Pulsweite verglichen wird?!
Hajo, ich denke Du weisst eher wo da was zu ergänzen ist ?
Gruß Jürgen
Das ist dokumentiert in Special Functions.txt - wie meistens. War aber
etwas ungünstig vom Handling gebe ich zu. Ab jetzt verzweight er direkt
ins Menü wenn FFT aufgerufen wird. Der zusätzliche Druck führt aber
immer noch ins Menü.
@Jürgen
Die Doku kannte ich noch nicht, da werde ich mal sehen ob ich da was
machen kann, danke.
Gruß Hayo
Hayo W. schrieb:> Anbei übrigens mal ein Monochromer Status mit Gridlayer als Textlayer> und das Ganze mit meiner Lieblingspalette. Nur so als Demo wie es> aussehen könnte.
Die Darstellung der Statuszeile mit dunklem Hintergrund scheint mir auch
sehr gelungen. Allerdings halte ich es für nicht so praktisch, den Text
in den Gridlayer zu packen, da das Grid doch oft dezent in den
Hintergrund gedreht wird, man aber die Angaben zum Meßbereich eigentlich
doch immer in voller Schönheit sehen möchte.
Gruß
Rainer
Michael D. schrieb im Beitrag #2329221:
> Man kann ebenfalls ein beliebiges "NULL-MODEM" Kabel verwenden, sollte> nur nicht zu lang sein, könnte Übertragungsfehler geben!
Das mit dem "Null-Modem" Kabel halte ich für ein Gerücht. Für die
Verbindung vom PC zum DSO ist das IMHO ein ganz normales serielles 1:1
Kabel bzw. USB-Seriell Adapter mit Stecker DE-9 male auf DSO-Seite ohne
irgendwelche Adernvertauschungen.
... und das funktioniert bestens. ;-)
Gruß
Rainer
Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse
während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.
Gruß Hayo
Hallo Hayo,
hier die geänderte Funktion SetupTrigger() zur Übernahme. Feinschliff
(ext. Trigger usw.)und weitere Tests (Ch.2-4) dann später. War doch
einfacher als gedacht :-)
Jetzt kann man den Ch1 mit Pulse Width- Trigger über den Schirm jagen
und die Triggerung bleibt erhalten.
GN Jürgen
> Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse> während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.
Ihr habt natürlich Recht! Das war Blödsinn. Ich habe beim Mod die
Löschung beantragt.
Hallo Hayo,
drückt man im Utility Menü auf Default Settings, werden in der Kopfzeile
die Kanalnummern in einem runden Hintergrund gezeichnet. Hier ist das
Menüupdate wahrscheinlich noch nicht durchgelaufen... ;-)
Nach längerer Abwesenheit tut sich wieder ziemlich viel hier. Das Scope
entwickelt sich wirklich klasse weiter. War schon kurz davor, es zum
Höker zu geben...
<All>
Gibt es eigentlich schon ein Handbuch für das Scope? Sicher, hier
tüfteln viele Cracks aber nach den Meldungen sind doch auch Einige dabei
(wie ich), die nur so hobbymäßig rumlöten. Und da fehlt's so manches Mal
an Infos, was das Teil alles kann und wie man's effektiv einsetzt...
Michel
Hayo W. schrieb:> Nullmodem würde mich jetzt auch wundern, das hat doch Buchse - Buchse> während man fürs WELEC ein normales 1:1 Stecker - Buchse Kabel benötigt.>> Gruß Hayo
Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem
zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar
nichts in Sachen Kommunikation PC <-> Scope.
Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit
dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit
dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das
Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort
aus zu initiieren?
(Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das
Henne - Ei Problem, oder?)
Michel
also wie tuts das Serielle Kabel mit welchen ich die Firmware aufspiele
oder nicht. Habs noch nicht durchgemessen ob Nullmodem oder normal.
Zum Terminal habe ich es zeitlich noch nicht geschafft, werde das am WE
mal nachholen aber die obere Statusleiste sieht schon um einiges besser
aus.
Ich wollte mein Scopy auch schon dahin tuhen wo es herkam. Aber da hat
sich die letzte Zeit wirklich was getan, man kann garnicht so oft
"Danke" sagen wie man will.
Ja es tut sich wirklich wieder was. Ich möchte auch nochmal (hab ich ja
schon öfters) darauf hinweisen, dass zeitweilige Pausen hier nicht zu
bedeuten haben dass das Projekt nicht mehr läuft.
Bei mir ist es z.B. so dass ich abhängig von meinen beruflichen
Projekten manchmal keine Zeit habe , besonders wenn es Auslandsprojekte
sind. Da kann es dann einfach mal mehrere Wochen Funkstille geben. Das
Ganze hier ist aber ein langfristiges Projekt und geht auf jeden Fall
weiter. Sobald ich wieder Luft habe bin ich dann auf jeden Fall wieder
dran.
Also gebt Eure Büchse nicht gleich weg wenn es hier mal ruhig ist.
@Jürgen
Klasse, werd ich mir mal ansehen und einbauen. Vielleicht können wir den
PW-Trigger ja doch noch wieder brauchbar machen.
Ich habe mir auch schon überlegt nur die Funktionen per Software
nachzurüsten die per Hardwareansteuerung nicht realisierbar sind, so
dass wir aber die volle Funktionalität haben.
Gruß Hayo
Michael W. schrieb:> Ich habe ein USB-Seriell Interface im Einsatz, welches ich nur mit einem> zusätzlichen Kabel zum Laufen bekommen habe - ohne dies Kabel ging gar> nichts in Sachen Kommunikation PC <-> Scope.
Das ist aber sehr speziell und anscheinend ein Einzelfall. Du kannst ja
mal genau dokumentieren was da bei Dir im Einsatz ist (Kabel, Interface)
damit andere da nicht dran verzweifeln wenn sie die gleichen Prbleme
haben.
> Bin schon ein wenig lange raus aus dem Projekt: Wie war das nochmal mit> dem USB - Anschluss? wozu war der da? Ist über den die Kommunikation mit> dem Scope möglich? Besteht vielleicht die Möglichkeit darüber das> Flashfile von der Firmware aus einzulesen und den Flashvorgang von dort> aus zu initiieren?
Der USB-Anschluß ist momentan für (fast) nichts zu gebrauchen. Ich habe
noch ein neues USB-Interface in Planung (bzw. auch schon teilweise
implementiert). Es gab auch mal jemanden der sich das übernehmen wollte,
da habe ich aber nichts mehr von gehört.
Zur Zeit kann man die mitgelieferte WELEC PC-Software in begrenztem
Umfang
benutzen, aber leider ist auch die etwas buggy und es gehen nicht alle
Funktionen.
> (Nicht hauen, wenn die Frage zu blöd ist. Wahrscheinlich ist das das> Henne - Ei Problem, oder?)
Die Frage ist durchaus berechtigt. Aber zur Zeit ist die RS232 einfach
die Schnittstelle der Wahl beim WELEC.
Gruß Hayo
Hayo W. schrieb:> Ich habe mir auch schon überlegt nur die Funktionen per Software> nachzurüsten die per Hardwareansteuerung nicht realisierbar sind, so> dass wir aber die volle Funktionalität haben.>> Gruß Hayo
Hajo, die Idee ist schon gut. Größer">" und Range"><" funktioniert ja
nun ganz gut. Ich hab bloß Bedenken, wie Du per SW das Timing bei "<"
einhalten willst? Im Prinzip kann man ja bei PulseWidth kleiner als
("<") durch Range ("><")ersetzen, weil lt. Welec Spezi im Handbuch der
Zeitbereich auch bei "<" nur von 16ns bis 100ms gehen darf. Ich hab
heute noch etwas experimentiert. Tatsächlich scheint die untere Grenze
auch bei Range eher bei 72ns zu beginnen. Man könnte also bei der
Einstellung von "<" einfach im Hintergrund "><" parametrieren... Oder
man läßt das "<" einfach weg ("temporär"grau machen):-)
Auf der anderen Seite ist meine Zusammenfassung der Kommentare
"registers_nios.pdf" aus den Sourcen noch mit sehr vielen Fragezeichen
versehen. Vielleicht muß nur ein Bit richtig gesetzt werden und alles
funktioniert?
Habe vorhin übrigens mit dem Mode(Auto/Normal/Combi)noch etwas gespielt.
Was spricht eigentlich dagegen dies generell in SetupTriggers()
freizugeben und nicht nur für Edge?
Beste Grüße
Jürgen
Danke für den Tip,
übrigens, die neue Version wird Euch gefallen. Da habe ich die
Menüstruktur wieder umgebaut und es gibt eine Menge Spielereien. Muß
allerdings noch Feinschliff machen und dann die Bugs noch fixen.
Gruß Hayo
Hayo W. schrieb:> Hi bin gerade erst von meiner Viperausfahrt zurück.>> @Jürgen - woran lags mit der Frequenz? Bevor ich jetzt lange suche...>> Gruß Hayo
Hi, bin gerade erst von der Party zurück.
In der floatstr_t.cpp hast Du ab k(Hz) versehendlich in Rendertext das
Komma anstatt den Punkt in einer Floatzahl verwendet ( und der Compiler
hat es dann falsch verstanden ).
GN Jürgen
Moin Hayo,
beim Trigger gibt es - zumindest in der BF4.1 - noch ein
"Anfangswertproblem" bei der Benutzung der Holdoff Funktion.
Wenn man den Holdoff verändert, wird der neue Wert bei der ersten darauf
folgenden Messung ignoriert. Erst bei den nächsten Messungen verschiebt
sich der Triggerpunkt für die Signalaufzeichnung entsprechen.
Dabei bin ich auf die Frage gestoßen, ob zusätzlich zu dem Zeit Holdoff
nicht auch ein Event Holdoff ganz praktisch wäre?
Solange man in Pulsfolgen mit halbwegs festen Pulspositionen einen
bestimmten Puls genauer ausmessen möchte, geht das mit dem Zeit-Holdoff
ganz gut (falls das 134 ms-Limit nicht stört). Das scheitert aber,
sobald die Pulse sich zeitlich zu deutlich verschieben. Man müßte also
statt einer Totzeit die triggerwürdigen Ereignisse zählen, die ersten
(n-1) ignorieren und erst auf den n-te Puls wirklich triggern.
__|-|__________________|-\_________|\_________________
T ^
1 2 3
Hauptsächlich interessant wäre das für den Single Shot. Auf einem Regler
müßte man dann das n einstellen können. Wie siehst du die Möglichkeit
soetwas zu implementieren? IMHO müßte die Totzeit des Zeit Holdoffs
durch einen Zähler ersetzt werden, der dann für die Triggerfreigabe
sorgt, oder sehe ich das zu einfach bzw. ist das im FPGA verkapselt?
Gruß Rainer
Rainer W. schrieb:> Moin Hayo,>> beim Trigger gibt es - zumindest in der BF4.1 - noch ein> "Anfangswertproblem" bei der Benutzung der Holdoff Funktion.> Wenn man den Holdoff verändert, wird der neue Wert bei der ersten darauf> folgenden Messung ignoriert. Erst bei den nächsten Messungen verschiebt> sich der Triggerpunkt für die Signalaufzeichnung entsprechen.
Da werde ich vermutlich nichts machen können wegen s.u. (ich prüfe das)
> Dabei bin ich auf die Frage gestoßen, ob zusätzlich zu dem Zeit Holdoff> nicht auch ein Event Holdoff ganz praktisch wäre?
Unbedingt eine gute Idee.
> oder .... ist das im FPGA verkapselt?
Leider ja. Da wäre wieder nur der Versuch möglich das in Software
nachzubilden - schwierig!
Gruß Hayo
Schon mal ein kleiner Vorgeschmack was man in der neuen 4.3 so alles
einstellen kann.
Die Farbe ist allerdings in Echt mehr Hellrot als Orange. Da hat das
screenshotprogramm wohl noch nicht so ganz den richtigen Farbton
erwischt.
Hayo
moin moin Hayo
noch eine bitte: druckst du den trigger Mode/Coupling button ist
unten im softmenu die 3, stelle frei, kann da SOURCE hin zum
wechseln des trigger Kanal ?, tnx!
ps. und halte uns nicht soooo lange 'angefuettert' ;)
vlG
Charly
Hallo Charly,
hier kommt schon die 4.3, wollte nur sichergehen dass bei all den
Neuerungen nicht noch ein Bug mit reingerutscht ist, wie es immer gern
mal passiert.
Leider konnte ich Deinem Wunsch mit dem 3. Button nicht entspechen, da
dieser Platz jetzt anders belegt ist. Dafür kriegst Du jetzt aber Deine
änderbare Timebase im Single Shot Modus.
Denkt dran das Ihr neu kalibriert, da ich alle Einstellungen
zurücksetzen mußte.
Die Puls Width Triggerung von Jürgen konnte ich nicht mehr testen, aber
das sah eigentlich so gut aus, dass ich das einfach so übernommen habe.
Es gibt ein neues Display Setup-Menü in dem man nett rumspielen kann.
Die Änderungen am Menü findet Ihr wie immer gelb markiert im Programmers
Guide auf dem Menü-Tab.
Viel Spaß Hayo
Ach ja einen hatte ich noch vergessen, ich glaube das war Rainer, der
gerne die Kanalanzeige unterdrücken wollte z.B. wenn der Kanal als
Triggersource genutzt wird.
-> Kannst Du jetzt! Guckst Du im Display-Menü.
Gruß Hayo
moin moin Hayo,
das iss ja super, da weiss i was i die Nacht teste ;)
vieeelen Dank!
laut meinem 1. Test haste an der Triggeranzeige im
Single Mode noch nix gmacht, richtig ?
noch eine Frage, wozu ist im Mode/Coupling menu der
Button PROBE ?
vlG
Charly
Hm bei mir gibt es einige Menüprobleme mit der neuen Version (default
setup habe ich gemacht). Es werden an einigen Stellen nur die roten
Pfeile für den Drehknopf unten im Menü angezeigt, aber kein Text. Immer
wieder bleiben auch Artefakte in der unteren Menüleiste stehen.
Eben habe ich auch etwas nach der FFT gesucht - gibt es einen logischen
Grund, warum sie nicht im Math Menü steckt?
Alles was ich von mir gebe soll konstruktive Kritik sein, also bitte
nicht in den falschen Hals kriegen. In letzter Zeit hat es wieder tolle
Fortschritte gegeben - weiter so!
Gruß,
Michael
Michael H. schrieb:> Eben habe ich auch etwas nach der FFT gesucht - gibt es einen logischen> Grund, warum sie nicht im Math Menü steckt?
Guck mal ins Main/Delay Menü.
Gruß
Rainer
Hi,
das mit den roten Pfeilen hatte ich vorhin schon bemerkt. Da werden die
alten Bereiche nicht gelöscht.
Ich gebe noch eine Korrekturkompilation raus.
Hayo
Die FFT habe ich aus mehreren Gründen verlegt:
- es gab immer etwas Probleme mit den unterrschiedlichen Betriebsmodi.
Die FFT und die normalen Math-Funktionen arbeiten völlig
unterschiedlich.
- jetzt konnte ich die zugehörigen Steuerparameter sauber voneinander
trennen.
- dadurch konnte ich im Math-Menü eine Menüebene einspaaren.
- ich finde die Bedienung viel intuitiver wenn alle Betriebsmodi in
einem Menü nebeneinander zu finden sind
Und hier ist die korrigierte Kompilation
Gruß Hayo
Hallo Hayo,
erstmal vielen Dank an dich und die anderen Entwickler.
Habe vorige Woche mein W2022A für nur 125€ bei eBay erstanden und dank
eurer Firmware bin ich echt zufrieden damit.
Mir ist noch eine Kleinigkeit aufgefallen:
Drücke ich auf Utility und gehe auf "More" wird ja der Drehregler weiß
beleuchtet, da aktiviert. Gehe ich jetzt in das "Hardware"-Untermenü und
wieder zurück bleibt die LED hingegen aus.
Firmware 1.2.BF.4.3
Viele Grüße,
Cazwo
Stimmt, da hakt es noch etwas. Auch wenn man erst More drückt und wieder
zurückspringt, dann bleibt die LED an.
Wird natürlich korrigiert.
Viel Spaß mit Deinem Schnäppchen
Gruß Hayo
Die möglichen Optikoptionen gefallen mir richtig gut. Klasse.
Was mir aber aufgefallen ist. Wenn ich ins Aquiere Menü gehe und dort
der Drehschalter weiß leuchtet um Average bzw. die Noise Filter zu
ändern ist die Bedienung meiner Meinung nach invertiert. Wie seht ihr
das? Ich bin es gewöhnt mit einem Rechtsdreh in Menüs nach unten zu
gehen und mit links nach oben, dort ist es aber anderst rum. Beim ersten
mal drehe ich immer in die Flasche richtig bis ichs bemerke.
Hallo zusammen,
mir ist gerade aufgefallen, dass in FFT-Modus beim Umschalten der Quelle
Zeichenfragmente in der Kopfzeile verbleiben. Scheinbar sind die
Spannungsanzeigen "länger" als sie gelöscht (übermalt??) werden.
Ist aber nur eine optische Kleinigkeit.
Ausserden erscheint beim Umschalten von der FFT-Menüzeile nach "oben"
der Text "USTB" fürs Untermenü.
Viele Grüße,
Rainer
Danke. ;)
Mir ist gerade aufgefallen, dass das Problem mit dem roten Pfeil mit der
korrigierten Kompilation noch nicht ganz behoben ist.
Nach einem Neustart des Oszi kann ich mit der korrigierten Fassung zwar
im Utility Menü zwischen den Untermenüs hin und her springen, ohne das
es Probleme gibt. Das hat mit der unkorrigierten so nicht geklappt.
Wenn ich dann aber etwas in den Menüs Display, Aquire und Quick Measure
ändere und dazwischen hin und her springe gibt es immer mal wieder
Probleme (Pfeil, wo aktuell keine Schaltfläche ist (Aquire-Menü); sich
überlappende Pfeile (Quick Measure)).
Gruß Cazwo
Alles klar, danke für die Hinweise,
ich werde mal heute eine korrigierte dritte Kompilation reinstellen.
@Cazwo
Du kannst nicht zufällig einen Screenshot beisteuern?
Gruß Hayo
Thomas O. schrieb:> Die möglichen Optikoptionen gefallen mir richtig gut. Klasse.>> Was mir aber aufgefallen ist. Wenn ich ins Aquiere Menü gehe und dort> der Drehschalter weiß leuchtet um Average bzw. die Noise Filter zu> ändern ist die Bedienung meiner Meinung nach invertiert.
Ja die Richtung habe ich (glaube ich) bei den anderen Menüs auch. Ist
die normalerweise andersrum? Dann kann ich die auch ändern, das wäre
kein Problem.
Gruß Hayo
Hallo zusammen,
noch was Kleines:
Bei der Displayeinstellung erscheint beim 2-Kanal-Scope unter "No
Display":
Off, Channel 1, C 2, C 3+4 (Channel 1+2 ist ausgegraut). Ist das so
gemeint?
Viele Grüße,
Rainer
Hier die Screenshots...
Bei screen-0000.png befindet man sich im Quick Measure Menü (passiert
auch direkt nach dem Start / Default Setup). Man sieht den überlagerten
Pfeil bei "Select: Average".
Das zweite Bild ist vom Aquire-Menü. Hier tritt der Fehler nicht direkt
nach dem Start auf, ruft man aber vorher das Utility-Untermenü ("More")
auf und geht dann auf Aquire bleibt der Pfeil erhalten.
Den Bug den Rainer hat, habe ich auch (W2022A) - es gibt Channel 1,
Channel 2 und Channel 3+4 zur Auswahl... Siehe screen-0002.png.
CaZwo schrieb:> Den Bug den Rainer hat, habe ich auch (W2022A) - es gibt Channel 1,> Channel 2 und Channel 3+4 zur Auswahl... Siehe screen-0002.png.
Ja den Fehler hatte ich auch schon bemerkt - ist schon behoben.
Danke für die Screenshots, da finde ich die Fehler schneller.
Gruß Hayo
Rainer H. schrieb:> Ausserden erscheint beim Umschalten von der FFT-Menüzeile nach "oben"> der Text "USTB" fürs Untermenü.
Das ist kein Fehler, sondern da ist momentan tatsächlich das USTB-Menü
drunter, auch wenn FFT aktiv ist. Ich plane da aber eine dynamische
Belegung.
Gruß Hayo
ich habe das jetzt in anderen Menüs nicht getestet, vielleicht wäre eine
globale Variable eine Lösung um es in allen Menüs gleichzeitig zu
ändern, wird bestimmt viel Aufwand machen aber dann stünde auch eine
benutzerdefinierten Richtung nichts im weg.
Was sagen die anderen zu der Richtung ist das bei anderen Herstellern
auch so oder wie findet ihr es ergonomischer?
Hallo nochmal,
zum USTB bei Main/Delayed: Da hatte mich irritiert, dass USTB als
Untermenü (durch den Pfeil) angezeigt wird. Faktisch ist auch FFT ein
Sprung in ein Untermenü, oder?
Wenn ich aus dem FFT-Untermenü kommend den Softkey für Main oder Delayed
drücke, bleibt die rechte Bildhälfte mit den FFT-Daten überlagert, der
Rest wird darunter (scheinbar korrekt) angezeigt.
Viele Grüße,
Rainer
CaZwo schrieb:> Hier die Screenshots...>> Bei screen-0000.png befindet man sich im Quick Measure Menü (passiert> auch direkt nach dem Start / Default Setup). Man sieht den überlagerten> Pfeil bei "Select: Average".
Das ist kein Fehler, sondern hierr wird ein anderes (größeres) Symbol
verwendet.
> Das zweite Bild ist vom Aquire-Menü. Hier tritt der Fehler nicht direkt> nach dem Start auf, ruft man aber vorher das Utility-Untermenü ("More")> auf und geht dann auf Aquire bleibt der Pfeil erhalten.
Hast Du schon die C2 drauf? Bei mir tritt der Fehler nicht mehr auf. Hat
jemand von den Anderen noch das Problem?
Gruß Hayo
Hajo, bitte auch die Triggerpegelanzeige in der oberen Statuszeile um
ein paar Pixel nach rechts rücken. Beim External HF Reject löscht diese
Ausgabe sonst den rechten senkrechten Strich des Buchstaben "H". Ich
hoffe nur eine Kleinigkeit... :-)
VG Jürgen
mir ist gerade aufgefallen wenn man einen Singelshot durchführt das man
nicht rauszoomen kann um also ein längeres Signal sichtbar zu machen, so
muss man mehrere Zeitbasen durchprobieren bis man es richtig auf den
Schirm bekommt, da der Speicher aber für einen Singelshot ausreichend
groß ist könnte man ja gleich sehr schnell auszeichnen und danach
passend rauszoomen.
Ein kleiner optischer Schönheitsfehler ist mir aufgefallen wenn ich Oszi
einschalte taucht Info Screen ist unten rechts einen kleine Vertikale
Linie etwa 10 Pixel hoch 1 Pixel breit auf.
Thomas O. schrieb:> mir ist gerade aufgefallen wenn man einen Singelshot durchführt das man> nicht rauszoomen kann um also ein längeres Signal sichtbar zu machen, so> muss man mehrere Zeitbasen durchprobieren bis man es richtig auf den> Schirm bekommt, da der Speicher aber für einen Singelshot ausreichend> groß ist könnte man ja gleich sehr schnell auszeichnen und danach> passend rauszoomen.
Rauszoomen hakt aus irgendwelchen Gründen noch, daher habe ich die
Funktion noch nicht freigeschaltet - ist aber in Arbeit. Ich hoffe in
einem der nächsten 4er Releases.
> Ein kleiner optischer Schönheitsfehler ist mir aufgefallen wenn ich Oszi> einschalte taucht Info Screen ist unten rechts einen kleine Vertikale> Linie etwa 10 Pixel hoch 1 Pixel breit auf.
Ja hat mich auch schon ewig genervt, aber hatte noch keine Zeit mich
drum zu kümmern. Jetzt kille ich das Ding aber...
Hayo
Hayo W. schrieb:>> Hast Du schon die C2 drauf? Bei mir tritt der Fehler nicht mehr auf. Hat> jemand von den Anderen noch das Problem?>> Gruß Hayo
Hallo Hayo,
ich hatte erst die Variante von Sourceforge drauf (noch bevor du gestern
Abend die korrigierte gepostet hast), dann die von deinem Beitrag
gestern um 22:54 installiert.
Was mir auffällt, beide TomCat.flash-Dateien haben die gleiche MD5sum
(20578432d849ba19e2d0b51198f24ccd) und beide wurden "Gestern, 4.
September 2011, 19:04:02" geändert (laut Windows).
Kann's sein, dass du da irgendwie nochmal die alte Variante hochgeladen
hast?
Gruß Cazwo
Gerade geflasht - sieht gut aus... Der Bug mit den Pfeilen, wo sie nicht
hingehören ist weg und die weiße Beleuchtung des Drehreglers
funktioniert auch so wie sie soll.
Super Arbeit, danke!
Habe auch gerade die C3 ausprobiert und die Richtung getestet dabei ist,
mir ist noch ein kleiner "Käfer" aufgefallen.
1. Aquire Menü aufrufen
2. Nun ist entweder das Symbol für Noise Filter oder Average rot.
Angenommen Noise Filter ist rot.
3. Ich drücke auf Average das Symbol wird aber nicht rot auch wenn ich
nun drehe nicht, erst wenn das Menü wieder verschwunden ist wird das
Symbol rot.
@Hayo
Erstmal ein großes Dankeschön für die bisher geleistete Arbeit und die
Zeit die Du in das Projekt so reinsteckst.
Ich habe eine Frage zu der 1.2.BF.4.3C3:
Display->NoDisplay:
Welche Idee steckt hinter dem NoDisplay -> Ch1+2 (beim W2022)?
Macht m.E. keinen Sinn, daher die Frage.
Ch3-Ch4 sind gegraut, sollte das nicht auch für NoDisplay -> CH1+CH2
beim W2022 so sein?
Dann dazu noch evtl. ein Käferchen:
Wenn man das Gerät in dieser Einstellung ( NoDisplay -> Ch1+2 ) aus- und
dann wieder einschaltet werden beide CH's nicht dargestellt, das hat er
sich sauber gemerkt. NoDisplay steht aber auf Off. Es bedarf eines
erneuten Tastendrucks auf NoDisplay.
Robert schrieb:> @Hayo> Ich habe eine Frage zu der 1.2.BF.4.3C3: Display->NoDisplay:> Welche Idee steckt hinter dem NoDisplay -> Ch1+2 (beim W2022)?> Macht m.E. keinen Sinn, daher die Frage.> Ch3-Ch4 sind gegraut, sollte das nicht auch für NoDisplay -> CH1+CH2> beim W2022 so sein?
Nein, die Idee ist, dass man dann den Math-Channel ohne die
Source-Kanäle darstellen kann.
> Dann dazu noch evtl. ein Käferchen:> Wenn man das Gerät in dieser Einstellung ( NoDisplay -> Ch1+2 ) aus- und> dann wieder einschaltet werden beide CH's nicht dargestellt, das hat er> sich sauber gemerkt. NoDisplay steht aber auf Off. Es bedarf eines> erneuten Tastendrucks auf NoDisplay.
Du hast recht, da vergißt er noch etwas. Werde ich mal in Ordnung
bringen
Gruß Hayo
Thomas O. schrieb:> Habe auch gerade die C3 ausprobiert und die Richtung getestet dabei ist,> mir ist noch ein kleiner "Käfer" aufgefallen.>> 1. Aquire Menü aufrufen> 2. Nun ist entweder das Symbol für Noise Filter oder Average rot.> Angenommen Noise Filter ist rot.> 3. Ich drücke auf Average das Symbol wird aber nicht rot auch wenn ich> nun drehe nicht, erst wenn das Menü wieder verschwunden ist wird das> Symbol rot.
Ja daws ist etwas schwierig, da der Drehregler-Interrupt die
Statusaktualisierung unterbindet. Mal sehen ob mir dazu was einfällt.
Gruß Hayo
Hallo Hayo,
ich hab mich heute nochmal um die externe Triggerung gekümmert.
Zunächst hab ich mal die Hardware geringfügig modifiziert, indem ich ein
C 100nF/0603 parallel zu C37 gelötet hab.
Die zwei Screenshots zweigen die Wirkung: vorher ca 425mV pp, gemessen
am Eingang des Comparators U6/Pin4.
Wie ich vor längerer Zeit schon gehofft hatte, ergibt sich damit eine
verringerte Welligkeit des externen Triggerpegels von ca 18mV.
Damit ist endlich eine stabile Triggerung bei HF Reject zu erreichen!
Leider bin ich auf einen simplen Fehler hereingefallen: Im Stromlaufplan
V1.1 ist zwar unten die Pinbelegung des MAX4707 gezeigt, im Plan ist
aber trotzdem Pin 3 + 4 verwechselt :-(
Also:
Hajo, bitte die Ansteuerung im Setuptrigger() für HFReject und LFReject
austauschen.
HF Reject ist jetzt die Einstellung unserer Wahl für Signale << 50kHz.
LF Reject reagiert dann auch erst auf Signale > 50kHz.
Ich wollte dann die Triggerpegel stufenweise messen und die Tabellen
aktualisieren...
Hab mich aber dann für eine direkte Gleichung entschieden, die nur 1x in
den Sourcen berechnet wird:
voltoff = ( Trigger_POS_CHE * 0.1943 - 11.852) * vfactor
Neuer Startwert für 0.00V ext. Triggerpegel ist jetzt 61.
Damit können die zwei Tabellen entfallen. Paßt auch bei meinem 2.Gerät.
Gruß Jürgen
Wo wir gerade bei bisher nicht dokumentierten Features sind, da hätte
ich auch noch was:
Bei den Arbeiten zur neuen Eingangsstufe habe ich die Schieberegister
mal vollständig abgeklopft, was davon ggf. noch frei ist. Ergebnis ist
die Tabelle im Anhang. Hoffentlich kann da so unaufbereitet auch jemand
außer mir was mit anfangen...
So richtig neu ist jetzt nur Bit 5 von U21. Ist an den Eingang !T/B der
ADCs angeschlossen, damit könnte man die zwischen Zweierkomplement und
vorzeichenlos umschalten, warum auch immer.
Ferner war Bit 2 von U26 glaube ich noch nicht so bekannt, scheint den
externen Trigger zwischen AC und DC umzuschalten.
Mit U24 können merkwürdige Terminierungen an den Eingangskanälen
ausgewählt werden.
Gibt es den TV-Trigger in der Software eigentlich schon, bzw.
funktioniert die Hardware dafür?
Grüße
Jörg
Uuups, kaum ist man vom Griechen zurück wird man hier schon mit
Hardcorefakten konfrontiert. Das muß ich mir morgen noch mal in aller
Ruhe zu Gemüte führen.
@Jürgen
Die Korrekturen werde ich dann mit der 4.4 raushauen.
@Jörg
Bit 2 von U26 könnte natürlich als neues Feature in die externe
Triggerung Einzug halten wenn das denn so funktioniert wie vermutet.
Den TV Trigger gibt es eigentlich schon, ist aber angesichts der
aktuellen Technik wohl eher als antiquiert zu bezeichnen und daher auch
nicht mehr in der aktuellen FW aktiv (zumal die Funktion im Original
nicht richtig arbeitete).
Gruß und gutes Nächtle
Hayo
Jörg H. schrieb:> Ferner war Bit 2 von U26 glaube ich noch nicht so bekannt, scheint den> externen Trigger zwischen AC und DC umzuschalten.
Hallo Jörg,
bin gestern auch beinahe über dieses Bit 2 gestolpert. Die Verbindung
vom Schieberegister zum Transistor hab ich nur aus den Fotos geahnt.
Gut, daß Du das gleich in Hardware bestätigen kannst. Es ist offenbar
die gleiche Hardware mit Transistor, AQY usw., wie an den Kanälen
eingebaut.
>Gibt es den TV-Trigger in der Software eigentlich schon, bzw.>funktioniert die Hardware dafür?
Hab das unlängst herausgesucht und in die SW eingepflegt, kann da aber
nicht wirklich helfen. Ist nicht mein Terrain :-)
Kannst Du das testen?
Gruß
Jürgen
Ah, Hayo, der Grieche :-)
Hayo W. schrieb:> @Jürgen>> Die Korrekturen werde ich dann mit der 4.4 raushauen.>
Wäre schön, zumal es nur 5 Zeilen sind.
>> @Jörg>> Bit 2 von U26 könnte natürlich als neues Feature in die externe> Triggerung Einzug halten wenn das denn so funktioniert wie vermutet.
Ist schon lang drin und funktioniert sogar.
GN JK
Hayo W. schrieb:> Ja daws ist etwas schwierig, da der Drehregler-Interrupt die> Statusaktualisierung unterbindet. Mal sehen ob mir dazu was einfällt.
vielleicht den Status gleich ändern nachdem die Menütaste für Noise oder
Average gedrückt wird also beim Aufklappen des Menüpunktes
@Jürgen
Hast Du da schon fertiges Coding, das ich mit copy and paste übernehmen
kann?
@Thomas
Ja sowas in der Art hab ich mir heute Nacht schon überlegt. Schaun wir
mal...
Gruß Hayo
Hayo W. schrieb:> Hast Du da schon fertiges Coding, das ich mit copy and paste übernehmen> kann?
@ Hayo
Hab nur in der hardware_t.cpp und display_t.cpp geändert.
Ich hab noch einige Kommentare eingearbeitet und bin inzwischen an einem
Problem des Updates des Triggerpegels in der Statuszeile dran: Falls bei
EDGE extern eingestellt ist, und man wechselt zu PULS, wird der Pegel
nicht mehr upgedated bzw. es wird der falsche Pegel (von extern)
angezeigt.
( könnte Zeile 2398 in dispplay_t.cpp sein?? ) Steige aber in dem
Menü-Kram noch nicht wirklich durch. :-( Scheint wohl die Altlast PULS
mit Extern zu sein....
Hier die zwei Dateien. Kannst ja mal mit dem Stand 4.3C3 vergleichen.
Muß ausserdem jetzt leider erstmal weg...
Gruß Jürgen
Hi Jürgen,
hatte noch keine Gelegenheit reinzugucken, da ich zur Zeit am
Button-Menü herumoptimiere. Als kleines Gutie habe ich z.B. die
Buttonmimik überarbeitet und wieder aktiviert.
Gruß Hayo
p.s. habe zur Zeit die originale 1.4 auf einem meiner DSOs und hab mal
einiges gecheckt. Ist schon ernüchternd wenn man liebgewonnene
Funktionen auf einmal nicht mehr hat...
Die Pulsweitentriggerung funktioniert jedenfalls in der 1.4 nicht besser
als in der BF.4.3 - eher schlechter, denn ich meine die größer/kleiner
Werte sind vertauscht in der 1.4. Sehe ich das richtig?
Hayo W. schrieb:> Die Pulsweitentriggerung funktioniert jedenfalls in der 1.4 nicht besser> als in der BF.4.3 - eher schlechter, denn ich meine die größer/kleiner> Werte sind vertauscht in der 1.4. Sehe ich das richtig?
Die 1.4 wollte ich mir eigentlich nicht noch mal antun, aber ich check
das gleich nochmal..
Hayo W. schrieb:> denn ich meine die größer/kleiner> Werte sind vertauscht in der 1.4. Sehe ich das richtig?
Nein, kann ich nicht bestätigen! In meiner 3-er Impulsfolge (s.o.) wird
bei größer auch stabil auf den längsten Impuls getriggert. Auch die
Kodierung im ctrl_reg ist so, wie jetzt in der 4.3.C3.
Gruß Jürgen
Als Nachtrag noch die Position C37 und dazu parallel den zusätzlichen
100nF-C für die externe Triggerung. Sitzt direkt neben dem seriellen
Interface.
Gruß Jürgen
Jürgen schrieb:> Hayo W. schrieb:>> denn ich meine die größer/kleiner>> Werte sind vertauscht in der 1.4. Sehe ich das richtig?>> Nein, kann ich nicht bestätigen! In meiner 3-er Impulsfolge (s.o.) wird> bei größer auch stabil auf den längsten Impuls getriggert. Auch die> Kodierung im ctrl_reg ist so, wie jetzt in der 4.3.C3.
Stimmt, ich hab's nochmal geprüft, es verhalten sich beide gleich, mit
einer Ausnahme - wenn bei der 4.3 der Combi-Trigger an ist, dann gibt es
immer wieder einen Refresh wenn der Timeout kommt. Ist manchmal ganz
praktisch.
Die 1.4 kennt sowas ja nicht...
Jetzt aber schnell die 1.4 wieder runterlöschen, da kriegt man ja
Ausschlag.
Gruß
n'Abend Hayo,
der aktuelle BF 4.3 C3 habe ich gerade in Bezug auf Save/Recall etwas
auf den Zahn gefüllt. Beim Recall werden anscheinend manche
Einstellungen nicht richtig aktualisiert, z.B.
1. Wenn beim Save die Gridlines auf "solid" standen, man dann "dotted"
einstellt und anschließend über Recall die gespeichten Einstellungen
wieder abruft, wird das Grid richtig mit durchgezogenen Linien
dargestellt, aber wenn man unter Display * Setup nachguckt, steht dort
"Dotted" (Recall_GridLine.png)
2. Nicht aktive Kanäle werden beim Recall nicht abgeschaltet. Wenn
beim Abspeichern z.B. nur Kanal 1 aktiv war, vorm Recall aber mehrer
aktiv waren und man dann den Speicher abruft, bleiben die Traces der
inaktiven Kanäle in der Anzeige, sind aber in der Statuszeile richtig
ausgeblendet (Recall_Chan1.png). Auch wenn vorm Recall z.B. Math aktiv
war, bleibt die Kurve stehen, hat dann aber nichts mit den abgerufenen
Daten zu tun.
Und dann stellt sich das QuickMeas Menü neuerdings (?) etwas zickig an.
Außer, dass der rote Pfeil auf dem zweiten Softkey etwas ungewohnt
aussieht (ScreenShot_vor.png, Absicht?), verschwindet nach einem
Screenshot (mit Double Push ausgelöst), fast die komplette
Tastenbeschriftung des QuickMeas Menüs (ScreenShot_nach.png). Bisher
dachte ich immer, das der Screenshot verlustfrei funktioniert ;-)
Hat der zweite Pfeil auf dem QuickMeas Select Button irgendwas mit dem
machnmal vorhandenen "verlorenen" roten Strich im Math Menü (Tastenplatz
2) zu tun. Beides wirkt etwas deplaziert.
Ich will dich damit aber nicht von den wirklich wichtigen Dingen
abhalten ;-)
Danke für deinen unermüdlichen Einsatz
Gruß
Rainer
Hallo Rainer,
keine Sorge Du hälst mich nicht von wichtigen Dingen ab. Ich bin ja auf
Eure Fehlerreports angewiesen um die Firmware nachhaltig zu verbessern.
Das ist insbesondere dann wichtig wenn ich größere Umbauten vorgenommen
habe. Die ganzen Quereffekte kann ich selbst gar nicht alle testen.
Allerdings weiß ich überhaupt nicht warum jetzt der arme QM-Pfeil so ins
Fadenkreuz geraten ist. Der gehört nämlich zu den wenigen Dingen die ich
nicht geändert habe und die auch in der originalen WELEC-Firmware
genauso aussehen.
Die anderen Punkte versuche ich mal in die 4.4 mit einzuarbeiten.
Gruß Hayo
Hayo W. schrieb:> Allerdings weiß ich überhaupt nicht warum jetzt der arme QM-Pfeil so ins> Fadenkreuz geraten ist. Der gehört nämlich zu den wenigen Dingen die ich> nicht geändert habe und die auch in der originalen WELEC-Firmware> genauso aussehen.
Da hast du irgendwie Recht - der merkwürdige Strich im Math Menü war's.
Die andere Darstellung des QuickMeas Pfeils halte ich eigentlich für
überflüssig. Man kann natürlich einen Sinn darin sehen, wenn sie
symbolisieren soll, dass die Bedienung wahlweise per Taste über
Pull-Down als auch über den Universalregler möglich ist. Also bleibt's
erstal so ...
Gruß
Rainer
Rainer W. schrieb:> Man kann natürlich einen Sinn darin sehen, wenn sie> symbolisieren soll, dass die Bedienung wahlweise per Taste über> Pull-Down als auch über den Universalregler möglich ist.
So ist es. Ich hätte das Symbol auch bei den anderen Pulldowns
verwendet, um da homogen zu bleiben, aber ich hatte da weniger Platz
wegen der längeren Bezeichnung (Delay-Einstellung).
>Also bleibt's erstal so ...
Würde sagen ja
Hayo
Hi zusammen, ab und zu komme ich dazu, hier hereinzuschauen.
Ein Feature, das mir sehr abgeht (auch beim LeCroy), das mein alter 453
aber konnte: wenn man die Helligkeit genug aufdrehte, sah man auch bei
nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der
aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob
man den Tastkopf gut kontaktiert hat.
Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der
immer bei x=0 den aktuellen DAC-Wert anzeigt.
Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit
viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall
ist mir der Unterschied AUTO und COMBI nicht klar. Kann das jemand bitte
anhand eines praktischen Beispiels erläutern, wann man was nimmt, mit
Vor- und Nachteilen?
Die aktuelle Spannung kann man sich ja erstmal mit Autotrigger ansehen
und dann auf Normal oder Single schalten, wo hätte man da mit deiner
Variante Vorteile? Stelle ich mir persönlich eher unnütz vor, aber ich
lasse mich gern eines Besseren belehren.
Der Unterschied zwischen Auto und Combi ist eigentlich der, dass Combi
zuverlässig triggert, Auto dagegen nicht - rate mal was von Welec kommt
:)
Im Prinzip basiert der Combitrigger auf dem Welec Normal Trigger, der
gut arbeitet, ist aber um einen Timeout ergänzt, d.h. wenn innerhalb des
timeouts kein Trigger kommt dann wird vom Oszi selbst einer ausgelöst.
Gruß
Michael
Hayo W. schrieb:> Ok hab leider nicht viel Zeit.
Für einen Compilerlauf scheint es ja trotzdem immer noch zu reichen ;-)
Bei mir kommt es nach DefaultSetup - Save Trace - Recall Trace - <Menü>
zu ungewohnten "Hieroglyphen" in der Menüzeile (z.B. bei Display), als
ob sich irgendwer im Speicher verlaufen hat.
Bin auch auf dem Sprung...
Gruß
Rainer
Hi, bin gerade erst zurück und checke gerade die Rückmeldungen:
eProfi schrieb:> ...wenn man die Helligkeit genug aufdrehte, sah man auch bei> nicht ausgelöstem Trigger am linken Bildrand einen Punkt in Höhe der> aktuellen Eingangsspannung. Das ist sehr praktisch, um z.B. zu sehen, ob> man den Tastkopf gut kontaktiert hat.> Ich wünsche mir also einen (per Menü aktivierbaren) 2x2 Pixel-Fleck, der> immer bei x=0 den aktuellen DAC-Wert anzeigt.
Sorry, das hab ich irgendwie nicht so ganz verstanden. Die Höhe der
aktuellen Eingangsspannung in negativer oder positiver Richtung oder wie
ist das gemeint. Ich kann mir da nichts drunter vorstellen. Du hast
nicht zufällig ein Bild davon?
> Was mir immer wichtig ist: die Triggerung. Da hat sich in letzter Zeit> viel getan, ich bin aber noch nicht zum Testen gekommen. Auf jeden Fall> ist mir der Unterschied AUTO und COMBI nicht klar.
Was Michael erklärt ist schon ganz richtig, aber Auto und Combi arbeiten
im Prinzip gleich. Wenn nach einer bestimmten Zeit kein Triggerereignis
eintritt wird das Signal trotzdem ausgegeben. Der Unterschied liegt im
Timeout. Der Combitrigger hat einen wesentlich längeren Timeout so daß
auch langsamere Signal zuverlässig getriggert werden. Der Autotrigger
arbeitet leider nur bei schnellen Signalen ganz brauchbar.
@Rainer
> Bei mir kommt es nach DefaultSetup - Save Trace - Recall Trace - <Menü>> zu ungewohnten "Hieroglyphen" in der Menüzeile (z.B. bei Display), als> ob sich irgendwer im Speicher verlaufen hat.
Oh ja, da läuft noch was schief. Das liegt wohl daran, dass einige
Funktionen jetzt im Display Setup Menü untergebracht sind.
Ich versuche das mal zu fixen.
Gruß Hayo
Moin moin!
Hayo, es gibt beim externen Trigger noch einige Fehlerchen:
In Hardware_t.cpp, Zeile 1652, muß ext_trig_val_reg = Trigger_POS_CHE +
0x40 gesetzt werden. Ebenso sind einige Initialisierungen noch falsch
(0x80 statt 61+0x40=125).
In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden
(Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann
entfallen, da die zwei Felder ExtTriggerLevel und ExtTriggerDispl
entfallen können. OK, das ist mein Fehler. Ich hatte bloß zwei Dateien
geschickt :-(
Beim Test der Save/Recall Geschichte hatte ich nach dem Flashen ein
Memory 0 (Index 0). Da geht gar nichts. Fehlt da eine Initialisierung?
Gruß Jürgen
PS Die Buttonmimik macht die Kiste nur noch träger. Meine Meinung.
Jürgen schrieb:> Moin moin!>> Hayo, es gibt beim externen Trigger noch einige Fehlerchen:> ....> entfallen können. OK, das ist mein Fehler. Ich hatte bloß zwei Dateien> geschickt
Bau ich ein
> Beim Test der Save/Recall Geschichte hatte ich nach dem Flashen ein> Memory 0 (Index 0). Da geht gar nichts. Fehlt da eine Initialisierung?
Ja so ist es. Ich hab den Wert jetzt ins Flash übernommen, damit man
nach dem Neustart nicht immer neu den Speicherplatz wählen muß. Das
sollte aber nach dem ersten Verstellen erledigt sein.
Gruß Hayo
da kommt mir gerade eine Idee wäre es möglich anzuzeigen ob auf einem
Speicherplatz schon Daten abgelegt wurden, evtl. durch eine Farbe auf
dem Buttonfeld?
Jürgen schrieb:> Hayo, es gibt beim externen Trigger noch einige Fehlerchen:> In Hardware_t.cpp, Zeile 1652, muß ext_trig_val_reg = Trigger_POS_CHE +> 0x40 gesetzt werden.
ist erledigt
> Ebenso sind einige Initialisierungen noch falsch> (0x80 statt 61+0x40=125).
welche und wo?
> In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden> (Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann> entfallen,
ist erledigt
> da die zwei Felder ExtTriggerLevel und ExtTriggerDispl> entfallen können.
Habe ich erstmal gelassen, stört ja im Augenblick nicht
OK, das ist mein Fehler. Ich hatte bloß zwei Dateien
> geschickt :-(
Kein Problem
> PS Die Buttonmimik macht die Kiste nur noch träger. Meine Meinung.
Das täuscht, eigentlich ist es jetzt schneller weil nur noch der
betroffene Button aktualisiert wird und nicht mehr das ganze Menü.
Weitere Optimierungen sind in Arbeit.
Gruß Hayo
So die Korrekturen sind drin. Da ich gestern keine Zeit mehr hatte hier
noch ein kleiner Hinweis. Die Autoscale-Funktion habe ich überarbeitet.
Die Spannungsbereichsfindung arbeitet jetzt zuverlässiger, weil ich die
Schwellwertvergleiche jetzt auf Screenwerte umrechne (Skalierung).
Dadurch werden auch unterschiedliche Hardwareeinstellungen
berücksichtigt und die Schwellwerte sind viel präziser.
Gruß Hayo
Hayo W. schrieb:>> Ebenso sind einige Initialisierungen noch falsch>> (0x80 statt 61+0x40=125).> welche und wo?
Hardware_t.cpp: zeile 307 und 727
tc_vars.cpp: zeile 556
Thomas O. schrieb:
>da kommt mir gerade eine Idee wäre es möglich anzuzeigen ob auf einem>Speicherplatz schon Daten abgelegt wurden, evtl. durch eine Farbe auf>dem Buttonfeld?
Die Idee ist garnicht schlecht. Es genügt die Farbe oder ein Zeichen auf
dem Button. Natürlich braucht es dann aber einen Menüpunkt, um eine
Speicherposition wieder frei zu geben.
Thomas O. schrieb:> vielleicht eine Clear Funktion wenn man den Speicherplatz lange gedrückt> hält. Oder kurzer Druck Clear langer Druck Save
Gute Idee. Aus Sicherheitsgründen wäre ich für die Belegung:
- kurzer Druck: "Save"
- langer Druck: "Clear"
Etwas generelles zu den Speicherplätzen: Mir geht es, wahrscheinlich auf
Grund meines Alters so, dass nach 10 gespeicherten Kurven mein Gedächnis
für die Inhalte der Speicher überläuft, d.h. ich habe nie und nimmer von
80 Plätzen individuell den Inhalt im Kopf. Sinn macht die Zahl der
Plätze IMHO nur bei Serienmessungen und dafür wäre ein
Autoinkrement-Funktion für die Speicherplatznummer sowohl bei "Save" als
auch bei "Recall" sehr praktisch. Wenn man dafür nicht extra eine
Menüfunktionen schaffen möchte, vielleicht in der Form, dass ab einem
bestimmten Speicherplatz n (z.B. n=10) die Funktion automatisch aktiv
ist.
Gruß
Rainer
p.s. Die Belegungsanzeige für einen Speicher könnte man einfach über die
"Recall Trace" Taste erledigen:
- "Recall" enabled = Speicher belegt
- "Recall" disabled = Speicher frei
Hallo Hayo,
bei der Trigger Mode/Coupling Taste scheint in der 4.4 irgendetwas mit
der Kurzfunktion für die Umschaltung des Trigger Modes durcheinander
geraten zu sein. Bei sichtbarem Trigger Menü kann man ja durch Drücken
der HW-Taste den Mode (Auto/Normal/Combi) umschalten. Die
Umschaltfunktion funktioniert, aber auf dem Softkey "Mode" im Trigger
Menü wird die aktuelle Einstellung nicht richtig angezeigt.
Gruß
Rainer
Hi Rainer,
danke für den Hinweis, das liegt an der neuen Button und Menülogik.
@Thomas + Jürgen
Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der
Speicherplätze.
> Etwas generelles zu den Speicherplätzen: Mir geht es, wahrscheinlich auf> Grund meines Alters so, dass nach 10 gespeicherten Kurven mein Gedächnis> für die Inhalte der Speicher überläuft, d.h. ich habe nie und nimmer von> 80 Plätzen individuell den Inhalt im Kopf
Das geht mir auch so. Ich hatte auch schon überlegt die Anzahl der
Speicherplätze auf die Hälfte zu reduzieren zugunsten der Möglichkeit
die 32 kbyte Puffer der USTB abspeichern zu können. Alternativ würde ich
sonst den restlichen Flashspeicher so aufteilen daß nur die ersten 5
Speicherplätze 32 kbyte aufnehmen können.
Was sagt Ihr dazu?
Gruß Hayo
Hayo W. schrieb:> Ich hatte auch schon überlegt die Anzahl der> Speicherplätze auf die Hälfte zu reduzieren zugunsten der Möglichkeit> die 32 kbyte Puffer der USTB abspeichern zu können. Alternativ würde ich> sonst den restlichen Flashspeicher so aufteilen daß nur die ersten 5> Speicherplätze 32 kbyte aufnehmen können.
Finde die Idee gut, ein paar extra große Speicherplätze zu haben.
Hayo W. schrieb:> Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der> Speicherplätze.
Was hälst du von meinem Anzeigevorschlag über "Recall" enable/disable?
> Was sagt Ihr dazu [Speicheraufteilung]?
Wie wäre ist mit einer dynamischen Aufteilung mit einem Directory. Den
Speicher könnte man in festen Blöcken entsprechend der kürzesten Traces
organisieren und in einer Block Allocation Table verwaltet. An jedem
Dir-Eintrag hängen dann verkettete Listen mit belegten Speicherblöcken.
Das würde deutlich Freiheit geben, was die Länge der Aufzeichnung
betrifft, auch wenn es erstmal natürlich etwas Zirkus ist.
Gruß Rainer
Rainer W. schrieb:> Hayo W. schrieb:>> Ich denk mir da mal was aus zu der Belegungsanzeige bzw. zum Löschen der>> Speicherplätze.>> Was hälst du von meinem Anzeigevorschlag über "Recall" enable/disable?
ich wäge noch ab ob so, oder vielleicht mit einem farbigen Symbol oder
Ähnliches.
>> Was sagt Ihr dazu [Speicheraufteilung]?>> Wie wäre ist mit einer dynamischen Aufteilung mit einem Directory.
Das ist aber schon heftig viel Aufwand. Erstmal würde mich interessieren
ob tatsächlich jemand mehr als 40 Plätze braucht.
Ich selbst könnte gut damit klarkommen wenn ich dafür auf allen Plätzen
32 kbyte zur Verfügung habe. Ansonsten hätten wir wie bisher 80 Plätze
und die ersten 5 hätten 32 kbyte.
Gruß Hayo
Hayo W. schrieb:> .... das liegt an der neuen Button und Menülogik.
Jedenfalls funktioniert in der 4.4C2 die Anzeige des Triggerpegels (oder
Verstellung des externen Triggerpegels?) und die Rückschaltung ext.->CHx
nicht mehr :-(
Gruß Jürgen
PS: Es ist wohl eher die Verstellung ext. Pegel.
Hayo W. schrieb:> Das ist aber schon heftig viel Aufwand. Erstmal würde mich interessieren> ob tatsächlich jemand mehr als 40 Plätze braucht.
Das genügt mir vollkommen!
Jürgen schrieb:> Jedenfalls funktioniert in der 4.4C2 ... die Rückschaltung ext.->CHx> nicht mehr :-(
Das kann ich bei mir so allgemein nicht bestätigen, zumindest
Trig. Norm auf Ch1 - Umschaltung auf Ext - Rückschaltung auf Ch1
funktioniert problemlos.
Gruß
Rainer
Rainer W. schrieb:>> Jedenfalls funktioniert in der 4.4C2 ... die Rückschaltung ext.->CHx>> nicht mehr :-(>> Das kann ich bei mir so allgemein nicht bestätigen, zumindest> Trig. Norm auf Ch1 - Umschaltung auf Ext - Rückschaltung auf Ch1> funktioniert problemlos.
Das Menü Button3 und 4 (ext. und TV) bleibt aber schwarz. Ein erneuter
Druck auf Button 3 graut diese dann erst aus.
Hayo W. schrieb:>> In der userif_t.cpp muß die Begrenzung Trigger_POS_CHE geändert werden>> (Zeilen 8381+8395). Grenzen sind jetzt 0 und 132 und das +-1 kann>> entfallen,> ist erledigt
Hehe,nicht ganz! + 1 bzw. -1 natürlich bloß in der Bedingungsabfrage!
:-)
So:
case 5: if (Trigger_Pos_CHE > 0){ Trigger_Pos_CHE = Trigger_Pos_CHE - 1;
}else{ Trigger_Pos_CHE = 0; } break;
und
case 5: if (Trigger_Pos_CHE < 132){ Trigger_Pos_CHE = Trigger_Pos_CHE +
1; }else{ Trigger_Pos_CHE = 132; } break;
Dann klappts auch mit der Pegelverstellung.
Gruß Jürgen
ja wahnsinn, was hier los is'...
Hallo Hayo,
die Drehgeberrichtung ging mir schon lange auf den Nerv, jedes mal
drehte ich in die falsche Richtung! Hast du schick hinbekommen, bin
begeistert.
Wie sieht es mit der horizontalen Signalverschiebung aus, könnte man die
auch in die richtige Drehrichtung bringen, d.h. drehe ich nach Links,
verschiebt sich das Signal nach Rechts statt nach Links, was meinst du,
oder ihr?
Gruß Michael
Hi Hayo,
kannst du bei der Umschaltung von FFT nach Main (Menü Main/Delayed) noch
mal nach dem Rechten sehen. Da bleibt die Info-Box mit den FFT Parameter
im Moment stehen.
Schönen Abend
Gruß
Rainer
Schon mal ein kleiner Ausblick auf die 4.5
Ich habe es schon lange vor mir hergeschoben, aber jetzt habe ich es
getan. Ich habe die bisher nicht funktionierenden QM-Optionen Delay und
Phase implementiert, ebenso wie die zugehörigen Menüs zur Einstellung
von Sourcen und Flanken.
Gruß Hayo
Hayo W. schrieb:> Ich habe die bisher nicht funktionierenden QM-Optionen Delay und> Phase implementiert
Moin Hayo,
das finde ich klasse. Im Journalistendeutsch würde man das wohl als
echten Quantensprung in der Funktionalität bezeichnen. Ich hatte mich
schon über die ausgegrauten Parameter in der Liste gewundert ;-)
Wo du damit die Zeitbezüge ansprichst:
Wäre es bei den Cursorpositionen nicht sinnvoller, für die Zeiten X1 und
X2 als Nullpunkt die Triggerposition zu verwenden. Der Zeitbezug auf den
linken Bildschirmrand hat eigentlich eine relativ geringe Bedeutung.
Meßtechnisch ist doch eher der Triggerzeitpunkt ein ausgezeichneter
Zeitpunkt, der mir als Referenzzeit geeigneter erscheint. Man müßte
eigentlich nur auf die im Cursor Menü angezeigten Werte X1 und X2 den
Offset von der Position der Triggermarke draufrechnen.
Gruß und frohes Schaffen
Rainer
Michael D. schrieb:> ja wahnsinn, was hier los is'...>> Hallo Hayo,>> die Drehgeberrichtung ging mir schon lange auf den Nerv, jedes mal> drehte ich in die falsche Richtung! Hast du schick hinbekommen, bin> begeistert.> Wie sieht es mit der horizontalen Signalverschiebung aus, könnte man die> auch in die richtige Drehrichtung bringen, d.h. drehe ich nach Links,> verschiebt sich das Signal nach Rechts statt nach Links, was meinst du,> oder ihr?
Ich habe mir das nochmal angesehen, die Drehrichtung passt schon, da Du
nicht das Signal verschiebst sondern das Speicherfenster.
Dafür habe ich die Drehrichtung der Zerolevelgeber geändert.
Alle neuen Menüs findet Ihr wie immer im Programmer Guide.
Und jetzt gehts ab in die Wanne
Gruß Hayo
dann danke für die neue Version habe noch einen Bug gefunden.
Displaytaste drücken->Grid ist angewählt(rot) und per Drehregler
verstellbar->nun drücke ich auf die No Display Taste, das Menü No
Display klappt auf ein drehen am Drehregler bewirkt aber ein verändern
des Grids nicht das verstellen des aufgeklappten Menüs.
Oh sehe gerade das das nur für die Menüs mit dem Drehsymbol
funktioniert.
Hallo Hayo,
von mir auch gleich ein Report zur neuen Version:
Im FFT Menü stellt sich die "Mode" Taste etwas zickig an. Man kann zwar
den Berechnungsmode auswählen, aber die Auswahlliste springt beim
Drücken der Taste sofort weg...
Gruß
Rainer
moin moin Hayo,
tnx f. die neue Version, aber....
im Quick Meas ist der drehregler falsch herum und der
3. softbutton wird erst beim druecken aktualisiert,
die Triggeranzeige im single geht auch nicht ;(
vlG
Charly
Hallo Hayo,
bleib nicht zu lange in der Wanne sonst wird alles schrumpelig! :-)))
> Ich habe mir das nochmal angesehen, die Drehrichtung passt schon, da Du> nicht das Signal verschiebst sondern das Speicherfenster.
Achso? Na dann bleibt's eben...
Charly's Aussage über die Drehrichtung im QM-Menu stimmt aber.
Gruß Michael
Charly B. schrieb:> .. i habe den Eindruck die Regler f. Y Position sind> auch gedreht, oder ?
Sehe ich auch so. CCW = runter, CW=rauf fühlte sich besser an - so wie
beim Trigger-Level.
Gruß
Rainer
Hallo Hayo,
danke, das ist auf jeden Fall die beste Version, die wir je hatten!
Hayo W. schrieb:> Dafür habe ich die Drehrichtung der Zerolevelgeber geändert.
Hm,das war voll daneben! Das passt einfach nicht. Ich kenn kein Oszi, wo
sich das so bewegt. Du schaust auf dem Monitor nach links und drehst mit
dem linken Rand des Drehgebers nach oben! So geht das!
Noch eine Kleinigkeit zum ext. Trigger. Ich hab mal das Line-Signal an
der Kathode D2 gemessen. Es sind nur 142mV / 50Hz an U6/3. Das bedeutet
ca. +80mV am Comparator zum sicheren Auslösen des Triggers notwendig.
Die notwendige Änderung im SetupTrigger() sind + 3 Inkremente (siehe im
Textschnipsel). Das funktioniert sehr gut! Test mit ext. Trigger-> Line
und einfach den Tastkopf an der Spitze anfassen. Stehendes Bild im
Normal Modus.
VG Jürgen
Hi Leute,
hier ist ja wieder richtig was los!
> bleib nicht zu lange in der Wanne sonst wird alles schrumpelig! :-)))
Zu spät!!!
@Thomas
wie Du schon selbst bemerkt hast - das ist gewollt so -> kein Bug.
> Im FFT Menü stellt sich die "Mode" Taste etwas zickig an. Man kann zwar> den Berechnungsmode auswählen, aber die Auswahlliste springt beim> Drücken der Taste sofort weg...
Ok, muß ich mir morgen mal ansehen, danke.
> im Quick Meas ist der drehregler falsch herum und der> 3. softbutton wird erst beim druecken aktualisiert,> die Triggeranzeige im single geht auch nicht ;(
Ok, auch das werde ich morgen gleich mal unter die Lupe nehmen, danke
> CCW = runter, CW=rauf fühlte sich besser an - so wie> beim Trigger-Level.
Kein Problem, kann ich wieder rückgängig machen.
@Jürgen
Bau ich natürlich mit ein.
Ich versuche mal morgen eine korrigierte Kompilation fertig zu machen.
Danke für die schnelle Rückmeldung.
Bis morgen
Hayo
Hayo W. schrieb:> Ich versuche mal morgen eine korrigierte Kompilation fertig zu machen.
Nur keine Eile - es brennt ja nichts.
Im neuen QM Delay-Submenü sind noch zwei Dinge:
1. Als Bezugspunkt wird nicht der mit Source1 (Taste1) gewählte Kanal
verwendet, sondern der im QM (Haupt-)menü als Source (auch Taste1)
eingestellte. Für den Screenshot war im QM (Haupt-)Menü "Source 1"
gewählt, so daas mangels Ch1-Signal als Bezugszeitpunkt der
Fensteranfang genommen wurde.
2. Im QM Delay-Submenü stimmt IMHO die Beschriftung der Taste 5 nicht.
Statt "Measure Frequency" sollte da bestimmt "Measure Delay" stehen.
Bei der Anzeige des Meßwertes wäre es noch eine Verfeinerung, wenn man
dort beide Bezugskanäle unterbringen könnte, also z.B. in der Form
"Delay (2-3)= 13.6 µs".
Super Sache mit der funktionierenden Delay Messung.
Gruß
Rainer
Moin Hayo,
im Cursor Menü könnte man die Aktualisierung der Werte noch ändern.
Wenn man den Kanal mit Taste 1 "Source" ändert, wird nur der Wert
Delta-Y neu berechnet/angezeigt, aber nicht die Y-Meßwerte auf den
Tasten 4 und 5, was dann zu inkonsistenter Anzeige wie im Bild
Cursor_Ch4.png führt.
Gruß
Rainer
p.s. Die Drehrichtung beim Ch.3 Offset ist ok ;-)
Rainer W. schrieb:> Nur keine Eile - es brennt ja nichts.
...läßt mir aber keine Ruhe!
> Im neuen QM Delay-Submenü sind noch zwei Dinge:>> 1. Als Bezugspunkt wird nicht der mit Source1 (Taste1) gewählte Kanal> verwendet, sondern der im QM (Haupt-)menü als Source (auch Taste1)> eingestellte. Für den Screenshot war im QM (Haupt-)Menü "Source 1"> gewählt, so daas mangels Ch1-Signal als Bezugszeitpunkt der> Fensteranfang genommen wurde.
Stimmt, das fehlte noch, ist aber jetzt erledigt
> 2. Im QM Delay-Submenü stimmt IMHO die Beschriftung der Taste 5 nicht.> Statt "Measure Frequency" sollte da bestimmt "Measure Delay" stehen.
Stimmt auch, ich hatte das nicht mit dem Drehregler getestet. Ist auch
erledigt.
> Bei der Anzeige des Meßwertes wäre es noch eine Verfeinerung, wenn man> dort beide Bezugskanäle unterbringen könnte, also z.B. in der Form> "Delay (2-3)= 13.6 µs".
Da das kein Bugfix ist, bleibt das erstmal offen.
> Super Sache mit der funktionierenden Delay Messung.
Ja gefällt mir auch. Allerdings habe ich jetzt festgestellt, dass das
Thresholdsmenü völlig ohne Funktion ist. Dem würde ich gerne abhelfen.
@all
Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle?
Gruß Hayo
Rainer W. schrieb:> im Cursor Menü könnte man die Aktualisierung der Werte noch ändern.
Ist erledigt.
> p.s. Die Drehrichtung beim Ch.3 Offset ist ok ;-)
Bei den Anderen ist sie jetzt auch wieder ok.
Hayo
charly schrieb:> im Quick Meas ist der drehregler falsch herum
Die Drehrichtung ist genauso wie bei den anderen Pulldowns. Die Richtung
hatte ich auf Wunsch hier im Forum geändert.
> und der 3. softbutton wird erst beim druecken aktualisiert,
Ist erledigt
> die Triggeranzeige im single geht auch nicht ;(
Das habe ich nicht verstanden. Welche Anzeige geht nicht? (Screenshot?)
Gruß Hayo
Hayo W. schrieb:> Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle?
Das sollte normalerweise der Quotient aus "+Width" und "Periode" sein,
um z.B. PWM-Signale auszumessen.
Gruß
Rainer
Jürgen schrieb:> Die notwendige Änderung im SetupTrigger() sind + 3 Inkremente (siehe im> Textschnipsel). Das funktioniert sehr gut!
Ist eingebaut
Hayo
Hayo W. schrieb:> Dem würde ich gerne abhelfen.>> @all>> Hat jemand eine Ahnung wofür das sein sollte? Duty Cycle?
Ok, habe in der Anleitung zum Agilent alles gefunden. Zum Glück ist ja
alles 1:1 abgekupfert, so dass man die Anleitung großenteils für unser
DSO benutzen kann.
Hayo
Ok nächste Erkenntnis: Es hat doch Auswirkung auf die Messungen, aber
die Implementierung ist noch unvollständig und die einstellbaren Werte
sind zum Teil sinnlos -> ist in Arbeit.
Hayo
moin moin Hayo,
das war nix ;)
Y pos. ch1 ist falschrum,
Y pos. ch2 ist richtig
wenn du noch invert einschaltest und bisschen
flotter drehst macht er wie ein Kaenguruh :)
vlG
Charly
Hayo W. schrieb:> Zum Glück ist ja alles 1:1 abgekupfert, so dass man die Anleitung> großenteils für unser DSO benutzen kann.
Welchem Agilent Modell ähnelt das Welec denn am meisten?
Ich habe das Oszi seit zwei Jahren, mittlerweile ist es tatsächlich sehr
nützlich. Dank euch. Dafür ein herzliches Dankeschön!
Keine Ahnung, aber die Anleitung ist für folgende Scopes:
Agilent 54621A/22A/24A/41A/42A Oscilloscopes and
Agilent 54621D/22D/41D/42D Mixed-Signal Oscilloscopes
Wer Selbige nicht finden kann schreibe mir eine PN, dann schicke ich sie
zu. Posten kann ich sie hier aus rechtlichen Gründen leider nicht.
Gruß Hayo
charly schrieb:> moin moin Hayo,>> das war nix ;)> Y pos. ch1 ist falschrum,> Y pos. ch2 ist richtig
Mist, der ist mir irgendwie wieder durchgerutscht.
Ist schon korrigiert.
> wenn du noch invert einschaltest und bisschen> flotter drehst macht er wie ein Kaenguruh :)
Das ist der DAC der sich da einschwimgt und die etwas träge
Drehgeberverarbeitung
Gruß Hayo
> Das sollte normalerweise der Quotient aus "+Width" und "Periode" sein,> um z.B. PWM-Signale auszumessen.
...und deren Tastverhältnis. Im obigen Fall ist ein Tastverhältnis von
50%, d.h. 50% der Impulsdauer sind der eingeschalteter Zustand.
Hab' ich noch was vergessen?
...ich finde diese Messoption sehr praktisch.
Wenn Hayo so weiter macht, kann das Welec in der nächsten Zeit noch
fliegen lernen! :-)))
> Gruß> Rainer
Gruß Michael
Hi Hayo,
im Quickmeasure geht die automatische Messbereichsumschaltung immer noch
nicht.
Wenn am Drehgeber z.B. "Rise-Time" ausgewählt wird, dann müsste das
jetzt an Stelle von "Measure RMS" stehen(siehe Screenshot), tut es aber
nicht!
Man muß jetzt jedes Mal auf den "Select" Button drücken, erst dann kann
der Messbereich ausgewählt werden.
Ich dachte du hättest das gefixt? Charly hatte ja auch schon gepöpelt...
:-)
Gruß Michael
Hallo Hayo,
so fleißig wie du zur Zeit dabei bist, wird es langsam mühseliger, noch
Bugs auszugraben. Aber einen konnte ich trotzdem noch entdecken: Drück
mal im Save/Recall-Menü die "Restore Settings"-Taste....
Die Softekeys werden erst beim Drücken aufgebaut und in der Statuszeile
wird zwischen den Zeichen die Textfarbe als Hintergrundfarbe gemalt.
Beim Recall trat das neulich auch auf, hattest du dann dort aber
repariert.
Michael D. schrieb:> ...und deren Tastverhältnis
@Michael
Das meinte ich doch mit dem Quotienten ;-)
Gruß
Rainer
charly schrieb:> undganzschnellwegbevorespruegelgibt
Haha, hier wird niemand verhauen! Viele Softwareentwickler würden sich
so hartnäckige Tester wie euch viel Geld kosten lassen. ;-)
Das spornt Hayo nur weiter an und ihr müsst die Zeit nutzen, bevor er
beruflich wieder gestresst wird.
Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder
vergessen :-(. Das Alter!
Grüße, Guido
@ Guido
> Haha, hier wird niemand verhauen! Viele Softwareentwickler würden sich> so hartnäckige Tester wie euch viel Geld kosten lassen. ;-)
Das ist wahr. So frustrierend es im ersten Moment ist wenn was schief
läuft, so wertvoll sind aber unter dem Strich all die Hinwweise. Danke
dafür!
@Charly
Der Drehregler ist schon richtig rum. Genau wie die Anderen eben. Oder?
@Michael
> im Quickmeasure geht die automatische Messbereichsumschaltung immer noch> nicht.> Wenn am Drehgeber z.B. "Rise-Time" ausgewählt wird, dann müsste das> jetzt an Stelle von "Measure RMS" stehen(siehe Screenshot), tut es aber> nicht!
Verdammt, das lief doch vorhin. Sehe ich mir morgen mal an. Jetzt bin
ich vom Griechen zu angeschickert. Ich war heute auch mehr mit dem
Thresholds-Menü beschäftigt. Das sieht schon ganz anständig aus
mittlerweile.
@all
Zum Duty Cycle gibt es auch einen Wikipedia-Beitrag der ganz informativ
ist.
Gruß Hayo
im QM den Regler CCW gehts in der Liste nach oben,
sollte aber nach meinem gefuehl nach unten, oder ?
die beiden Y-Pos Regler von Ch1 & Ch2 sind
gegenlaeufig (oder ist das nur bei mir so ?)
vlG
Charly
Charly B. schrieb:> die beiden Y-Pos Regler von Ch1 & Ch2 sind> gegenlaeufig (oder ist das nur bei mir so ?)
Wenn man mal dich und Hayo betrachtet, ist das nur bei dir so ;-)
Hayo W. schrieb:> Ist schon korrigiert.
Gruß
Rainer
branadic schrieb:> Hallo Hayo,>> in wie weit wird jetzt die Huckepackplatine eigentlich schon von der> neuen Firmware unterstützt?>> branadic
Danke für's Ignorieren.
branadic
Hallo Branadic,
sorry war nicht mit Absicht, aber die beste aller Ehefrauen drängelte
gestern etwas, da habe ich dann lieber Schluss gemacht.
Die Unterstützung ist eingebaut. Was wohl noch fehlt ist die korrekte
Skalierung. Mir fehlt im Augenblick die Möglichkeit das zu prüfen bzw.
die Skalierung selbst durchzuführen.
Am Besten direkt an Jörg wenden, da er den aktuellen Stand am Besten
kennt. Ich habe ja nur seine Ansteuerung mit eingebaut.
Gruß Hayo
Also irgendwie müssten wir uns da mal einigen, wie der Drehregler zu
gestalten ist ?!?
Im Allgemeinen bedeutet Rechtsdrehung 'mehr' u. nach Links 'weniger',
wie beim Lautstärkeregler...
Bei den Pullup-down-Menus, würde demnach Links 'runter' u. Rechts' hoch
bedeuten, ist doch eigendlich ganz einfach, oder?
Bei der Spannungswahl der Kanäle, drehe ich ständig falsch herum, müsste
dann auch korrigiert werden...
@Guido
> Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder> vergessen :-(. Das Alter!
Wenn du den Hauptschalter meinst, da habe ich noch welche da!
@Rainer
> Wenn man mal dich und Hayo betrachtet, ist das nur bei dir so ;-)
der Charly ist bestimmt Australier, da läuft alles falsch herum.. :-)))
@branadic
> Danke für's Ignorieren.
Hayo meinte, das die Platine schon implementiert sei und er noch einige
Parameter bräuchte, soweit ich mich erinnern kann.
Gruß Michael
Michael D. schrieb:> Also irgendwie müssten wir uns da mal einigen, wie der Drehregler zu> gestalten ist ?!?
Versuchsweise habe ich mal als Diskussionsgrundlage ohne Anspruch auf
Vollständigkeit eine kleine Tabelle zusammengestellt:
CCW CW
TB Geschw. langsamer schneller
TB Fenster-X links rechts
Cursor X links rechts
Cursor Y runter hoch
Gain unempfindlich empfindlich
Y-Position runter hoch
Menü runter hoch
Triggerschwelle runter hoch
Bei invertierter Erfassung der Kanäle, muß man sich noch einigen, ob die
Drehreglerrichtung (Offset, Trigger, Cursor) sich auf die Meßwerte oder
auf die Bildschirmdarstellung beziehen soll. IMHO wäre BS intuitiver,
aber für beide Arten gibt es gute Gründe.
Gruß
Rainer
ich sitze jetzt leider gerade nicht am Oszi. Ein Beitrag im Wiki wäre
nicht schlechte den kann jeder bearbeiten und jeder kann einen Strich
setzen wie die einzelnen Dinge auf die Drehrichtung zu reagieren haben.
Dann kann das jeder mal in Ruhe vor dem Oszi testen.
So, habe alle Bugs soweit abgearbeitet und auch die Drehrichtung gemäß
Wiki angepasst.
Neu ist das jetzt funktionierende Threshold-Menü dass es erlaubt für
jeden Kanal eigene Schwellwerte einzustellen. Bei Default Setup wird
alles wieder auf 10/50/90 zurückgestellt.
Gruß Hayo
1.2.BF.4.6
ein Mini-Mini-Bug für die Liste:
Display->Setup->Grid Lines
Nach dem Betätigen dieses QB bleibt der Rand des Auswahlfeldes
kurzzeitig stehen. Bei QB-Grid Color und QB-Status ist die Darstellung
ok.
Gruß
Robert
1.2.BF.4.6
Kann es sein das Grid Color White und Grid Color Gray sich nicht
unterscheiden? Bin mir nicht sicher, aber ich erkenne da keinen
Unterschied.
Gruß
Robert
Hallo Hayo,
hab die 4.6 gerade geflasht, Defaults geladen und mal ein bisschen
rumgespielt.
Ein paar kleine Sachen sind mir aufgefallen:
Siehe screen-0000: Im Math-Menü war erst ein kleiner oranger Strich
zwischen auf Softkey 2 da. Wurde hier den ich schon mal erwähnt. Habe
dann nochmal auf Math gedrückt (Math deaktiviert) und dann am Drehregler
gedreht - das Ergebnis sieht man auf dem Screenshot.
Dann hab ich erst ein paar andere Sachen getestet und bin zurück ins
Math-Menü. Der Drehregler bzw. dessen weiße LED war an, aber der Pfeil
bei Softkey 1 ausgegraut. Drehen hat wieder diesen Wert auf Softkey 2,
der da nicht hingehört, geändert.
Defaults geladen - nun ist der orange Strich nicht mehr da, das Problem
mit dem Softkey 2 immer noch.
Nächste Sache ist QM. Drücke ich Setting passiert nichts.
Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die
Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und
aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann
natürlich auch ein Feature sein.
Im Aquire Menü war vorhin noch ein halber Pfeil auf Softkey 6 zu sehen
(screen-0001) - keine Ahnung wo der herkam, kann das jetzt so nicht mehr
reproduzieren.
Ansonsten wie immer: Klasse Arbeit, schön zu sehen, wie unser Oszi hier
Tag für Tag besser wird :)
Auf einen falsch rum drehenden Regler bin ich noch gestoßen:
Wenn man einen Kanal invertiert, wandert bei CCW-Drehung am Trigger
Level die Linie noch nach oben.
Gruß
Rainer
Danke für die Rückmeldungen,
leider komme ich morgen wohl nicht dazu Fixes zu machen da ich tagsüber
in der Firma bin. Werde aber trotzdem hier reingucken und mal ob sich
was tut.
Gruß Hayo
Sebastian S. schrieb:> Nächste Sache ist QM. Drücke ich Setting passiert nichts.
Hab gerade mal in die Programmers Reference geschaut - jetzt verstehe
ich, was Setting bewirken soll. Also ist das Problem nur, dass die
Settings Softkey bei anderen Einstellungen als Phase und Delay nicht
ausgeblendet wird.
In den QM Phase Settings ist mir aber auch noch eine Kleinigkeit
aufgefallen - hier ist wieder mal der orange Strich zu sehen, wo
eigentlich ncihts sein sollte (siehe Screenshot).
EDIT: Und noch etwas - im Settingsmenü von sowohl Phase als auch Delay
leuchtet die weiße LED am Drehregler, obwohl nix zu drehen ist...
EDIT2: Noch zwei kleine Unstimmigkeiten:
Die erste ist vermutlich nur ein Fehler in der Programmers Reference /
Menu Table. Bei 28 (Display FFT) soll laut Reference F5 ja "Display
Layout" sein - am Oszi ist diese Taste nicht belegt.
Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch
am Oszi vorhanden - nur ändert es nichts, außer das es die Anzeige neu
aufbaut. Ich vermute ein Überbleibsel aus Zeiten, bevor es das
Setup-Untermenü gab?
So, dass war's dann erstmal von meiner Seite. Oszi aus und ins Bett
hüpfen ;)
Sebastian S. schrieb:> Sebastian S. schrieb:>> Nächste Sache ist QM. Drücke ich Setting passiert nichts.
Um das etwas einzugrenzen: Der Fehler scheint nur direkt nach einem DSO
Neustart (Einschalten/Reset) aufzutreten. Wenn man dann in das QM Menü
geht, ist die Taste 5 (Setting) nicht richtig ausgeblendet
(Select_Reset.png), so wie es sonst der Fall ist (Select.png).
Gruß
Rainer
Robert schrieb:> Kann es sein das Grid Color White und Grid Color Gray sich nicht> unterscheiden? Bin mir nicht sicher, aber ich erkenne da keinen> Unterschied.
Hi Robert,
wegen der stark beschränkten Farbpalette gibt es zwischen den beiden
Einstellungen einen echten Unterschied nur bei Helligkeit 66%.
Gruß
Rainer
Hallo @ all,
habe hier mal einiges gelesen und gehofft mein altes W2022 (ohne A) in
einen brauchbaren Zustand versetzen zu können. Leider ist mir das zuviel
Aufwand für zu wenig Nutzen. Vielleicht findet sich aber hier ein
Interessent, der mir das Gerät abkaufen möchte.
Habe irgendwann mal die Firmware upgedated, aber nicht bedacht, daß die
für mein altes Gerät nicht paßt. Nun funktioniert nichts mehr richtig.
Zum Zustand:
Angezeigt wird:
Model: W2022A (aber das Gerät ist ein W2022)
Hardwareversion: 3C7.0I
Softwareversion: 1.10.03
Seriennummer: 00030004C7
An der Hardware habe ich nichts verändert. Da das Gerät sein Leben
bisher im Karton verbracht hat, ist es auch äußerlich unbeschädigt. Ich
habe noch den Originalkarton und auch die Tastköpfe.
Wenn jemand Interesse hat, kann er sich per PN mit einem Gebot bei mir
melden.
Gruß Helmut
Hallo Helmut,
das mit der PN ist nicht möglich da du dich als Gast eingeloggt hast.
Ein Kollege ist von meinem W2022 begeistert und hat jetzt Interesse
bekundet eins käuflich zu erwerben, leider ist er bei eBay nicht mehr
fündig geworden. Deshalb freut er sich sehr über dein Angebot und würde
gerne wissen was du dafür haben möchtest.
Kannst deine Preisvorstellungen per PN an mich senden, ich werde es dann
weiterreichen.
Jan
Na guck mal, da gibt es ja wieder Zuwachs in der W2000 Gemeinde.
@Sebastian
> Also ist das Problem nur, dass die> Settings Softkey bei anderen Einstellungen als Phase und Delay nicht> ausgeblendet wird.
Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay
und Phase grau sein und auch keine Funktion haben. Nur bei Delay und
Phase soll sie in das jeweilige Menü verzweigen. Bei mir tut sie das
auch. Habt Ihr nach dem Flashen einen Neustart und dann ein default
Setup gemacht?
Wenn der Fehler weiterhin auftritt bitte mit Screenshot posten.
> im Settingsmenü von sowohl Phase als auch Delay> leuchtet die weiße LED am Drehregler, obwohl nix zu drehen ist...
Ok, muß korrigiert werden.
> In den QM Phase Settings ist mir aber auch noch eine Kleinigkeit> aufgefallen - hier ist wieder mal der orange Strich zu sehen, wo> eigentlich ncihts sein sollte
Das blöde Teil stammt vom QM-Auswahlmenü. Der Pfeil ist etwas größer als
die normalen Pfeile und wird deshalb nicht richtig gelöscht. Kümmere ich
mich drum...
> Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch> am Oszi vorhanden - nur ändert es nichts
Bist Du sicher dass nichts passiert? Bei mir wird die Gridteilung in
X-Richtung (also die Frequenzteilung) umgeschaltet zwischen 8 und 10
Divs. Gleichzeitig sollte sich auch die Anzeige auf der rechten Seite
ändern.
@Rainer
> wegen der stark beschränkten Farbpalette gibt es zwischen den beiden> Einstellungen einen echten Unterschied nur bei Helligkeit 66%.
Korrekt, das sieht sich sehr ähnlich weil nur der eine Wert abweicht.
Gruß Hayo
Hayo W. schrieb:> Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay> und Phase grau sein und auch keine Funktion haben.
Hayo, hast du direkt nach Reset mal geguckt?
Rainer W. schrieb:> Um das etwas einzugrenzen: Der Fehler scheint nur direkt nach einem DSO> Neustart (Einschalten/Reset) aufzutreten. ...
edit: Mit Screenshot ;-)
Hayo W. schrieb:>> Die andere Unstimmigkeit: F4 wird als "Switch Grid" bezeichnet, ist auch>> am Oszi vorhanden - nur ändert es nichts> Bist Du sicher dass nichts passiert? Bei mir wird die Gridteilung in> X-Richtung (also die Frequenzteilung) umgeschaltet zwischen 8 und 10> Divs. Gleichzeitig sollte sich auch die Anzeige auf der rechten Seite> ändern.
Du hast recht, hab ich gestern Nacht gar nicht mehr bemerkt - war dann
wohl doch etwas zu spät ;)
Hayo W. schrieb:> @Sebastian>>> Also ist das Problem nur, dass die>> Settings Softkey bei anderen Einstellungen als Phase und Delay nicht>> ausgeblendet wird.>> Also eigentlich soll die Setting-Taste bei allen Messungen bis auf Delay> und Phase grau sein und auch keine Funktion haben. Nur bei Delay und> Phase soll sie in das jeweilige Menü verzweigen. Bei mir tut sie das> auch. Habt Ihr nach dem Flashen einen Neustart und dann ein default> Setup gemacht?>> Wenn der Fehler weiterhin auftritt bitte mit Screenshot posten.
Siehe Rainers Nachricht, tritt direkt nach Default Setup und/oder
Neustart auf... Screenshot hat Rainer oben ja schon gepostet
(select_reset.png).
Gruß
Sebastian
Hallo Hayo,
hab hier doch zwei kleine Sachen:
Schau mal im display_t.cpp Zeile 2524. SelectedTriggerSource sollte=6
gesetzt werden? Ich denke, nur TV ist als Triggersource 6 vereinbart.
Ich weiß auch nicht, welche "schlimmen" Auswirkungen das hat.
Irgendwie hakt es noch im Edge Menü: EDGE drücken
1. Schalte mit F2 von CH1 nach Ext. - angezeigt wird External,LF Reject
2. Schalte mit F3 zu Line - ist auch in der Statuszeile Line
3. Zurück mit F2 zu CH1 - Statuszeile = 1, F3 ist grau-> richtig
4. Zurück mit F2 zu Ext. - über F3 steht LF Reject
5. Drückst 1 x F3 - Häkchen ist bei Line und mit Loslassen F3 schaltet
es auch auf Line
Du kannst doch sicher feststellen, ob das Menü schon mal aufgerufen
wurde?Dann muß nicht nochmal ein Default gesetzt werden.
Gruß Jürgen
Ok, stimmt. Bei mir tritt das nach einem Neustart auch auf. Hab's schon
repariert. Jetzt suche ich mal nach dem verdammten roten Strich.
@Jürgen
sehe ich mir gleich mal an.
Hayo
Ok, im Prinzip hast Du Recht, aber...
das Setzen der Variable an dieser Stelle ist eigendlich völlig sinnlos,
da diese in Setup_Trigger sowieso gesetzt wird. Ich werde das also mal
rauslöschen.
Weiterhin werden Werte über 3 ohnehin nicht in Setup_ADC ausgewertet. Ob
da also 5 oder 6 oder 13 drinsteht ist piepschnurzegal.
Aber aufräumen werde ich trotzdem mal.
Dass Edge-Menü ist gerade in Arbeit.
Gruß Hayo
Jürgen schrieb:> Du kannst doch sicher feststellen, ob das Menü schon mal aufgerufen> wurde?Dann muß nicht nochmal ein Default gesetzt werden.
Nein leider nicht. Der Wert des Menüs wird beim deaktivieren gelöscht.
Ich müßte das also in einer Backup-Variablen zwischenspeichern. Da es ja
nur drei Einträge sind finde ich das nicht so schlimm. Ansonsten habe
ich dass jetzt repariert.
Gruß Hayo
Rainer W. schrieb:> Auf einen falsch rum drehenden Regler bin ich noch gestoßen:> Wenn man einen Kanal invertiert, wandert bei CCW-Drehung am Trigger> Level die Linie noch nach oben.
Da bist Du leider auf dem Holzweg :-)
Die Darstellung ist invertiert, nicht das wirkliche Signal. Daher läuft
natürlich auch der Trigger genau andersherum. Ist also kein Bug sondern
ein Feature.
Gruß Hayo
Hayo W. schrieb:> Die Darstellung ist invertiert, nicht das wirkliche Signal. Daher läuft> natürlich auch der Trigger genau andersherum. Ist also kein Bug sondern> ein Feature.
Aber irgendwie guckt man jedes mal doof, wenn man das Signal auf dem
Schirm sieht, den Trigger Level nach links dreht und die Trigger-Linie
entgegengesetzt zur Drehrichtung (verglichen mit nicht-invertiert
Darstellung) wandert. Zumindest ich denke da immer eher in der
Bildschirmdarstellung und nicht so sehr in den echten Signalvorzeichen.
Gruß
Rainer
Ich hätte auch gerne getestet. Bin zwar vom Fach (Elektronik-Ing.), aber
leider hab ich zu wenig Zeit und die Versuche und Recherchen im Netz
haben schon zuviel Zeit gekostet. Letztlich bin ich jetzt an der
Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab
das Ganze abgebrochen.
Falls sich doch kein Kaufinteressent findet, wäre ich für Antwort von
den Fachleuten hier auf folgende Fragen dankbar:
Angezeigt wird:
Model: W2022A (aber das Gerät ist ein W2022)
Hardwareversion: 3C7.0I
Softwareversion: 1.10.03
Seriennummer: 00030004C7
1. Ist das Gerät trotz der falsch aufgespielten Software mit
vertretbarem Aufwand noch zu retten?
2. Wenn ich das richtig sehe, muß ich erst mal das Gerät von W2022 auf
W2022A bringen und brauche dafür u.a. USB-Blaster. Läuft das unter Win7?
Sonst könnte ich unter einem virtuellen XP noch versuchen.
Liege ich so weit richtig?
Brauche ich ein alte Original-Firmware?
Gruß Helmut
PS: Nun bin ich hoffentlich eingeloggt und wer Kaufinteresse hat kann
sich hier oder per PN bei mir melden.
Sebastian S. schrieb:> Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die> Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und> aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann> natürlich auch ein Feature sein.
Eine Frage an die Runde:
Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für
sinnvoll, oder sollte man diesen Zopf einfach abschneiden?
Gruß
Rainer
Helmut M. schrieb:> 1. Ist das Gerät trotz der falsch aufgespielten Software mit> vertretbarem Aufwand noch zu retten?
Hast du diese Seite schon gefunden? Ist halt was für Windowsuser,
deshalb kann ich perönlich nichts dazu sagen:
http://sourceforge.net/apps/trac/welecw2000a/wiki/Upgrade
Und, da war noch eine Frage an dich, bitteschön:
Jan D. schrieb:> Hallo Helmut,>> das mit der PN ist nicht möglich da du dich als Gast eingeloggt hast.> Ein Kollege ist von meinem W2022 begeistert und hat jetzt Interesse> bekundet eins käuflich zu erwerben, leider ist er bei eBay nicht mehr> fündig geworden. Deshalb freut er sich sehr über dein Angebot und würde> gerne wissen was du dafür haben möchtest.>> Kannst deine Preisvorstellungen per PN an mich senden, ich werde es dann> weiterreichen.>> Jan
Michael D. schrieb:> @Guido>> Ich habe gerade eine Bestellung vom C bekommen und den Schalter wieder>> vergessen :-(. Das Alter!> Wenn du den Hauptschalter meinst, da habe ich noch welche da!
Klar meine ich den. ich schreibe dir mal eine PN, mitbestellen
klappt irgendwie seit Jahren nicht.
Hallo Rainer!
Rainer W. schrieb:>> Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die>> Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und>> aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann>> natürlich auch ein Feature sein.>> Eine Frage an die Runde:> Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für> sinnvoll, oder sollte man diesen Zopf einfach abschneiden?
Ich halte dies für nützlich, und möchte das beibehalten! So kann man
kurzzeitig Platz auf dem Schirm schaffen und etwas mehr Performance
erreichen und muss sich später nicht wieder durch die Menüs hangeln.
JK
Rainer W. schrieb:> Sebastian S. schrieb:>> Andere Sache, gleiches Menü: Ich wähle Clear Measure aus und die>> Messungen werden wie gewünscht gelöscht. Deaktiviere ich QM und>> aktiviere es wieder werden wieder Freq und Pk-Pk gemessen. Kann>> natürlich auch ein Feature sein.>> Eine Frage an die Runde:> Legt irgendjemand Wert auf dieses Feature bzw. hält es wenigstens für> sinnvoll, oder sollte man diesen Zopf einfach abschneiden?
Wie sollte es denn dann wieder starten? Mit ohne Messung? Ich finde das
nicht so schlecht, da das eigentlich die häufigsten Messungen sind die
man macht und die auch am meisten über das Signal aussagen.
Es ist ja nur ein Knopfdruck um das wieder zu löschen.
Gruß Hayo
Hayo W. schrieb:> Wie sollte es denn dann wieder starten? Mit ohne Messung?
Ja.
Wenn ich in das QM Menü gehe, habe ich i.A. eine ganz bestimmte
Vorstellung, was ich messen möchte - und meist ist das nicht Freq &
Pk-Pk, d.h. in den meisten Fällen bin ich erstmal am aufräumen. Das
hängt natürlich viel vom Einsatzzweck ab. Bei der Einstellung anderer
gewünschten Parameters nützt es nichts und füllt IMHO erstmal nur die
ersten beiden Meßwertfelder mit ungebetenen Parametern.
Gruß
Rainer
Moin zusammen,
als Luxuslösung für die QM Defaults könnte ich mir eine Speicherung in
den Setups vorstellen.
Dann könnte man sich für verschiedene Meßszenarien das komplette Setup
incl. QM Parameterwahl über "Save/Recall - Save Trace" im Speicher
ablegen. Dazu müßten die aktuell eingestellten QM Parameter bei Save
Traces mit gespeichert werden. Nach einem "QM - Clear Measure" könnten
die beim letzten "Save/Recall - Recall Trace" vorhandenen Parameter als
Default (anstelle von z.Z. fix Freq.(1) und pk-pk(1)) herangezogen
werden. Mit "Utility - Default Setup" könnte man auf die jetzig
Konfiguration schalten.
In jedem Fall wäre es natürlich praktisch, die aktuellen QM Parameter
mit beim "Save/Recall - Save Trace" zu berücksichtigen.
Hayo, was meinst du? Wäre in der Richtung ohne Neuerfindung der Welt
etwas machbar?
Gruß
Rainer
Helmut M. schrieb:> Letztlich bin ich jetzt an der> Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab> das Ganze abgebrochen.
machs dir einfach und verwende einen Rechner mit XP sowie einen
richtigen onboard- Com Port, besonders auch fürs FW Flashen ist das
sonst ein ziemliches gefrickel bis das mit virtuellen/ USB Lösungen mal
unter Win7 läuft, wenn überhaupt.
Moin,
also bisher hatte ich Cursoreinstellungen und QM-Einstellungen extra aus
Save Recall herausgehalten. Man kann das aber ohne großen Aufwand mit
abspeichern. Die entsprechenden Stellen sind zur Zeit einfach nur
auskommentiert.
Wie ist denn da so die allgemeine Meinung?
Ich bin davon augegangen, dass man z.B. ein Signal mißt und die Cursor
oder QM dazu benutzt. Wenn man jetzt ein Vergleichssignal aus dem
Speicher lädt möchte man ja eigentlich so weitermessen wie gehabt und
nicht alles umgestellt haben oder?
Gruß Hayo
Könnte man die nicht mit abspeichern, und beim recall gefragt werden, ob
die aktuellen Cursorwerte etc. überschrieben werden sollen?
Nur mal so als Idee.
Viele Grüße,
egberto
Hayo W. schrieb:> ... Wenn man jetzt ein Vergleichssignal aus dem> Speicher lädt möchte man ja eigentlich so weitermessen wie gehabt und> nicht alles umgestellt haben oder?
Mmh. Ist es beim Signalvergleich nicht sowieso so, dass die
Geräteeinstellung identisch zur Vergleichsmessung sind?
Ich sehe den Speicher ganz wesentlich auch als Möglichkeit, das
Gerätesetup für ein Szenario zu speichern, ohne das dabei die
Trace-Daten interessieren. Sonst müßte man noch zwischen Save/Recall
Trace und Save/Recall Setup unterscheiden, was natürlich auch eine
Möglichkeit wäre.
Man könnte z.B. ein eigenes Softmenü für z.B. 5 oder 6 Setups machen,
mit push für Recall und double-push für Save oder so.
Gruß
Rainer
elecBlu schrieb:> Helmut M. schrieb:>> Letztlich bin ich jetzt an der>> Installation von USB-Blaster auf meinen PC's (Win7) gescheitert und hab>> das Ganze abgebrochen.>> machs dir einfach und verwende einen Rechner mit XP sowie einen> richtigen onboard- Com Port, besonders auch fürs FW Flashen ist das> sonst ein ziemliches gefrickel bis das mit virtuellen/ USB Lösungen mal> unter Win7 läuft, wenn überhaupt.
Danke für den Tip! Das hätte ich dann wohl auch versucht. Hätte aber
erst mal einen alten PC suchen müssen mit nativen COM-Ports und dann XP
installieren. Beruflich habe ich alle krtitischen Anwendungen mit RS232
über LAN-COM-Server im Griff. Bei den USB-RS232-Wandlern gibt es auch
nur wenige die zuverlässig arbeiten.
Nun hat der Jan aber mein Verkaufsangebot angenommen und ich bin die
Kiste los. Habe ja noch mein schönes Scope von Agilent;-)
Danke noch einmal @all!
Hayo, ich habe eine Frage zu dem Testsignal.
Ist es richtig, dass der 2. CH unten abgeschnitten dargestellt wird?
(siehe Screen-Shot)
Kann es sein, das da die QB-Reihe mit in die Berechnung mit aufgenommen
wird und die Null-Linie zu tief sitzt?
Um das Signal vollständig zu sehen verschiebe ich den CH2 nach oben.
Nach einem Autoscale sitzt das Biest aber wieder zu tief.
Ja, das ist nur ein Testsignal, aber irgendwie kommt mir das nicht so
ganz richtig vor.
Hi Robert,
das Testsignal skaliert leider nicht ganz so wie ein echtes Signal.
Außerdem kann Autoscale das Signal nicht "sehen", da dieses an einer
anderen Stelle in den Puffer gemischt wird. D.h. Autoscale findet
nichts, läßt daher die Spannungsbereiche unverändert, führt dann aber
ein dispatch channels aus.
Daher diese Reaktion. Bei einem echten Signal sähe das anders aus
solange die Möglichkeit besteht in den nächst höheren Spannungsbereich
zu schalten.
Gruß Hayo
Wie würde Euch denn die volle Integration des Math-Channel in QM
gefallen?
Ungefähr so wie auf dem Bild - ist die 4.7.
Und wenn dann Math auch noch um Fakt 4 - 5 schneller wär?
Aber das ist ja bloß soon Gedanke... :-)
Gruß Hayo
Hayo W. schrieb:> Ungefähr so wie auf dem Bild - ist die 4.7.
So wie der Screen Shot aussieht, scheint der Gedanke schon recht weit
fortgeschritten. Mit dem Geschwindigkeitsfaktor könnte ich wohl leben
;-)
Rainer W. schrieb:> Wäre es bei den Cursorpositionen nicht sinnvoller, für die Zeiten X1 und> X2 als Nullpunkt die Triggerposition zu verwenden. ....
Hast du mal über die Sache mit den signalorientierten X-Cursorpositionen
nachgedacht? Die Y-Cursor beziehen sich schließlich auch immer auf das
Signal und nicht auf den Bildschirm.
Gruß
Rainer
Hier ein schönes Beispiel bei dem man den Triggerkanal ausblendet um das
Delay zwischen Math und Kanal 2 zu messen. Durch das Ausblenden wird
natürlich auch die Geschwindigkeit etwas höher.
@Rainer
> Hast du mal über die Sache mit den signalorientierten X-Cursorpositionen> nachgedacht?
Ja hab ich.
> Die Y-Cursor beziehen sich schließlich auch immer auf das> Signal und nicht auf den Bildschirm.
Nich ganz richtig, sie beziehen sich auf den Zerolevel, was Du wohl auch
meintest.
Die Idee hat Ihre Vorzüge, aber ich finde die bisherige Lösung besser
weil ich mich da besser (am Grid) orientieren kann. Stell Dir vor Du
scrollst ungefähr bei Index 14580 durch den Signalspeicher (also am
Arsch der Welt bzw. des Signals) und willst dann messen. Da hast Du dann
erstens irgendwelche Zeiten die Dir überhaupt nichts sagen, und evtl.
durch die großen Werte schon eine oder zwei Nachkommastellen weniger an
Genauigkeit.
Oder andersherum. Wenn der Pretrigger irgendwo rechts außerhalb des
Bildschirms ist, dann hast Du die ganze Zeit negative Werte, die aber
keinen sichtbaren Bezug haben.
Wie sehen das die Anderen?
Gruß Hayo
Gruß Hayo
Hayo W. schrieb:>> Die Y-Cursor beziehen sich schließlich auch immer auf das>> Signal und nicht auf den Bildschirm.> Nich ganz richtig, sie beziehen sich auf den Zerolevel, was Du wohl auch> meintest.
Na ja, der Zerolevel liegt hoffentlich zumindest bei DC Messungen fest
bei Signal=0V. Klar, bei AC muß man da unterscheiden.
Mit den Zahlenwerten ist natürlich ein Argument und bei USTB bzw. in den
schnelleren 1GSa/s-Bereichen ein ernstes.
;-)
Einen festen Zeitbezug der Cursor zum Signal erreicht man jetzt IMHO
nur, wenn man den Trigger mit "Pre Trigger / Left Edge" an den linken
Bildschirmrand legt und dann weder die Regler für Horiz.Pos. noch
PreTrigger anfaßt.
Damit man den vollen Zeitbezug hat, ohne Zahlendarstellungprobleme
heraufzubeschwören, würde es helfen, wenn die Lage des Fensters bezogen
auf den Triggerzeitpunkt als Zahlenwert verfügbar wäre. Da das Fenster
sowieso nicht beliebig fein bewegt wird, hält sich die erforderliche
Stellenanzahl auch mehr in Grenzen. Rechts neben dem Browse-Balken wäre
vielleicht Platz. Man könnte die Anzeige dann zusammen mit dem Balken
aktivieren.
Are you working a lot lately! The latest version is wonderful, thanks!
Still some problems in the fft, wrapped crashes.
Found small display problem in the new menu display/setup, the button
(grid lines) have grafic malfunctions.
Thanks again for the great work!
Gyppe.
Hallo Jürgen bzw. Hayo,
ich muß mal fragen, wie ihr den aktuelle Status bei der Puls-Trigger
Funktion beurteilt?
Ich hatte gerade mal mit der gezeigten Pulsfolge (100, 300, 200 µs)
probiert und gehofft, dass das Scope sich dazu bewegen läßt, auf den
rechten 200 µs Puls zu triggern, aber da will es so gar nicht ran. Ist
das noch FW Baustelle oder nachhaltig im FGPA vermurkst?
Gruß
Rainer
Rainer W. schrieb:> Ist das noch FW Baustelle oder nachhaltig im FGPA vermurkst?
Letzteres. Während Jürgen versucht aus dem vergurkten Design noch was
rauszuholen, habe ich auch schon einen zusätzlichen Softwaretrigger im
Hinterkopf, mit dem sich auch noch zusätzliche Funktionen wie
Mustererkennung (CAN-Bus, I²C und Ähnliches) realisieren ließe.
Allerdings ist natürlich grundsätzlich alles vorzuziehen, was man dem
FPGA noch aus dem Kreuz leiern kann.
@Guido
Auch keine schlechte Idee. Aber ich möchte noch mal darauf hinweisen das
es auch schon so ziemliche Performance Probleme gibt. Also alles was
extra implementiert wird zieht die Framerate nach unten bzw. läßt die
Drehregler träger werden.
Gruß Hayo
Rainer W. schrieb:> ... 200 µs Puls zu triggern, aber da will es so gar nicht ran.
Korrektur:
Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits.
Solange die Summe der beiden Werte für die Länge des
Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von
287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen
Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder
gar (>187, <100) einstellt.
Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der
Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und
dann
1. von >180 auf >250 drehen.
Bei >237 (Summe >287) erfolgt der Sprung vom 192 us Puls auf den
längeren Puls.
2. von >250 auf >180 zurückdrehen.
Bei >192 (d.h. bei der Pulslänge des kürzeren Pulses) springt der
Trigger wieder auf den kürzeren Puls.
Gruß Rainer
p.s. die Pulsfolge stammt ganz einfach aus einem ATmega8 mit ein paar
dahingefuschten delays.
Rainer W. schrieb:> Rainer W. schrieb:>> ... 200 µs Puls zu triggern, aber da will es so gar nicht ran.
....
> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits.> Solange die Summe der beiden Werte für die Länge des> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder> gar (>187, <100) einstellt.> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und> dann>> 1. von >180 auf >250 drehen.> Bei >237 (Summe >287) erfolgt der Sprung vom 192 us Puls auf den> längeren Puls.>> 2. von >250 auf >180 zurückdrehen.> Bei >192 (d.h. bei der Pulslänge des kürzeren Pulses) springt der> Trigger wieder auf den kürzeren Puls.>
Hallo, hier ist ja schon wieder was los...:-)
@Rainer
Ich hatte eigentlich PW soweit getestet, daß ausser "kleiner als" die
Funktionen gut triggern. Allerdings sind diese teilweise sehr
empfindlich auf den Triggerpegel, was sie aber auch sollen, wenn die
Impulsflanken nicht so steil sind. Teilweise kam es mir vor, daß nur mit
positivem Triggerpegel (nicht Impuls, das ist klar) getriggert wird.
Aber insgesamt sichere Triggerung, wenn einmal der Wert gefunden ist.
Problem war der Wiederanlauf, wenn man die Triggerbedingung einmal
verstellt hat.(Ich arbeite meist im NORMAL Mode). Nach einem Hin- und
Herschalten zwischen Edge und Pw springt es dann sofort wieder an.
Das Weiterschalten des Pulse Width Modus <, >, >< durch mehrfaches
Betätigen von PW erscheint mir hier störend. Sollten wir dies hier
unterdrücken?
In dem Zusammenhang hab ich den Vorschlag die Modeumschaltung
AUTO/NORMAL/COMBI generell freizugeben!
Gruß Jürgen
@Rainer
Deine Messungen sind insofern ganz interessant, als im Welec-Handbuch
(was ja recht gut mit einem Agilent-Handbuch übereinstimmt :-) noch
andere Startzeiten (z.B.>16ns) angegeben sind und der Welec
Programmierer hier falsch verstanden hat oder die Spezi für die
Schrittweite im FPGA nochmal geändert wurde. Warum auch immer.
Vielleicht sollten wir hier nochmal weiter systematisch forschen. Eine
entsprechende Umsetzung zur Fütterung des FPGA im Vergleich mit den
jetzigen Werten sollte dann machbar sein.
@Hayo,
folgender Bug tritt bei USTB noch auf: Die Messung läuft trotz STOP
weiter.
Es passiert, z.B. wenn im Mode Roll Forward die Messung vorm
Pufferüberlauf mit STOP beendet wird und dann mit Quick Print Daten
übertragen werden. Nach Ende der Übertragung wird weiter gesamplet,
obwohl Run/Stop weiterhin rot ist.
@Jürgen
Jürgen schrieb:> Ich hatte eigentlich PW soweit getestet, daß ausser "kleiner als" die> Funktionen gut triggern.
Ich habe jetzt nur mit satten digitalen Signalen getestet.
"Kleiner als" tut bei mir auch gar nichts.
"Größer als" funktioniert gut, nur finde ich das Verhalten etwas
gewöhnungsbedürftig. Das Triggerereignis wird anscheinend in dem Moment
ausgelöst, wo die Logik feststellt, dass ein Puls länger als der
eingestellte ">"-Wert ist. Dadurch liegt der Triggerpunkt irgendwo auf
dem Puls, genaugenommen um den ">"-Wert hinter der steigenden Flanke
(Puls_gt). Irgendwie finde ich es unpraktisch, dass der Triggerpunkt
nicht nur von der Pulslänge sondern auch vom eingestellten Limit
abhängt. Beim zweiten Bild (Puls_gt2) verstehe ich allerdings nicht,
warum der Trigger nicht schon auf den ersten Puls (380µs) erfolgt, der
auch die Triggerbedingung erfüllt. Meine Pulspakete haben 50 ms Abstand,
was eigentlich reichen sollte
Bei "Zwischen ><" scheint mir nur das ">"-Limit richtig zu
funktionieren, während das "<"-Limit eher verwirrend auf die
Triggerlogik wirkt. Dort ist es im Gegensatz zum "größer als" Mode aber
so, dass das Triggerevent am Ende vom Puls liegt, nicht mitten drauf.
Das scheint mir vernünftiger.
Jürgen schrieb:> Das Weiterschalten des Pulse Width Modus <, >, >< durch mehrfaches> Betätigen von PW erscheint mir hier störend. Sollten wir dies hier> unterdrücken?
Ack
> In dem Zusammenhang hab ich den Vorschlag die Modeumschaltung> AUTO/NORMAL/COMBI generell freizugeben!
Ack
Es wäre schon schön, wenn man den Pulsweitentrigger auch hinbekommt,
insbesondere über das FPGA. Die Dinger sind (bisher) leider überhaupt
nicht meine Ecke.
Gruß
Rainer
Rainer W. schrieb:> Es wäre schon schön, wenn man den Pulsweitentrigger auch hinbekommt,> insbesondere über das FPGA. Die Dinger sind (bisher) leider überhaupt> nicht meine Ecke.
Hi Rainer,
wir kommen hier und anderswo eventuell genau in diese Bereiche. Hab auf
SVN nachgesehen und Du hast die HW-Version 1C9.0L. Ich habe die 8C7.0H
auf meinem W2024A. Kann sein, daß u.a. beim Pulse Width Trigger schon
hier eine Unterschied besteht und meine Version vielleicht schon weniger
Fehler hat. Wir sollten dies schon beim Vergleich der Funktionen
berücksichtigen!
Dann hilft nur ein Update der FPGA-Software. Da wir nicht wissen, ob
eine fortlaufende Version auch ohne Fehler ist, können wir nur
vergleichen. Lt. SVN hat Kurt die "letzte" Version der FPGA-SW.
Allerdings sehen wir, daß auch innerhalb gleicher Versionen
unterschiedliche Prüfsummen existieren. Kann auch nur z.B. die
Seriennummer sein?!
Vielleicht haben andere User hier andere Ergebnisse?
Gruß Jürgen
Hallo allerseits,
nach viel Fummelei habe ich jetzt auch endlich die Multiplikation
hinbekommen, so dass sie endlich richtig skaliert und das Ergebnis
richtig herum anzeigt.
Anbei ein schönes Beispiel für eine Leistungsberechnung aus einer
Spannungs und einer Stromkurve.
Leider stimmen die Einheiten (V) noch nicht, hier muß es natürlich
entweder V² oder W heißen. Zusätzlich konnte ich die Berechnung deutlich
beschleunigen.
@Rainer
> folgender Bug tritt bei USTB noch auf: Die Messung läuft trotz STOP> weiter.
Ok, danke -> ist in Arbeit.
Gruß Hayo
@Hayo: Ist das die gewünschte Funktion um den Strom anzeigen zu können?
Also mit Kanal 1 vor dem Shunt und mit Kanal 2 nach dem Shunt messen und
die Differenz wird dann invertiert und verstärkt(Multipliziert) um den
Strom anzeigen zu können?
Nicht ganz,
eine Kurve ist die Spannung vor dem Widerstand gegen Masse und die
andere ist der Spannungsabfall über den Widerstand (1 Ohm).
Multipliziert ergibt das die Leistung die vom Widerstand verbraten wird
über die Zeit. Man sieht schön wie die Leistung an den Nulldurchgängen
ebenfalls gegen Null geht.
Bei kapazitiver oder induktiver Last könnte man auch noch eine
Phasenverschiebung sehen.
Gruß Hayo
Hi Hayo,
Hayo W. schrieb:> Anbei ein schönes Beispiel für eine Leistungsberechnung aus einer> Spannungs und einer Stromkurve.
Du machst es ja spannend mit der neuen Version: Das hört sich wieder
nach echten Riesenfortschritten an.
Hier noch ein kleines Schönheits-"feature" im QM-Menü:
In der BF4.6.C2 stimmt in den QM Submenüs für die Settings von Delay-
bzw. Phasenmessung bei der Auswahl von Soure1 bzw. Source2 irgendetwas
noch nicht. Nach einem Neustart/Reset sind, auch wenn am W2024 z.B. nur
Ch. 1 und 2 aktiv sind, alle vier Kanäle als Source anwählbar. Wenn man
dann z.B. Ch. 3 aktiviert und Ch. 2 deaktiviert (1, 3 aktiv), sind in
der Liste 1, 3 und 4 auswählbar. Nach einem Default Setup benimmt sich
die Auswahl anscheinend richtig.
Gruß
Rainer
Rainer W. schrieb:> Du machst es ja spannend mit der neuen Version: Das hört sich wieder> nach echten Riesenfortschritten an.
Ja es wird endlich ein voll benutzbarer Math-Bereich sein. Allerdings
ist es viel Klein und Fummelkram der da erledigt werden muß.
> Hier noch ein kleines Schönheits-"feature" im QM-Menü:> In der BF4.6.C2 stimmt in den QM Submenüs für die Settings von Delay-> bzw. Phasenmessung bei der Auswahl von Soure1 bzw. Source2 irgendetwas> noch nicht.
Hatte ich auch schon bemerkt. Die Logik, die die Verfügbaren Kanäle
einträgt bzw. austrägt ist noch etwas buggy. Eine der Altlasten. Werde
ich mal überarbeiten.
Gruß Hayo
So, hat etwas länger gedauert weil es immer wieder kleine Hindernisse zu
Überwinden gab. Jetzt arbeiten die Math-Funktionen recht brauchbar. Die
Integration in QM und die Cursor-Logik war nicht so einfach.
Viel Spaß
Hayo
Vielen Dank für die neue Version, werde sie gleich drauf spielen.
Aber warum willst du die Einheit bei Multiplikation in W oder VA ändern?
VV ist imho einzig richtig, da du ja nicht wissen kannst, welche
physikalische Größe durch die Spannung repräsentiert wird (muß ja nicht
der Strom sein).
Viele Grüße,
Egberto
Shunt ist dann aber zu kurz gedacht...ein beliebiger Scalierungsfaktor
(float) wäre optimal.
Und die Angezeigt Buchstabenkombination müsste auch frei einstellbar
sein.
Aber das ist alles absoluter Luxus und nicht unbedingt nötig -
Fehlerbehebung hat doch Vorrang.
Und ein Blick Richtung LA wäre auch toll (mit i2c, rs232,SPI
Interpreter).....
Viele Grüße,
Egberto
Egberto schrieb:> Aber das ist alles absoluter Luxus und nicht unbedingt nötig -> Fehlerbehebung hat doch Vorrang.
Schon richtig, aber das mache ich meistens nebenbei wenn ich durch die
Tiefen des Codes pflüge...
Momentan gehen mir allerlei weitere Math Funktionen durch den Kopf. So
wie Ableitung und Integral, angeregt durch das Agilent-Handbuch. Auch
bei der FFT habe ich immer noch einige Ideen nicht umgesetzt. Aber nach
und nach arbeite ich das alles ab.
Gruß Hayo
Puh, alles in allem ist das ganze mittlerweile sehr undurchsichtig und
wenn man nicht stets am Ball geblieben ist - wie in meinem Fall - weiss
man mittlerweile nicht einmal mehr, ob die aktuelle Firmware
1.2.BF.4.7.zip noch kompatibel zu einem voellig unverbastelten Geraet
ist.
Ist sie das?
Ansonsten vielen Dank an Hayo und alle beteiligten fuer die
hervorragende Arbeit an der Firmware :)
Gruessle
André
Hayo W. schrieb:>> Aber das ist alles absoluter Luxus und nicht unbedingt nötig ->> Fehlerbehebung hat doch Vorrang.>> Schon richtig, aber das mache ich meistens nebenbei wenn ich durch die> Tiefen des Codes pflüge...>> Momentan gehen mir allerlei weitere Math Funktionen durch den Kopf. So
Und warum ist "External Trig" jetzt erstmal gesperrt?
Gruß Jürgen
Offtopic: 1,6 Millionen Euro in die Entwicklung für ein Gerät, dass der
Hersteller jetzt selbst bei eBay für 100 bis 200€ verschleudert?
Irgendwas ist da aber kräftig schief gegangen - vielleicht hätte man
sich gleich auf ein gutes, aber für den Hobby-Bastler bezahlbares
Hardware-Design beschränken sollen und die Software von Anfang an durch
die Community entwickeln lassen sollen - OpenSource kann sich für einen
Hersteller lohnen.
Ontopic:
Hab die 4.7 gerade geflasht - läuft soweit ganz gut, konnte beim
fröhlich durch Menüs springen nur eine Sache feststellen:
Bei Source sowohl in Edge als auch Pulse Width kann ich Kanal 1, 2, 3
und External auswählen (hab das W2022A), sobald Math aktiviert ist - ist
Math aus hab ich nur Kanal 1, 2 und External. Hier wird Math also
fälschlicherweise als Kanal 3 bezeichnet, sollte ja besser wie im QM und
Cursor-Menü auch Math heißen.
Schönen Gruß und wie immer: Danke für deine gute Arbeit! :)
Egberto schrieb:> 1000! - neuer Thread? (ich kurble mir auf dem iPad jetzt schon nen Wolf> beim scrollen)
Wenn du dich anmeldest, dürfte das wegen der Seitenaufteilung locker
eine Faktor 5 und mehr sparen.
Andre schrieb:> Puh, alles in allem ist das ganze mittlerweile sehr undurchsichtig und> wenn man nicht stets am Ball geblieben ist - wie in meinem Fall - weiss> man mittlerweile nicht einmal mehr, ob die aktuelle Firmware> 1.2.BF.4.7.zip noch kompatibel zu einem voellig unverbastelten Geraet> ist.>> Ist sie das?
Hallo Andre,
ja sie ist es! Ich entwickle die Firmware grundsätzlich auf einem
unverbastelten W2014A. Alle Extras für die Unterstützung alternativer
Hardware ist grundsätzlich optional und wird entweder von mir auf meinem
"getunten" W2022A entwickelt oder von einigen hier im Forum die mir dann
das Coding freundlicherweise zukommen lassen.
@Jürgen & Sebastian
> Bei Source sowohl in Edge als auch Pulse Width kann ich Kanal 1, 2, 3> und External auswählen (hab das W2022A),> Und warum ist "External Trig" jetzt erstmal gesperrt?
Normalerweise prüfe ich alles was mit den Kanälen zu tun hat noch auf
dem W2022A. Hier scheint mir aber was durchgerutscht zu sein. In
Display::Init() bzw. in MenuInit() werden die Menüs extra für die
Zweikanalgeräte angepasst. Da scheint ein kleiner Fehler drin zu sein.
Ich stelle natürlich möglichst schnell eine Korrektur zur Verfügung.
Gruß Hayo
>Wenn du dich anmeldest, dürfte das wegen der Seitenaufteilung locker>eine Faktor 5 und mehr sparen.
Ach ja, stimmt, hatte ich verdrängt... aber Zeit für Teil 5 ist es aber
wohl trotzdem.
Viele Grüße,
egberto
Jürgen schrieb:> Und warum ist "External Trig" jetzt erstmal gesperrt?
Hallo Jürgen,
ich wollte das gerade fixen, stelle aber fest das bei mir alles richtig
ist und der Eintrag nicht gesperrt ist. Ist das bei Dir noch aktuell?
Gruß Hayo
Jürgen schrieb:> Und warum ist "External Trig" jetzt erstmal gesperrt?
Bei mir am W2024 ist es im Menü "Edge" freigegeben und in "Puls Width"
gesperrt.
Gruß
Rainer
Ja,
das ist korrekt. Ich bin der Meinung dass die Pulsweitentriggerung für
Extern nicht funktioniert. Täusche ich mich da? Wenn ja dann gebe ich
das natürlich wieder frei.
@all
Allerdings habe ich gerade festgestellt, dass anscheinend der
Math-Channel bei den 2-Kanalgeräten zwar ausgewählt werden kann, aber
keine Auswirkungen zeigt bzw. versucht den nicht vorhandenen Kanal 3 zu
benutzen.
Diese immer wieder auftauchenden Altlasten machen mich echt fertig. Es
gibt aber auch keine Ecke die einfach mal funktioniert.
Ich werde also die Popupsteuerung mal überarbeiten und das vernünftig
machen.
Liebe Besitzer eines 2 Kanal Gerätes - nicht böse sein, Ihr bekommt
natürlich möglichst schnell Abhilfe.
Dear owner of a 2 channel WELEC DSO please don't worry about not working
math channel as source for QM and cursors. Correction will come soon.
Gruß Hayo
Hayo W. schrieb:>> Und warum ist "External Trig" jetzt erstmal gesperrt?> Hallo Jürgen,>> ich wollte das gerade fixen, stelle aber fest das bei mir alles richtig> ist und der Eintrag nicht gesperrt ist. Ist das bei Dir noch aktuell?>> Gruß Hayo>
Das gibt es doch nicht! Jetzt ist es bei Edge freigegeben (W2024A). Ich
bin mir ziemlich sicher, daß es gestern beim F2-Button war, d.h. bei
Edge.
Sorry, vielleicht doch schon das Alter :-(
Jedenfalls funktioniert es jetzt.
Gruß Jürgen
Hallo Hayo,
na also, es scheint bei mir doch noch alles i.O. :-O
Nach Default Setup ist bei Edge External gesperrt. Fragt nicht, wie man
das dann freigeben kann...
Hayo W. schrieb:> Bei Pulsewidth lasse ich es aber gesperrt, oder?>> Gruß Hayo
Da fehlt meiner Ansicht nach noch ein Stück Programm. Ich kann es auch
schlecht testen, wenn ich übers Menü nicht dorthin komme...
Vielleicht kannst Du es erstmal freigeben und wir sehen dann weiter?
Gruß Jürgen
Jürgen schrieb:> Nach Default Setup ist bei Edge External gesperrt. Fragt nicht, wie man> das dann freigeben kann...
Mit Reset/Neustart ;-)
Gruß
Rainer
Ich habe inzwischen die ganze Popuplogik überarbeitet. Es ist jetzt
möglich nicht verfügbare Einträge einfach auszublenden. Dadurch wird die
Initialisierung viel einfacher und das Problem mit dem Math-Channel hat
sich auch erledigt genau wie die ausgegrauten Einträge im Triggersource
Menü.
Gruß Hayo
So, diesmal gibt es keine weitere Kompilation, sondern gleich eine neue
Version. Ich habe die letzten Tage alles an Popuplogik und
Kanalwechsellogik durchforstet was da so drinsteckt und habe etliches
neu geschrieben bzw. erweitert oder gelöscht.
Da fehlte es an allen Ecken und Enden. Ich hatte bei meinen Tests so den
Eindruck als ob das jetzt ganz rund läuft. Ihr seid natürlich
aufgefordert das zu überprüfen.
Besonderes Augenmerk bitte auf den QM-Slotwechsel legen. Da die Tests
recht Zeitaufwändig sind konnte ich nur die wichtigsten Kombinationen
testen.
Die Sollfunktion ist:
Wenn eine neue Messung angefordert wird (mit dem Measure Button), dann
wird diese auf den nächsten freien Slot gelegt. Sind alle Slots belegt,
dann werden die Messungen von rechts nach links weitergeschoben (first
in first out). Die neue Messung bekommt dann den neu freigewordenen Slot
zugewiesen.
Wird jetzt ein Kanal abgeschaltet der bei einer Messung als Sourcekanal
dient, dann muß diese Messung beendet werden, der Slot freigegeben
werden und alle restlichen Messungen linksbündig angeordnet werden.
Das Ganze ist nicht so ganz ohne, da alle Parameter der Messungen an den
neuen Slot übergeben werden müssen. Das ist besonders bei Delay und
Phase etwas aufwändiger, da hier eigene Sourcekanäle verwendet werden.
Bei aktivem Math-Channel als Source wird bei Abschalten von Kanal 1 oder
2 der Math-Channel ebenfalls deaktiviert. Es müssen dann also alle Slots
mit Sourcen des abgeschalteten Kanals und des Math-Channels freigegeben
werden.
Viel Spaß beim Testen, ich freue mich auf die Rückmeldungen.
Gruß Hayo
moin moin, Hayo
Ich habe deine 4.8er gerade mal aufgespielt und mal den USTB-Modus mit
einem ca. 100mHz Sinus gefüttert. Wenn der 8KB Buffer voll ist, wird
dieser vor dem nächsten Messzyklus dann nicht geleert?
Auf dem Shot war der Buffer voll, hat von vorne begonnen und
überschreibt die vorherige Messung, ist das Absicht?
Zur Erläuterung: Die Spitze auf dem Shot geht von der neuen auf die alte
Messung, also überschreibt diese.
Gruß Michael
Sieht doch gut aus? Es sollen doch immer möglichst viele
Daten angezeigt werden, deshalb machen das eigentlich alle
Speicheroszilloskope so.
Grüße, Guido
Ok, dann ist ja gut!
Hier habe ich noch ein schickes Dreieck.
Wenn der Singleshot betätigt wird, ist dann der Speicher leer und das
Ganze fängt von vorne an...
Das Messen im QM-Menu läuft jetzt auch etwas flüssiger oder bilde ich
mir das nur ein?
@Hayo,
Ich sollte dich noch an das vierte Messfenster im QM-Menu erinnern...
:-)
Gruß Michael
Ja das vierte Messfenster. Ich hatte das nicht vergessen, im Gegenteil,
ich hatte mir schon Gedanken gemacht ob und wie man das implementieren
könnte. Ich habe zum Ergebnis nur noch nichts gesagt, um den Aufschrei
der Entäuschung zu vermeiden. ;-)
Also - folgende Gründe die dagegegen sprechen:
- einige der Messausgaben sind so breit, dass schlichtweg nicht vier
nebeneinander passen. Nur einige der Ausgaben würden da reinpassen.
- Der zusätzliche Verwaltungs und Programmieraufwand wäre nicht
unerheblich.
- Last but not least - die Rechenleistung unserer kleinen CPU ist mit
drei gleichzeitigen Messungen schon so vollauf beschäftigt, dass eine
weitere Messung den Ablauf fast ganz zum Stillstand bringen würde.
I'm sorry
Hayo
moin,
wenn dem so ist, dann lassen wir das wohl lieber sonst würden wir von
der Performance her, ja rückwärts gehen! Das soll nicht sein und wir
werden's wohl überleben.
Gruß Michael
Hallo,
kennt Ihr die Anschlusseinstellungen ? Ich bekomme keine Verbindung mit
dem Updateprogramm von Welec.
Es ist allerdings ein RS232-USB-Adapter vor dem Notebook eingesteckt.
Verschiedene Baudraten und Einstellungen brachten keinen Erfolg, bleibt
wohl nur noch am PC mit RS232-Schnittstelle auszuprobieren ?
Danke
Gruss
Rolf
teste mal ob du im Terminal Programm mit 115200
was empfangst beim einschalten des Oszi
vlG
Charly
ps. der original updater iss nix, es gibt hier bessere
Die Einstellungen findest Du in der Datei 'How to use a terminal' im
Verzeichnis 'doc'.
Hier noch mal in Kurzform:
Port: hier den benutzten seriellen Port eingeben, meistens COM1
Baud Rate: 115200
Data: 8 bit
Parity: None
Stop: 1 bit
Flow control: None
Auch bekannt unter 8N1 115200.
Hast Du den Updater von Markus benutzt? Die beste Lösung ist es das
Perlskript zu benutzen. Dazu mußt Du ActivePerl installieren.
Anleitung auch im 'doc' Verzeichnis Datei
'How to upload via shell script.txt'
Ansonsten hatte noch ein anderer W20xx Besitzer hier Probleme mit einem
RS232/USB Adapter, ich glaube er hat ein anderes Kabel mit gekreuzten
Leitungen benutzt.
Am besten erstmal wie weiter oben empfohlen testen ob mit dem
Terminalprogram etwas empfangen wird. Wenn alles funktioniert gibt das
DSO beim Hochfahren über die RS232 einige Meldungen aus und nimmt dann
Tastaturbefehle entgegen. Wenn das funktioniert, dann geht auch das
Update mit dem Perlskript.
Wenn Du weitere Fragen hast, nur keine Hemmungen, wir helfen da Schritt
für Schritt weiter.
Gruß Hayo
der Updater den ich gepostet habe, funzt wunderbar!
Wenn er jetzt noch Aktive-Perl installieren soll, sitzt er bis morgen
früh, schätze ich.
Ich benutze auch einen RS232 Adapter(Hama). Es gibt da keine Probleme,
egal ob Notebook oder Tower, die Übertragung dauert nur ein wenig
länger.
Wenn die Anschlusseinstellungen am Rechner(Comport) geändert werden, muß
man den "meistens" neu hochfahren, damit die Einstellungen wirksam
werden.
@Hayo
wer hat denn da ein Kabel gekreuzt???
Gruß Michael
Ich meine ein anderer Michael - Michael W. oder so war das glaube ich.
Da funktionierte das Ganze nur mit einem anderen Zusatzkabel.
Ist aber wohl eher eine Ausnahme. Bei mir läuft das Ganze sowohl am
PC-Port als auch am NoName USB-RS232-Adapter am Notebook problemlos.
Die guten alten echten RS232 Ports...
Tja auf manches kann man eben doch nicht verzichten.
Gruß Hayo
Ach, jetzt hätte ich es fast vergessen: Ich hab heute mit einem alten
Studienkollegen gesprochen und Ihm von unserem Projekt erzählt.
Ergebnis: Er interessiert sich für ein 4 Kanalgerät von WELEC. Wer also
sein Gerät verscherbeln will oder bei Ibähi ein Angot sieht bitte bei
mir melden.
Hayo
Hi Hayo, Jürgen, and guys all!
I am back after a long time.
I am in a hurry now, but I want to say some things.
Necessarily I will be short. ;-)
First I have to thanks all You and especially Hayo for the great work
You are doing on Welec's oscilloscopes: no words, RESPECT!
I installed the latest firmware release 1.2.BF.4.8 and by the way I
noticed some things who I report follow here in order to improve them:
mine are not critical to the work done but only for knowledge.
Again for knowledge, I specify that all screenshots were made with a
W2012A.
@Hayo
When QM is on, changing Time Base sometimes get corruption on the screen
who can be removed by setting to default or performing reset sequence or
again by switch between measure's screen to the informations screen:
please look at the screenhot CORRUPTED_1.jpg, CORRUPTED_2.jpg, and
CORRUPTED_3.jpg.
I know the FFT have to be finished in order to improve it, but seems to
me the division's value for either df, div and fN are wrong: please look
at the screenshot DIMENSION div fN.jpg, DIMENSION fN div.jpg, DIMENSION
div_fN.jpg and DIMENSION fN_div.jpg.
Again for the FFT when You switch to Display in order to change
graticule's dimension, then Grid up to 100% without intensity change and
turning the knob the grid's intensity increase but never is possible to
set it down, it is stuck until perform default setting: please look at
screenshot FFT Grid Level.jpg.
About the Quick Measure I noticed when some values are below certain
levels then zero is showed: is not possible to increase recognized level
in order to show a more low level?
For some example please look at the screenshot ZERO in QM.jpg and ZERO
in QM_.jpg.
About the Hardware ADC Setup, I tried some settings because the behavior
of both mine either W2022A and W2012A prevents to use Hig Freq's
setting.
So right choice is a bit difficult to make for me.
Please refer to the screenshot Factory.jpg, High Freq.jpg, Test 1.jpg,
Test 2.jpg, Test 3.jpg, Test 4.jpg and Test 5.jpg.
Is not there a precise way to make a choice?
How can I know if an unknown signal actually appears on screen as in
real life or only for the wrong setting of the ADC Setup?
Can I get trust or I must to hope it is a right setting?
@Hayo, Jürgen
As I understand You are trying to further improve either the internal
trigger and external, I repeat some things I already wrote.
Seems when the trigger's threshold is low the waveform is moving and the
signal's amplitude is a bit more low compared to when the trigger's
treshold itself is high and so the signal's amplitude becomes it itself
more high and the waveform is more steady on the screen.
Please refer to my former post and here screenshot Trig Lev High.jpg and
Trg Lev Low.jpg.
@All
Is there somebody noted that signal amplitude seems to depend on the
trigger treshold?
Is there somebody noted that when the trigger's threshold is low
amplitude waveforms on the screen are dancing while when it is much
higher the waveforms are much more steady on the screen?
@Jürgen
Can You kindly explain further about the C37 matter?
What are the benefits?
And contraindications?
Seems to me the modification need for a software support, is not so?
Thanks in advance Jürgen.
Perhaps the C37 modification together with the change of line and
termination resistance for the MAX121 are the minimun to do on the
original hardware in order to improve the performances if the Piggyback
board is not installed.
Of course firmware is much important too.
Hayo W. schrieb:
>- Last but not least - die Rechenleistung unserer kleinen CPU ist mit>drei gleichzeitigen Messungen schon so vollauf beschäftigt, dass eine>weitere Messung den Ablauf fast ganz zum Stillstand bringen würde.
I connect here in order to make some considerations.
Of course what You say is right, fast response it is fundamental
otherwise the device becomes unusable and useless.
In the present and in the past all yours efforts were aimed at improving
the device without make it unusable.
It is can say the goal was reached, infact now the Welec DSO are much
more similar to Agilent and other blasonate DSO's brands and I do not
only refering at the features but to the performances too.
So there was, there is and there will, I hope, a great improve on either
estetic and features: I like very much new configurable screen setting
as well some killer applications as Overlay, single shot configuration,
new mathematical functions and many others.
Said this, I think perhaps
> Ich hätte da mal einen Vorschlag:> im Quickmeasure sowie im Curserbereich, stehen fett und breit, 3x> Messbereiche zur Verfügung!> Wäre es möglich, diese Anzeigen um ein Drittel (Breite)zu verkleinern> und einen vierten Messbereich dazu zzu nehmen? Genug Platz ist ja> voranden.
it do not kill ours DSO, is not so?
I know, this and other things are already in the wish list, but since
there was also talk of aesthetic improvements I wanted to remember also
this.
About the wish list:
What about the sin(X/X) interpolation implementation?
And centre and span features for the FFT?
Now I must to run away, so thank You to all You.
Vielen Dank!!!
Gruß Luc
Hayo W. schrieb:> Ich meine ein anderer Michael - Michael W. oder so war das glaube ich.> Da funktionierte das Ganze nur mit einem anderen Zusatzkabel.>> Ist aber wohl eher eine Ausnahme. Bei mir läuft das Ganze sowohl am> PC-Port als auch am NoName USB-RS232-Adapter am Notebook problemlos.>> Die guten alten echten RS232 Ports...>> Tja auf manches kann man eben doch nicht verzichten.>> Gruß Hayo
Hi,
hat sich inzwischen erledigt mit dem Interface: Ich hab's nochmal ohne
Zusatzkabel probiert und dann ging's doch. Weiss auch nicht, woran's
damals gelegen hat...
Zwischenzeitlich hatte ich tatsächlich überlegt, meinen 4-Kanäler zu
verjubeln aber dank der wieder erstarkendne Entwicklung bin ich wieder
dabei. Inzwischen habe ich noch schöne Aluknöppe gemacht (gibt'n schönen
Beitrag im Hardwarethread) und mit der Firmware ist's wirklich gut
brauchbar.
Leider sind mir die Lötereien für die Huckepackplatinchen zu schwierig,
da trau' ich mich nicht so ran, olles Vogelfutter... :-/
Michel
> Inzwischen habe ich noch schöne Aluknöppe gemacht (gibt'n schönen> Beitrag im Hardwarethread) und...
War der Beitrag von mir?
Zeig' mal deine Knöppe, dann halt im HW-Thread
Gruß Michael
Luc schrieb:> Hi Hayo, Jürgen, and guys all!
Hi Luc, welcome back!
> Necessarily I will be short. ;-)
Yes, I know, You are allways short ;-)
> @Hayo> When QM is on, changing Time Base sometimes get corruption on the screen
Yes I noticed this too and I'm searching for the reason. I hope I can
fix it soon.
> I know the FFT have to be finished in order to improve it, but seems to> me the division's value for either df, div and fN are wrong:
I guess the values are correct. For example:
Sample Rate 1GSa/s -> fN (span) = Sample Rate/2 = 500MHz
Points = 512 -> Spectrum = 512/2 = 256. Grid width is 512 -> one
frequency line is 2 pixels wide.
div = fN/10 = 50MHz = 50 Pixel wide.
df = div/25 = 2MHz (one line is 2 pixel wide at 512 point FFT)
am I right?
>> Again for the FFT when You switch to Display in order to change> graticule's dimension...
Yes You are right, there is a bug. I'm working on it. Thanks.
> About the Quick Measure I noticed when some values are below certain> levels then zero is showed:
Hmmm, difficult. I think it is because of the interpolation. I will
check if it can be improved.
> About the Hardware ADC Setup, I tried some settings because the behavior> of both mine either W2022A and W2012A prevents to use Hig Freq's...
Yes this is a Problem. The adjustments with the best HF-behaviour have a
problem with spikes which seem to be generated by wrong FPGA timing. So
I called them Test 1 and Test 2 because they seem to be more
experimental, but may be helpful at very high frequencies. On normal
purposes the factory setting should work ok.
> @Hayo, Jürgen> Seems when the trigger's threshold is low the waveform is moving
correct, trigger is more stable when the level is not zero but a little
bit higher. The wave form differs because of the zoom effect of some
timebases. at 50ns/div the zoomfactor is 1 and it shouldn't occur.
> About the wish list:> What about the sin(X/X) interpolation implementation?
I investigated in this theme but it is not trivial. Unfortunately I
didn't find a good implemention example (as code), but only theoretic
descriptions. I'm working on it...
> And centre and span features for the FFT?
Yes this is also on my list and also a 2048 point FFT if possible with
the CPU performance.
Thanks for Your short report,
Hayo
Luc schrieb:
Hi Luc,
> @Hayo, Jürgen> As I understand You are trying to further improve either the internal> trigger and external, I repeat some things I already wrote.> Seems when the trigger's threshold is low the waveform is moving and the> signal's amplitude is a bit more low compared to when the trigger's> treshold itself is high and so the signal's amplitude becomes it itself> more high and the waveform is more steady on the screen.
Yes, this is the same on internal and external trigger. When the
trigger's treshold is high the waveform is more steady on the screen. On
the internal trigger the trigger logic sees more noise and this is why
you have more trigger events on a zero trigger level. The waveform is
moving on the screen.
>@Jürgen>Can You kindly explain further about the C37 matter?>What are the benefits?>And contraindications?>Seems to me the modification need for a software support, is not so?>Thanks in advance Jürgen.
On external trigger this new capacitor to C37 reduce the amplitude of
the reference voltage of the external trigger comparator U6, because
this reference voltage is build by a PWM signal and a low pass filter.
So there is with this additional C a more stable timing and the
waveforms are not so much "dancing".
There are no con's. You can use this hardware modifcation also with the
original firmware 1.4.
Regards, Jürgen
Hi Hayo and guys all!
Hayo W. schrieb:
>Yes, I know, You are allways short ;-)
Oh man, as usual You are right! :-)
You certainly know your chickens! ;-)
Hayo W. schrieb:
>> When QM is on, changing Time Base sometimes get corruption on the screen>Yes I noticed this too and I'm searching for the reason. I hope I can>fix it soon.
For sure you will succeed, I will bet on it!
Hayo W. schrieb:
>> I know the FFT have to be finished in order to improve it, but seems to>> me the division's value for either df, div and fN are wrong:>I guess the values are correct. For example:>Sample Rate 1GSa/s -> fN (span) = Sample Rate/2 = 500MHz>Points = 512 -> Spectrum = 512/2 = 256. Grid width is 512 -> one>frequency line is 2 pixels wide.>div = fN/10 = 50MHz = 50 Pixel wide.>df = div/25 = 2MHz (one line is 2 pixel wide at 512 point FFT)>am I right?
Yes of course I think You are right, but I was referring to numerical
values in the lateral table and not to the physical size of the
graticule.
Looking at screenshot DIMENSION_div_fN.jpg with 1Gsa/s and 512pts it is:
df=1.95MHz
div=50.02MHz
fN=500.24MHz
And further looking at screenshot DIMENSION_div_fN.jpg with 500Ksa/s and
512pts it is:
div=977.5Hz
div=25.01KHz
fN=250.12MHz
Seems to me that the accounts do not come back, is not so?
Maybe I am wrong, otherwise sorry, I do not understand.
Hayo W. schrieb:
>> Again for the FFT when You switch to Display in order to change>> graticule's dimension...>Yes You are right, there is a bug. I working on it. Thanks.
Thank You a lot Hayo!
Hayo W. schrieb:
>> About the Quick Measure I noticed when some values are below certain>> levels then zero is showed:>Hmmm, difficult. I think it is because of the interpolation. I will>check if it can be improved.
You knew the job was difficult when you took it, Hayo! ;-)
Ok, no kidding anymore, I know it is not simple because in this case it
is to push the measure under the nS value, pratically in the pS's field:
really not easy!
Hayo W. schrieb:
>> About the Hardware ADC Setup, I tried some settings because the behavior>> of both mine either W2022A and W2012A prevents to use Hig Freq's...>Yes this is a Problem. The adjustments with the best HF-behaviour have a>problem with spikes which seem to be generated by wrong FPGA timing. So>I called them Test 1 and Test 2 because they seem to be more>experimental, but may be helpful at very high frequencies. On normal>purposes the factory setting should work ok.
Yes, thank You for the explanation, Hayo!
The real problem is some setting are ok with waveforms as for example
the inner probe compensation's generator but are worst with other kind
of waveforms as for example pulses.
Not easy set it correctly because could happen with a not suitable
waveform.
And yes, Factory setting work well apart some spikes problem in some
circumstance, but upon a time with a former firmware release High Freq
setting was the better choise for all the situations.
I am sure one of the setting it is the right answer also this time, I
will pursue it!
Hayo W. schrieb:
>> Seems when the trigger's threshold is low the waveform is moving>correct, trigger is more stable when the level is not zero but a little>bit higher. The wave form differs because of the zoom effect of some>timebases. at 50ns/div the zoomfactor is 1 and it shouldn't occur.
Thank You very much also for this explanation, Hayo!
I guess this even affects the amplitude.
Hayo W. schrieb:
>> About the wish list:>> What about the sin(X/X) interpolation implementation?>I investigated in this theme but it is not trivial. Unfortunately I>didn't find a good implemention example (as code), but only theoretic>discriptions. I'm working on it...
Hayo, this is really an amazing news, thanks!
I guess this implementation can improve a lot the shape of the waveforms
shown on the screen.
Hayo W. schrieb:
>> And centre and span features for the FFT?>Yes this is also on my list and also a 2048 point FFT if possible with>the CPU performance.
Oh boys, another great amazing news, thank You Hayo, You are really the
best one: RESPECT!
Hayo W. schrieb:
>Thanks for Your short report,
Ok, ok, actually it is not so short! ;-)
Instead, thanks to You Hayo for the great patience and kindness and free
time You provided generously to us!!!
RESPECT!!!!!!!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Hi Jürgen and guys all!
Jürgen schrieb:
>> Seems when the trigger's threshold is low the waveform is moving and the>> signal's amplitude is a bit more low compared to when the trigger's>> treshold itself is high and so the signal's amplitude becomes it itself>> more high and the waveform is more steady on the screen.>>Yes, this is the same on internal and external trigger. When the>trigger's treshold is high the waveform is more steady on the screen. On>the internal trigger the trigger logic sees more noise and this is why>you have more trigger events on a zero trigger level. The waveform is>moving on the screen.
Thank You very much for the explanation, Jürgen: RESPECT!
Jürgen schrieb:
>>Can You kindly explain further about the C37 matter?>>On external trigger this new capacitor to C37 reduce the amplitude of>the reference voltage of the external trigger comparator U6, because>this reference voltage is build by a PWM signal and a low pass filter.>So there is with this additional C a more stable timing and the>waveforms are not so much "dancing".>There are no con's. You can use this hardware modifcation also with the>original firmware 1.4.
Very well Jürgen, I thank You a lot for these useful informations:
RESPECT!!!!!!!
For me, and I guess for somebody else also, this is really a very
interesting thing.
Going ahead, in relation to what You wrote this means there are other
capacitors can be modified putting in parallel of them more capacitors
in order to get a better behavior of the inner trigger, due C37 improve
only the external one if I am no wrong.
So, which are the capacitors and what is the final capacitance's value?
Jürgen, thank You very much for the kind reply: RESPECT!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Luc schrieb:> Hayo W. schrieb:>>Yes, I know, You are allways short ;-)> Oh man, as usual You are right! :-)> You certainly know your chickens! ;-)
rofl
<ot>
Ok, I learned: 3 pages and about 20 screenshots are defined as "short"
(for Luc). For all the others: 3 lines and max 2 shots, please. ;-)
</ot>
Have a nice sunday, Rainer
Hayo W. schrieb:
>>> About the Hardware ADC Setup, I tried some settings because>I am sure one of the setting it is the right answer also this time, I>will pursue it!
The Test 1 is the old High Frequency setting. I only changed the name!
The actual High Frequency Setting does not work so good as the old one
but doesn't has spikes.
Regards Hayo
Hi, here some fixes.
> Again for the FFT when You switch to Display in order to change> graticule's dimension, then Grid up to 100% without intensity change and> turning the knob the grid's intensity increase but never is possible to> set it down, it is stuck until perform default setting: please look at> screenshot FFT Grid Level.jpg.
Solved
> About the Quick Measure I noticed when some values are below certain> levels then zero is showed: is not possible to increase recognized level> in order to show a more low level?
Solved -> measuring is now possible with pico second resolution.
- Holdoff now is switched off at pulse width triggering
Hayo
moin moin Hajo & Co.
wenn du die Y pos auf die 2. unterste Linie stellst
und dann utility/calib. offset ausfuerst und dann mit
Y pos. fast ganz nach oben wanderst verdoppelt (ca.)
sich das dargestellte Rauschen ;(
ungekehrt ist der efekt aber ebebso (kalibrate ganz
oben).
vielleicht kann das mal noch jemand testen ob das
generell oder nur bei meinem so ist
vlG
Charly
Hi Charly,
> wenn du die Y pos auf die 2. unterste Linie stellst> und dann utility/calib. offset ausfuerst und dann mit> Y pos. fast ganz nach oben wanderst verdoppelt (ca.)> sich das dargestellte Rauschen ;(
Stimmt, das war schon immer ein kleines Problem, also auch bei meinem
Welec (2022A)!
> ungekehrt ist der efekt aber ebebso (kalibrate ganz> oben).
Stimmt auch!
Das kommmt daher, das dann die Nulllinie nicht hinterher kommt.
Ist die Linie ganz unten, sitzt Diese ca. 2 Pixel unter Null, umgekehrt
dann 2 Pixel darüber und das Rauschen nimmt ebenfalls zu, weil dann die
Kalibrierung für oben u. unten nicht mehr stimmt.
> vielleicht kann das mal noch jemand testen ob das> generell oder nur bei meinem so ist
und nein, das ist nicht nur bei dir so!
Das war aber in der Vergangenheit schon mal Thema, frag' mich jetzt blos
nicht, wo das mal war...
> vlG> Charly
Gruß Michael
Stimmt bei Euch die Nulllinie nicht? Muß ich da die Skalierung noch
anpassen? Ich dachte eigentlich das passt ganz gut. Habt Ihr die
Eingangswiderstände modifiziert oder so?
Gruß Hayo
Hi Hayo, Rainer W., charly, Michael D., and guys all!
Hayo W. schrieb:
>Solved
Hayo, thank You very much for the fix: RESPECT!
Hayo W. schrieb:
>Solved -> measuring is now possible with pico second resolution.
Oh boys, this is really incredible and make me very happy!
Hayo You are the best one, no words: RESPECT!!!!!!!
I must to say the Welec oscilloscopes are a lot improved and now their
are can compete with other blasonate DSO's brands on the market.
Today I finally managed to complete some measures with the sole help of
my W2022A without necessarily having to use other tools.
All this thanks to your great work Hayo and all who are involved in the
Welec project, so I thank all You again: RESPECT!!!!!!!
Hayo W. schrieb:
>The Test 1 is the old High Frequency setting. I only changed the name!>The actual High Frequency Setting does not work so good as the old one>but doesn't has spikes.
Great news, thank You very, very much Hayo!
Also this information aid me very much, now I know what is the better
choice even without necessarily take a look at all the options.
This is amazing for me also because I have not all the necessary
strumentation in order to investigate the matter.
Perhaps is not it better return the name?
Anyway thank You again Hayo: RESPECT!
@Rainer W.
Selbst wenn ich zu spät Ich erwidere den schönen Sonntag. :-)
I hope to have been understood. :-)
@charly, Michael D.
Sorry but I do not understand very well.
I even have a W2022A and maybe I can check it, so please can You explain
me what is the problem?
Thanks!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Hi Hayo and guys all!
@Hayo
Maybe I found a little bug in a 1.2.BF.4.8C2 firmware.
Setting channel delay in Hardware menu, values are not update by rotary
knob but only by push the buttons, but still on this by changing the
other delay's channel then get corruption on the screen's tag.
DSO is W2022A.
Mit freundlichen Grüßen,
Luc
@Hajo
nullinie stimmt schon, nur das rauschen verdoppelt sich,
i werd mal versuchen es mit bilder darzustellen sobald
i a bissel zeit habe (im moment muss i auch softw. f.
einen kunden anpassen)
@Luc
i will post a few pics so fast as possible
vlG
Charly
Hallo Hayo (und Huckepack-Platinenkunden),
nach etwas Pause (andere Projekte...) habe ich mir am Wochenende die
aktuelle Version von Hayo gesaugt, um für die nun in Alphaversion
unterstützte Eingangsplatine die Kalibrierwerte in der Software zu
ermitteln. Hier die dafür nötigen Code-Änderungen. Meine Basis ist die
Version 1.2.BF.4.8C2.
Erst tat sich praktisch nichts, die Platinen wurden nicht sinnvoll
initialisiert. Als Ursache habe ich mein zu straffes Timing gefunden,
das war grenzwertig. Mitunter war das FPGA mit seinem SPI-Transfer noch
nicht fertig wärend ich die nächste Flanke anfordere, es wurden Bits
verschluckt. Also bitte anpassen, in Zeile 41 von tc_vars.h:
1
#define SPI_DELAY16 175 // >150 us for shifting out a 16 bit value
Zur Sicherheit habe ich in hardware_t.cpp in Zeile 2908 die
Rest-Warteschleife durch folgenden Block ersetzt:
1
if((15000-49*SPI_DELAY16)>SPI_DELAY16)// if there's still more time to kill than the shift time
2
{
3
Sleep_us(15000-49*SPI_DELAY16);// wait for SPI shifting it out, plus remaining relay settling time
4
}
5
else// minimum time
6
{
7
Sleep_us(SPI_DELAY16);// wait for SPI shifting it out
8
}
Das ist falls jemand SPI_DELAY16 so groß definiert, das die Relay
Settling Time bereits erreicht wird. Sonst warten wir für eine negative
Zeit, das könnte u.U. sehr lange dauern... ;-)
Das if() kann bereits der Compiler auswerten, kostet also nichts.
So, nun konnte es an die Kalibrierung gehen. Ich habe die letzte Spalte
für ScaleFactor[] und DAC_ScaleFactor[] per DC-Messung an einem Kanal
ermittelt. Hoffentlich ist die Streuung gering.
In tc_vars.cpp ab Zeile 1084:
(Code bei Sourceforge aktuell halten wäre cool, das erspart uns beiden
diese Handarbeit.)
Das mögen noch nicht die endgültigen Werte sein, aber zumindest schon
mal eine Ausgangsbasis.
Es bleibt noch ein Offset-Problem. Mit der automatischen Kalibrierung
kriege ich das Ding nicht auf Null. Vielleicht entartet irgendwo die
Numerik, die neuen Faktoren sind ja schon recht anders. In den 5er
Bereichen ist die Signallinie ca. 1 Kästchen höher als die DC-Marke, in
den 2er Bereichen ca. 3 Kästchen, in den 1er Bereichen gut 5,5 Kästchen.
Hmm, ich bemerke gerade ein sehr seltsames Verhalten: Der Offset-Regler
von Kanal 3 beeinflußt den Offset von Kanal 4, und zwar gegensinnig. Für
Kanal 3 hingegen ist der Regler wirkungslos. Damit kriege ich immerhin
meinen zur Messung verwendeten Kanal 4 auf Null. Hat noch jemand aktuell
so eine Wechselwirkung, oder spinnt meine Hardware?
Grüße,
Jörg
Jörg H. schrieb:> Hat noch jemand aktuell> so eine Wechselwirkung, oder spinnt meine Hardware?
Beim W2024 ohne Hardwareumbauten funktioniert die Offseteinstellung für
alle 4 Kanäle ohne Seiteneffekte.
Hast du den obligatorischen Default Setup (Utility) durchgeführt?
Gruß
Rainer
Hallo Jörg,
deine Probleme interessieren uns nicht die Bohne. :-))
Wir wollen wissen, wie es mit der Huckepackplatine aussieht!
Hast du HF-Messmöglichkeiten? Ich meine ja, sonst müssten wir
noch etwas unternehmen.
Grüße, Guido
@Guido
>deine Probleme interessieren uns nicht die Bohne. :-))>Wir wollen wissen, wie es mit der Huckepackplatine aussieht!
ich nehme an, dass Du das lustig gemeinst hast was Du da in 'unserem'
Namen geschrieben hast, diese Art kannst Du aber m.E. -so- ruhig stecken
lassen.
Guido schrieb:> deine Probleme interessieren uns nicht die Bohne. :-))>> Wir wollen wissen, wie es mit der Huckepackplatine aussieht!
Oder war das etwa eine Anspielung auf mich...?
Soweit ich weiß, wurden die HF alle Messungen (vor langer Zeit)
erfolgreich von branadic durchgeführt und auch gründlich dokumentiert.
Jörg befasst sich nur noch mit dem Einbau und der Ansteuerung in der
Firmware. Außerdem gab es noch ein kleines ESD Problem, dass noch
geklärt werden muss.
Mfg,
Kurt
Robert schrieb:> ich nehme an, dass Du das lustig gemeinst hast
Na klar, deshalb auch der Smiley hintendran. Ich denke Jörg wird das
schon richtig verstehen. Ich glaube aber nicht, dass ich der einzige
bin, der sehr gespannt erwartet, was Walters und Branadics Werk in
der Praxis bringen. Jörg ist schließlich der Erste, der es zur
Funktion bekommt.
Luc schrieb:> Maybe I found a little bug in a 1.2.BF.4.8C2 firmware.> Setting channel delay in Hardware menu, values are not update by rotary> knob but only by push the buttons, but still on this by changing the> other delay's channel then get corruption on the screen's tag.> DSO is W2022A.
Oh man, how did You make it? I tried hard but all is ok, except the gray
turn arrows which appear on the empty two places after pushing the
button 1 or 2.
Hayo
Hui, hier ist ja was los. Passt schon, keine Empfindlichkeiten.
Das mit dem Geister-Offset muß ich mir also nochmal auf meiner Hardware
anschauen.
Ansonsten ist jetzt langsam der Zeitpunkt gekommen, wo auch andere Leute
sich die Platinen einbauen können. Dann gibt es auch mehr Erfahrungen
damit. Wohlmöglich sogar von Leuten, die das Oszi praktisch einsetzen
(ich gehöre nämlich noch nicht dazu).
Was ich weiterhin noch schreiben wollte:
Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man
die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung
bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren
Bereichs noch sinnvolle Meßwerte, die ADCs sind auch dort noch nicht in
Vollaussteuerung. Ich nehme an, das ist nicht so gewollt. Wir
verschenken also sichtbare Auflösung und zeigen auch unnötig großes
Rauschen.
Der Chip auf der Eingangsplatine hat eine programmierbare Verstärkung,
wir können die also reduzieren und recht fein aufeinander abstimmen.
Ich habe kein HF-Equipment (und auch wenig Ahnung davon). Kann sein, daß
da auch noch was zu holen ist. Die Rechtecke des Testgenerators haben
mit 1:10 Tastkopf etwas schräge Dächer. Vielleicht ist da noch was
suboptimal, oder ich sollte am Tastkopf drehen.
Grüße
Jörg
Jörg H. schrieb:> Ansonsten ist jetzt langsam der Zeitpunkt gekommen, wo auch andere Leute> sich die Platinen einbauen können. Dann gibt es auch mehr Erfahrungen> damit.
Ich komme erstmal nicht dazu weil ich nächste Woche im Urlaub auf
Sardinien bin.
> Was ich weiterhin noch schreiben wollte:> Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man> die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung> bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren> Bereichs noch sinnvolle Meßwerte,
Das ist bei den original Eingangsstufen leider auch so. Wenn man die
Verstärkung so umprogrammieren könnte, dass Fullscale knapp über
Gridhöhe liegt, dann wäre das auf jeden Fall sehr sachdienlich.
Allerdings müßten dann die Scalefaktoren noch mal angepasst werden.
Gruß Hayo
@Luc & all others
>> When QM is on, changing Time Base sometimes get corruption on the screen>Yes I noticed this too and I'm searching for the reason. I hope I can>fix it soon.
Unfortunately I wasn't able to reproduce this problem. Has anyone an
idea how to force this error? Otherwise it is a littlebit difficult to
analyze the problem.
Regards Hayo
Hayo W. schrieb:>> Was ich weiterhin noch schreiben wollte:>> Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man>> die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung>> bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren>> Bereichs noch sinnvolle Meßwerte,>> Das ist bei den original Eingangsstufen leider auch so. Wenn man die> Verstärkung so umprogrammieren könnte, dass Fullscale knapp über> Gridhöhe liegt, dann wäre das auf jeden Fall sehr sachdienlich.
Ah so, das ist also nicht gewollt. Hätte ja auch Vorbereitung für hohe
"Crestfaktoren" oder tolerante Ablesung sein können. Vielleicht habe
mich an der Originalverstärkung orientiert, vielleicht auch nur
irgendwas für 1-2-5 Abstufung reinprogrammiert und nix dabei gedacht.
;-)
Kann man in irgendeinem Debugmodus die Rohwerte der ADCs ablesen?
> Allerdings müßten dann die Scalefaktoren noch mal angepasst werden.
Das ist klar. Wie ich schon sagte, obiges ist der erste Wurf.
Jörg
Hallo Jörg,
das mit der Verstärkung haben wir früher schon diskutiert. Es wäre auch
im Original leicht möglich diese besser auf die ADCs anzupassen, aber
auf
Kosten von Bandbreite (erheblich) und Rauschen.
Grüße, Guido
1.2.BF.4.8C2
>Unfortunately I wasn't able to reproduce this problem. Has anyone an>idea how to force this error? Otherwise it is a littlebit difficult to>analyze the problem.
Maybe it's for the same reason as this one:
Press Utility -> Default Setup
wait until screen is redrawn
change Time Base
=> for a short time there is a problem sightable in the first horz.
Gridline.
Robert
Hi Hayo, Rainer W., Robert and guys all!
Hayo W. schrieb:
>> Maybe I found a little bug in a 1.2.BF.4.8C2 firmware.>Oh man, how did You make it? I tried hard but all is ok, except the gray>turn arrows which appear on the empty two places after pushing the>button 1 or 2.
I simply try to adjust the delay between the two channels of my W2022A
but sometime by the rotary knob does not work, it works only by buttons.
While this happens if I try to change the delay of one of the two
channels, tags on the screen show itself corrupt.
Hayo,please take a look at the screenshot.
@Rainer W.
Rainer, apologize me.
For this time I beg You to bear me, the screenshot is only one. ;-)
Hayo W. schrieb:
>>> When QM is on, changing Time Base sometimes get corruption on the screen>>Yes I noticed this too and I'm searching for the reason. I hope I can>>fix it soon.>>Unfortunately I wasn't able to reproduce this problem. Has anyone an>idea how to force this error? Otherwise it is a littlebit difficult to>analyze the problem.
As I already wrote, for me the bug seemed to gone by installing the last
1.2.BF.4.8C2 firmware release, but unfortunately it is not: it is like
Robert says.
Anyway the trouble manifested itself simply by changing the Time Base
and/or the vertical amplitude when QickMeasure is on, it show itself
like in my previous screenshots.
Mit freundlichen Grüßen,
Luc
@Robert
Danke für den Hinweis. Ich probiere das morgen mal aus.
Luc schrieb:> I simply try to adjust the delay between the two channels of my W2022A> but sometime by the rotary knob does not work, it works only by buttons.> While this happens if I try to change the delay of one of the two> channels, tags on the screen show itself corrupt.
Hmm, really strange. On my DSOs it works and I can't reproduce the
Problem. I will try to find it...
@all -> has anyone the same problem?
> As I already wrote, for me the bug seemed to gone by installing the last> 1.2.BF.4.8C2 firmware release, but unfortunately it is not: it is like> Robert says.> Anyway the trouble manifested itself simply by changing the Time Base> and/or the vertical amplitude when QickMeasure is on, it show itself> like in my previous screenshots.
I will try it tomorrow once again.
Thanks Hayo
Jörg H. schrieb:> Kann man in irgendeinem Debugmodus die Rohwerte der ADCs ablesen?
Ja, kann man. Muß ich aber erst raussuchen. Poste ich morgen.
Gruß Hayo
Oops, ich muß mich korrigieren:
Jörg H. schrieb:> Die Ansteuerung kann man vermutlich noch insofern optimieren, daß man> die Bildschirmhöhe und die Aussteuerung der ADCs mehr zur Deckung> bringt. Im Moment kriege ich auch recht weit außerhalb des sichtbaren> Bereichs noch sinnvolle Meßwerte, die ADCs sind auch dort noch nicht in> Vollaussteuerung.
Das hatte ich mit den alten Skalierungsfaktoren beobachtet.
Ich habe es nun mit den aktuellen Faktoren nochmal überprüft: Die
Aussteuerung ist perfekt, die Sättigung beginnt kurz hinter der Skala
(ca. 20% drüber).
Besser kann man das nicht machen. Man könnte den Eindruck haben, die
Entwickler der Eingangsplatine haben sich bereits was dabei gedacht.
;-))
Nochmals Entschuldigung für die Panik,
Jörg
@Luc
As promised I checked the better settings for dso frequency response.
The accuracy I can guarantee is 0,1 dB up to 8GHz,using generators and
power meters with internal alc and selftest, low loss cable and
termination at 50 ohm.These are HP,Tektronix,Wiltron..test instruments
is my job.
Anyway I tested W2022A, FW 1.2BF 4.8C2 HW with no modifications, up to
100 MHz.
To have a good, flat frequency responce, better is:
ADC setup=factory Pregain=1.25 Noise filter= IIR stage1
Trigger now works better than version 2.6 , very nice the last FW
modifications, let’s say firmware improve the hardware limit of our
DSO,proud to have the best of its class.
Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to
have it.
Thanks and regards
Sandro
Sandro(Alex) schrieb:> Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to> have it.
Hi Sandro, how should it look like? Can You explain a little bit or post
a modified screenshot.
Regards Hayo
Hi Hayo,
enclosed you'll find the image,pushing one menu key a dot goes to the
maximum peak on the screen,then display frequency and level.
Regards,
Sandro
>@all -> has anyone the same problem?
W2022A 1.2.BF.4.8C2
Two Gray arrows: Same here
> Setting channel delay in Hardware menu, values are not update by rotary> knob but only by push the buttons,
Well this is a little bit different here Luc/Hayo
Utility -> More -> CH1 Delay
Press button to next value -> no Update in the below line.
Value still the same as before. You may press thru all values, no
changes in the bottom line.
Using the rotary knop -> all ok then, values are changing.
This is the same for CH2 Delay.
Scope turned off and on, same problem with CH-Delay as before.
Robert
@Luc
You where right, I found it and fixed it. ;-)
But I couldn't reproduce the problem with the delay popup. Is it also
present on the DSO of Your friend?
@all
Die gemeldeten Probleme sollten erledigt sein. Leider mußte ich für die
Lösung des QM-Cursorproblems die beschleunigte Timebase und
Spannungsverstellung wieder rückgängig machen, da diese mit dem
Interrupthandler die Cursorausgabe abgewürgt hat und so die Cursorreste
auf dem Bildschirm produziert hat.
Hat jemand von Euch auch das Problem von Luc mit den Delay-Popups? Bei
mir funktioniert das alles einwandfrei.
Gruß Hayo
Hi Hayo, Robert, Sandro(Alex) and guys all!
Hayo W. schrieb:
>You where right, I found it and fixed it. ;-)
As always I thank You very much Hayo for the great job and free time You
provided generously to us!!!
Great work, no words... RESPECT!!!!!!!
Hayo W. schrieb:
>But I couldn't reproduce the problem with the delay popup. Is it also>present on the DSO of Your friend?
Hayo do not worry because seems to me by installing latest 1.2.BF.4.9C2
version problem is gone!
I have tried to replicate the problem but with the 1.2.BF.4.9C2 I am
unable to get it, for a very short time can happen there is corruption
in the tags, but they settle themselves quickly when screen is
refreshed, hard to see now if You deliberately do not pay attention!
Really an amazing and great job: RESPECT!!!!!!!
Anyway, going to answer to your question, yes the problem was also with
my friend's W2012A.
The two oscilloscopes are like follow:
W2022A 8C7.0C
W2012A 8C7.0B
@Hayo
Hayo thank You so much also for the rewriting of the ADC's Setup menu,
for me very very useful: RESPECT!!!!!!!
@Robert
Press thru all values but no changes in the bottom line sometimes
happens to me too.
Robert, thanks for reporting!
Sandro(Alex) schrieb:
>Only a hint ,is useful to have a marker peak on FFT,may be Hayo like to>have it.
Sandro, I agree too.
It is roughly the same I meant when I asked for the centre and span
features for the FFT.
@Sandro(Alex)
Very impressive instrumentations, congratulation Sandro!
I have a unmodified W2022A too, but unfortunately I have not a calibrate
signal's I prefer to use ADC Setup= High Frequency 2, Pregain=1.25 and
no filters.
The W2022A is visibly better than the W2012A.
Because I have not a calibrate signal's generator I usually compare
between the two by measuring a very fast 300pS pulse.generator.
Seems to me the unmodified W2022A can easy reach up 150MHz but maybe I
am wrong.
Sure the linearity is not the best but I believe the 150MHz perhaps are
workable.
If I am not wrong in the Hardware Forum Hayo and others put some
screenshots where the W2022A were good at 140MHz, seems to me it were a
resistors modified W2022A.
I am enough interested about the Welec DSO's bandwidth.
I read You use Noise filter= IIR stage1 when You make your measurements,
but does not this introduce a bandwidth reduction? (IIR 1 Stage ca. 70 -
80Mhz IIR-filter with 1 stage and coefficient 0.5)
Seem to me it bit introduce a offset level, too.
Is not Smooth filter better for the purpose? (Smooth ca. 80 - 90Mhz ->
in all other TB cutoff frequ. is half sample rate that means lossless!)
However I believe no filter is better choice when bandwidth is under
test.
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
@Luc
With the ADC high freq setting you have an overshoot in frequency
response,this the reason because you can go over 150 MHz
with an input stage that is hardware bandwidth limited,you may see the
datasheet.
High freq.-> the flatness isn't the best in the whole frequency range.
IIR1 limits the bandwidth,but compensate the Pre gain 1.25
Accurate measure up to 100 MHz with this setting
ADC setup=factory Pregain=1.25 Noise filter= IIR stage1 /smooth filter
With no filter e high freq setting ADC goes in saturation with your
settings,try to change the vertical sensitivity to see it,not suggested
for sine wave.
Let's wait for the improvement in the other features of the firmware,
than we may do together a DSO specifications datasheet.
@Hayo
Thank you,I am available for further details
@ all
Have a nice day
Sandro
Hi Sandro(Alex) and guys all!
Sandro(Alex) schrieb:
>With the ADC high freq setting you have an overshoot in frequency>response,this the reason because you can go over 150 MHz
Sandro, what You write is of course correct.
Due the fact I read about it, I know there is a linearity lack on the
Welec's DSO when I performed the measures.
Without the Piggyback board the only cure is to change some line and
termination's resistors for the MAX121.
Due this issue I subsequently opted for a pulse generator to evaluate
the bandwidth, because linearity lack make difficult the measures.
Sandro(Alex) schrieb:
>with an input stage that is hardware bandwidth limited,you may see the>datasheet.
Yes, of course I agree but You mean the filter bandwidth, not the
oscilloscope one.
Specifications says about 70-80Mhz bandwidth for IIR 1 Stage and about
80-90Mhz bandwidth for Smooth filter.
I wanted to try evaluate real DSO's bandwidth.
I know the W2022A is better of the W2012A, if I use the same filter then
the performances are identical on both the DSOs and this make no sense
for my purpose.
Anyway, if even there is an overshoot, I can observe the differences
between the two DSO.
I know it is no much and it is not formally correct, but this is better
than nothing.
However, during the firsts attemps I tried with Factory's ADS Setup even
if this no change much the things.
Sandro(Alex) schrieb:
>High freq.-> the flatness isn't the best in the whole frequency range.
Due of the overt linearity lack caused by wrong gain setting of the
MAX121.
Sandro(Alex) schrieb:
>IIR1 limits the bandwidth,but compensate the Pre gain 1.25
I did not know this, thanks for saying it to me!
Sandro(Alex) schrieb:
>Accurate measure up to 100 MHz with this setting>ADC setup=factory Pregain=1.25 Noise filter= IIR stage1 /smooth filter
Anyway, I think the Smooth filter is better than the IIR stage 1, also
under the aspect of the bandwidth's response.
Sandro(Alex) schrieb:
>With no filter e high freq setting ADC goes in saturation with your>settings,try to change the vertical sensitivity to see it,not suggested>for sine wave.
I understand the overshoot matter, but not about the vertical
sensitivity issue.
Can You kindly explain to me?
I used a no professional sine wave's generator up to 170MHz, it has no a
calibrated level output but both unmodified W2022A and W2012A can show
the waveforms on their screen.
Also, unfortunately the output of the my RF wave generator is not
adjustable.
Glad to read You again, Sandro.
Thank You very much for your report!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Hi Luc and Sandro,
just a little hint to check out the effect of the software filters and
the bandwidth limiter.
Take a signal with fast rise time and activate QM with the option "Rise
Time". Switching through the filters You will see how the rise time is
affected by the different filters. This is easy to do and shows very
impressive how much bandwidth is cut off by the filters.
Regards Hayo
Rainer W. schrieb:> Korrektur:> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits.> Solange die Summe der beiden Werte für die Länge des> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder> gar (>187, <100) einstellt.> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und> dann
Hallo Rainer,
ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen.
Das schau ich mir nochmal an! Da läßt sich sicher etwas machen.
Gruß Jürgen
Hi Hayo and guys all!
@Hayo
Yes, that is what I did and it is because I say the better choise is to
disable any filter when trying to evaluate the DSO's bandwidth.
In fact it is very simple to make the test, because stopping the DSO
then it is easy to view how filters act by changing the filters setup.
Hayo, thank You very much for your suggestion!
Vielen Dank!!!!!!!
Mit freundlichen Grüßen,
Luc
Schönen guten Abend,
habe jetzt ja das W2022 von Helmut auf dem Schreibtisch und wollte jetzt
das Update auf W2022A machen leider ist die Datei EPC16_W2022A.jcc nicht
mehr unter dem angegebenen Link zu bekommen. Hat einer von euch die
Datei noch auf dem Rechner?
Hoffe ihr könnt hier helfen.
Jan
Hallo,
Ich habe damals auch mal eine Wittig W2024 gekauft, aber bis jetzt nich
zu viel Zeit gehabt die auch zu gebrauchen.
Ich habe nun mal herumgeschaut, und gesehen das es bessere Software und
Hardware gibt.
Jetzt wollte ich gerne die Huckepack Platinen einbauen, aber konnte nich
finden ob die irgentwo zu kaufen sind.
Also die frage, kan ich die Platinen irgendwo kaufen, brauchen nicht
bestuckt zu sein, das kann ich mir selber machen.
Wann noch Firmware anderungen notig sind dafur, werde ich mich damit
auch gerne beschaftigen.
Grusse,
Gertjan.
(Niederlande, also entschuldige mein schlechtes Deutch.)
So, hab bis eben an der neuen Version gearbeitet. Das neue Feature wird
Euch gefallen.
Jetzt muß ich den Koffer packen und bin dann erstmal eine Woche auf
Sardinien.
Bis dann
Hayo
Hi,
schöne Grüße von Sardinien. Glücklicherweise gibts hier nen Hotspot, so
dass ich hier nicht ganz abgeschnitten bin.
Das neue Feature - was es ist wird noch nicht verraten, muß erstmal
sehen ob es funktioniert - ist etwas umfangreicher. Wenn ich wieder zu
hause bin werde ich noch etwas brauchen um es fertigzustellen.
@Gertjan
Willkommen in der Gemeinde :-)
Für die Unterstützung der Addon-Platine ist Jörg hier der
Ansprechpartner. Also bei Fragen zur Softwareansteuerung einfach direkt
an ihn wenden.
- und Dein Deutsch ist doch wirklich gut!
Gruß Hayo
Hayo W. schrieb:> schöne Grüße von Sardinien. Glücklicherweise gibts hier nen Hotspot, so> dass ich hier nicht ganz abgeschnitten bin.
Das hättest du zu Hause einfacher haben können ;-)
Bin gespannt, was du jetzt wieder an neuen Features ausheckst.
Schöne Tage am Mittelmeer.
Gruß
Rainer
Hallo,
unter
http://welecw2000a.sourceforge.net/docs/Hardware/Welec-Huckepack-Settings-ScaleFactors.xls
findet sich unterstützend zur Softwareentwicklung der Huckepackplatine
ein Tabellenkalkulation-Dokument, anhand dessen man die notwendigen
Einstellungen des LMH6518 und der Eingangsspannungsteiler ablesen und
die Software-Skalierungsfaktoren entnehmen kann.
Mit der Huckepackplatine stehen in allen bisherigen Vertikalablenkungen
224 bis 226 LSB zur Verfügung, der ADC ist also deutlich weiter und in
allen Bereichen bis auf ±1LSB gleich ausgesteuert. Damit wird auch das
Rauschen in den 1er und 2er Bereichen um Welten besser und in den 5er
Bereichen auch noch einmal um gute 10% besser.
Zum Vergleich, in den originalen Einstellungen waren es nur 131 LSB in
den 1er und 2er bzw. 204 LSB in den 5er-Bereichen.
Dies konnte durch die feste Verstärkung von G=1.25 des ersten
Verstärkers auf 163 LSB in den 1er und 2er-Bereichen verbessert werden,
was aber immer noch 20% weniger gegenüber den 5er Bereichen ist und
somit das deutlich größere Rauschen erklärt.
Diese einfache Gegenüberstellung zeigt noch einmal in eindrucksvoller
Weise was die Huckepackplatine zu leisten vermag.
Um das in allen bisherigen Vertikalablenkungen auch mal mit Zahlen
nachvollziehen zu können soll das Dokument zur Aufklärung beitragen.
Darüber hinaus besteht mit dem LMH6518 generell die Möglichkeit die
Vertikalablenkung fließend zu gestalten und nicht auf feste
Vertikalablenkungen in 1er, 2er, 5er-Teilung zurückgreifen zu müssen.
branadic
Jürgen schrieb:> Rainer W. schrieb:>> Korrektur:>> Es geht doch, allerdings mit mir völlig unverständlichen Zeitlimits.>> Solange die Summe der beiden Werte für die Länge des>> Pulstriggerfensters in dem gezeigten Fall gerade noch unterhalb von>> 287µs liegt, kriegt die Triggerfunktion den genau genommen 192µs langen>> Puls zu fassen. Es ist egal, ob man z.B. (<100, >187), (<140, >147) oder>> gar (>187, <100) einstellt.>> Einen komischen "Hystereseeffekt" gibt es, wenn man den ">"-Wert in der>> Nähe der Pulsdauer variiert, d.h. z.B. <50µs fest eingestellt hat und>> dann>> Hallo Rainer,>> ich konnte dies eben noch mal mit dem Probe Comp Signal nachvollziehen.> Das schau ich mir nochmal an! Da läßt sich sicher etwas machen.>> Gruß Jürgen
@Rainer
Ich hab mal wieder einen Blick zurück getan und die Lösung gefunden :-)
Als Anhang mal eine Probe für die Pulse Width Problematik. Du kannst ja
mal den Anhang ausprobieren, ob es so passt. Es fehlen allerdings noch
die gesamten Prüfungen zu den Eingabebereichen in der Firmware.
Gruß Jürgen